IMU or In-Memory Undo

* Good references is Craig Shallahamer's paper "All About Oracle's In-memory undo"
www.oracle.com/education/america_eblasts/fy09/q1/craig_shallahamer_all_about_oracle_s_in_memory_undo.pdf

* Related patent "Method and mechanism for implementing in-memory transaction logging records" 
www.freepatentsonline.com/6981004.html

* Main parameter is _in_memory_undo. But the value true doesn't mean IMU is enabled. For instance, "turning supplemental logging on disables IMU", regardless this parameter (See Note:428167.1). Also, in RAC, IMU is disabled too.

* Statistics related to IMU are all named like 'IMU%'

* There's latch "In memory undo latch", which has its children.

* Steve Adams, "some redo generation will not be seen in the stats for the session responsible"
www.freelists.org/archives/oracle-l/01-2008/msg00000.html

* http://www.itpub.net/thread-323700-3-1.html, #msg 23 and down

* According to Craig Shallahamer's paper, current IMU memory allocation in shared pool has a name "KTI-UNDO". I'm not sure what "I" in "KTI" means, maybe in-memory. (Not sure because Oracle code has functions called ktiNonImuPool(Allocate|Free) in addition to ktiImuPool(Allocate|Free). See Yurichev's Oracle function list at conus.info/oracle/oracle-10.2.0.4-linux/kti.txt) 

Things related to KTI are 
(a) event 30047; 
(b) lock type IM (see v$lock_type);
(c) fixed tables:
X$KTIFB
X$KTIFF
X$KTIFP
X$KTIFV
When IMU is used, you'll see non-zero numbers in KTIFFFLC column of X$KTIFF (e.g. "Commit flushes" goes up by 1 every 5 seconds). As soon as you turn off IMU by setting _in_memory_undo to false with alter system, these tables are emptied. But when you set it back to true, the original numbers are shown again and "Commit flushes" was still incrementing, as long as you didn't bounce the database in between.

* It's not clear to me whether Craig's article or the quoted patent answers the question whether redo size will be reduced with IMU. The patent says "A benefit of this approach [i.e. IMU] is that it significantly reduces the costs for writing redo information to disk, since the entire set of redo information items can be written as a large block or as a single record, rather than requiring separate I/O operations for writing individual redo records." It means with IMU, multiple otherwise smaller redo writes can be bundled into a larger one. But it doesn't say if the total redo size in bytes is different. I suppose if this bundling action reduces 'redo wastage', then the total redo size will really be reduced.

I did a small test with and without IMU. The session statistic 'redo size' doesn't appear to be consistent in different runs. Maybe my data change is too small.