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>From an operating perspective, there should be an IO bottleneck. While rare, if write caching is working wonderfully with IO write response times less than 5 ms, the total write time could be large enough to push, say db file parallel write, to the top. When this occurs, focusing on the IO subsystem will likely have little substantial effect. In this situation, focus on reducing the application IO write activity and increasing Oracle write efficiency. This also means creatively reducing write activity during peak database activity. Experienced DBAs have seen write-intensive IO activity like RMAN, backups and file transfers being performed during normal business hours. Decreasing non-Oracle IO requirements effectively increases the IO subsystem's capacity.
p><p>The wait event free buffer waits is closely related to database writer activity and is usually seen with the wait events db file parallel write and log file parallel write (log writer writing). Yet the free buffer waits event is unique in that it takes an interesting combination of database writer, IO subsystem, and server process activity to manifest.
p><p>Key to understanding free buffer waits is the difference between a push-to-disk issue and a pull-from-LRU-chain issue. When we see the wait event db file parallel write rise to the top of our reports, the problem is too much time being spent writing, or pushing, dirty buffers to disk. (The buffers are not actually moved to disk, but copied, which results in the block and buffer matching creating a free buffer.) A server process posts a free buffer waits event when it can't find a free buffer quick enough. One reason for this is the database writer has not pulled enough dirty buffers from the LRU chain and made them free again. So it's not a push-to-disk issue, but instead a pull-from-LRU-chain issue. While the difference may seem exaggerated, it has a huge impact on our solution approach.
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!
|
