Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
7Activity
0 of .
Results for:
No results containing your search query
P. 1
Diagnosing Performance With Stats_pack

Diagnosing Performance With Stats_pack

Ratings: (0)|Views: 268 |Likes:
Published by api-27242535

More info:

Published by: api-27242535 on Oct 18, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/09/2014

pdf

text

original

F
ORACLE MAGAZINE \u2013 MARCH/APRIL 2000
|
1
or many years, the only
performance-diagnostic tool
included with Oracle Database
Server software was a set of two
scripts:UTLBSTAT.SQL andUTLESTAT.SQL.
Together,BSTAT/ESTAT, as they\u2019ve 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

resultingBSTAT/ESTAT report is difficult to

read and interpret. In addition, the scripts
haven\u2019t 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 mor e
flexible reporting. The report output is also
significantly easier to interpret.

This art i c l e \u2014 p a rt 1 of a two-part
s e r i e s \u2014 p rovides an overview of Statspack
as well as an introduction to its installation
and use. Part 2 will cover the analysis and

i n t e r p retation of the data Statspack gathers.
WHAT IS STATSPACK?

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\u2019s
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 theV$
performance views and not those the
optimizer uses to choose SQL execution

plans.)

Because Statspack has been tailored
to include new Release 8.1.6 features,
you can\u2019t use it with earlier releases;
however, you can download pre-8.1.6-
compatible versions for trial. Statspack is
also able to capture data about Oracle
Parallel Server (OPS) instances; you can
capture data about each instance of an
OPS database simply by connecting to
the instance you wish to monitor and

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

You can download pre-8.1.6-
compatible versions of
Statspack from
www.oracle.com/oramag/ for

trial use. Note that these trial

releases will not be shipped
and are not supported. You
can also download the
Statspack 8.1.6 production
release.

2
|
MARCH/APRIL 2000 \u2013W W W. O R A C L E . C O M / O R A M A G /
traditional wait events and initialization
parameters. Table 1 shows a comparison of
the data that Statspack andBSTAT/ESTAT
collect and report.
Another major difference is the manner
in which the tools collect data. For
example,BSTAT/ESTAT doesn\u2019t separate the
collection of data from the creation of the
report: theESTAT script automatically

produces a report and then drops the
transitory tables that held the collected
data. But with Statspack, the data-
collection and -reporting phases are totally

distinct. You can initiate data collection on
demand, or automate the collection
process. Regardless of the approach,
Statspack stores data in permanent tables,
which you can then view at your
convenience.

The separation of these two phases and
the storage of data in permanent tables
enables you to base a report on specified
data points. For example, you may wish to
use the supplied automation script

(statsauto.sql) to collect data hourly. If a
performance issue arises later for which
you\u2019d rather look at a three-hour rather
than a one-hour data window, simply
specify the start and end points when you
run the report.

The Statspack report also looks very
different from theE S T A T report. The first
page is designed for easy identification of
the key data about the system, which
helps identify where to look in order to
analyze performance. Listing 1 shows the
first page of a Statspack report taken from
a production database. The Load Profile
area simplifies making comparisons with
other data points, because it normalizes
the load data by time and by the number
of transactions.

The Instance Efficiency area includes
computed statistics such as the buffer-
cache hit, soft-parse, and latch-hit ratios.

The summary page also includes Top-5

Wait Events, which lists the top-five events
waited for during the data-collection period.
Iftimed_statistics is set to true, the

taking a snapshot (see the \u201cData
Collection\u201d section on the next page).
(Future releases of Statspack may include
additional OPS-aware features.)

COMPARISON WITH BSTAT/ESTAT
Statspack differs fundamentally from the
well-knownBSTAT/ESTAT tuning scripts in
that it collects more information and stores
the performance-statistics data

permanently in Oracle tables, which can be
used for later reporting and analysis. You
can analyze the data collected by reviewing
the Statspack report, which includes an
\u201cinstance health and load\u201d summary page,
high-resource SQL statements, and the

TABLE 1: Statspack and BSTAT/ESTAT Compared
Feature
Statspack
BSTAT/ESTAT
Instance summary page
Y
N
Normalization of instance statistics by
time and number of transactions
Y
N
Wait events
Y
Y
High-resource SQL
Y*
N
Instance-activity statistics
Y
Y
Tablespace and file I/O statistics
Y
Y
Buffer-wait breakdown by type
Y
Y
Enqueue statistics
Y
N
Rollback-segment activity and storage data
Y
Y
Latch activity
Y
Y
Latch-sleep breakdown
Y
N
Latch children
Y**
N
Buffer-pool statistics
Y
N
Dictionary-cache activity
Y
Y
Library-cache activity
Y
Y
SGA memory summary
Y
N
SGA memory breakdown
Y
N
Nondefault init.ora parameters
Y
Y
Configurable output name
Y
N
Ability to move performance data
Y
N
Configurable amount of data collected
Y
N
Ability to run in multiple instances
for Oracle Parallel Server
Y
N
*Level 5 (default) data collection
**Level 10 data collection
3
|
MARCH/APRIL 2000 \u2013W W W. O R A C L E . C O M / O R A M A G /

For performance diagnosis, it is always
best to sett i m e d _ s t a t i s t i c s to true in
thei n i t . o r a parameter file; doing so lets
you quickly identify what is slowing the
instance and the server processes
attached to the instance.

DATA COLLECTION:
TAKING A SNAPSHOT

Statspack users will become familiar with
the concept of asnapshot, which is a
single collection of performance data for a
database instance. (As used with

Statspack,snapshot relates to
performance-data collection and should not
be confused with the snapshot feature in
Oracle\u2019s replication technology.) A data

snapshot is identified by a snapshot ID, a
unique number generated at the time
Statspack takes a snapshot; each time
Statspack produces a new collection, it
generates a new snapshot ID.

Choosing a Statistics Level DBAs can

change the amount of information or
detail of statistics Statspack gathers by
specifying a snapshotl e v e l. The level you
choose dictates how much data Statspack
collects. Level 5 is the default.

xLevel 0:Statspack collects general

performance statistics such as wait
statistics, system events, system statistics,
rollback-segment data, row cache, SGA,
background events, session events,
lock statistics, buffer-pool statistics, and
parent latch data.

xLevel 5:Statspack collects all the
statistics it gathers at level 0 plus
performance data about high-resource-
usage SQL statements.
xLevel 10:Statspack collects all the

statistics from level 0 and level 5 as well as
child-latch information. At level 10, the
snapshot can sometimes take longer to
gather data because level 10 can be

resource-intensive. You should use it only
on the advice of Oracle personnel.
Levels 5 and 10 capture high-resource
SQL statements that exceed any of the
following four threshold parameters:
xthe number of executions of the SQL

events are listed in order of the time spent waiting for the event. Iftimed_statistics is not set or is set to false, the events are listed in order of the number of waits. (In

Listing 1,timed_statistics is set to true.)
First page of a typical Statspack report highlights key data about the system.
STATSPACK report for
DB Name
DB Id
Instance
Inst Num
Release
OPS
Host
------- ----------
-------- -----------
---------
--- --------
MAIL
4221457278
MAIL
1
8.1.6.0.0
YES mailhost
Snap Length
Start Id
End Id
Start Time
End Time
(Minutes)
--------
-------
-------------------
-------------------
-------
2327
2329
24-Nov-99 11:00:26
24-Nov-99 13:00:37
120.18
Cache Sizesdb_block_buffers:
38000
db_block_size:
8192
log_buffer:
1048576
shared_pool_size:
150M
Load Profile
Per Second
Per Transaction
------------
----------------
Redo size:
15,689.18
3,922.02
Logical reads:
21,549.53
5,387.01
Block changes:
76.07
19.02
Physical reads:
12.53
3.13
Physical writes:
3.64
0.91
User calls:
210.33
52.58
Parses:
8.13
2.03
Hard parses:
0.00
0.00
Sorts:
6.18
1.54
Transactions:
4.00
Rows per Sort:
11.53
Pct Blocks changed / Read:
0.35
Recursive Call Pct:
14.94
Rollback / transaction Pct:
2.52
Instance Efficiency Percentages (Target 100%)
Buffer Nowait Ratio:
100.00
Buffer Hit Ratio:
99.94
Library Hit Ratio:
100.00
Redo NoWait Ratio:
100.00
In-memory Sort Ratio:
99.95
Soft Parse Ratio:
99.94
Latch Hit Ratio:
97.86
Top 5 Wait Events
Wait
% Total
Event
Waits
Time (cs)
Wt Time
--------------------------
------
---------
-------
db file sequential read
67,254
73,087
44.77
log file sync
28,252
30,550
18.71
log file parallel write
28,310
26,304
16.11
db file parallel write
2,681
9,430
5.78
global cache cr request
32,825
5,586
3.42
LISTING 1

Activity (7)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
bprasadreddyin liked this
Lupi Lupov liked this
Virat Choudhary liked this
Virat Choudhary liked this
palash09 liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->