Re: First 17 updated records disappeared from REDOLOG files …

Tanel,

but even in memory undo has to be flushed the undo blocks some time. When oracle flushes IMU to the undo blocks then it would need all those latches and pins. So where is the advantage with IMU?

Same with redo strands. The redo generated in those private redo strands has to be flushed after a commit. So does that mean LGWR needs to get all the latches protecting this redo strands when writing ?

thaks
amit

At 03:29 AM 2/22/2006 -0700, Tanel Põder wrote:
>Hi,
>
>That's in-memory undo (10g new feature), which is fooling logminer.
>Logminer probably can't handle all new structures in redologs yet
>(hint-hint: logical standby and streams ;)
>
>Try to set _in_memory_undo=false in your session and try again, you should
>get all records now.
>
>Stop reading here if you're not interested how Oracle10g achieves extreme
>scalability for OLTP transactions ;)
>
>IMU anticipates small transactions, relieving us from excessive CBC latch
>gets and undo segment buffer pinning. We can generate the undo into a
>preallocated shared pool area (number of pools is controlled by _imu_pools
>parameter).
>
>You can see the IMU stuff in shared pool:
>
>SQL> select * from v$sgastat where name like 'KTI%';
>
>POOL NAME BYTES
>------------ ---------------------------------------- ----------
>shared pool KTI latch structure 1000
>shared pool KTI-UNDO 686280
>shared pool KTI pool states 12
>shared pool KTI latches 160

--
http://www.freelists.org/webpage/oracle-l