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.
-------------------------------
The standard LRU algorithm is very simple. When a buffer is brought into the cache or accessed (query or DML), it is placed at the MRU end of the session's LRU chain (each session is associated with an LRU chain). The thinking is that a popular buffer will be repeatedly touched and therefore repeatedly moved to the MRU end of the LRU chain. The movement to the MRU of this list is commonly called, buffer promotion. If a buffer is not popular, then as other buffers are promoted or inserted into the LRU, the unpopular buffers will naturally migrate toward the LRU end of the LRU chain.
Possibly lurking near the LRU end of every LRU chain is a server process seeking a free unpopular buffer to replace with a block it just read from disk. I call such a server process the reaper, as it replaces buffers whose goal in life is to live long and gloriously in Oracle's buffer cache. For example, suppose the LRU situation is as shown in Figure 6-16 and there is a server process looking for a free buffer. The server process will start at the LRU end of the LRU chain and check if buffer header BH 310 is free. If buffer header BH 310 indicates it is free, it will be replaced (being transported to buffer heaven, we hope) with the just-read block's buffer header and moved to the MRU end of the list.
This simple strategy worked well for Oracle until tables grew in size beyond the bonus and dept tables. The LRU chain in Figure 6-16 is eight buffer headers long. Suppose an eight-block table was just full-table scanned, requiring every block to be read into Oracle cache and its buffer headers to be placed into the LRU chain. When this algorithm was used, there was only a single LRU chain, so the entire LRU chain would be replaced with the full-table scanned table. So hour after hour of refining the cache to contain the popular buffers have just been obliterated. Users would certainly notice a performance change, and the IO subsystem would also take a beating. As database size continued to increase, Oracle clearly had to make a change, resulting in the modified LRU algorithm.
©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.
|