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>Figure 6-20 is a flowchart of what I'm about to explain. After a server process reads a data block from disk, it must find an unpopular free buffer to replace with the just-read data block. The server process acquires the appropriate LRU latch, and then starts scanning buffer headers at the LRU end of the LRU chain. Remember that the buffer headers reside on the LRU chains, not the buffers. If the server process bumps into a free buffer header, then it checks if it is popular. If it is popular, the server process promotes the buffer header and continues scanning. If the free buffer header is not popular, the server process replaces the buffer with the block read from disk, updates the buffer header, and moves the buffer header to the LRU chain midpoint. Notice there is no need to update the CBC structure, because the buffer has not moved; only the buffer header on the LRU chain has moved. If the server process bumps into a dirty buffer header, then it checks if it is a popular dirty buffer header. If the dirty buffer header is popular, it promotes the buffer header and continues scanning. If the dirty buffer header is not popular, the server process moves the buffer header to the write list. If the server process bumps into a pinned buffer header it, simply continues with its scan. Pinned buffers are off limits.
p><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>
©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!
|
