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.
-------------------------------
Please remember that having many clones may not present a performance issue. If it is in fact a performance problem, CBC latching contention will clearly be an issue. If this is the case and you spot a cloned buffer, then consider the following as possible remedies:
* Fix the application. This is usually what must be done. It's painful, requires meetings, can get very personal if the application developer is involved, and usually requires the application to be modified in some way to reduce the popularity of the single cloned buffer.
* Move the rows. If you're lucky, there may be multiple rows that are intensifying the buffer's popularity. If possible, distribute the rows, so multiple buffers are now not quite so popular. While altering the traditional pct_free and pct_used storage parameters is an option, for increased control, consider setting the maximum number of rows table blocks can hold. Unexpectedly, there is more involved than simply issuing an alter statement like alter table all_status minimize records_per_block 5. But it works wonderfully! For details, see a SQL reference guide or do an Internet search.
©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.
|