Re: First 17 updated records disappeared from REDOLOG files .

  • From: Tanel Põder <tanel.poder.003@xxxxxxx>
  • To: <amit.poddar@xxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 22 Feb 2006 13:31:07 -0700

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.

Tanel.


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


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



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


Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 02-2006