You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
IMU structures reside-you guessed it-in the shared pool. As we know, when we care about memory structure access serialization, a control structure is required. Oracle chose to create a number of IMU latches, which, as you will learn soon, allow for the possibility of IMU latch contention.
With a couple of good figures for reference, understanding how both traditional undo and IMU work is very straightforward (at least at this abstracted level). Visually comparing Figure 7-16 (traditional undo management) and Figure 7-17 (IMU management), you can immediately see a significant difference. In Figure 7-17, there is the absence of undo segment activity until the transaction commits at time T4. And just as important, the multiple IMU nodes have been consolidated (not deallocated and officially called collapsed) into a single undo segment buffer 310. Here, I will walk you through this process.
Using Figure 7-16 as our reference, let's take a close look at how traditional undo management works.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|