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.
-------------------------------
* In every case, there are more chains than buffers. Not just by a few, but by two times or more. If there are more chains than buffers, this means some chains will not have an associated buffer header, effectively having a chain length of zero. While this may seem wasteful, it clearly shows that Oracle does not want a process consuming CPU resources, holding a latch and doing a sequential scan. It also implies the developers don't trust their hashing algorithm to not produce collisions. They decided it costs less (however that was measured-perhaps memory consumption) to increase the hashing structure size in the hope of saving CPU cycles and improving response time.
The fact that there are so many CBC latches represents an interesting shift in Oracle's thinking. By limiting the number of latches, Oracle can control which processes can run its kernel code. If there are only ten latches, then Oracle's thought is that only ten processes could be on the CPU. This way, Oracle developers thought they could help ensure the CPU subsystem is not being overwhelmed by Oracle processes. But this is bad policy and thinking for two reasons. First, if a process does not have a latch but wants one, the process will be repeatedly spinning and sleeping. As we know, spinning consumes CPU. So regardless of whether a process has the latch and is running kernel code or is spinning on a latch, CPU will be consumed. The only benefit is when sleeping is involved, which will reduce CPU consumption. Second, when Oracle tries to control this process, it is effectively saying it knows better how to balance operating system resources. I think Oracle developers learned it is best to liberally give latches to reduce any contention involved in acquiring the latch, and then let the operating system deal with the scheduling issues.
This does bring up an interesting point though. Latch contention can be the result of time spent acquiring the latch, not only time holding the latch. It is sad indeed when significant resources are used to simply acquire the latch and not actually do the database work we desire.
©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.
|