http://www.pafumi.net/Statspack_Analysis.

html

Analyzing a Statspack Report

Introduction
Executing Snapshots
Load Profile Section
Top 5 Timed Events Section
Resolving Event Waits Section
Common Wait Events, Explanation
SQL Information Section
Instance Activity Stats Section
Tablespace I/O Stats Section
Buffer cache Activity Information
Enqueue Activity
Undo Segment Information
Latch Information
Library Cache Statistics
A guide to the detail sections of the Statspack report
Wait Events Quick Reference Guide
Common Idle Events
Web tools to analyze Reports

Introduction
If you could choose just two Oracle utilities to find and monitor performance problems in your
Database system, those two utilities would be Oracle Enterprise Manager and Statspack. Which area of
the Summary page you will focus will depend on whether you are investigating a performance problem
on monitoring the load of changes, you should start checking the top 5 wait events section.
When statistics and wait events can be misleading
There are certain checks which can be performed to help identify whether a statistic or event is really of
interest. When timed_statistics is false, wait events are ordered by the number of waits. This
information may indicate which events are of interest, however it may be misleading. An event may be
waited for a large number of times, however the wait time (if it were available for comparison) may
show the actual time waited is small despite the high count, hence the event is not really of interest. If
wait time is available, a useful comparison can be made by taking the total wait time for an event, and
comparing it to the elapsed time between snapshots. For example, if the wait event accounts for only 30
seconds out of a two hour period, there is probably little to be gained by investigating this event.
However, if the event accounts for 30 minutes of a 45 minute period, the event may be worth
investigating. There is a warning here, too: even an event which had a wait of 30 minutes in a 45
minute snapshot may not be indicative of a problem, when you take into account there were 2000 users
on the system, and the host hardware was a 64 node machine.
When interpreting computed statistics (such as percentages, or per-second rates), it is important to
cross-verify the computed statistic with the actual statistic counts. This acts as a sanity check to
determine whether the derived rates are really of interest. On initial examination, a soft-parse ratio of
50% would normally indicate a potential tuning area. However if the actual statistic counts are small,
this would not be an area of interest. For example, if there was one hard parse and one soft parse during
the Statspack interval, the soft-parse ratio would be 50%, even though the statistic counts show this is
not an area of concern.
SNAPSHOT LEVELS
LEVEL 0 - GENERAL PERFORMANCE
This level can be used to gather general performance information about the database.
LEVEL 5 - GENERAL PERFORMANCE + SQL STATEMENTS (DEFAULT)
This snapshot level will gather all the information from the previous levels, plus it will collect
performance data on high resource SQL statements. This is also the default snapshot level when
Statspack is installed.
LEVEL 6 - GENERAL PERFORMANCE + SQL STATEMENTS + SQL PLANS AND SQL PLAN
USAGE
This level is new in Oracle9i and it will include all the information collected from the previous
snapshot levels, plus execution path and plan usage information as they relate to high resource SQL
statements. This type of information can prove critical when determining if the execution path or plan
has changed for high resource SQL statements. Oracle recommends using this level for when one of the
following situations has occurred:
- A plan has possibly changed after large volumes of data have been added.
- Obtaining new optimizer setting information.
LEVEL 10 - GENERAL PERFORMANCE + SQL STATEMENTS + SQL PLANS AND SQL PLAN
USAGE + PARENT AND CHILD LATCHES
This level will include all the information collected from previous snapshot levels, plus the addition of
parent and child latch information. This level will take even longer to complete since the parent and
child latch information are added to the duration of the previous 2 levels, which are already information
gathering intensive. First, because the information gathered is based on the shared_pool_size and
secondly the volume of information gathered based on SQL statement information, plus the parent and
child latch information. Snapshots taken from this level will take even longer and it is Oracle's
recommendation to only use this level when requested by Oracle technical support personnel.
LEVEL SETTING RECOMMENDATION
It is recommended to set the timed_statistics to true BEFORE the first snapshot because it will help to
establish a better baseline, otherwise another baseline will be needed AFTER it is turned on. This can
be done with the Alter SYSTEM command and/or setting it in the init.ora file.
SESSION SPECIFIC SNAPSHOT
Statspack also provides the capability to gather session specific information. Passing the i_session_id
value to the Statspack.snap procedure will enable this option.
The following is an example of using this feature:
SQL> EXECUTE STATSPACK.SNAP(i_session_id=>20);

EXECUTING SNAPSHOTS
Executing a snapshot interactively can be as easy as accessing SQL*Plus as the PERFSTAT user and
using the SNAPSHOT.SNAP command or automating when a snapshot is executed. The interactive
method is highly beneficial for when a problem is reported in the database and a snapshot could prove
beneficial for troubleshooting, whereas the value of an automated snapshot is realized when a problem
is reported at a later time and a comparison needs to be made between two specific times that occurred
in the past.
INTERACTIVE METHOD
Access SQL*Plus as the PERFSTAT user and execute either method 1, 2 or 3 as discussed in the above
snapshot Configuration section. The simplest form of the interactive mode is as follows:
SQL> EXECUTE STATSPACK.SNAP
AUTOMATED METHOD
The ability to automate a snapshot is another one of the great features of the Statspack utility.
Automating and scheduling when to take snapshots allows for the collection of database performance
information that would be beneficial for troubleshooting performance problems that occurred earlier.
The following are two ways that snapshots can be automated:
- Oracle's DBMS_JOB utility to schedule snapshots. This utility will be discussed in greater detail.
- An operating specific job scheduler. For example on Unix, shell scripts can be written and then
scheduled through the CRON scheduler. For NT, the AT scheduler in combination with .cmd files.
DBMS_JOB UTILITY
The DBMS_JOB utility provides a way to schedule database related tasks that are controlled within the
database. Through the DBMS_JOB utility snapshots can be taken at a scheduled interval. When the
spcpkg.sql script was executed as part of the Statspack installation, the DBMS_JOB package was
created for the PERFSTAT user. One of the requirements to use the DBMS_JOB utility is that the
init.ora parameter job_queue_processes must be set to a value greater than 0. The spauto.sql script is
designed to setup the automation of executing snapshots once every hour. The following line from the
script is how the job is added to the schedule:
dbms_job.submit(:jobno, 'statspack.snap;', trunc(sysdate+1/24,'HH'), - 'trunc(SYSDATE+1/24,''HH'')',
TRUE, :instno);
The benefits of using the spauto.sql script is that it:
- Displays the job number assigned
- Identifies the number of job_queue_processes set for the database
- The next time that the snapshot will occur

Load Profile Section

The Load Profile section of the Statspack report is useful primarily in comparing two reports to see if
the load characteristics from the two report periods are similar. In proactive tuning, you generate
reports on a routine basis and check the Load Profile for changes in throughput (shown by the per-
second statistics) and changes in application characteristics (shown by the per-transaction statistics). In
reactive tuning, you use the Load Profile to verify the validity of comparing a report generated during a
problem period with a report generated during a baseline period. Make sure the systems were running
comparable workloads during the two report periods. For example, if one report showed a majority of
read-only activity and the second was very update-intensive, comparing the two reports would not be
valid.
If you are not comparing two reports, it's still a good idea to scan the Load Profile for any rates that
seem high, irrespective of a baseline. For example, a high hard-parse rate (say, greater than 100 per
second) may have serious implications for performance. High hard-parse rates are likely to be
accompanied by latch contention, so you would expect to see latch free waits in the Top 5 Wait Events
or high in the complete Wait Events list.

Load Profile
~~~~~~~~~~~~ Per Second Per
Transaction
---------------
---------------
Redo size: 351,530.67
7,007.37
Logical reads: 5,449.81
108.64
Block changes: 1,042.0 8
20.77
Physical reads: 37.71
0.75
Physical writes: 134.68
2.68
User calls: 1,254.72
25.01
Parses: 4.92
0.10
Hard parses: 0.02
0.00
Sorts: 15.73
0.31
Logons: -0.01
0.00
Executes: 473.73
9.44
Transactions: 50.17

% Blocks changed per Read: 19.12 Recursive Call %: 4.71

Rollback per transaction %: 2.24 Rows per Sort: 20.91

Where:
. Redo size: This is the amount of redo generated during this
report.
. Logical Reads: This is calculated as Consistent Gets + DB Block
Gets = Logical Reads
. Block changes: The number of blocks modified during the sample
interval
. Physical Reads: The number of requests for a block that caused a
physical I/O.
. Physical Writes: The number of physical writes issued.
. User Calls: The number of queries generated
. Parses: Total of all parses: both hard and soft
. Hard Parses: Those parses requiring a completely new parse of the
SQL statement. A ‘hard parse’ rate of greater than 100 per second
indicates there is a very high amount of hard parsing on the system.
High hard parse rates cause serious performance issues, and must be
investigated. A high hard parse rate is usually accompanied by latch
contention on the shared pool and library cache latches. Check
whether waits for ‘latch free’ appear in the top-5 wait events, and
if so, examine the latching sections of the Statspack report. Of
course, we want a low number here.
. Soft Parses: Not listed but derived by subtracting the hard parses
from parses. A soft parse reuses a previous hard parse and hence
consumes far fewer resources. A high soft parse rate could be
anywhere in the rate of 300 or more per second. Unnecessary soft
parses also limit application scalability; optimally a SQL statement
should be soft-parsed once per session, and executed many times.
. Sorts and Logons are all self explanatory
. Executes: how many statements we are executing per second /
transaction
. Transactions: how many transactions per second we process
This gives an overall view of the load on the server. In this case, we are looking at a very good hard
parse number and a fairly high system load.
The per-second statistics show you the changes in throughput (i.e. whether the instance is performing
more work per second). For example:
• a significant increase in ‘redo size’, ‘block changes’ and ‘pct of blocks changed per read’ would
indicate the instance is performing more inserts/updates/deletes.
• an increase in the ‘redo size’ without an increase in the number of ‘transactions per second’ would
indicate a changing transaction profile.
Similarly, looking at the per-transaction statistics allows you to identify changes in the application
characteristics by comparing these to the corresponding statistics from the baseline report.

Evaluating the Instance Efficiency Percentages Section

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 100.00
Buffer Hit %: -45.57 In-memory Sort %: 97.55
Library Hit %: 99.89 Soft Parse %: 99.72
Execute to Parse %: -1.75 Latch Hit %: 99.11
Parse CPU to Parse Elapsd %: 52.66 % Non-Parse CPU: 99.99

Shared Pool Statistics Begin End

------ ------
Memory Usage %: 42.07 43.53
% SQL with executions>1: 73.79 75.08
% Memory for SQL w/exec>1: 76.93 77.64

Interpreting the ratios in this section can be slightly more complex than it may seem at first glance.
While high values for the ratios are generally good (indicating high efficiency), such values can be
misleading your system may be doing something efficiently that it would be better off not doing at all.
Similarly, low values aren't always bad. For example, a low in-memory sort ratio (indicating a low
percentage of sorts performed in memory) would not necessarily be a cause for concern in a decision-
support system (DSS) environment, where user response time is less critical than in an online
transaction processing (OLTP) environment.
Basically, you need to keep in mind the characteristics of your application - whether it is query-
intensive or update-intensive, whether it involves lots of sorting, and so on - when you're evaluating the
Instance Efficiency Percentages. Here's how each ratio is calculated, along with which related sections
of the report you should look at when investigating suspicious values:
It is possible for both the 'buffer hit ratio' and the 'execute to parse' ratios to be negative. In the case
of the buffer hit ration, the buffer cache is too small and the data in is being aged out before it can be
used so it must be retrieved again. This is a form of thrashing which degrades performance immensely.
Execute to Parse. If value is negative, it means that the number of parses is larger than the number of
executions. Another cause for a negative execute to parse ratio is if the shared pool is too small and
queries are aging out of the shared pool and need to be reparsed. This is another form of thrashing
which also degrades performance tremendously. This is very BAD!!
Buffer Nowait Ratio. This ratio relates to requests that a server process makes for a specific buffer; it
gives the percentage of those requests in which the requested buffer is immediately available. All buffer
types are included in this statistic. If the ratio is low, check the Buffer Wait Statistics section of the
report for more detail on which type of block is being contended for.
Buffer Hit Ratio. This ratio, also known as the buffer-cache hit ratio, gives the percentage of block
requests that were satisfied within the cache without requiring physical I/O. Although historically
known as one of the most important statistics to evaluate, this ratio can sometimes be misleading. A
low buffer hit ratio does not necessarily mean the cache is too small; it may be that potentially valid
full-table scans are artificially reducing what is otherwise a good ratio. Similarly, a high buffer hit ratio
(say, 99 percent) normally indicates that the cache is adequately sized, but this assumption may not
always be valid. For example, frequently executed SQL statements that repeatedly refer to a small
number of buffers via indexed lookups can create a misleadingly high buffer hit ratio. When these
buffers are read, they are placed at the most recently used (MRU) end of the buffer cache; iterative
access to these buffers can artificially inflate the buffer hit ratio. This inflation makes tuning the buffer
cache a challenge. Sometimes you can identify a too-small buffer cache by the appearance of the write
complete waits event, which indicates that hot blocks (that is, blocks that are still being modified) are
aging out of the cache while they are still needed; check the Wait Events list for evidence of this event.
Library Hit Ratio. This ratio, also known as the library-cache hit ratio, gives the percentage of pin
requests that result in pin hits. A pin hit occurs when the SQL or PL/SQL code to be executed is already
in the library cache and is valid to execute. If the "Library Hit ratio" is low, it could be indicative of a
shared pool that is too small (SQL is prematurely aging out), or just as likely, that the system did not
make correct use of bind variables in the application. If the soft parse ratio is also low, check whether
there's a parsing issue.
Redo Nowait Ratio. This ratio indicates the amount of redo entries generated for which there was
space available in the redo log. The percentage is calculated as follows:
100 x (1- (redo-log space requests/redo entries))
The redo-log space-request statistic is incremented when an Oracle process attempts to write a redo-log
entry but there is not sufficient space remaining in the online redo log. Thus, a value close to 100
percent for the redo nowait ratio indicates minimal time spent waiting for redo logs to become
available, either because the logs are not filling up very often or because the database is able to switch
to a new log quickly whenever the current log fills up.
If your alert log shows that you are switching logs frequently (that is, more than once every 15
minutes), you may be able to reduce the amount of switching by increasing the size of the online redo
logs. If the log switches are not frequent, check the disks on which the redo logs reside to see why the
switches are not happening quickly. If these disks are not overloaded, they may be slow, which means
you could put the files on faster disks.
In-Memory Sort Ratio. This ratio gives the percentage of sorts that were performed in memory, rather
than requiring a disk-sort segment to complete the sort. Optimally, in an OLTP environment, this ratio
should be high. Setting the PGA_AGGREGATE_TARGET (or SORT_AREA_SIZE) initialization
parameter effectively will eliminate this problem.
Soft Parse Ratio. This ratio gives the percentage of parses that were soft, as opposed to hard. A soft
parse occurs when a session attempts to execute a SQL statement and a usable version of the statement
is already in the shared pool. In other words, all data (such as the optimizer execution plan) pertaining
to the statement in the shared pool is equally applicable to the statement currently being issued. A hard
parse, on the other hand, occurs when the current SQL statement is either not in the shared pool or not
there in a shareable form. An example of the latter case would be when the SQL statement in the shared
pool is textually identical to the current statement but the tables referred to in the two statements
resolve to physically different tables.
Hard parsing is an expensive operation and should be kept to a minimum in an OLTP environment. The
aim is to parse once, execute many times.
Ideally, the soft parse ratio should be greater than 95 percent. When the soft parse ratio falls much
below 80 percent, investigate whether you can share SQL by using bind variables or force cursor
sharing by using the init.ora parameter cursor_sharing (new in Oracle8 i Release 8.1.6).
The Soft Parse % value is one of the most important (if not the only important) ratio in the database.
For a typical OLTP system, it should be as near to 100% as possible. You quite simply do not hard
parse after the database has been up for a while in your typical transactional / general-purpose database.

Before you jump to any conclusions about your soft parse ratio, however, be sure to compare it against
the actual hard and soft parse rates shown in the Load Profile. If the rates are low (for example, 1 parse
per second), parsing may not be a significant issue in your system. Another useful standard of
comparison is the proportion of parse time that was not CPU-related, given by the following ratio:
(parse time CPU) / (parse time elapsed)
A low value for this ratio could mean that the non-CPU-related parse time was spent waiting for
latches, which might indicate a parsing or latching problem. To investigate further, look at the shared-
pool and library-cache latches in the Latch sections of the report for indications of contention on these
latches.
Latch Hit Ratio. This is the ratio of the total number of latch misses to the number of latch gets for all
latches. A low value for this ratio indicates a latching problem, whereas a high value is generally good.
However, as the data is rolled up over all latches, a high latch hit ratio can artificially mask a low get
rate on a specific latch. Cross-check this value with the Top 5 Wait Events to see if latch free is in the
list, and refer to the Latch sections of the report. Latch Hit % of less than 99 percent is usually a big
problem.
Also check the "Shared Pool Statistics", if the "End" value is in the high 95%-100% range ,this is a
indication that the shared pool needs to be increased (especially if the "Begin" value is much smaller)
***Please see the following NOTES on shared pool issues
[NOTE:146599.1] Diagnosing and Resolving Error ORA­04031
[NOTE:62143.1] Understanding and Tuning the Shared Pool
[NOTE:105813.1] SCRIPT TO SUGGEST MINIMUM SHARED POOL SIZE 

Top 5 Timed Events Section

Just knowing the breakdown of time into the above 3 categories is not very useful so Oracle has a set of
'Wait Events' for activities in 'a' and 'c', and can record CPU utilization for 'b'. This is best illustrated
with a simplified example of few seconds in the life of an Oracle shadow process:
State Notes...
~~~~~ ~~~~~~~~
IDLE Waiting for 'SQL*Net message from client'.
 Receives a SQL*Net packet requesting 'parse/execute' of a statement
ON CPU decodes the SQL*Net packet.
WAITING Waits for 'latch free' to obtain the a 'library cache' latch
Gets the latch.
ON CPU Scans for the SQL statement in the shared pool, finds a match,
frees latch , sets up links to the shared cursor etc.. & begins to
execute.
WAITING Waits for 'db file sequential read' as we need a block which is
not in the buffer cache. Ie: Waiting for an IO to complete.
ON CPU Block read has completed so execution can continue.
Constructs a SQL*Net packet to send back to the user containing
the first row of data.
WAITING Waits on 'SQL*Net message to client' for an acknowledgement that the
SQL*Net packet was reliably delivered.
IDLE Waits on 'SQL*Net message from client' for the next thing to do.

This section is among the most important and relevant sections in the Statspack report. Here is
where you find out what events (typically wait events) are consuming the most time. In Oracle9i
Release 2, this section includes a new event: CPU time
When you are trying to eliminate bottlenecks on your system, your Statspack report's Top 5 Timed
Events section is the first place to look. This section of the report shows the top 5 wait events, the full
list of wait events, and the background wait events. If your system's TIMED_STATISTICS
initialization parameter is set to true, the events are ordered in time waited, which is preferable, since
all events don't show the waits. If TIMED_STATISTICS is false, the events are ordered by the number
of waits.
Listing 1 shows a large number of waits related to reading a single block (db file sequential read) as
well as waits for latches (latch free). You can see in this listing high waits for some of the writing to
datafiles and log files. To identify which of these are major issues, you must narrow down the list by
investigating the granular reports within other sections of Statspack.

Code Listing 1: Statspack report showing waits related to reading a single block
Top 5 Wait Events
------------------------------------
Event Waits Time (s) % Total Elap. Time
------------------------------------------------------------------------------
db file sequential read 18,977,104 22,379,571 82.29
latch free 4,016,773 2,598,496 9.55
log file sync 1,057,224 733,490 2.70
log file parallel write 1,054,006 503,695 1.85
db file parallel write 1,221,755 404,230 1.49

Wait Events Information Section

The following section will describe in detail most of the sections provided in a statspack report.
- Foreground Wait Events: Foreground wait events are those associated with a session or client
process waiting for a resource
- Background Wait Events: Background wait events are those not associated with a client process.
They indicate waits encountered by system and non-system processes. Examples of background system
processes are LGWR and DBWR. An example of a non-system background process would be a
parallel query slave. Note that it is possible for a wait event to appear in both the foreground and
background wait events statistics, for examples the enqueue and latch free events. The idle wait events
appear at the bottom of both sections and can generally safely be ignored. Typically these type of
events keep record of the time while the clien is connected to the database but not requests are being
made to the server.

Resolving Wait Events Section

A critical activity in Database Performance Tuning is Response Time Analysis: this consists of finding
out where time is being spent in a database.
Response Time Analysis for an Oracle Database is done using the following equation:
Response Time = Service Time + Wait Time
'Service Time' is measured using the statistic 'CPU used by this session'
'Wait Time' is measured by summing up time spent on Wait Events
When presented with such a list of top Wait Events it sometimes becomes easy to simply start dealing
with the listed Wait Events and to forget evaluating their impact on overall Response Time first. In
situations where 'Service Time' i.e. CPU usage is much more significant than 'Wait Time', it is very
likely that investigating Wait Events will not produce significant savings in 'Response Time'. Therefore,
one should always compare the time taken by the top wait events to the 'CPU used by this session' and
direct the tuning effort to the biggest consumers.
Note:
To address this possible source of confusion, starting with Oracle9i Release 2 the "Top 5 Wait Events"
section has been renamed to "Top 5 Timed Events". Here, 'Service Time' as measured by the statistic
'CPU used by this session' is listed as 'CPU time'. This means that it is now easier to accurately measure
the impact of Wait Events in overall 'Response Time' and to correctly target the subsequent tuning
effort.
MISINTERPRETING THE IMPACT OF WAIT EVENTS: AN EXAMPLE
Here is a real life example of why it is important to look at both 'Wait Time' and 'Service Time' when
investigating database performance. The following is the "Top 5 Wait Events" section of a Statspack
report generated from two snapshots 46 minutes apart:
Top 5 Wait Events
------------------------------------
Event Waits Time (s) % Total Elap. Time
----------------------------- ------------- ---------- --------------------
direct path read 4,232 10,827 (a) 52.01 (b)
db file scattered read 6,105 6,264 30.09
direct path write 1,992 3,268 15.70
control file parallel write 893 198 .95
db file parallel write 40 131 .63

Based on this listing we may be tempted to immediately start looking at the causes between the 'direct
path read' and 'db file scattered read' waits and to try to tune them. This approach would not take into
account 'Service Time'. Here is the statistic that measures 'Service Time' from the same report:

Statistic Total per Second per Trans

------------------------- ---------- ---------- ----------

CPU used by this session 358,806 130.5 12,372.6

Let's do some simple math from these figures:
'Wait Time' = 10,827 (a) x 100% / 52,01% (b) = 20,817 cs
'Service Time' = 358,806 cs
'Response Time' = 358,806 + 20,817 = 379,623 cs
If we now calculate percentages for all the 'Response Time' components:
CPU time = 94.52%

direct path read = 2.85%

db file scattered read = 1.65%

direct path write = 0.86%

control file parallel write = 0.05%

db file parallel write = 0.03%

It is now obvious that the I/O-related Wait Events are not really a significant component of the overall
Response Time and that subsequent tuning should be directed to the Service Time component i.e. CPU
consumption.
Incidentally, the improved "Top 5 Timed Events" section in Statspack starting with Oracle9i Release 2
would show output similar to our calculated listing.

In this section we list the I/O-related Wait Events that occur most often in Oracle databases together
with reference notes describing each wait.
Datafile I/O-Related Wait Events:
'db file sequential read' [NOTE:34559.1]
'db file scattered read' [NOTE:34558.1]
'db file parallel read'
'direct path read' [NOTE:50415.1]
'direct path write' [NOTE:50416.1]
'direct path read (lob)'
'direct path write (lob)'
Controlfile I/O-Related Wait Events:
'control file parallel write'
'control file sequential read'
'control file single write'
Redo Logging I/O-Related Wait Events:
'log file parallel write' [NOTE:34583.1]
'log file sync' [NOTE:34592.1]
'log file sequential read'
'log file single write'
'switch logfile command'
'log file switch completion'
'log file switch (clearing log file)'
'log file switch (checkpoint incomplete)'
'log switch/archive'
'log file switch (archiving needed)'
Buffer Cache I/O-Related Wait Events:
'db file parallel write' [NOTE:34416.1]
'db file single write'
'write complete waits'
'free buffer waits'
Approaches for handling General I/O problems
Some of these approaches can be used regardless of the particular Wait Event.

o Reduce the I/O requirements of the database by tuning SQL:

o Reduce the I/O requirements of the database by tuning instance parameters:

This works in two ways:
a) Using memory caching to limit I/O:
The amount of I/O required by the database is limited by the use of a number of memory caches e.g.
the Buffer Cache, the Log Buffer, various Sort Areas etc.
Increasing the Buffer Cache, up to a point, results in more buffer accesses by database processes
(logical I/Os) being satisfied from memory instead of having to go to disk (physical I/Os).
With larger Sort Areas in memory, the likelihood of them being exhausted during a sorting operation
and having to use a temporary tablespace on disk is reduced.
b) Tuning the size of multiblock I/O:
The size of individual multiblock I/O operations can be controlled by instance parameters.
Up to a limit, multiblock I/Os are executed faster when there are fewer larger I/Os than when there are
more smaller I/Os.
For example, transferring 100Mb of data will complete faster if it is done in 100 requests of size 1Mb
each than if it is done in 1,000 requests of size 100Kb each or 10,000 requests of 10Kb each (up to
10MB)

o Optimizing I/O at the Operating System level

This involves making use of I/O capabilities such as Asynchronous I/O or using Filesystems with
advanced capabilities such as Direct I/O (bypassing the Operating System's File Caches). Another
possible action is to raise the limit of maximum I/O size per transfer (referred to as max_io_size in this
article).

o Balancing the database I/O by usage of Striping, RAID, SAN or NAS

o Redistribute database I/O by manual placement of database files across different filesystems,
controllers and physical devices
This is an approach used in the absence of advanced modern storage technologies. Again the aim is to
distribute the database I/O so that no single set of disks or controller becomes saturated from I/O
requests when there is still unused disk throughput. It is harder to get right than the previous approach
and most often less successful.

Common WAIT EVENTS

If you want quick instancewide wait event status, showing which events are the biggest contributors to
total wait time, you can use the following query :
select event, total_waits,time_waited from V$system_event

where event NOT IN

('pmon timer', 'smon timer', 'rdbms ipc reply', 'parallel deque

wait',

'virtual circuit', '%SQL*Net%', 'client message', 'NULL event')

order by time_waited desc;

EVENT TOTAL_WAITS TIME_WAITED

------------------------ ------------- -------------

db file sequential read 35051309 15965640

latch free 1373973 1913357

db file scattered read 2958367 1840810

enqueue 2837 370871

buffer busy waits 444743 252664

log file parallel write 146221 123435

1. DB File Scattered Read. That generally happens during a full scan of a table or Fast Full Index
Scans. As full table scans are pulled into memory, they rarely fall into contiguous buffers but instead
are scattered throughout the buffer cache. A large number here indicates that your table may have
missing or suppressed indexes. Although it may be more efficient in your situation to perform a full
table scan than an index scan, check to ensure that full table scans are necessary when you see these
waits. Try to cache small tables to avoid reading them in over and over again, since a full table scan is
put at the cold end of the LRU (Least Recently Used) list. You can use the Statspack report to help
identify the query in question and fix it.
The init.ora parameter db_file_multiblock_read_count specifies the maximum numbers of blocks read
in that way. Typically, this parameter should have values of 4-16 independent of the size of the database
but with higher values needed with smaller Oracle block sizes. If you have a high wait time for this
event, you either need to reduce the cost of I/O, e.g. by getting faster disks or by distributing your I/O
load better, or you need to reduce the amount of full table scans by tuning SQL statements. The
appearance of the‘db file scattered read’ and ‘db file sequential read’events may not necessarily
indicate a problem, as IO is a normal activity on a healthy instance. However, they can indicate
problems if any of the following circumstances are true:
• The data-access method is bad (that is, the SQL statements are poorly tuned), resulting in unnecessary
or inefficient IO operations
• The IO system is overloaded and performing poorly
• The IO system is under-configured for the load
• IO operations are taking too long
If this Wait Event is a significant portion of Wait Time then a number of approaches are possible:
o Find which SQL statements perform Full Table or Fast Full Index scans and tune them to make sure
these scans are necessary and not the result of a
suboptimal plan.
- Starting with Oracle9i the new view V$SQL_PLAN view can help:
For Full Table scans:
select sql_text from v$sqltext t, v$sql_plan p

where t.hash_value=p.hash_value

and p.operation='TABLE ACCESS'

and p.options='FULL'

order by p.hash_value, t.piece;

For Fast Full Index scans:
select sql_text from v$sqltext t, v$sql_plan p

where t.hash_value=p.hash_value

and p.operation='INDEX'

and p.options='FULL SCAN'

order by p.hash_value, t.piece;

o In cases where such multiblock scans occur from optimal execution plans it is possible to tune the
size of multiblock I/Os issued by Oracle by setting the instance parameter
DB_FILE_MULTIBLOCK_READ_COUNT so that:
DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT = max_io_size of system
Query tuning should be used to optimize online SQL to use indexes.
2. DB File Sequential Read. This wait event will be generated while waiting for writes to TEMP
space generally (direct loads, Parallel DML (PDML) such as parallel updates. You may tune the PGA
AGGREGATE TARGET parameter to reduce waits on sequential reads.
The sequential read event identifies Oracle reading blocks sequentially, i.e. one after each other.. A
large number of waits here could indicate poor joining orders of tables, unselective indexing or you
either need to reduce the cost of I/O, e.g. by getting faster disks or by distributing your I/O load better,
or you need to reduce the amount of I/O by increasing the buffer cache or by tuning SQL statements. It
is normal for this number to be large for a high-transaction, well-tuned system, but it can indicate
problems in some circumstances. You should correlate this wait statistic with other known issues within
the Statspack report, such as inefficient SQL. Check to ensure that index scans are necessary, and check
join orders for multiple table joins. The DB_CACHE_SIZE will also be a determining factor in how
often these waits show up. Problematic hash-area joins should show up in the PGA memory, but they're
also memory hogs that could cause high wait numbers for sequential reads. They can also show up as
direct path read/write waits. These circumstances are usually interrelated. When they occur in
conjunction with the appearance of the 'db file scattered read' and 'db file sequential read' in the Top 5
Wait Events section, first you should examine the SQL Ordered by Physical Reads section of the report,
to see if it might be helpful to tune the statements with the highest resource usage.
It could be because the indexes are fragmented. If that is the case, rebuilding the index will compact it
and will produce to visit less blocks.
Then, to determine whether there is a potential I/O bottleneck, examine the OS I/O statistics for
corresponding symptoms. Also look at the average time per read in the Tablespace and File I/O sections
of the report. If many I/O-related events appear high in the Wait Events list, re-examine the host
hardware for disk bottlenecks and check the host-hardware statistics for indications that a disk
reconfiguration may be of benefit.
Block reads are fairly inevitable so the aim should be to minimize unnecessary I/O. I/O for sequential
reads can be reduced by tuning SQL calls that result in full table scans and using the partitioning option
for large tables.
3. Free Buffer. When a session needs a free buffer and cannot find one, it will post the database writer
process asking it to flush dirty blocks. Waits in this category may indicate that you need to increase the
DB_BUFFER_CACHE, if all your SQL is tuned. Free buffer waits could also indicate that unselective
SQL is causing data to flood the buffer cache with index blocks, leaving none for this particular
statement that is waiting for the system to process. This normally indicates that there is a substantial
amount of DML (insert/update/delete) being done and that the Database Writer (DBWR) is not writing
quickly enough; the buffer cache could be full of multiple versions of the same buffer, causing great
inefficiency. To address this, you may want to consider accelerating incremental checkpointing, using
more DBWR processes, or increasing the number of physical disks. To investigate if this is an I/O
problem, look at the statspack file I/O Statistics.
4. Buffer Busy Waits. A buffer busy wait happens when multiple processes concurrently want to
modify the same block in the buffer cache. This typically happens during massive parallel inserts if
your tables do not have free lists and it can happen if you have too few rollback segments.
Buffer busy waits should not be greater than 1 percent. Check the Buffer Wait Statistics section (or
V$WAITSTAT) to find out if the wait is on a segment header. If this is the case, increase the freelist
groups or increase the pctused to pctfree gap. If the wait is on an undo header, you can address this by
adding rollback segments; if it's on an undo block, you need to reduce the data density on the table
driving this consistent read or increase the DB_CACHE_SIZE. If the wait is on a data block, you can
move data to another block to avoid this hot block, increase the freelists on the table, or use Locally
Managed Tablespaces (LMTs). If it's on an index block, you should rebuild the index, partition the
index, or use a reverse key index. To prevent buffer busy waits related to data blocks, you can also use
a smaller block size: fewer records fall within a single block in this case, so it's not as "hot." When a
DML (insert/update/ delete) occurs, Oracle Database writes information into the block, including all
users who are "interested" in the state of the block (Interested Transaction List, ITL). To decrease waits
in this area, you can increase the initrans, which will create the space in the block to allow multiple ITL
slots. You can also increase the pctfree on the table where this block exists (this writes the ITL
information up to the number specified by maxtrans, when there are not enough slots built with the
initrans that is specified). Buffer busy waits can be reduced by using reverse-key indexes for busy
indexes and by partitioning busy tables
5. Latch Free. Latches are low-level queuing mechanisms (they're accurately referred to as mutual
exclusion mechanisms) used to protect shared memory structures in the system global area (SGA).
Latches are like locks on memory that are very quickly obtained and released. Latches are used to
prevent concurrent access to a shared memory structure. If the latch is not available, a latch free miss is
recorded. Most latch problems are related to the failure to use bind variables (library cache latch), redo
generation issues (redo allocation latch), buffer cache contention issues (cache buffers LRU chain), and
hot blocks in the buffer cache (cache buffers chain). There are also latch waits related to bugs; check
MetaLink for bug reports if you suspect this is the case (oracle.com/support ). When latch miss ratios
are greater than 0.5 percent, you should investigate the issue. If latch free waits are in the Top 5 Wait
Events or high in the complete Wait Events list, look at the latch-specific sections of the Statspack
report to see which latches are contended for.
6. Enqueue. An enqueue is a lock that protects a shared resource. Locks protect shared resources, such
as data in a record, to prevent two people from updating the same data at the same time application, e.g.
when a select for update is executed.. An enqueue includes a queuing mechanism, which is FIFO (first
in, first out). Note that Oracle's latching mechanism is not FIFO. Enqueue waits usually point to the ST
enqueue, the HW enqueue, the TX4 enqueue, and the TM enqueue. The ST enqueue is used for space
management and allocation for dictionary-managed tablespaces. Use LMTs, or try to preallocate
extents or at least make the next extent larger for problematic dictionary-managed tablespaces. HW
enqueues are used with the high-water mark of a segment; manually allocating the extents can
circumvent this wait. TX4s are the most common enqueue waits. TX4 enqueue waits are usually the
result of one of three issues. The first issue is duplicates in a unique index; you need to
commit/rollback to free the enqueue. The second is multiple updates to the same bitmap index
fragment. Since a single bitmap fragment may contain multiple rowids, you need to issue a commit or
rollback to free the enqueue when multiple users are trying to update the same fragment. The third and
most likely issue is when multiple users are updating the same block. If there are no free ITL slots, a
block-level lock could occur. You can easily avoid this scenario by increasing the initrans and/or
maxtrans to allow multiple ITL slots and/or by increasing the pctfree on the table. Finally, TM
enqueues occur during DML to prevent DDL to the affected object. If you have foreign keys, be sure to
index them to avoid this general locking issue.
7. Log Buffer Space. This wait occurs because you are writing the log buffer faster than LGWR can
write it to the redo logs, or because log switches are too slow. To address this problem, increase the size
of the log files, or increase the size of the log buffer, or get faster disks to write to. You might even
consider using solid-state disks, for their high speed.
8. Log File Switch. All commit requests are waiting for "logfile switch (archiving needed)" or "logfile
switch (chkpt. Incomplete)." Ensure that the archive disk is not full or slow. DBWR may be too slow
because of I/O. You may need to add more or larger redo logs, and you may potentially need to add
database writers if the DBWR is the problem.
9. Log File Sync. When a user commits or rolls back data, the LGWR flushes the session's redo from
the log buffer to the redo logs. The log file sync process must wait for this to successfully complete. To
reduce wait events here, try to commit more records (try to commit a batch of 50 instead of one at a
time, for example). Put redo logs on a faster disk, or alternate redo logs on different physical disks, to
reduce the archiving effect on LGWR. Don't use RAID 5, since it is very slow for applications that
write a lot; potentially consider using file system direct I/O or raw devices, which are very fast at
writing information. The associated event, ‘log buffer parallel write’ is used by the redo log writer
process, and it will indicate if your actual problem is with the log file I/O. Large wait times for this
event can also be caused by having too few CPU resources available for the redolog writer process.
10. Idle Event. There are several idle wait events listed after the output; you can ignore them. Idle
events are generally listed at the bottom of each section and include such things as SQL*Net message
to/from client and other background-related timings. Idle events are listed in the stats$idle_event table.
11. global cache cr request: (OPS) This wait event shows the amount of time that an instance has
waited for a requested data block for a consistent read and the transferred block has not yet arrived at
the requesting instance. See Note 157766.1 'Sessions Wait Forever for 'global cache cr request' Wait
Event in OPS or RAC'. In some cases the 'global cache cr request' wait event may be perfectly normal
if large buffer caches are used and the same data is being accessed concurrently on multiple instances.
In a perfectly tuned, non-OPS/RAC database, I/O wait events would be the top wait events but since
we are avoiding I/O's with RAC and OPS the 'global cache cr request' wait event often takes the place
of I/O wait events.
12. library cache pin Library cache latch contention may be caused by not using bind variables. It is
due to excessive parsing of sql statement.
13. CPU time is not really a wait event (hence, the new name), but rather the sum of the CPU used by
this session, or the amount of CPU time used during the snapshot window. In a heavily loaded system,
if the CPU time event is the biggest event, that could point to some CPU-intensive processing (for
example, forcing the use of an index when a full scan should have been used), which could be the cause
of the bottleneck. When CPU Other is a significant component of total Response Time the next step is
to find the SQL statements that access the most blocks. Block accesses are also known as Buffer Gets
and Logical I/Os. Statspack lists such SQL statements in section SQL ordered by Gets.
14. DB File Parallel Read This Wait Event is used when Oracle performs in parallel reads from
multiple datafiles to non-contiguous buffers in memory (PGA or Buffer Cache). This is done during
recovery operations or when buffer prefetching is being used as an optimization i.e. instead of
performing multiple single-block reads. If this wait is an important component of Wait Time, follow the
same guidelines as 'db file sequential read'.
15. PX qref latch Can often mean that the Producers are producing data quicker than the Consumers
can consume it. Maybe we could increase parallel_execution_message_size to try to eliminate some of
these waits or we might decrease the degree of parallelism. If the system workload is high consider to
decrease the degree of parallelism. If you have DEFAULT parallelism on your object you can decrease
the value of PARALLEL_THREADS_PER_CPU. Have in mind DEFAULT degree =
PARALLEL_THREADS_PER_CPU * #CPU's
16. Log File Parallel Writes. Log file parallel write waits occur when waiting for writes of REDO
records to the REDO log files to complete. The wait occurs in log writer (LGWR) as part of normal
activity of copying records from the REDO log buffer to the current online log. The actual wait time is
the time taken for all the outstanding I/O requests to complete. Even though the writes may be issued in
parallel, LGWR needs to wait for the last I/O to be on disk before the parallel write is considered
complete. Hence the wait time depends on the time it takes the OS to complete all requests.
Waits for log file parallel writes can be identified by looking at the "Top 5 Timed Events" or "Wait
Events" section of the Statspack report.
Log file parallel write waits can be reduced by moving log files to the faster disks and/or separate disks
where there will be less contention.

SQL Information Section

The SQL that is stored in the shared pool SQL area (Library cache) is reported in this section in
different ways:
. SQL ordered by Buffer Gets
. SQL ordered by Physical Reads
. SQL ordered by Executions
. SQL ordered by Parse Calls
- SQL ordered by Gets:
This section reports the contents of the SQL area ordered by the number of buffer gets and can be used
to identify the most CPU Heavy SQL.
- Many DBAs feel that if the data is already contained within the buffer cache the query should be
efficient. This could not be further from the truth. Retrieving more data than needed, even from the
buffer cache, requires CPU cycles and interprocess IO. Generally speaking, the cost of physical I/O is
not 10,000 times more expensive. It actually is in the neighborhood of 67 times and actually almost
zero if the data is stored in the UNIX buffer cache.
- The statements of interest are those with a large number of gets per execution especially if the number
of executions is high.
- High buffer gets generally correlates with heavy CPU usage

- SQL ordered by Reads:

This section reports the contents of the SQL area ordered by the number of reads from the data files and
can be used to identify SQL causing IO bottlenecks which consume the following resources.
- CPU time needed to fetch unnecessary data.
- File IO resources to fetch unnecessary data.
- Buffer resources to hold unnecessary data.
- Additional CPU time to process the query once the data is retrieved into the buffer.

- SQL ordered by Executions:

This section reports the contents of the SQL area ordered by the number of query executions. It is
primarily useful in identifying the most frequently used SQL within the database so that they can be
monitored for efficiency. Generally speaking, a small performance increase on a frequently used query
provides greater gains than a moderate performance increase on an infrequently used query. Possible
reasons for high Reads per Exec are use of unselective indexes require large numbers of blocks to be
fetched where such blocks are not cached well in the buffer cache, index fragmentation, large
Clustering Factor in index etc.

- SQL ordered by Parse Calls (9i Only):

This section shows the number of times a statement was parsed as compared to the number of times it
was executed. One to one parse/executions may indicate that:
- Bind variables are not being used.
- On RDBMS version 8172 and higher the init.ora parameter session_cached_cursors was not set in the
init.ora (100 is usually the suggested starting value). See enhancement bug 1589185 for an explanation
of the change that shifts some of the load from the library cache to the user session cache.
- The shared pool may be too small and the parse is not being retained long enough for multiple
executions.
- cursor_sharing is set to exact (this should NOT be changed without considerable testing on the part of
the client).

Generate Execution Plan for given SQL statement

If you have identified one or more problematic SQL statement, you may want to check the execution
plan. Remember the "Old Hash Value" from the report above (1279400914), then execute the scrip to
generate the execution plan.
sqlplus perfstat/perfstat
SQL> @?/rdbms/admin/sprepsql.sql
Enter the Hash Value, in this example: 1279400914

SQL Text

~~~~~~~~

create table test as select * from all_objects

Known Optimizer Plan(s) for this Old Hash Value

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Shows all known Optimizer Plans for this database instance,

and the Snap Id's

they were first found in the shared pool. A Plan Hash Value

will appear

multiple times if the cost has changed

-> ordered by Snap Id

First First Plan

Snap Id Snap Time Hash Value Cost

--------- --------------- ------------ ----------

6 14 Nov 04 11:26 1386862634 52

Plans in shared pool between Begin and End Snap Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Shows the Execution Plans found in the shared pool between

the begin and end

snapshots specified. The values for Rows, Bytes and Cost

shown below are those

which existed at the time the first-ever snapshot captured

this plan - these

values often change over time, and so may not be indicative

of current values

-> Rows indicates Cardinality, PHV is Plan Hash Value

-> ordered by Plan Hash Value

-------------------------------------------------------------
-------------------

| Operation | PHV/Object Name |

Rows | Bytes| Cost |

-------------------------------------------------------------

-------------------

|CREATE TABLE STATEMENT |----- 1386862634

----| | | 52 |

|LOAD AS SELECT |

| | | |

| VIEW | |

1K| 216K| 44 |

| FILTER |

| | | |

| HASH JOIN | |

1K| 151K| 38 |

| TABLE ACCESS FULL |USER$ |

29 | 464 | 2 |

| TABLE ACCESS FULL |OBJ$ |

3K| 249K| 35 |

| TABLE ACCESS BY INDEX ROWID |IND$ |

1 | 7 | 2 |

| INDEX UNIQUE SCAN |I_IND1 |

1 | | 1 |

| NESTED LOOPS | |

5 | 115 | 16 |

| INDEX RANGE SCAN |I_OBJAUTH1 |

1 | 10 | 2 |

| FIXED TABLE FULL |X$KZSRO |

5 | 65 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

 1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| FIXED TABLE FULL |X$KZSPR |

1 | 26 | 14 |

| VIEW | |

1 | 13 | 2 |

| FAST DUAL | |

1 | | 2 |

-------------------------------------------------------------

-------------------

Instance Activity Stats Section

The statistics section shows the overall database statistics. These are the statistics that the summary
information is derived from. A list of the statistics maintained by the RDBMS kernel can be found in
Appendix C of the Oracle Reference manual for the version being utilized.

Instance Activity Stats for DB: PHS2 Instance: phs2 Snaps: 100 -104
Statistic Total per Second
per Trans
--------------------------------- ---------------- ------------
------------
CPU used by this session 84,161 23.4
3,825.5
CPU used when call started 196,346 54.5
8,924.8
CR blocks created 709
0.2 32.2
DBWR buffers scanned 0
0.0 0.0
DBWR checkpoint buffers written 245
0.1 11.1
DBWR checkpoints 33
0.0 1.5
DBWR cross instance writes 93
0.0 4.2
DBWR free buffers found 0
0.0 0.0
....

Of particular interest are the following statistics.

- CPU USED BY THIS SESSION, PARSE TIME CPU or RECURSIVE CPU USAGE: These
numbers are useful to diagnose CPU saturation on the system (usually a query tuning issue). The
formula to calculate the CPU usage breakdown is:
Service (CPU) Time = other CPU + parse time CPU
Other CPU = "CPU used by this session" - parse time CPU
Some releases do not correctly store this data and can show huge numbers. The rule to decide if you
can use these metrics is:

Trustworthy if :
(db version>= 8.1.7.2 and 9.0.1)
OR ((db version >= 9.0.1.1) = 8.0.6.0 AND not using job_queue_processes AND CPU_PER_CALL =
default)
recursive cpu usage = This component can be high if large amounts of PL/SQL are being processed.
It is outside the scope of this document to go into detail with this, but you will need to identify your
complete set of PL/SQL, including stored procedures, finding the ones with the highest CPU load and
optimize these. If most work done in PL/SQL is procedural processing (rather than executing SQL), a
high recursive cpu usage can actually indicate a potential tuning effort.
parse time cpu= Parsing SQL statements is a heavy operation, that should be avoided by reusing SQL
statements as much as possible. In precompiler programs, unnecessary parting of implicit SQL
statements can be avoided by increasing the cursor cache (MAXOPENCURSORS parameter) and by
reusing cursors. In programs using Oracle Call Interface, you need to write the code, so that it re-
executes (in stead of reparse) cursors with frequently executed SQL statements. The v$sql view
contains PARSE_CALLS and EXECUTIONS columns, that can be used to identify SQL, that is parsed
often or is only executed once per parse.
other cpu= The source of other cpu is primarily handling of buffers in the buffer cache. It can
generally be assumed, that the CPU time spent by a SQL statement is approximately proportional to the
number of buffer gets for that SQL statements, hence, you should identify and sort SQL statements by
buffer gets in v$sql. In your statspack report, look at the part ‘SQL ordered by Gets for DB’. Start
tuning SQL statements from the top of this list. In Oracle9i, the v$sql view contain a column,
CPU_TIME, which directly shows the cpu time associated with executing the SQL statement.
- DBWR BUFFERS SCANNED: the number of buffers looked at when scanning the lru portion of
the buffer cache for dirty buffers to make clean. Divide by "dbwr lru scans" to find the average number
of buffers scanned. This count includes both dirty and clean buffers. The average buffers scanned may
be different from the average scan depth due to write batches filling up before a scan is complete. Note
that this includes scans for reasons other than make free buffer requests.
- DBWR CHECKPOINTS: the number of checkpoints messages that were sent to DBWR and not
necessarily the total number of actual checkpoints that took place. During a checkpoint there is a slight
decrease in performance since data blocks are being written to disk and that causes I/O. If the number
of checkpoints is reduced, the performance of normal database operations improve but recovery after
instance failure is slower.
- DBWR TIMEOUTS: the number of timeouts when DBWR had been idle since the last timeout.
These are the times that DBWR looked for buffers to idle write.
- DIRTY BUFFERS INSPECTED: the number of times a foreground encountered a dirty buffer
which had aged out through the lru queue, when foreground is looking for a buffer to reuse. This
should be zero if DBWR is keeping up with foregrounds.
- FREE BUFFER INSPECTED: the number of buffers skipped over from the end of the LRU queue
in order to find a free buffer. The difference between this and "dirty buffers inspected" is the number of
buffers that could not be used because they were busy or needed to be written after rapid aging out.
They may have a user, a waiter, or being read/written.
- RECURSIVE CALLS: Recursive calls occur because of cache misses and segment extension. In
general if recursive calls is greater than 30 per process, the data dictionary cache should be optimized
and segments should be rebuilt with storage clauses that have few large extents. Segments include
tables, indexes, rollback segment, and temporary segments.
NOTE: PL/SQL can generate extra recursive calls which may be unavoidable.
- REDO BUFFER ALLOCATION RETRIES: total number of retries necessary to allocate space in
the redo buffer. Retries are needed because either the redo writer has gotten behind, or because an
event (such as log switch) is occurring
- REDO LOG SPACE REQUESTS: indicates how many times a user process waited for space in the
redo log buffer. Try increasing the init.ora parameter LOG_BUFFER so that zero Redo Log Space
Requests are made.
- REDO WASTAGE: Number of bytes "wasted" because redo blocks needed to be written before they
are completely full. Early writing may be needed to commit transactions, to be able to write a
database buffer, or to switch logs
- SUMMED DIRTY QUEUE LENGTH: the sum of the lruw queue length after every write request
completes. (divide by write requests to get average queue length after write completion)
- TABLE FETCH BY ROWID: the number of rows that were accessed by a rowid. This includes
rows that were accessed using an index and rows that were accessed using the statement where rowid =
'xxxxxxxx.xxxx.xxxx'.
- TABLE FETCH BY CONTINUED ROW: indicates the number of rows that are chained to another
block. In some cases (i.e. tables with long columns) this is unavoidable, but the ANALYZE table
command should be used to further investigate the chaining, and where possible, should be eliminated
by rebuilding the table.
- Table Scans (long tables) is the total number of full table scans performed on tables with more than 5
database blocks. If the number of full table scans is high the application should be tuned to effectively
use Oracle indexes. Indexes, if they exist, should be used on long tables if less than 10-20% (depending
on parameter settings and CPU count) of the rows from the table are returned. If this is not the case,
check the db_file_multiblock_read_count parameter setting. It may be too high. You may also need to
tweak optimizer_index_caching and optimizer_index_cost_adj.
- Table Scans (short tables) is the number of full table scans performed on tables with less than 5
database blocks. It is optimal to perform full table scans on short tables rather than using indexes.

Tablespace I/O Stats Section

IO Activity Input/Output (IO) statistics for the instance are listed in the following sections/formats:
- Tablespace I/O Stats for DB: Ordered by total IO per tablespace.
- File I/O Stats for DB: Ordered alphabetically by tablespace, filename.
If the statistic "Buffer Waits" for a tablespace is greater than 1000, you may want to consider tablespace
reorganization in order to spread tables within it across another tablespaces.
In Oracle 8.1.7 many other columns were included as follow:
- Avg. Read / Second
- Avg. Blocks / Read
- Avg. Writes / Second
- Buffer Waits
- Avg. Buffer Waits / Milisecond
Note that Oracle considers average read times of greater than 20 ms unacceptable. If a datafile
consistently has average read times of 20 ms or greater then:
- The queries against the contents of the owning tablespace should be examined and tuned so that less
data is retrieved.
- If the tablespace contains indexes, another option is to compress the indexes so that they require less
space and hence, less IO.
- The contents of that datafile should be redistributed across several disks/logical volumes to more
easily accommodate the load.
- If the disk layout seems optimal, check the disk controller layout. It may be that the datafiles need to
be distributed across more disk sets.

Buffer cache Activity Information

The buffer statistics are comprised of two sections:
- Buffer Pool Statistics: This section can have multiple entries if multiple buffer pools are allocated. A
baseline of the database's buffer pool statistics should be available to compare with the current
statspack buffer pool statistics. A change in that pattern unaccounted for by a change in workload
should be a cause for concern. Also check the Buffer Pool Advisory to identify if increasing that
parameter (db_cache_size) would help to reduce Physical Reads.
- Buffer Wait Statistics: This section shows a breakdown of each type of object waited for. This section
follows the Instance Recovery Stats for DB.
Buffer wait Statistics for DB: PHS2 Instance: phs2 Snaps: 100 -104
-> ordered by wait time desc, waits desc
Tot Wait Avg
Class Waits Time (cs) Time (cs)
------------------ ----------- ---------- ---------
undo header 42 21 1
data block 18 6 0

The above shows no real contention. Typically, when there is buffer contention, it is due to data block
contention with large average wait times, like the example below:
Buffer wait Statistics for DB: GLOVP Instance: glovp Snaps: 454 - 455
 Tot Wait Avg
Class Waits Time (cs) Time (cs)
------------------ ----------- ---------- ---------
data block 9,698 17,097 2
undo block 210 1,225 6
segment header 259 367 1
undo header 259 366 1
file header block 24 1 33
system undo header 1 0 0

Instance Recovery Statistics

This section was added in 9i and is useful for monitoring the recovery and redo information

PGA Memory Statistics

This section was added in 9i and helps when using the new model to allocate PGA in Oracle9i using
PGA_AGGREGATE_TARGET. This section is particularly useful when monitoring session memory
usage on Windows servers

Enqueue Activity
An enqueue is simply a locking mechanism. This section is very useful and must be used when the wait
event "enqueue" is listed in the "Top 5 timed events".
Enqueue activity for DB: S901 Instance: S901 Snaps: 2 -3
-> Enqueue stats gathered prior to 9i should not be compared with 9i data
-> ordered by waits desc, Waits desc
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------ ------------ ----------- ----------- ------------- ------------
TC 44,270 44,270 0 8,845 619.37 5,478
TX 13,072,864 13,072,809 0 4,518 641.72 2,899
CU 5,532,494 5,532,494 0 33,355 4.78 159
SQ 418,547 418,547 0 1,251 15.10 19
PS 5,950,717 5,189,366 761,354 69,381 .19 13
US 4,912 4,912 0 282 45.16 13
PR 8,325 8,325 0 11 213.64 2
CI 67,060 67,060 0 15 18.93 0
JD 165,560 165,560 0 1 261.00 0
HW 56,401 56,401 0 3 2.67 0

The action to take depends on the lock type that is causing the most problems. The most common lock
waits are generally for:
- TX (Transaction Lock): Generally due to application concurrency mechanisms, or table setup issues.
The TX lock is acquired when a transaction initiates its first change and is held until the transaction
does a COMMIT or ROLLBACK. It is used mainly as a queuing mechanism so that other resources
can wait for a transaction to complete.
- TM (DML enqueue): Generally due to application issues, particularly if foreign key constraints have
not been indexed. This lock/enqueue is acquired when performing an insert, update, or delete on a
parent or child table.
- ST (Space management enqueue): Usually caused by too much space management occurring. For
example: create table as select on large tables on busy instances, small extent sizes, lots of sorting, etc.
These enqueues are caused if a lot of space management activity is occurring on the database (such as
small extent size, several sortings occurring on the disk).

Undo Segment Information

Undo information is provided in the following sections:
- Undo Segment Summary
- Undo Segment Stats
The examples below show typical performance problem related to Undo (rollback) segments:
- Undo Segment Summary for DB
Undo Segment Summary for DB: S901 Instance: S901 Snaps: 2 -3
-> Undo segment block stats:
-> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
-> eS - expired Stolen, eR - expired Released, eU - expired reUsed

Undo Undo Num Max Qry Max Tx Snapshot Out of uS/uR/uU/

TS# Blocks Trans Len (s) Concurcy Too Old Space eS/eR/eU
---- -------------- ---------- -------- ---------- -------- ------
-------------
1 20,284 1,964 8 12 0 0
0/0/0/0/0/0

The description of the view V$UNDOSTAT in the Oracle9i Database Reference guide provides
some insight as to the columns definitions. Should the client encounter SMU problems,
monitoring this view every few minutes would provide more useful information.
- Undo Segment Stats for DB
Undo Segment Stats for DB: S901 Instance: S901 Snaps: 2 -3
-> ordered by Time desc

Undo Num Max Qry Max Tx Snap Out of uS/uR/uU/

End Time Blocks Trans Len (s) Concy Too Old Space eS/eR/eU
------------ ------------ -------- ------- -------- ------- ------
-------------
12-Mar 16:11 18,723 1,756 8 12 0 0
0/0/0/0/0/0
12-Mar 16:01 1,561 208 3 12 0 0
0/0/0/0/0/0

This section provides a more detailed look at the statistics in the previous section by listing the
information as it appears in each snapshot.
It should be noted that 9i introduces an optional init.ora parameter called UNDO_RETENTION
which allows the DBA to specify how long the system will attempt to retain undo information
for a committed transaction without being overwritten or recaptured. This parameter, based in
units of wall-clock seconds, is defined universally for all undo segments.
Use of UNDO_RETENTION can potentially increase the size of the undo segment for a given
period of time, so the retention period should not be arbitrarily set too high. The UNDO
tablespace still must be sized appropriately. The following calculation can be used to determine
how much space a given undo segment will consume given a set value of
UNDO_RETENTION.
 Undo Segment Space Required = (undo_retention_time * undo_blocks_per_seconds)
As an example, an UNDO_RETENTION of 5 minutes (default) with 50 undo blocks/second (8k
blocksize) will generate:
Undo Segment Space Required = (300 seconds * 50 blocks/ seconds * 8K/block) = 120 M
The retention information (transaction commit time) is stored in every transaction table block
and each extent map block. When the retention period has expired, SMON will be signaled to
perform undo reclaims, done by scanning each transaction table for undo timestamps and
deleting the information from the undo segment extent map. Only during extreme space
constraint issues will retention period not be obeyed.

Latch Information
Latch information is provided in the following three sections:
. Latch Activity
. Latch Sleep breakdown
. Latch Miss Sources
This information should be checked whenever the "latch free" wait event or other latch wait events
experience long waits. This section is particularly useful for determining latch contention on an
instance. Latch contention generally indicates resource contention and supports indications of it in
other sections. Latch contention is indicated by a Pct Miss of greater than 1.0% or a relatively high
value in Avg Sleeps/Miss. While each latch can indicate contention on some resource, the more
common latches to watch are:
cache buffer chain= The cache buffer chain latch protects the hash chain of cache buffers, and is used
for each access to cache buffers. Contention for this latch can often only be reduced by reducing the
amount of access to cache buffers. Using the X$BH fixed table can identify if some hash chains have
many buffers associated with them. Often, a single hot block, such as an index root block, can cause
contention for this latch. In Oracle9i, this is a shared latch, which minimizes contention for blocks
being read only. Contention on this latch confirms a hot block issue.
shared pool= The shared pool latch is heavily used during parsing, in particular during hard parse. If
your application is written so that it generally uses literals in stead of bind variables, you will have high
contention on this latch. Contention on this latch in conjunction with reloads in the SQL Area of the
library cache section indicates that the shared pool is too small. In release 8.1.6 and later, you can set
the cursor_sharing parameter in init.ora to the value ‘force’ to reduce the hard parsing and reduce some
of the contention for the shared pool latch. Applications that are coded to only parse once per cursor
and execute multiple times will almost completely avoid contention for the shared pool latch.
• Literal SQL is being used. See Note 62143.1 'Understanding and Tuning the Shared Pool for an
excellent discussion of this topic.
• On versions 8.1.7.2 and higher, session_cached_cursors might need to be set. See enhancement
bug 1589185 for details.
library cache= The library cache latch is heavily used during both hard and soft parsing. If you have
high contention for this latch, your application should be modified to avoid parsing if at all possible.
Setting the cursor_sharing parameter in init.ora to the value ‘force’ provides some reduction in the
library cache latch needs for hard parses, and setting the session_cached_cursors sufficiently high
provides some reduction in the library cache latch needs for repeated soft parsing within a single
session. There is minor contention for this latch involved in executing SQL statements, which can be
reduced further by setting cursor_space_for_time=true, if the application is properly written to parse
statements once and execute multiple times.
row cache= The row cache latch protects the data dictionary information, such as information about
tables and columns. During hard parsing, this latch is used extensively. In release 8.1.6 and above, the
cursor_sharing parameter can be used to completely avoid the row cache latch lookup during parsing.
cache buffer lru chain= The buffer cache has a set of chains of LRU block, each protected by one of
these latches. Contention for this latch can often be reduced by increasing the db_block_lru_latches
parameter or by reducing the amount of access to cachebuffers.

Library Cache Statistics

This section of the report shows information about the different sub-areas activity in the library cache.
Library Cache Activity for DB: S901 Instance: S901 Snaps: 2 -3
->"Pct Misses" should be very low
Get Pct Pin Pct Invali-
Namespace Requests Miss Requests Miss Reloads dations
--------------- ------------ ------ -------------- ------ ---------- --------
BODY 310,879 0.0 310,880 0.0 0 0
CLUSTER 1,009 0.3 1,007 0.6 0 0
INDEX 14,713 0.2 17,591 0.3 0 0
SQL AREA 14,184,204 0.1 313,089,592 1.9 5,793,355 38,421
TABLE/PROCEDURE 46,190,602 0.0 91,843,902 0.0 825 0
TRIGGER 148,809 0.0 148,809 0.0 2 0

Values in Pct Misses or Reloads in the SQL Area, Tables/Procedures or Trigger rows indicate that the
shared pool may be too small. To confirm this, consistent values (not sporadic) in Pct Misses or
Reloads in the Index row indicate that the buffer cache is too small. (No longer available in 9i.)
Values in Invalidations in the SQL Area indicate that a table definition changed while a query was
being run against it or a PL/SQL package being used was recompiled.

PGA Aggr Section

Shared Pool Advisory Section

Use this section to evaluate your shared pool size parameter.

A guide to the detail sections of the Statspack report

Section(s) What You Can Use the Section(s) for

Wait Events Look for excessive waits and wait times; drill down to
specific problems

SQL Ordered by Buffer Gets, Physical Reads, and Rows Figure out which SQL statements to tune
Processed

Instance Activity Statistics Compare with baseline report; compute additional statistics
Tablespace and File I/O Investigate I/O bottlenecks, identify files and tablespaces
with heavy I/O

Buffer Pool Identify specific buffer pools with high contention or I/O

Buffer Wait Statistics Identify types of buffers with large number of buffer waits

Enqueue Activity Investigate specific lock types that are causing the most
waits

Rollback Segment Statistics and Storage Investigate waits for rollback segment headers

Latch Activity, Latch Sleep Breakdown, Latch Miss Identify latching bottlenecks; diagnose and related problems
Sources

Library Cache Diagnose problems with shared pool

Non-default init.ora Look for unnecessary or problematic parameter definitions

Wait Events Quick Reference Guide

Wait Problem Potential Fix

DB File Wait for Multi-block read of a table or index (full scan): tune the code and/or
Scattered Read cache small tables.

DB File Wait for single block read of a table or index. Indicates many index reads: tune the
Sequential Read code (especially joins).

Used when Oracle performs in parallel reads from multiple datafiles to non-
DB File parallel
contiguous buffers in memory (PGA or Buffer Cache). Similar to db file sequential
read
read
Free Buffer Increase the DB_CACHE_SIZE; shorten the checkpoint; tune the code.

Buffer Busy Segment header: add freelists or freelist groups.

Buffer Busy Data block: separate "hot" data; use reverse key indexes and/or smaller blocks.
Buffer Busy Data block: increase initrans and/or maxtrans.

Buffer Busy Undo header: add rollback segments or areas.

Buffer Busy Undo block: commit more often; use larger rollback segments or areas.

Latch Free Investigate the latch detail.

Enqueue-ST Use LMTs or preallocate large extents.

Enqueue-HW Preallocate extents above high-water mark.

Enqueue-TX4 Increase initrans and/or maxtrans on the table or index.

Enqueue-TM Index foreign keys; check application locking of tables.

Log Buffer Space Increase the log buffer; use faster disks for the redo logs.

Log File Switch Archive destination slow or full; add more or larger redo logs.

Log File Sync Commit more records at a time; use faster redo log disks or raw devices.

Direct Path Read Used by Oracle when reading directly into PGA (sort or hash)
Direct Path Write Used by Oracle when writing directly into PGA (sort or hash)
Idle Event Ignore it.

Common Idle Events

Event Idle Event Type

Dispatcher timer Shared server

Lock manager wait for remote message Oracle9i Real Application Clusters

Pipe get User process

pmon timer Background process

PX Idle wait Parallel query

PX Deq Credit: need buffer Parallel query

PX Deq Credit: send blkd Parallel query

rdbms ipc message Background process

smon timer Background process

SQL*Net message from client User process

virtual Circuit status Shared server

Web tools to analyze Reports

http://www.oraperf.com
http://www.txmemsys.com/statspack-reg.htm
http://www.spviewer.com/index.html
spReporter 1.0.30
http://www.softpedia.com/get/Internet/Servers/Database-Utils/spReporter.shtml
http://www.wise-oracle.com
www.statspackanalyzer.com

Good Links with more Information

http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/