Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Reading statspack reports

RE: Reading statspack reports

From: Bobak, Mark <>
Date: Wed, 1 Mar 2006 13:21:24 -0500
Message-ID: <> does a pretty good analysis of StatsPack reports. It's probably worth a look.

I always start with a quick check of Execute to Parse % and % Non-parse CPU in the instance efficiency percentages. After that it's on to the Top 5 Timed Events. From there, it really depends on what events appear in the Top 5.

CPU time? Look at your SQL ordered by Gets.....any SQLs doing insane numbers of buffer gets/exec?
db file sequential read? Again, look at SQL ordered by Gets, and possibly also SQL ordered by Reads.
db file scattered read? Again, poorly tuned sql.... enqueues? Needs more analysis...could be application design issues, could be block level concurrency, could be several different things, you need to deep dive into the enqueues data and see which specific enqueues have the most waits.
log file sync? Look at commit frequency and also response time of the disks the online redo logs are on
latch free? Depends on the latch. Cache buffers chains is likely to be either inefficient SQL, or possibly some Oracle bug

This is a *far* from complete list....The idea is, start with the Top 5 Timed Events, cause that's where the bottlenecks are. Depending on what YOUR Top 5 are, will tell you where to go next.

Hope that helps,



Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning

"Exception: Some dividends may be reported as qualified dividends but are not qualified dividends. These include:

-----Original Message-----

[] On Behalf Of J. Dex Sent: Wednesday, March 01, 2006 12:14 PM To:
Subject: Reading statspack reports

Does anyone have a quick cheat sheet for reading statspack reports or can
refer me to a site where I can obtain it? I've seen a lot of stuff on Metalink but nothing that is short of quick and to the point.

FREE pop-up blocking with the new MSN Toolbar - get it now!


-- Received on Wed Mar 01 2006 - 12:21:24 CST

Original text of this message