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.
-------------------------------
If the database server is the bottleneck, then the database server bottleneck will be either CPU, IO, or some lock/blocking (for example, enqueues) issue. Your graph will reflect either the general queue time increase of an IO bottleneck or the steep and dramatic elbow of a CPU bottleneck. Figure 9-8 is a good guide, as it contrasts both the CPU and IO bottlenecks.
Based on v$osstat data shown in Figure 9-6 and the reporting interval shown in Figure 9-2, we calculated in the subsequent sections the server is running at 100% CPU utilization. While the wait event situation is not shown, the Statspack report shows the top wait event is clearly CBC latch contention. Based on the instance CPU consumption data shown in Figure 9-3, the reporting interval shown in Figure 9-2, and the CPU core number shown in Figure 9-6, we calculated an Oracle CPU utilization of 94%. Clearly, there is a CPU bottleneck.
When you choose an appropriate unit of work, the response-time graph will be a good representation of the real system. This will make presenting the graph very natural and understandable, and will naturally lead into your performance solutions discussion.
©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.
|