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.
-------------------------------
Every Oracle process is either posting a wait event or consuming CPU3-there are no exceptions. This means that if you have hundreds of Oracle sessions, there is a good chance you'll have hundreds of sessions posting wait events. Knowing that sessions either consume CPU or post a wait event will become more important as you go deeper into performance analysis.
Let's take a look at another multiblock read call but using a different operating system tracing option. Look closely at Figure 2-7. Process 6852 was traced using the rp options. The r option shows the timing information at the beginning of the next line. For this example, the initial gettimeofday call took 0.000147 (s, or 0.147 ms. The 16 8KB block multiblock read request took 22.5 ms. This is much too slow for a respectable IO subsystem. Clearly, this IO request contains at least one block that resides on a physically spinning disk.
Figure 2-7. Oracle's instrumentation through an operating system lens. Oracle has submitted a multiblock IO read request to the operating system by issuing the operating system readv call. The call took 22.5 ms, which is much too long for most Oracle systems.
©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.
|