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.
-------------------------------
Suppose you are a server process executing a SQL statement. Based on the SQL statement and Oracle's data dictionary, you discover there is row you must access located in file number 35 with a block number of 2435.
You hash 35,2435, which hashes to CBC 02. If the hash function and the number of buckets have not been changed, hashing this block will always point to CBC 02. So, if the block does exist in the buffer cache, it absolutely must reside in CBC 02. Referencing the CBC, you realize that you must acquire latch CS 800 in shared mode. You go through the spinning and sleeping algorithm, burning CPU and sleeping (screaming "latch free cache buffer chain!"), but finally do acquire latch CS 800.
Now with the latch in hand, you begin traversing CBC 02 in the hope of finding buffer 35,2435. You check buffer header BH 165 and discover it is associated with another buffer, so you move onto buffer header BH 145. You discover this buffer header is associated with another buffer, so you continue. But you hit the end of CBC 02, and therefore you know that buffer 32,2435 is not in the buffer cache. You release the CBC latch CS 800.
©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.
|