I think I found the problem I mentioned above! My database uses Oracle Golden Gate and because of this I had to enable Database supplemental logging and this setting disable IMU, Am I right ?

After I read this paper http://www.teamycc.com/rmoug_2008_conference/PDF/Haisley.pdf I saw some restrictions that disable IMU and I was very sad!. I hope that in the next releases it can improve.

Thank you!

“I put the results on the link below to get better understanding. Sorry if this is not useful.”

http://pastebin.com/skFJ4ga8

Thank you

Remember that in all versions of Oracle the redo vectors are copied into the redo buffer before any blocks are changes. This is true in all versions of Oracle; but the sequence of the redo change vectors, and how they are combined into redo records changes in 10g.

OTN Thread “In Memory Undo”. – in this thread , you explaned very well ..and its really excellent
One question – the REDO /UNDO are generated (chaneg vectors are prepared) just before when Oracle is ready to change a block in “current mode”- is it correct ? (in ALL Version of oracle)

I mean

Oracle will get the block in current mode
preapre the change vectors for undo/data block
change the undo block in current mode
chnage the data block in current mode
commit

Thanks for your time ..

select 
	indx, ptr_kcrf_pvt_strand, strand_size_kcrfa 
from 
	x$kcrfstrand
;


      INDX PTR_KCRF STRAND_SIZE_KCRFA
---------- -------- -----------------
         0 00                 3494400	public
         1 00                 3494400
         2 20F27C80             66560	private
         3 20F38080             66560	
         4 20F48480             66560
         5 20F58880             66560
         6 20F68C80             66560
         7 20F79080             66560
         8 00                   66560	dynamically disabled
         9 00                   66560
        10 00                   66560
        11 00                   66560

If you look at x$ktifp you can see information about the undo buffers, including the address of the buffer and the address (when it’s in use) of the associated private redo buffer. In this example I’ve got one live transaction that has inserted three rows of about 2,000 bytes each into a table, one row at a time. The query shows the start, “current highwater” mark and usage – for the 10 IMU buffers, with one buffer showing the same information for the associated redo buffer. Notice how the redo buffer usage is about 8K while the undo buffer usage is about 1KB:

select
	ktifpno,
	ktifpxcb				tx_addr,
	ktifpupb				undo_start,
	ktifpupc				undo_cur,
	to_number(ktifpupc,'XXXXXXXX') -
		to_number(ktifpupb,'XXXXXXXX')	undo_usage,
	ktifprpb				redo_start,
	ktifprpc				redo_cur,
	to_number(ktifprpc,'XXXXXXXX') -
		to_number(ktifprpb,'XXXXXXXX')	redo_usage
from
	x$ktifp
order by
	ktifpno
/

   KTIFPNO TX_ADDR  UNDO_STA UNDO_CUR UNDO_USAGE REDO_STA REDO_CUR REDO_USAGE
---------- -------- -------- -------- ---------- -------- -------- ----------
         0 00       20FCB800 20FCB800          0 00       00                0
         1 20EFB500 20FDC400 20FDC7E8       1000 20F38080 20F3A21C       8604
         2 00       20FED000 20FED000          0 00       00                0
         3 00       20435000 20435000          0 00       00                0
         4 00       20445C00 20445C00          0 00       00                0
         5 00       20456800 20456800          0 00       00                0
         6 00       20467400 20467400          0 00       00                0
         7 00       20478000 20478000          0 00       00                0
         8 00       20488C00 20488C00          0 00       00                0
         9 00       20499800 20499800          0 00       00                0

Just to demonstrate that the undo and redo buffers really are separate, and the “redo for the undo” doesn’t go into the redo buffer. This is what I get after I commmit, and then start a new transaction that deletes those three rows:

   KTIFPNO TX_ADDR  UNDO_STA UNDO_CUR UNDO_USAGE REDO_STA REDO_CUR REDO_USAGE
---------- -------- -------- -------- ---------- -------- -------- ----------
         0 00       20FCB800 20FCB800          0 00       00                0
         1 20EFB500 20FDC400 20FDF218      11800 20F38080 20F38428        936
         2 00       20FED000 20FED000          0 00       00                0
         3 00       20435000 20435000          0 00       00                0
         4 00       20445C00 20445C00          0 00       00                0
         5 00       20456800 20456800          0 00       00                0
         6 00       20467400 20467400          0 00       00                0
         7 00       20478000 20478000          0 00       00                0
         8 00       20488C00 20488C00          0 00       00                0
         9 00       20499800 20499800          0 00       00                0

Notice how the undo buffer has now used 11KB while the redo buffer has used only 1KB.

In passing, you may think that the volumes recorded in these structures are larger than seems necessary. You’d be right (in a way): there are overheads in these buffers that do not get copied into the redo log or undo blocks so, for example, after I committed the insert my session showed the following related stats:

Name                                                 Value
----                                                 -----
redo entries                                             1
redo size                                            6,944      -- not 8,604

undo change vector size                                256    -- not 1,000
IMU commits                                              1
IMU undo allocation size                             1,000