Académique Documents
Professionnel Documents
Culture Documents
Oracle9i Server
Release 9.2
Production
-------------------------------------------------------------------------
Copyright (C) 1993, 2002, Oracle Corporation. All rights reserved.
Author: Connie Dialeris Green
Contributors: Cecilia Gervasio, Graham Wood, Russell Green, Patrick Tearle,
Harald Eri, Stefan Pommerenk, Vladimir Barriere
Please refer to the Oracle9i server README file in the rdbms doc directory,
for copyright, disclosure, restrictions, warrant, trademark, disclaimer,
and licensing information. On Unix systems, the file is README.doc,
and on Windows systems the file is README_RDBMS.HTM.
Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
-------------------------------------------------------------------------
2. Statspack Configuration
---------------------------
2.1. Database Space Requirements
The amount of database space required by the package will vary considerably
based on the frequency of snapshots, the size of the database and instance,
and the amount of data collected (which is configurable).
It is therefore difficult to provide general storage clauses and space
utilization predictions which will be accurate at each site.
The default initial and next extent sizes are 100k, 1MB, 3MB or 5MB for all
Statspack tables and indexes. To install Statspack, the minimum
space requirement is approximately 100MB.
Locally Managed Tablespaces
---------------------------
If you install the package in a locally-managed tablespace, modifying
storage clauses is not required, as the storage characteristics are
automatically managed.
Dictionary Managed Tablespaces
------------------------------
If you install the package in a dictionary-managed tablespace, Oracle
suggests you monitor the space used by the objects created, and adjust
the storage clauses of the segments, if required.
The spcreate install script runs 3 other scripts - you do not need to
run these - these scripts are called automatically:
1. spcusr -> creates the user and grants privileges
2. spctab -> creates the tables
3. spcpkg -> creates the package
Check each of the three output files produced (spcusr.lis,
spctab.lis, spcpkg.lis) by the installation to ensure no
errors were encountered, before continuing on to the next step.
Note that there are two ways to install Statspack - interactively (as
shown above), or in 'batch' mode; batch mode is useful when you do
not wish to be prompted for the PERFSTAT user's default and
temporary tablespaces.
Example output:
SQL> connect perfstat/perfstat_password
Connected.
SQL> @spreport
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
2618106428 PRD1 1 prd1
Completed Snapshots
Snap Snap
Instance DB Name Id Snap Started Level Comment
------------ ------------ ----- ----------------- ----- ----------------------
prd1 PRD1 1 11 May 2000 12:07 5
2 11 May 2000 12:08 5
3 12 May 2000 07:07 5
4 12 May 2000 08:08 5
The report will now scroll past, and also be written to the file
specified (e.g. sp_1_2.lis).
4.2. Running the instance report when there are multiple instances
spreport.sql assumes you are connected to the database you wish to report
on. There are certain situations where this assumption may not be
valid:
- In a clustered database environment, you may be connected to
an instance which is not the instance you wish to report on
- If you are archiving baseline Statspack data in a separate database
from your production database, or when importing Statspack data
(e.g. in the case of Oracle support)
In these situations, you would not be able to produce the Statspack
instance report using spreport.sql, as the instance assumed may be
unavailable, possibly on a totally different host.
To circumvent this problem, you should run the sprepins.sql report
instead. The sprepins.sql report output is identical to the
spreport.sql output, as spreport.sql simply calls sprepins.sql, first
defaulting the Instance Number and DBId of the database you are
currently connected to.
If you run sprepins.sql directly, you are prompted for the DBId and
Instance Number for the instance you wish to report on, in addition
to the begin_snap and end_snap Ids and report output name (i.e. the
current DBId and Instance Number are not defaulted).
You will be prompted for:
1. The DBId
2. The Instance Number
3. The beginning snapshot Id
4. The ending snapshot Id
5. The name of the report text file to be created
Example output:
SQL> connect perfstat/perfstat_password
Connected.
SQL> @sprepins
Completed Snapshots
Snap Snap
Instance DB Name Id Snap Started Level Comment
------------ ------------ ----- ----------------- ----- ----------------------
prd1 PRD1 37 02 Mar 2001 11:01 6
38 02 Mar 2001 12:01 6
39 08 Mar 2001 09:01 5
40 08 Mar 2001 10:02 5
5.3. Changing the default values for Snapshot Level and SQL Thresholds
If you wish to, you can change the default parameters used for taking
snapshots, so that they are tailored to the instance's workload.
The full list of parameters which can be passed into the
modify_statspack_parameter procedure are the same as those for the
snap procedure. These are listed in section 5.6. below.
7. Event Timings
-----------------
If timings are available, the Statspack report will order wait events by time
(in the Top-5 and background and foreground Wait Events sections).
If timed_statistics is false for the instance, however a subset of users or
programs set timed_statistics set to true dynamically, the Statspack report
output may look inconsistent, where some events have timings (those which the
individual programs/users waited for), and the remaining events do not.
The Top-5 section will also look unusual in this situation.
Optimally, timed_statistics should be set to true at the instance level for
ease of diagnosing performance problems.
sprepsql.sql
o 'All Optimizer Plan(s) for this Hash Value' change:
Instead of showing the first time a plan was seen for a specific hash
value, this section now shows each time the Optimizer Plan
changed since the SQL statement was first seen e.g. if the SQL statement
had the following plan changes:
snap ids plan hash value
-------- ---------------
1 -> 12 AAAAAAA
13 -> 134 BBBBBBB
145 -> 299 CCCCCCC
300 -> 410 AAAAAAA
Then this section of the report will now show:
snap id plan hash value
-------- ---------------
1 AAAAAAA
13 BBBBBBB
145 CCCCCCC
300 AAAAAAA
Previously, only the rows with snap_id's 1, 13 and 145 would have been
displayed, as these were the first snap Id's these plans were found.
However this data could not show that plan AAAAAA was found again in
snap_id 300.
The new output format makes it easier to see when an older plan is again
in use. This is possible due to the change in the SQL Plan Usage
capture (described above).
Data Compatibility
~~~~~~~~~~~~~~~~~~
Prior to release 9.0, the STATS$ENQUEUESTAT table gathered data based on
an X$ table, rather than a V$view. In 9.0, the column data within the
underlying X$ table has been considerably improved, and the data
externalised via the V$ENQUEUE_STAT view.
The Statspack upgrade script spup817.sql migrates the data captured from
prior releases into the new format, in order to avoid losing historical data.
Note however, that the column names and data contained within the columns
has changed considerably between the two releases: the STATS$ENQUEUE_STAT
columns in 9.0 capture different data to the columns which existed in the
STATS$ENQUEUESTAT table in the 8.1. Statspack releases.
The column data migration performed by spup817.sql is as follows:
8.1 STATS$ENQUEUESTAT 9.0 STATS$ENQUEUE_STAT
--------------------- ----------------------
GETS TOTAL_REQ#
WAITS TOTAL_WAIT#
Upgrading
Must be run as SYSDBA
spup90.sql -> Converts data from the 9.0 schema to the
newer 9.2 schema. Backup the existing schema
before running the upgrade. If upgrading from
Statspack 8.1.6, spup816.sql must be run, then
spup817.sql, then spup90.sql
spup817.sql -> Converts data from the 8.1.7 schema to the
newer 9.0 schema. Backup the existing schema
before running the upgrade. If upgrading from
Statspack 8.1.6, spup816.sql must be run, then
spup817.sql
spup816.sql -> Converts data from the 8.1.6 schema to the
8.1.7 schema. Backup the existing schema
before running the upgrade.
Documentation
Should be read by the DBA running the scripts
spdoc.txt -> This file contains instructions and
documentation on the STATSPACK package.
15.2. Modifications
All Statspack code is Oracle proprietary and must not be modified. Any
modifications made to Statspack software will render the code and
data captured thereafter unsupported; unsupported changes may result in
errors in data capture or reporting. Instead, please request
enhancements.
-------------------------------------------------------------------------