Diagnosing Performance
with Statspack
New with Oracle8i Release 8.1.6, Statspack gives
administrators and tuning specialists a tool for diagnosing
system performance. / By Connie Dialeris and Graham Wood
F
or many years, the only
performance-diagnostic tool
included with Oracle Database
Server software was a set of two
scripts: UTLBSTAT.SQL and UTLESTAT.SQL.
Together, BSTAT/ESTAT, as they’ve come to
be known, form a very simple
performance-diagnosis tool that captures a
single snapshot of performance data
between specified start and end times.
However, the organization of the data in the
resulting BSTAT/ESTAT report is difficult to
read and interpret. In addition, the scripts
haven’t been updated to reflect the growing
number of features available in the Oracle
database server product.
To address these issues, Oracle is
including Statspack, a new package of SQL
scripts, with Release 8.1.6 of Oracle8i. The
package not only addresses new database
features but also captures additional
performance data while providing more
flexible reporting. The report output is also
significantly easier to interpret.
This article—part 1 of a two-part
series—provides an overview of Statspack
as well as an introduction to its installation
and use. Part 2 will cover the analysis and
interpretation of the data Statspack gathers.
W H AT IS S TAT S PA C K ?
Typically, there are two general approaches
to tuning: proactive and reactive. Proactive
tuning usually occurs during software
analysis and design. Focusing on tuning at
these early stages provides the biggest
performance gains. In practice, however,
most tuning is performed reactively, on
either preproduction or production
systems. Statspack is
specifically designed to
simplify reactive
tuning.
To perform reactive
tuning effectively, it is
vital to have an
established baseline or
benchmark from when
the system is running
well to use to compare
when the system is
running poorly. Without baseline
information, it is difficult to identify the
source of the problem: Has the system’s
transaction volume increased? Has the
transaction profile changed? Has the
number of users increased?
Statspack collects statistical data
according to your specifications and stores
the data so that baseline information is
always available for comparison to current
information when performance problems
arise. (Note: The statistics referenced in
this article are gathered from the V$
performance views and not those the
optimizer uses to choose SQL execution
plans.)
Because Statspack has been tailored You can download pre-8.1.6-
to include new Release 8.1.6 features, compatible versions of
you can’t use it with earlier releases; Statspack from
www.oracle.com/oramag/ for
however, you can download pre-8.1.6-
trial use. Note that these trial
compatible versions for trial. Statspack is
releases will not be shipped
also able to capture data about Oracle and are not supported. You
Parallel Server (OPS) instances; you can can also download the
capture data about each instance of an Statspack 8.1.6 production
OPS database simply by connecting to release.
the instance you wish to monitor and
ORACLE MA GAZINE – MARCH/APRIL 2000
| 1
 taking a snapshot (see the “Data traditional wait events and initialization
Collection” section on the next page). parameters. Table 1 shows a comparison of
(Future releases of Statspack may include the data that Statspack and BSTAT/ESTAT
additional OPS-aware features.) collect and report.
C O M PARI S ON W IT H B STAT / E S TAT Another major difference is the manner
Statspack differs fundamentally from the in which the tools collect data. For
well-known BSTAT/ESTAT tuning scripts in example, BSTAT/ESTAT doesn’t separate the
that it collects more information and stores collection of data from the creation of the
the performance-statistics data report: the ESTAT script automatically
permanently in Oracle tables, which can be produces a report and then drops the
used for later reporting and analysis. You transitory tables that held the collected
can analyze the data collected by reviewing data. But with Statspack, the data-
the Statspack report, which includes an collection and -reporting phases are totally
“instance health and load” summary page, distinct. You can initiate data collection on
high-resource SQL statements, and the demand, or automate the collection
process. Regardless of the approach,
TABL E 1 : S ta tsp ack and BSTAT / E S TAT Com pare d Statspack stores data in permanent tables,
Feature Statspack BSTAT/ESTAT which you can then view at your
Instance summary page Y N
convenience.
Normalization of instance statistics by
The separation of these two phases and
time and number of transactions Y N the storage of data in permanent tables
Wait events Y Y enables you to base a report on specified
High-resource SQL Y* N
data points. For example, you may wish to
use the supplied automation script
Instance-activity statistics Y Y
(statsauto.sql) to collect data hourly. If a
Tablespace and file I/O statistics Y Y performance issue arises later for which
Buffer-wait breakdown by type Y Y you’d rather look at a three-hour rather
than a one-hour data window, simply
Enqueue statistics Y N
specify the start and end points when you
Rollback-segment activity and storage data Y Y
run the report.
Latch activity Y Y The Statspack report also looks very
Latch-sleep breakdown Y N
different from the ESTAT report. The first
page is designed for easy identification of
Latch children Y** N
the key data about the system, which
Buffer-pool statistics Y N helps identify where to look in order to
Dictionary-cache activity Y Y analyze performance. Listing 1 shows the
first page of a Statspack report taken from
Library-cache activity Y Y
a production database. The Load Profile
SGA memory summary Y N
area simplifies making comparisons with
SGA memory breakdown Y N other data points, because it normalizes
Nondefault init.ora parameters Y Y
the load data by time and by the number
of transactions.
Configurable output name Y N
The Instance Efficiency area includes
Ability to move performance data Y N computed statistics such as the buffer-
Configurable amount of data collected Y N cache hit, soft-parse, and latch-hit ratios.
Ability to run in multiple instances The summary page also includes Top-5
for Oracle Parallel Server Y N Wait Events, which lists the top-five events
*Level 5 (default) data collection waited for during the data-collection period.
**Level 10 data collection
If timed_statistics is set to true, the

2 | M A R C H / A P R I L 2 0 0 0 – W W W. O R A C L E . C O M / O R A M A G /
 events are listed in order of the time spent For performance diagnosis, it is always
waiting for the event. If timed_statistics best to set timed_statistics to true in
is not set or is set to false, the events are the init.ora parameter file; doing so lets
listed in order of the number of waits. (In you quickly identify what is slowing the
Listing 1, timed_statistics is set to true.) instance and the server processes
attached to the instance.
LISTING 1
DATA C OL LE C T IO N :
First page of a typical Statspack report highlights key data about the system. TAK IN G A SNAP SH OT
STATSPACK report for Statspack users will become familiar with
DB Name DB Id Instance Inst Num Release OPS Host
the concept of a snapshot, which is a
------- ---------- -------- ----------- --------- --- -------- single collection of performance data for a
MAIL 4221457278 MAIL 1 8.1.6.0.0 YES mailhost
database instance. (As used with
Snap Length Statspack, snapshot relates to
Start Id End Id Start Time End Time (Minutes)
performance-data collection and should not
-------- ------- ------------------- ------------------- -------
2327 2329 24-Nov-99 11:00:26 24-Nov-99 13:00:37 120.18 be confused with the snapshot feature in
Oracle’s replication technology.) A data
Cache Sizes
snapshot is identified by a snapshot ID, a
db_block_buffers: 38000
unique number generated at the time
db_block_size: 8192 Statspack takes a snapshot; each time
log_buffer: 1048576
shared_pool_size: 150M
Statspack produces a new collection, it
generates a new snapshot ID.
Load Profile Choosing a Statistics Level DBAs can
change the amount of information or
Per Second Per Transaction
------------ ---------------- detail of statistics Statspack gathers by
Redo size: 15,689.18 3,922.02 specifying a snapshot level. The level you
Logical reads: 21,549.53 5,387.01
Block changes: 76.07 19.02
choose dictates how much data Statspack
Physical reads: 12.53 3.13 collects. Level 5 is the default.
Physical writes: 3.64 0.91
◆ Level 0: Statspack collects general
User calls: 210.33 52.58
Parses: 8.13 2.03 performance statistics such as wait
Hard parses: 0.00 0.00
statistics, system events, system statistics,
Sorts: 6.18 1.54
Transactions: 4.00 rollback-segment data, row cache, SGA,
Rows per Sort: 11.53 background events, session events,
Pct Blocks changed / Read: 0.35 lock statistics, buffer-pool statistics, and
Recursive Call Pct: 14.94
Rollback / transaction Pct: 2.52 parent latch data.
◆ Level 5: Statspack collects all the
Instance Efficiency Percentages (Target 100%)
statistics it gathers at level 0 plus
performance data about high-resource-
Buffer Nowait Ratio: 100.00
Buffer Hit Ratio: 99.94 usage SQL statements.
Library Hit Ratio: 100.00 ◆ Level 10: Statspack collects all the
Redo NoWait Ratio: 100.00
In-memory Sort Ratio: 99.95 statistics from level 0 and level 5 as well as
Soft Parse Ratio: 99.94 child-latch information. At level 10, the
Latch Hit Ratio: 97.86
snapshot can sometimes take longer to
Top 5 Wait Events gather data because level 10 can be
Wait % Total resource-intensive. You should use it only
Event Waits Time (cs) Wt Time on the advice of Oracle personnel.
-------------------------- ------ --------- -------
db file sequential read 67,254 73,087 44.77 Levels 5 and 10 capture high-resource
log file sync 28,252 30,550 18.71 SQL statements that exceed any of the
log file parallel write 28,310 26,304 16.11
db file parallel write 2,681 9,430 5.78 following four threshold parameters:
global cache cr request 32,825 5,586 3.42 ◆ the number of executions of the SQL

3 | M A R C H / A P R I L 2 0 0 0 – W W W. O R A C L E . C O M / O R A M A G /
 statement (default = 100)
◆ the number of disk reads the SQL
statement performs (default = 1,000)
◆ the number of parse calls the SQL
statement performs (default = 1,000)
◆ the number of buffer gets the SQL
statement performs (default = 10,000)
If a SQL statement’s resource usage
exceeds any one of these threshold values,
Statspack captures the statement when it
takes a snapshot.
The level and threshold values are
stored in the table stats$statspack_
parameters. You can change or temporarily
override the default values by specifying
new values for the thresholds and levels
when Statspack takes the snapshot.
I N S TA L LI N G S TAT S PA CK AN D
CO LL E CTIN G DATA
Statspack is a set of SQL, PL/SQL, and
SQL*Plus scripts that allow the collection,
automation, storage, and viewing of
performance data (see Table 2). The
installation script (statscre.sql) calls
several other scripts in order to create the
entire Statspack environment. (Note: You
should run only the installation script, not
the base scripts that statscre.sql
invokes.)
All the scripts you need for installing
and running Statspack are in the
$ORACLE_HOME/rdbms/admin directory for
TA BL E 2 : Scr i pts Sup plie d w ith Stat sp ack
The files that comprise the Statspack performance tool are located in the $ORACLE_HOME/rdbms/admin directory.
Filename Script Type Function
statspack.doc documentation Contains instructions and
information about Statspack
statscre.sql installation Creates entire Statspack
environment (calls statscusr.sql,
statsctab.sql, statspack.sql)
statsdrp.sql installation Drops entire Statspack
environment (calls statsdtab.sql
and statsdusr.sql)
statsrep.sql reporting Generates a Statspack report
statsauto.sql automation Automates Statspack statistics
collection, using dbms_job
statsuexp.par performance-data moving A sample export parameter file
that you can use to export the
perfstat user
4 | M A R C H / A P R I L 2 0 0 0 – W W W. O R A C L E . C O M / O R A M A G /
UNIX platforms and in %ORACLE_HOME%\
rdbms\admin for Microsoft Windows NT
systems.
Documentation for Statspack is in the
file statspack.doc, which explains the
steps required for installing and using
Statspack. The installation script creates a
PL/SQL package called statspack, which
is the core of the system and contains the
procedures for collecting statistics. When
you run the report, the report package—a
combination of SQL, PL/SQL, and SQL*Plus
commands—calls the statspack package
to perform data calculations.
To install Statspack, connect to the
Oracle database as internal and run the
statscre.sql script. This step creates the
user perfstat, who owns all the PL/SQL
code and database objects created as well
as the Statspack tables, constraints, and
the statspack package. This user has
limited, query-only privileges on the V$
views required for performance tuning. The
script prompts you to specify the user
perfstat’s default tablespace and
temporary tablespace. It then asks you to
specify the tablespace for the Statspack
data-collection tables and indexes—
Statspack does not assume you want to
use the default tablespace.
The simplest interactive way to take a
snapshot is to log in to SQL*Plus as the
Usage
Read all documentation before running
install script
Connect as SYS or INTERNAL to install
Connect as SYS or INTERNAL to run
Connect as PERFSTAT to run
Connect as PERFSTAT to run
Connect as PERFSTAT to run
 ◆ Use the Oracle dbms_job procedure
LISTING 2
within the database to schedule the
Running a Statspack report. snapshots. (Statspack includes the
SQL> connect perfstat/perfstat statsauto.sql script to assist you with this
Connected.
SQL> @statsrep configuration. See “Using dbms_job to
Automate Statistics Collection,” on the
DB Id DB Name Instance# Instance
----------- -------- --------- --------
following page, for more information.)
4221457278 MAIL 1 MAIL ◆ Use an operating-system utility outside of
the database, such as UNIX’s cron, to take
Completed Snapshots
the snapshot.
Instance DB Name SnapId Snap Started Snap Level
-------- ------- ------ --------------------- ----------- CON FI GU RI NG SNAP SH O T L EV EL
MAIL MAIL 2326 24 Nov 1999 10:00:53 5 AN D S QL THR E SH OLDS
2327 24 Nov 1999 11:00:26 5
2328 24 Nov 1999 12:00:01 5 Although the default snapshot level is level
2329 24 Nov 1999 13:00:37 5 5, DBAs can change the default
2330 24 Nov 1999 14:00:11 5
Enter beginning Snap Id: 2327
parameters to tailor them to the instance’s
Enter ending Snap Id: 2329 workload. To change the parameters,
Enter name of output file [st_2327_2329] : <enter name or return>
simply specify the new defaults that
Statspack should use. To save your new
owner perfstat and execute the parameter values permanently, use
statspack.snap procedure: statspack.snap to set the
i_modify_parameter input variable to true;
SQL> connect perfstat/perfstat
this will save the new values in the
SQL> execute statspack.snap;
stats$statspack_parameter table, as
This stores the current performance follows:
statistics in the Statspack tables; you can
SQL> execute statspack.snap -
compare the data with other snapshots and
(i_snap_level=>10, i_modify_parameter=> ↵
begin to look for differences that account ‘true’);
for performance problems.
In order to compare performance from (Table 3 shows the list of parameters you
one day, week, or year to the next, you can set with the snap procedure.)
need multiple snapshots taken over a Alternatively, you can change the
period of time. The simplest way to collect defaults without taking a snapshot
a series of snapshots is to automate data immediately, using the statspack.modify_
collection at regular times. You can do this statspack_parameter procedure. For
in one of two ways: example, to change the snapshot level to

TAB LE 3 : st ats pac k.s na p Pr o c e d u r e Pa r ame ter s

Parameter Valid Values Default Value Meaning

i_snap_level 0, 5, 10 5 Snapshot level

i_ucomment text blank Comment to be stored with snapshot

i_executions_th integer >=0 50 SQL threshold: number of executions

i_disk_reads_th integer >=0 1,000 SQL threshold: number of disk reads

i_parse_calls_th integer >=0 1,000 SQL threshold: number of parse calls

i_buffer_gets_th integer >=0 10,000 SQL threshold: number of buffer gets

i_session_id valid SID from v$session 0 (no session) Session ID; capture session granular statistics

i_modify_parameter true, false true Save specified parameters for future snapshots

5 | M A R C H / A P R I L 2 0 0 0 – W W W. O R A C L E . C O M / O R A M A G /
 10 and the SQL thresholds for buffer_gets
and disk_reads without actually taking a
snapshot, issue the following statement:
SQL> execute statspack.modify_statspack_↵
parameter -
(i_snap_level=>10, i_buffer_gets_↵
th=>10000, i_disk_reads_th=>1000);
In addition to collecting instance
statistics, you can collect all the session
statistics for a single session when you take
a snapshot:
SQL> execute statspack.snap(i_session_id=>3);
Gathering session-level statistics is not the
default behavior, however.
Once you have multiple snapshots on
hand, you can examine instance activity by
running the report created by the
statsrep.sql script. Listing 2 shows the
SQL*Plus session executing this script. Be
sure to log on to the Oracle database as
user perfstat. You’ll be prompted for the
beginning and ending snapshot IDs and
the name of the report output file. (The
default name includes the beginning and
ending snapshot IDs.)
I T G E TS BET T E R
Statspack gives DBAs a sophisticated new
tool for collecting and analyzing database-
performance statistics. Two key benefits
over BSTAT/ESTAT include Statspacks’
ability to store the statistical data
permanently in Oracle database tables—
enabling easy reporting and analysis—and
the collection of far more data. And
because Statspack stores statistics data in
tables, you can copy performance data
simply by using the Oracle export utility.
This is especially useful should you ever
need to send data to Oracle Support for
assistance with problem diagnosis, for
example. (The Statspack package includes
an export parameter file—statsuexp.par—
for this purpose.)
Oracle8i Release 8.1.6 contains the first
production release of Statspack. Oracle will
enhance this product with each new release
of Oracle Database Server in order to
provide an efficient, easy-to-use tool for
capturing performance data and diagnosing
performance problems. Part 2 of this article
will give an introduction to analyzing the
statistics Statspack reports.
Connie Dialeris (cdialeri@us.oracle.com) and
Graham Wood (gwood@us.oracle.com) are
members of the Oracle Server Technology
Performance Group and together have more
than 25 years of Oracle-software expertise.

For more information on

dbms_job, see the Supplied
Packages Reference Manual,
available online at Oracle
Technology Network
(http://technet.oracle.com).
U SI NG D B M S _ J O B T O AU T O M ATE S TAT I S T I C S CO LL E CTI O N
You can use dbms_job to automate statistics collection. The file statsauto.sql contains an
example of how to do this, scheduling a snapshot every hour. When you create a job by
using dbms_job, Oracle assigns the job a unique number that you can use for changing or
removing the job. In order to use dbms_job to schedule snapshots automatically, you must
set the job_queue_processes initialization parameter to greater than 0 in the init.ora file:

# Set to enable the job-queue process to start. This allows dbms_job

# to schedule automatic statistics collection, using Statspack
job_queue_processes=1

Change the interval of statistics collection by using the dbms_job.interval procedure:

execute dbms_job.interval(<job number>,’SYSDATE+(1/48)’);

In this case, ‘SYSDATE+(1/48)’ causes the statistics to be gathered each 1/48 day—every
half hour. To stop and remove the automatic-collection job:

execute dbms_job.remove(<job number>);

6 | MARCH/APRIL 2000 – W W W. O R A C L E . C O M / O R A M A G /