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.
-------------------------------
Oracle does, in fact, update the v$sess_time_model view with the database writer resource consumption about every 6 seconds. I tested this by simply repeatedly running the first query shown in Figure 5-6. The background cpu time statistic stayed constant for 6 seconds, and then I saw the value incremented. Notice the database writer CPU time is classified as background cpu time, not DB CPU time. Oracle server process time is placed into the DB CPU bucket.
Also notice the statistic value in the second query in Figure 5-6. This is the CPU time consumed (instance statistic CPU used by this session) by the database writer since the instance has started. But it shows zero seconds of CPU consumed! This demonstrates that for the database writer, v$sesstat does not contain background process CPU consumption. Therefore, if you want to classify background process CPU time, you must either gather from the /proc virtual file system or simply query from v$sess_time_model or v$sys_time_model.
Let's shift from background processes to Oracle server processes. Just as with tracing the database writer process, an active server process will make a getrusage call an average of once every 6 seconds. I keep saying active because if a process is waiting for an event to complete (for example, a multiblock read request or an enqueue), the getrusage call obviously cannot be made. When this delay occurs, the time model details are not updated. For example, if a session is waiting 20 seconds for a lock, its time model details will not be updated until after the lock is acquired. Repeated tests demonstrate the delay is sometimes longer, possibly due to the fact that the next getrusage call may not occur immediately after the lock is acquired.
©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.
|