Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: First 17 updated records disappeared from REDOLOG files .

Re: First 17 updated records disappeared from REDOLOG files .

From: Tanel Põder <>
Date: Wed, 22 Feb 2006 13:31:07 -0700
Message-ID: <041801c637ee$e9d25e60$0400a8c0@porgand>

> 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?

Yes, but instead of pinning/unpinning blocks and getting releasing several buffer cache related latches every time you want to generate some more undo you can have your own private memory area, protected by a latch which doesn't have contention by much anyone else. So, you generate undo 10 times, efficiently and then flush once.

> 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 ?

Again, the benefit comes with each session having it's own redo allocation latch, thanks to private memory areas. Before private strands we had to satisfy just with split redo log and few redo allocation latches. Before 9i we had to satisfy with only one redo log buffer area protected by single redo allocation latch.

Brief testing shows that for commit redo allocation latches of all shared strands and only the committed transaction's binded private redo strand have to be gotten. I started another transaction before starting the to be committed transaction and it seemed that the first strand was untouched. When the second strand commits, it's contents are written to logfile. Starting from 9i the redolog contents don't have to be physically ordered, so it is ok to have redo with smaller SCNs coming after bigger SCNs.


> thaks
> amit
> At 03:29 AM 2/22/2006 -0700, Tanel Põder wrote:
>>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
>>You can see the IMU stuff in shared pool:
>>SQL> select * from v$sgastat where name like 'KTI%';
>>------------ ---------------------------------------- ----------
>>shared pool KTI latch structure 1000
>>shared pool KTI-UNDO 686280
>>shared pool KTI pool states 12
>>shared pool KTI latches 160
> --

Received on Wed Feb 22 2006 - 14:31:07 CST

Original text of this message