Craig Shallahamer's Blog
|
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.
Please—Out 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.
-------------------------------
<p>The promotion cutoff is a shockingly low value of 2 (_db_aging_hot_criteria). So when a server process or a database writer asks, "What's your touch count?" it's actually asking, "Is your touch count greater than or equal to _db_aging_hot_criteria?" As long as a buffer gets touched every few seconds, it should remain in the cache; if not, it could be quickly subjected to replacement.
p><p>When a popular buffer is promoted, life only gets more difficult. Part of the promotion is the touch count is reset to zero (_db_aging_stay_count). This occurs unless the buffer is a segment header or a consistent read (CR) buffer. So while a buffer may feel like a rock star one second, the next second, it must once again prove its worth to remain in the buffer cache.
p><p>The database writers can also promote popular buffer headers. When a database writer is inactive, it wakes up every 3 seconds. Each database writer has its own write list (dirty list) and is also associated with one or more LRU chains. When an LRU chain's database writer wakes up, it checks its write list to see if it is long enough to warrant an IO write. If the database writer decides to build up its write list, it will scan one of its LRU chains looking for unpopular dirty buffers. Much like the server process looking for free buffers, the database writer will acquire the associated LRU chain latch, start at the LRU end of the LRU chain, and check if the buffer header is both dirty and not popular. If an unpopular dirty buffer is found, the database writer will move the buffer header from the LRU chain to its write list. (Keep in mind that the buffer header remains in the CBC structure so it can be found by other processes.) If the write list is still not long enough to warrant a write, then the database writer continues scanning its LRU chain, looking for more unpopular dirty buffer headers.
p>
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
Please—Out 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.
|
|
Know what's important before it's too late!
OraPub's
Performance Training
is like no other...
More Class Pics...
Get student testimonials!
|
