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>When a buffer is inserted into the buffer cache, its touch count is set to zero. However, if the buffer is repeatedly touched within a short period of time, there is a good chance the touch will not count. In Figure 6-19, the time period labeled A will result in the touch count being incremented only once, as is the case for all the periods diagrammed. Without the 3-second rule, the buffer header's touch count would be increased by 14; with the 3-second rule, the touch count will be increased by only 5. This ensures that for a buffer to be deemed popular, it can't just be popular for a few seconds. It must continue to be popular to generate a large touch count.
</p><p>Oracle also allows a touch count to be missed. There is no latch involved (which is a fantastic way to eliminate latch contention), and Oracle does not pin the buffer header. Without serialization control, two server processes can increment and update a buffer header's touch count to the same value!
</p><p>As an example, suppose that server process S100 gets the buffer header's touch count at time T0, which is 13, and it begins the increment to 14. But server process S200 now asks the buffer its touch count at time T1, and since server process S100 has not completed the increment, it shows its touch count to still be 13. Server process S200 now begins the increment from 13 to 14. At time T2, server process S100 changes the buffer header's touch count to 14, and at time T3, server process S200 also changes the buffer header's touch count to 14. Is it significant that a touch count increment was missed? No structures have been corrupted, and the touch count has indeed been incremented, but just not twice. In the larger scheme, if the buffer is indeed popular, it will be touched again. What Oracle has saved with this fuzzy implementation is CPU consumption and the amount of kernel code being run.
</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!
|
