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.
-------------------------------
So, while having a single redo allocation latch may seem like a serious potential problem, for most Oracle systems, the problem can be solved entirely from an Oracle perspective. However, if you're responsible for one of those other Oracle systems, you may need something better.
When a single redo allocation latch is in use, which is the case prior to Oracle9i Release 2, the redo algorithm is very elegant and straightforward. But as Oracle systems continued to grow in concurrency and redo generation requirements, redo-related latch concurrency constraints started to become more likely. So, Oracle began making significant changes in the redo log buffer.
Oracle9i Release 2 and later have multiple redo allocation latches available, and the redo copy latches are normally not required. In summary, the redo log buffer works like this: A server process contends for one of the redo allocation latches, acquires one, allocates redo log buffer space, copies its redo into the redo log buffer, and releases its redo allocation latch. In more detail, it works like this:
©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.
|