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.
-------------------------------
Figure 6-17. Oracle's modified LRU algorithm created a window of a few buffer headers, which all full-table scanned (FTS) buffer headers flowed through when read into the buffer cache. This ensured the more popular buffers residing in the MRU LRU chain area would not be replaced.
As with all algorithms, there are limitations. But these limitations did not cause a problem for many years. However, once customers began using Oracle for large data warehouse applications, two significant problems began to occur:
* Large data warehouses have massive indexes, and when those massive indexes undergo a large range scan, thousands and thousands of index leaf blocks must be read into the cache. The problem, until Oracle8i, was if the index leaf block was not in the buffer cache, Oracle made a single block IO request (think db file sequential read) to bring the block into the buffer cache. The kicker was that since this was not a multiblock IO request, the index buffers were inserted into the LRU chain at the MRU end of the chain, destroying a beautifully developed cache, now completely full of index leaf blocks!
©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.
|