Oracle9i Server Release 9.2 Production ...

8/14/2019 Oracle9i Server Release 9.2 Production Copyright (C)

http://slidepdf.com/reader/full/oracle9i-server-release-92-production-copyright-c 1/35

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

Oracle9i Server

Release 9.2

Production

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

Copyright (C) 1993, 2002, Oracle Corporation. All rights reserved.

Author: Connie Dialeris GreenContributors: 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.

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

Statistics Package (STATSPACK) README (spdoc.txt)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TABLE OF CONTENTS-----------------

0. Introduction and Terminology1. Oracle Enterprise Manager (EM) and Statspack2. Statspack Configuration

2.1. Database Space Requirements2.2. Installing the Tool2.3. Errors during Installation

3. Gathering data - taking a snapshot3.1. Automating Statistics Gathering3.2. Using dbms_job

4. Running the Performance reports4.1. Running the instance report4.2. Running the instance report when there are multiple instances

4.3. Running the SQL report4.4. Gathering optimizer statistics on the PERFSTAT schema5. Configuring the amount of data captured

5.1. Snapshot Level5.2. Snapshot SQL thresholds5.3. Changing the default values for Snapshot Level and SQL Thresholds5.4. Snapshot Levels - details5.5. Specifying a Session Id5.6. Input Parameters for the SNAP and

MODIFY_STATSPACK_PARAMETERS procedures6. Time Units used for Performance Statistics7. Event Timings8. Managing and Sharing performance data

8.1. Sharing data via export8.2. Purging/removing unnecessary data8.3. Removing all data



9. New and Changed Features9.1. Changes between 9.0 and 9.29.2. Changes between 8.1.7 and 9.09.3. Changes between 8.1.6 and 8.1.7

10. Compatibility and Upgrading from previous releases10.1. Compatibility Matrix

10.1.1. Using Statspack shipped with 9.2

10.1.2. Using Statspack shipped with 9.010.1.3. Using Statspack shipped with 8.1.7 on 9i releases

10.2. Upgrading an existing Statspack schema to a newer release10.2.1. Upgrading the Statspack schema from 9.0 to 9.210.2.2. Upgrading the Statspack schema from 8.1.7 to 9.010.2.3. Upgrading the Statspack schema from 8.1.6 to 8.1.710.2.4. Upgrading the Statspack schema from 8.1.6 to 9.210.2.5. Upgrading the Statspack schema from 8.1.6 to 9.010.2.6. Upgrading the Statspack schema from 8.1.7 to 9.2

11. Oracle Real Application Clusters specific considerations11.1. Changing Instance Numbers11.2. Cluster Specific Report

11.3. Cluster Specific Data12. Conflicts and differences compared to UTLBSTAT/UTLESTAT12.1. Running BSTAT/ESTAT in conjunction to Statspack12.2. Differences between Statspack and BSTAT/ESTAT

13. Removing the package14. Supplied Scripts Overview15. Limitations and Modifications

15.1. Limitations15.2. Modifications

0. Introduction and Terminology--------------------------------

To effectively perform reactive tuning, it is vital to have an establishedbaseline for later comparison when the system is running poorly. Withouta baseline data point, it becomes very difficult to identify what a newproblem is attributable to: Has the volume of transactions on the systemincreased? Has the transaction profile or application changed? Has thenumber of users increased?

Statspack fundamentally differs from the well known UTLBSTAT/UTLESTATtuning scripts by collecting more information, and also by storing theperformance statistics permanently in Oracle tables, which can laterbe used for reporting and analysis. The data collected can be analyzedusing the report provided, which includes an 'instance health and load'summary page, high resource SQL statements, as well as the traditionalwait events and initialization parameters.

Statspack improves on the existing UTLBSTAT/UTLESTAT performance scriptsin the following ways:

- Statspack collects more data, including high resource SQL(and the optimizer execution plans for those statements)

- Statspack pre-calculates many ratios useful when performancetuning, such as cache hit ratios, per transaction and persecond statistics (many of these ratios must be calculated

manually when using BSTAT/ESTAT)

- Permanent tables owned by PERFSTAT store performance statistics;



instead of creating/dropping tables each time, data is insertedinto the pre-existing tables. This makes historical datacomparisons easier

- Statspack separates the data collection from the report generation.Data is collected when a 'snapshot' is taken; viewing the datacollected is in the hands of the performance engineer when he/she

runs the performance report

- Data collection is easy to automate using either dbms_job or anOS utility

NOTE: The term 'snapshot' is used to denote a set of statistics gatheredat a single time, identified by a unique Id which includes thesnapshot number (or snap_id). This term should not be confusedwith Oracle's Snapshot Replication technology.

How does Statspack work?

Statspack is a set of SQL, PL/SQL and SQL*Plus scripts which allow thecollection, automation, storage and viewing of performance data. A useris automatically created by the installation script - this user, PERFSTAT,owns all objects needed by this package. This user is granted limitedquery-only privileges on the V$views required for performance tuning.

Statspack users will become familiar with the concept of a 'snapshot'.'snapshot' is the term used to identify a single collection ofperformance data. Each snapshot taken is identified by a 'snapshot id'which is a unique number generated at the time the snapshot is taken;each time a new collection is taken, a new snap_id is generated.

The snap_id, along with the database identifier (dbid) and instance number(instance_number) comprise the unique key for a snapshot (using thisunique combination allows storage of multiple instances of a Clustereddatabase in the same tables).

Once snapshots are taken, it is possible to run the performance report.The performance report will prompt for the two snapshot id's the reportwill process. The report produced calculates the activity on the instancebetween the two snapshot periods specified, in a similar way to theBSTAT/ESTAT report; to compare - the first snap_id supplied can beconsidered the equivalent of running BSTAT; the second snap_idspecified can be considered the equivalent of ESTAT. Unlike BSTAT/ESTATwhich can by it's nature only compare two static data points, the reportcan compare any two snapshots specified.

1. Oracle Enterprise Manager (EM) and Statspack------------------------------------------------

Statspack allows you to capture Oracle instance-related performance data,and report on this data in a textual format.

Oracle Enterprise Manager Diagnostics Pack offers extended features including

capturing related operating system, middle-tier and application performancedata for end-to-end diagnostics.



The Oracle Diagnostics Pack can automatically analyze this performance data,display it in a graphical interface, and use alerts to immediately directyou to any performance problems. In addition, you can be alertedautomatically via email or page when a problem is detected. OracleEnterprise Manager also includes an integrated diagnostics methodologythat uses guided drilldowns and expert advice to help you quickly resolveperformance issues.

EM also allows you the ability to store the captured data in a separateperformance repository database, and to store the performance data formultiple databases in the same repository.

For more information about Oracle Enterprise Manager or for a trial license,visit the Oracle website (www.oracle.com) or the Oracle Store website(oraclestore.oracle.com).

2. Statspack Configuration---------------------------

2.1. Database Space Requirements

The amount of database space required by the package will vary considerablybased 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 spaceutilization predictions which will be accurate at each site.

The default initial and next extent sizes are 100k, 1MB, 3MB or 5MB for allStatspack tables and indexes. To install Statspack, the minimumspace requirement is approximately 100MB.

Locally Managed Tablespaces---------------------------If you install the package in a locally-managed tablespace, modifyingstorage clauses is not required, as the storage characteristics areautomatically managed.

Dictionary Managed Tablespaces------------------------------If you install the package in a dictionary-managed tablespace, Oraclesuggests you monitor the space used by the objects created, and adjustthe storage clauses of the segments, if required.

2.2. Installing the Tool

Installation scripts create a user called PERFSTAT, which will own allPL/SQL code and database objects created(including the STATSPACK tables, constraints and the STATSPACK package).

During the installation you will be prompted for the PERFSTATuser's password and default and temporary tablespaces.

The default tablespace will be used to create all Statspack

objects (such as tables and indexes). The temporary tablespacewill be used for sort-type activities (for more information ontemporary tablespaces, see the Oracle9i Concepts Manual).





variables which specify the password and the default and temporarytablespaces before running spcreate.

The variables are:perfstat_password -> for the passworddefault_tablespace -> for the default tablespacetemporary_tablespace -> for the temporary tablespace

e.g.on Unix:SQL> connect / as sysdbaSQL> define default_tablespace='tools'SQL> define temporary_tablespace='temp'SQL> define perfstat_password='erg8oiw'SQL> @?/rdbms/admin/spcreateSQL> undefine perfstat_password

spcreate will no longer prompt for the above information.

2.3. Errors during installation

A common error made during Statspack installation is running the installscript from Server Manager (svrmgrl) rather than from SQL*Plus. If youuse svrmgrl, the installation will fail.

Another possible error during installation is to specify the SYSTEMtablespace for the PERFSTAT user's DEFAULT or TEMPORARY tablespace.In such a situation, the installation will fail, stating the problem.

To correctly install Statspack after such errors, first run thede-install script, then the install script. Both scripts must berun from SQL*Plus.

e.g. Start SQL*Plus, connect as a user with SYSDBA privilege, then:SQL> @spdropSQL> @spcreate

3. Gathering data - taking a snapshot--------------------------------------

The simplest interactive way to take a snapshot is to login to SQL*Plusas the PERFSTAT user, and execute the procedure Statspack.snap:

e.g.SQL> connect perfstat/perfstat_passwordSQL> execute statspack.snap;

Note: In a Clustered database environment, you must connect to theinstance you wish to collect data for.

This will store the current values for the performance statisticsin the Statspack tables, and can be used as a baseline snapshotfor comparison with another snapshot taken at a later time.

For better performance analysis, set the initialization parametertimed_statistics to true; this way, Statspack data collected will include



important timing information. The timed_statistics parameter is alsodynamically changeable using the 'alter system' command. Timing data isimportant and is usually required by Oracle support to diagnose performanceproblems.

Typically, in the situation where you would like to automate the gatheringand reporting phases (such as during a benchmark), you may need to know the

snap_id of the snapshot just taken. To take a snapshot and display thesnap_id, call the statspack.snap function. Below is an example of callingthe snap function using an anonymous PL/SQL block in SQL*Plus:

e.g.SQL> variable snap number;SQL> begin :snap := statspack.snap; end;2 /

PL/SQL procedure successfully completed.SQL> print snap

SNAP----------

12

3.1. Automating statistics gathering

To be able to make comparisons of performance from one day, week oryear to the next, there must be multiple snapshots taken over a periodof time.

The best method to gather snapshots is to automate the collection ona regular time interval. It is possible to do this:

- within the database, using the Oracle dbms_job procedure to

schedule the snapshots

- using Operating System utilities (such as 'cron' on Unix or 'at' onNT) to schedule the snapshot

3.2. Using dbms_job

To use an Oracle-automated method for collecting statistics, you can usedbms_job. A sample script on how to do this is supplied in spauto.sql,which schedules a snapshot every hour, on the hour.

You may wish to schedule snapshots at regular times each day to reflect yoursystem's OLTP and/or batch peak loads. For example take snapshots at 9am,10am, 11am, 12 midday and 6pm for the OLTP load, then a snapshot at12 midnight and another at 6am for the batch window.

In order to use dbms_job to schedule snapshots, the job_queue_processesinitialization parameter must be set to greater than 0 for the job torun automatically.

Example of setting the job_queue_processes parameter in an init.ora file:# Set to enable the job queue process to start. This allows dbms_job# to schedule automatic statistics collection using STATSPACKjob_queue_processes=1

If using spauto.sql in a Clustered database environment, the spauto.sqlscript must be run once on each instance in the cluster. Similarly, the



job_queue_processes parameter must also be set for each instance.

Changing the interval of statistics collection~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~To change the interval of statistics collection use the dbms_job.intervalprocedure

e.g.execute dbms_job.interval(1,'SYSDATE+(1/48)');

Where 'SYSDATE+(1/48)' will result in the statistics being gathered each1/48 hours (i.e. every half hour).

To force the job to run immediately,execute dbms_job.run(<job number>);

To remove the autocollect job,execute dbms_job.remove(<job number>);

For more information on dbms_job, see the Supplied Packages ReferenceManual.

4. Running the Performance reports-----------------------------------

Once snapshots are taken, it is possible to generate a performance report.There are two reports:

- spreport.sql (and sprepins.sql)is a general instance health report, covering all aspects of instance

performance. The instance report calculate and print ratios,increases etc. for all statistics between the two snapshot periods,in a similar way to the BSTAT/ESTAT report.

Note: spreport.sql calls sprepins.sql, first defaulting the dbid andinstance number of the instance you are connected to. For moreinformation on the difference between sprepins and spreport,see section 4.2 Running the instance report when there aremultiple instances.

- sprepsql.sqlis a report for a specific SQL statement. The SQL report is usuallyrun after examining the high-load SQL sections of the instance healthreport. The SQL report provides detailed statistics and data for asingle SQL statement (as identified by the Hash Value).

Both reports prompt for the beginning snapshot id, the ending snapshot id,and the report name. The SQL report additionally requests the Hash Valuefor the SQL statement to be reported on.

Note: It is not correct to specify begin and end snapshots where thebegin snapshot and end snapshot were taken from differentinstance startups. In other words, the instance must not havebeen shutdown between the times that the begin and end snapshotswere taken.

The reason for this requirement is the database's dynamicperformance tables which Statspack queries to gather the dataare memory resident, hence shutting down the database will





----------- ------------ -------- ------------2618106428 PRD1 1 prd1

Instances in this Statspack schema~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host----------- -------- ------------ ------------ ------------2618106428 1 PRD10 prd1 dlsun525

Using 261810642 for database IdUsing 1 for instance number

Completed Snapshots

Snap SnapInstance DB Name Id Snap Started Level Comment

------------ ------------ ----- ----------------- ----- ----------------------prd1 PRD1 1 11 May 2000 12:07 52 11 May 2000 12:08 5

3 12 May 2000 07:07 54 12 May 2000 08:08 5

Specify the Begin and End Snapshot Ids~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Enter value for begin_snap: 1Begin Snapshot Id specified: 1

Enter value for end_snap:End Snapshot Id specified: 2

Specify the Report Name~~~~~~~~~~~~~~~~~~~~~~~The default report file name is sp_1_2 To use this name,press <return> to continue, otherwise enter an alternative.Enter value for report_name: <press return or enter a new name>

Using the report name sp_1_2

The report will now scroll past, and also be written to the filespecified (e.g. sp_1_2.lis).

Batch mode report generation~~~~~~~~~~~~~~~~~~~~~~~~~~~~To run a report without being prompted, assign values to theSQL*Plus variables which specify the begin snap id, the end snap idand the report name before running spreport.

The variables are:begin_snap -> specifies the begin Snapshot Id

end_snap -> specifies the end Snapshot Idreport_name -> specifies the Report output name



e.g.on Unix:SQL> connect perfstat/perfstat_passwordSQL> define begin_snap=1SQL> define end_snap=2SQL> define report_name=batch_runSQL> @?/rdbms/admin/spreport

spreport will no longer prompt for the above information.

4.2. Running the instance report when there are multiple instances

spreport.sql assumes you are connected to the database you wish to reporton. There are certain situations where this assumption may not bevalid:

- In a clustered database environment, you may be connected toan instance which is not the instance you wish to report on

- If you are archiving baseline Statspack data in a separate databasefrom 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 Statspackinstance report using spreport.sql, as the instance assumed may beunavailable, possibly on a totally different host.

To circumvent this problem, you should run the sprepins.sql reportinstead. The sprepins.sql report output is identical to thespreport.sql output, as spreport.sql simply calls sprepins.sql, firstdefaulting 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 andInstance Number for the instance you wish to report on, in additionto the begin_snap and end_snap Ids and report output name (i.e. thecurrent DBId and Instance Number are not defaulted).

You will be prompted for:

1. The DBId2. The Instance Number3. The beginning snapshot Id4. The ending snapshot Id5. The name of the report text file to be created

Example output:SQL> connect perfstat/perfstat_passwordConnected.SQL> @sprepins

Instances in this Statspack schema~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

----------- -------- ------------ ------------ ------------590400074 1 CON90 con90 dlsun5254290976145 1 MAIL MAIL mailhost



Enter value for dbid: 4290976145Using 4290976145 for database IdEnter value for inst_num: 1

Then similarly to spreport, the available snapshots are displayed,and the begin and end snaps and report name are prompted for.

Batch mode report generation~~~~~~~~~~~~~~~~~~~~~~~~~~~~To run the sprepins.sql report without being prompted, assign valuesto the SQL*Plus variables which specify the dbid, instance number,begin snap id, the end snap id, and the report name, before runningspreport.

The variables are:dbid -> specifies the dbid

inst_num -> specifies the instance numberbegin_snap -> specifies the begin Snapshot Idend_snap -> specifies the end Snapshot Idreport_name -> specifies the Report output name

e.g.SQL> connect perfstat/perfstat_passwordSQL> define dbid=4290976145SQL> define inst_num=1SQL> define begin_snap=1SQL> define end_snap=2SQL> define report_name=batch_runSQL> @?/rdbms/admin/sprepins

sprepins will no longer prompt for the above information.

4.3. Running the SQL report

Once the instance report has been analyzed, often there are high-load SQLstatements which should be examined to determine if they are causingunnecessary load.

The SQL report sprepsql.sql, displays statistics, the complete SQL textand (if level 6 snapshot has been taken), information on any SQL Plan(s)associated with that statement.

The SQL statement to be reported on is identified by the statement's HashValue (which is a numerical representation of the statement's SQL text).The Hash Value for each statement is displayed in the high-load SQLsections of the instance report.

The sprepsql.sql file is executed while being connected to the PERFSTATuser, and is located in the rdbms/admin directory of the Oracle Home.

Note: To run sprepsql.sql in a Cluster environment, you must connectto the instance you wish to report on.

You will be prompted for:1. The beginning snapshot Id2. The ending snapshot Id



3. The Hash Value for the SQL statement4. The name of the report text file to be created

Example output:SQL> connect perfstat/perfstat_passwordConnected.SQL> @sprepsql

DB Id DB Name Inst Num Instance----------- ------------ -------- ------------2618106428 PRD1 1 prd1

Completed Snapshots

Snap SnapInstance DB Name Id Snap Started Level Comment------------ ------------ ----- ----------------- ----- ----------------------

prd1 PRD1 37 02 Mar 2001 11:01 638 02 Mar 2001 12:01 6

39 08 Mar 2001 09:01 540 08 Mar 2001 10:02 5

Specify the Begin and End Snapshot Ids~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Enter value for begin_snap: 39Begin Snapshot Id specified: 39

Enter value for end_snap: 40

End Snapshot Id specified: 40

Specify the Hash Value~~~~~~~~~~~~~~~~~~~~~~Enter value for hash_value: 1988538571Hash Value specified is: 1988538571

Specify the Report Name~~~~~~~~~~~~~~~~~~~~~~~The default report file name is sp_39_40_1988538571. To use this name,press <return> to continue, otherwise enter an alternative.Enter value for report_name:

Using the report name sp_39_40_1988538571

The report will scroll past, and also be written to the filespecified (e.g. sp_39_40_1988538571.lis).

Batch mode report generation~~~~~~~~~~~~~~~~~~~~~~~~~~~~Similarly to spreport.sql, the SQL report can be run in batch mode.To run a report without being prompted, assign values to theSQL*Plus variables which specify the begin snap id, the end snap id,

the SQL hash value, and the report name before running spreport.

The variables are:



begin_snap -> specifies the begin Snapshot Idend_snap -> specifies the end Snapshot Idhash_value -> specifies the Hash Valuereport_name -> specifies the Report output name

e.g.SQL> connect perfstat/perfstat_password

SQL> define begin_snap=39SQL> define end_snap=40SQL define hash_value=1988538571SQL> define report_name=batch_sql_runSQL> @sprepsql

sprepsql will no longer prompt for the above information.

4.4. Gathering Optimizer statistics on the PERFSTAT schema

For best performance when running the performance reports, collect

optimizer statistics for tables and indexes owned by PERFSTAT. Thisshould be performed whenever significant change in data volumes inPERFSTAT's tables. To do this, either to use dbms_stats, or dbms_utility,and specify the PERFSTAT user:

execute dbms_stats.gather_schema_stats(ownname=>'PERFSTAT',cascade=>true);or

execute dbms_utility.analyze_schema('PERFSTAT','COMPUTE');

5. Configuring the amount of data captured~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Both the snapshot level, and the thresholds specified will affect the amountof data Statspack captures.

5.1. Snapshot Level

It is possible to change the amount of information gathered by the package,by specifying a different snapshot 'level'. In other words, the levelchosen (or defaulted) will decide the amount of data collected.The higher the snapshot level, the more data is gathered. The defaultlevel set by the installation is level 5.

For typical usage, level 5 snapshot is effective on most sites. Thereare certain situations when using a level 6 snapshot is beneficial, suchas when taking a baseline.

The events listed below are a subset of events which should prompttaking a new baseline, using level 6:- when taking the first snapshots- when a new application is installed, or an application is modified/upgraded- after gathering optimizer statistics- before and after upgrading

The various levels are explained in detail section 5.4 below.

5.2. Snapshot SQL thresholds

There are other parameters which can be configured in addition to the



snapshot level.

These parameters are used as thresholds when collecting data on SQLstatements; data will be captured on any SQL statements that breachthe specified thresholds.

Snapshot level and threshold information used by the package is stored

in the stats$statspack_parameter table.

5.3. Changing the default values for Snapshot Level and SQL Thresholds

If you wish to, you can change the default parameters used for takingsnapshots, so that they are tailored to the instance's workload.

The full list of parameters which can be passed into themodify_statspack_parameter procedure are the same as those for thesnap procedure. These are listed in section 5.6. below.

Temporarily using new values~~~~~~~~~~~~~~~~~~~~~~~~~~~~To temporarily use a snapshot level or threshold which is different tothe instance's default snapshot values, simply specify the requiredthreshold or snapshot level when taking the snapshot. This value willonly be used for immediate snapshot taken - the new value willnot be saved as the default.

e.g. Take a single level 6 snapshot (do not save level 6 as the default):SQL> execute statspack.snap(i_snap_level=>6);

Saving new defaults~~~~~~~~~~~~~~~~~~~~If you wish to save the new value as the instance's default, you can dothis either by:

o Taking a snapshot, and specifying the new defaults to be saved to thedatabase (using statspack.snap, and using the i_modify_parameterinput variable).

SQL> execute statspack.snap -(i_snap_level=>10, i_modify_parameter=>'true');

Setting the i_modify_parameter value to true will save the newthresholds in the stats$statspack_parameter table; these thresholdswill be used for all subsequent snapshots.

If the i_modify_parameter was set to false or if it were omitted, thenew parameter values would not be saved. Only the snapshot taken atthat point will use the specified values, any subsequent snapshots willuse the preexisting values in the stats$statspack_parameter table.

o Changing the defaults immediately without taking a snapshot, using thestatspack.modify_statspack_parameter procedure. For example to changethe snapshot level to 10, and the SQL thresholds for buffer_gets anddisk_reads, the following statement can be issued:

SQL> execute statspack.modify_statspack_parameter -(i_snap_level=>10, i_buffer_gets_th=>10000, i_disk_reads_th=>1000);



This procedure changes the values permanently, but does nottake a snapshot.

5.4 Snapshot Levels - details

Levels >= 0 General performance statisticsStatistics gathered:This level and any level greater than 0 collects generalperformance statistics, such as: wait statistics, system events,system statistics, rollback segment data, row cache, SGA, backgroundevents, session events, lock statistics, buffer pool statistics,latch statistics, resource limit, enqueue statistics, and statisticsfor each of the following, if enabled: automatic undo management,buffer cache advisory data, auto PGA memory management, Cluster DBstatistics.

Levels >= 5 Additional data: SQL Statements

This level includes all statistics gathered in the lower level(s),and additionally gathers the performance data on high resourceusage SQL statements.

In a level 5 snapshot (or above), note that the time required for thesnapshot to complete is dependent on the shared_pool_size and on thenumber of SQL statements in the shared pool at the time the snapshotis taken: the larger the shared pool, the longer the time taken tocomplete the snapshot.

SQL 'Thresholds'The SQL statements gathered by Statspack are those which exceed one ofsix predefined threshold parameters:

- number of executions of the SQL statement (default 100)- number of disk reads performed by the SQL statement (default 1,000)- number of parse calls performed by the SQL statement (default 1,000)- number of buffer gets performed by the SQL statement (default 10,000)- size of sharable memory used by the SQL statement (default 1m)- version count for the SQL statement (default 20)

The values of each of these threshold parameters are used whendeciding which SQL statements to collect - if a SQL statement'sresource usage exceeds any one of the above threshold values, itis captured during the snapshot.

The SQL threshold levels used are either those stored in the tablestats$statspack_parameter, or by the thresholds specified whenthe snapshot is taken.

Levels >= 6 Additional data: SQL Plans and SQL Plan usageThis level includes all statistics gathered in the lower level(s),and additionally gathers optimizer execution plans, and plan usagedata for each of the high resource usage SQL statements captured.

A level 6 snapshot gathers information which is invaluable whendetermining whether the execution plan used for a SQL statementhas changed. Therefore level 6 snapshots should be usedwhenever there is the possibility a plan may change, such as

after large data loads, or after gathering new optimizerstatistics.



To capture the plan for a SQL statement, the statement must be in theshared pool at the time the snapshot is taken, and must exceed one ofthe SQL thresholds. To gather plans for all statements in theshared pool, you can temporarily specify the executions threshold(i_executions_th) to be zero (0) for those snapshots. For informationon how to do this, see section 5.3. above.

Levels >= 7 Additional data: Segment level statisticsThis level includes all statistics gathered in the lower level(s),and additionally gathers the performance data on highly used segments.

A level 7 snapshot gathers information which determines what segments aremore heavily accessed and contended.With this information, you can decide to modify the physical layoutof some segments or of the tablespaces they reside in.For example, to better spread the segment io load, you can add filesresiding on different disks to a tablespace storing a heavily accessedsegment or you can (re)partition a segment. This information can also helpdecide on changing segment attributes values such as PCTFREE

and/or INITRANS. On a RAC environment, this information allows us to easilyspot the segments responsible for much of the cross-instance traffic.

Segment statistics are:- logical reads- db block changes- physical reads- physical writes- physical reads direct- physical writes direct- global cache cr blocks served (RAC specific)- global cache current blocks served (RAC specific)- buffer busy waits

- ITL waits- row lock waits

Although statspack capture all segment statistics, it reports only thefollowing statistics:

- logical reads- physical reads- buffer busy waits- ITL waits- row lock waits- global cache cr blocks served (RAC only)- global cache current blocks served (RAC only)

Segment statistics 'Thresholds'The segments gathered by Statspack are those which exceed one ofseven predefined threshold parameters:- number of logical reads on the segment (default 10,000)- number of physical reads on the segment (default 1,000)- number of buffer busy waits on the segment (default 100)- number of row lock waits on the segment (default 100)- number of ITL waits on the segment (default 100)- number of global cache ConsistentRead blocks served-RAC (default 1000)- number of global cache CUrrent blocks served (RAC) (default 1000)

The values of each of these threshold parameters are used when

deciding which segment statistics to collect - if a segment's statisticexceeds any one of the above threshold values, all statisticsregarding this segment are captured during the snapshot.



The threshold levels used are either those stored in the tablestats$statspack_parameter, or by the thresholds specified whenthe snapshot is taken.

Levels >= 10 Additional statistics: Parent and Child latches

This level includes all statistics gathered in the lower levels, and

additionally gathers Parent and Child Latch information. Datagathered at this level can sometimes cause the snapshot to take longerto complete i.e. this level can be resource intensive, and shouldonly be used when advised by Oracle personnel.

5.5. Specifying a Session Id

If you would like to gather session statistics and wait events for aparticular session (in addition to the instance statistics and wait events),it is possible to specify the session id in the call to Statspack. Thestatistics gathered for the session will include session statistics,

session events and lock activity. The default behaviour is to not togather session level statistics.

SQL> execute statspack.snap(i_session_id=>3);

5.6. Input Parameters for the SNAP and MODIFY_STATSPACK_PARAMETERS procedures

Parameters able to be passed in to the statspack.snap andstatspack.modify_statspack_parameter procedures are as follows:

Range of DefaultParameter Name Valid Values Value Meaning

------------------ ------------ ------- -----------------------------------i_snap_level 0, 5,6,7, 10 5 Snapshot Leveli_ucomment Text Blank Comment to be stored with Snapshoti_executions_th Integer >=0 100 SQL Threshold: number of times

the statement was executedi_disk_reads_th Integer >=0 1,000 SQL Threshold: number of disk reads

the statement madei_parse_calls_th Integer >=0 1,000 SQL Threshold: number of parse

calls the statement madei_buffer_gets_th Integer >=0 10,000 SQL Threshold: number of buffer

gets the statement madei_sharable_mem_th Integer >=0 1048576 SQL Threshold: amount of sharable

memoryi_version_count_th Integer >=0 20 SQL Threshold: number of versions

of a SQL statementi_seg_phy_reads_th Integer >=0 1,000 Segment statistic Threshold: number

of physical reads on a segment.i_seg_log_reads_th Integer >=0 1,0000 Segment statistic Threshold: number

of logical reads on a segment.i_seg_buff_busy_th Integer >=0 100 Segment statistic Threshold: number

of buffer busy waits for a segment.i_seg_rowlock_w_th Integer >=0 100 Segment statistic Threshold: number

of row lock waits for a segment.i_seg_itl_waits_th Integer >=0 100 Segment statistic Threshold: number

of itl waits for a segment.

i_seg_cr_bks_sd_th Integer >=0 1000 Segment statistic Threshold: numberof Consistent Reads blocks served bythe instance for the segment (RAC).



i_seg_cu_bks_sd_th Integer >=0 1000 Segment statistic Threshold: numberof CUrrent blocks served by theinstance for the segment (RAC).

i_session_id Valid sid 0 (no Session Id of the Oracle Sessionfrom session) to capture session granularv$session statistics for

i_modify_parameter True, False False Save the parameters specified for

future snapshots?

6. Time Units used for Performance Statistics----------------------------------------------

Oracle now supports capturing certain performance data with millisecond andmicrosecond granularity.

Views which include microsecond timing include:- v$session_wait, v$system_event, v$session_event (time_waited_micro column)

- v$sql, v$sqlarea (cpu_time, elapsed_time columns)- v$latch, v$latch_parent, v$latch_children (wait_time column)- v$sql_workarea, v$sql_workarea_active (active_time column)

Views which include millisecond timings include:- v$enqueue_stat (cum_wait_time)

Note that existing columns in other views continue to capture centi-secondtimes.

As centi-second and microsecond timing may not be appropriate for rolledup data such as that displayed by Statspack, Statspack displays mostcumulative times in seconds, and average times in milliseconds (for easier

comparison with Operating System monitoring utilities which often reporttimings in milliseconds).

For clarity, the time units used are specified in the column headings ofeach timed column in the Statspack report. The convention used is:

(s) - a second(cs) - a centisecond - which is 100th of a second(ms) - a millisecond - which is 1,000th of a second(us) - a microsecond - which is 1,000,000th of a second

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 orprograms set timed_statistics set to true dynamically, the Statspack reportoutput may look inconsistent, where some events have timings (those which theindividual 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 forease of diagnosing performance problems.

8. Managing and Sharing performance data



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

8.1. Sharing data via export

If you wish to share data with other sites (for example if OracleSupport requires the raw statistics), it is possible to exportthe PERFSTAT user.

An export parameter file (spuexp.par) has been supplied for thispurpose. To use this file, supply the export command with theuserid parameter, along with the export parameter file name.e.g.exp userid=perfstat/perfstat_password parfile=spuexp.par

This will create a file called spuexp.dmp and the log file spuexp.log

If you wish to load the data into another database, use the importcommand. For more information on using export and import, pleasesee the Oracle Utilities manual.

8.2. Purging/removing unnecessary data

It is possible to purge unnecessary data from the PERFSTAT schema usingsppurge.sql. This script deletes snapshots which fall betweenthe begin and end range of Snapshot Id's specified.

NOTE:It is recommended you export the schema as a backup before running thisscript, either using your own export parameters, or those provided inspuexp.par

Purging may require the use of a large rollback segment, as all datarelating each Snapshot Id to be purged will be deleted.To avoid rollback segment extension errors, explicitly use a largerollback segment. This can be done by executing the 'set transactionuse rollback segment..' command before running the sppurge.sql script(for more information on the set transaction command see the SQL referencemanual). Alternatively, to avoid rollback segment extension errorsspecify a smaller range of Snapshot Id's to purge.

When sppurge is run, the instance currently connected to and theavailable snapshots are displayed. The DBA is then prompted for thelow Snap Id and high Snap Id. All snapshots which fall within thisrange will be purged.

e.g. Purging data - connect to PERFSTAT using SQL*Plus, then run thescript - an example output appears below.

SQL> connect perfstat/perfstat_passwordSQL> set transaction use rollback segment rbig;SQL> @sppurge

Database Instance currently connected to========================================

InstanceDB Id DB Name Inst Num Name

----------- ---------- -------- ----------720559826 PERF 1 perf



Snapshots for this database instance====================================

SnapSnap Id Level Snapshot Started Host Comment

---------- ----- --------------------- --------------- -------------------1 5 30 Feb 2000 10:00:01 perfhost

2 5 30 Feb 2000 12:00:06 perfhost3 5 01 Mar 2000 02:00:01 perfhost4 5 01 Mar 2000 06:00:01 perfhost

WARNING=======sppurge.sql deletes all snapshots ranging between the lower andupper bound Snapshot Id's specified, for the database instanceconnected to.

You may wish to export this data before continuing.

Specify the Lo Snap Id and Hi Snap Id range to purge~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Enter value for losnapid: 1Using 1 for lower bound.

Enter value for hisnapid: 2Using 2 for upper bound.

Deleting snapshots 1 - 2

Purge of specified Snapshot range complete. If you wish to ROLLBACKthe purge, it is still possible to do so. Exiting from SQL*Plus willautomatically commit the purge.

SQL> -- end of example output

Batch mode purging~~~~~~~~~~~~~~~~~~To purge in batch mode, you must assign values to the SQL*Plusvariables which specify the low and high snapshot Ids to purge.

The variables are:losnapid -> Begin Snapshot Idhisnapid -> End Snapshot Id

e.g.SQL> connect perfstat/perfstat_passwordSQL> define losnapid=1SQL> define hisnapid=2SQL> @sppurge

sppurge will no longer prompt for the above information.

8.3. Truncating all data

If you wish to truncate all performance data indiscriminately, it ispossible to do this using sptrunc.sql This script truncates allstatistics data gathered.



NOTE:It is recommended you export the schema as a backup before running thisscript either using your own export parameters, or those provided inspuexp.par

e.g. Truncating all data - connect to PERFSTAT using SQL*Plus, and run

the script - an example is below

SQL> connect perfstat/perfstat_passwordSQL> @sptrunc

About to Truncate Statspack Tables~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~NOTE:Running sptrunc.sql removes ALL data from Statspack tablesYou may wish to export the data before continuing

If you would like to continue, enter any string, followed by <return>

Enter value for anystring:entered - starting truncate operation

Table truncated.<etc>Truncate operation complete

9. New and Changed Features----------------------------

9.1. Changes between 9.0 and 9.2

Changes on the Summary Page of the Instance Report (spreport.sql)

o The Top 5 Wait Events has been changed to be the Top 5 Timed Events.

What was previously the Top 5 Wait Events has been expanded to give theTop 5 time usage within the instance: i.e. in addition to including Waitevents, this section can now include the 'CPU used by this session'statistic. This statistic will appear in the Top 5 only if it's valueis one of the the Top 5 users of time for the snapshot interval.

Note that the name of the statistic 'CPU used by this session' willactually appear in the Top 5 section as 'CPU Time'. The statisticname is masked in the Top 5 to avoid the confusion of the suffix'by this session'.The statistic will continue to appear in the System Statistics(SYSSTAT) section of the report as 'CPU used by this session'.

Additionally, instead of the percentage calculation being the % TotalWait Time (which is time for each wait event divided by the total waittime for this snapshot interval), the percentage calculation is now% Total Elapsed Time (which is time for each timed event divided bythe total elapsed time).i.e.

previously: time for each wait event / total wait time for all eventsnow: time for each timed event / total elapsed time



The total elapsed time is computed using the total wait time for allevents added to the total CPU time used for the intervali.e.total elapsed time = total wait time + total CPU time

Purpose~~~~~~~

The purpose for including CPU time with wait events:

When tuning a system, the first step is to identify where the most of thetime is spent, in order to identify where the most productive tuningeffort should be concentrated.

The majority of time could be spent in waiting for events to complete(and so be identifyable in the wait event data), or the system could beconsuming much CPU (for which Operating System statistics, and the OracleCPU statistic 'CPU used by this session' in SYSSTAT are examined).Having the CPU Time co-located with the wait events in the Top 5 sectionof the instance report makes it easier to compare the relative values

and to identify whether the most productive investigation would occurby drilling down the wait events, or in reducing Oracle CPU usage(e.g. by tuning SQL).

Changes on the Top SQL sections of the Report (spreport.sql)

o When specified by the application, the MODULE information is reportedjust before the SQL statement itself.This information is preceded by the mention "Module: "

New columns added to- stats$db_cache_advicesize_factor: compares the estimated cache size with the current cache size

- stats$sql_plansearch_columns: the number of index columns with matching predicates.access_predicates: predicates used to locate rows in an access structure.

For example, start and/or stop predicates for an index range scan.filter_predicates: predicates used to filter rows before producing them.

- stats$sql_summarychild_latch: the library cache child latch number which protects this

SQL statement (join to v$latch_children.child#). A parent SQLstatement, and all it's children are protected by the same librarycache child latch.

fetches: the number of fetches performed for this SQL statement

New Scriptso spup90.sql - Upgrades a 9.0 Statspack schema to the 9.2 format

New Data captured/reported on - Level 1- Shared Pool Advisory- PGA statistics including PGA Advisory, PGA Histogram usage

New Data captured/reported on - Level 7- Segment level Statistics

Cluster Featureso Cluster Statistics page (page 2 of a clustered database report) has

been significantly modified to add new ratios and remove ratios

deemed less-useful.o RAC specific segment level statistics are captured with level 7



SQL Plan Usage capture changedo The logic for capturing SQL Plan Usage data (level 6) has been modified

significantly. Instead of capturing a Plan's Usage once the first timethe plan is used and never again thereafter, the algorithm now capturesthe plans used each snapshot. This allows tracking whether multipleplans are in use concurrently, or whether a plan has reverted back toan older plan.

Note that plan usage data is only captured for high-load SQL (this isunchanged between 9.0 and 9.2).

Due to the significant change in data capture, it is not possible toconvert existing data. Instead, any pre-existing data will bearchived into the table STATS$SQL_PLAN_USAGE_90 (this allows queryingthe archived data, should this be necessary).

sprepsql.sqlo '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 Planchanged since the SQL statement was first seen e.g. if the SQL statementhad the following plan changes:snap ids plan hash value-------- ---------------1 -> 12 AAAAAAA13 -> 134 BBBBBBB145 -> 299 CCCCCCC300 -> 410 AAAAAAA

Then this section of the report will now show:snap id plan hash value-------- ---------------

1 AAAAAAA13 BBBBBBB145 CCCCCCC300 AAAAAAA

Previously, only the rows with snap_id's 1, 13 and 145 would have beendisplayed, as these were the first snap Id's these plans were found.However this data could not show that plan AAAAAA was found again insnap_id 300.

The new output format makes it easier to see when an older plan is againin use. This is possible due to the change in the SQL Plan Usagecapture (described above).

9.2. Changes between 8.1.7 and 9.0

Timing datao columns with cumulative times are now displayed in seconds.

Changes on the Summary Pageo All cache sizes are now reported in M or K

New Statistics on the Summary pageo open cursors per session values for the begin and end snapshot

o comments specified when taking a snapshot are displayed for thebegin and end snapshots



Latcheso The Latch Activity, Child and Parent Latch sections have the followingadditional column:- wait_time: cumulative time spent waiting for the latch

New Scriptso spup817.sql - Upgrades an 8.1.7 Statspack schema to the 9.0 format

o sprepsql.sql - Reports on a single hash_value, includingthe SQL statistics for the snapshot, the complete SQLtext and optimizer execution plan information.

o sprepins.sql - A report which can be run to query performance datafor any instance which the PERFSTAT schema contains.The report will prompt for a dbid, instance_number andbegin and end snap id's.This report can be used when importing data from anotherinstance, or in a Real Application Clusters environmentto report on an instance which you are not directlyconnected to.

New Data captured/reported on - Level 1- Data from v$resource_limit- If the instance is a Cluster instance, v$dlm_misc data- Additional columns are now captured in stats$enqueue_stat- Automatic Undo Management statistics- Buffer Cache advisory data- New Auto-PGA memory management data- Support for multiple sized-block buffer pools- Support for resizable buffer pool and shared pool- Data from v$instance_recovery

New Snapshot Level - Level 6- New SQL plans and SQL Plan usage information for high-load SQL

statements are captured.

Cluster Featureso There is additional derived data and statistics which are now included

in the Statspack report for a clustered database. For more information,see section 11.3. Cluster Specific Data

New SNAP functiono the call to take a snapshot can also be a PL/SQL function call whichreturns the snapshot Id of the snapshot taken. Using the function ratherthan the procedure is useful in situations where you wish to know thesnap_id immediately, such as when running Statspack reports in batchmode, or during benchmark runs.

Installationo The installation script will no longer accept the SYSTEM tablespace for

the PERFSTAT user's DEFAULT or TEMPORARY tablespace. If SYSTEM isspecified, the installation will error.

SQLo Each SQL report has two new columns CPU Time and Elapsed Time. These

show the cumulative CPU time and Elapsed time for all executions ofthat SQL statement for the snapshot period. If cumulative CPU andElapsed times are not shown, the CPU and Elapsed times per executeare shown.

Changedo The SGA Breakdown difference section of the statspack report now



shows the difference between begin and end values as a percentageof the begin value, rather than in bytes.

o The data in the Dictionary Cache Stats and Library Cache Activitysection are only printed if the number of gets is greater than zero.

9.3. Changes between 8.1.6 and 8.1.7

New Statistics on the Summary pageo connections at the begin snapshot and connections at the end snapshot

Load Profileo executes per transaction and per secondo logons per transaction and per second

Instance Efficiencyo % Non-Parse CPU: which is the parse time CPU / CPU used by this sessiono Parse CPU to Parse Elapsd%: which is the parse time CPU / parse time

elapsed

o Execute to Parse %: The ratio of executions to parses

Instance Efficiency - Shared Pool Statistics are shown for the begin andend snapshots.o Memory Usage %: The percentage of the shared pool which is used.o % SQL with executions>1: The percentage of reused SQL (i.e. the

percentage of SQL statements with more than one execution).o % Memory for SQL w/exec>1: The percentage of memory used for SQL

statements with more than one execution.This data is newly gathered by the 8.1.7 Statspack for level 5 snapshotsand above, and so will not evident if the report is run against olderdata captured using the 8.1.6 Statspack.

Tablespace and File IOo Tempfile statistics are now captured. The statistics for tempfiles are

shown in the same sections with statistics for datafiles and tablespaces.o The tablespace and File IO reports have been modified to include reads/s

and writes/s.

Latcheso The report has been modified to include parent and child latch

sections, which only appears in the report when a level 10 snapshotis taken.

New Scriptso sppurge.sql - Purges a range of Snapshot Idso sptrunc.sql - Deletes all datao spup816.sql - Upgrades an 8.1.6 Statspack to the 8.1.7 schema

Batch Mode executiono The installation, reporting and purge scripts (spcreate.sql, spreport.sql

and sppurge.sql) have been modified so they can be run in batch mode, ifthe appropriate SQL*Plus variables are defined before the scripts are run.

SQLo Two new SQL thresholds (and sections in the report) have been added:

sharable_mem and version_counto The report which was previously ordered by rows processed has been

changed to be ordered by executionso The full text of a SQL statement is now captured (previously only the

first 1000 bytes of the text was captured); the text is captured once



only. Previously, Statspack gathered all SQL related information,including all the SQL text for each snapshot. The new strategy willresult less space usage.

o The first 5 lines of a SQL statement are shown in each SQL report(rather than the first line)

File Rename

o The Statspack files have been renamed, with all files now beginningwith the prefix sp.The new and old file names are given below. For more information onthe purpose of each file, please see the Supplied Scripts Overviewsection.

New Name Old Name------------ -------------spdoc.txt statspack.docspcreate.sql statscre.sqlspreport.sql statsrep.sqlspauto.sql statsauto.sql

spuexp.par statsuexp.parsppurge.sql - new file -sptrunc.sql - new file -spup816.sql - new file -spdrop.sql statsdrp.sqlspcpkg.sql statspack.sqlspctab.sql statsctab.sqlspcusr.sql statscusr.sqlspdtab.sql statsdtab.sqlspdusr.sql statsdusr.sql

o The default Statspack report output file name prefix has been modifiedto sp_ (was st_) to be consistent with the new script names.

10. Compatibility and Upgrading from previous releases-------------------------------------------------------

10.1 Compatibility Matrix

Database - Statspack Release -Release 9.2 9.0 8.1.7 8.1.6-------- ----- ----- ----- -----9.2 Y - - -9.0 - Y - -8.1.7 - - Y -8.1.6 - - - Y

In summary, it is best to use the Statspack release shipped withthe version of the database you are using.

If you are already using an earlier release of Statspack must usea newer Statspack release (e.g. because you are upgrading the database),it is possible to upgrade an existing Statspack schema, and sokeep previously captured data. See the section 10.2. below whichdescribes Upgrading an existing Statspack schema to a newer release.




The Statspack scripts shipped with 9.2 can not be used with any releaseearlier than 9.2, as Statspack uses new v$views (and new columns added toexisting v$views) introduced in this server release.


The Statspack scripts shipped with 9.0 can not be used with any releaseearlier than 9.0, as the 9.2 release uses new v$views (and new columns addedto existing v$views) introduced in this server release.

10.1.3. Using Statspack shipped with 8.1.7 on 9i releases

It is not possible to use the Statspack shipped with 8.1.7 with any 9iinstance, due to the definition of an undocumented view Statspack 8i used,changing between Oracle8i and Oracle9i. Attempting to use 8.1 Statspackon an instance running 9i will result in package compilation errors.

10.2. Upgrading an existing Statspack schema to a newer release

Scripts are provided which convert performance data in an existingStatspack schema running an older Statspack release, to the newer schemaformat.

Although data conversion is not a supported activity, these scripts have beenprovided as a convenient way of keeping previously captured Statspack data.

Due to the differences in schema layout, minor irregularities may resultin statistics captured before conversion. An example of this is theEnqueue statistics data migration: do not compare Enqueue statistics data

collected pre-9.0 to the Enqueue statistics data captured in 9.0 (for moredetails, see section 10.2.2. Upgrading the Statspack schema from 8.1.7 to 9.0).

Note: There is no downgrade script. Backup the PERFSTAT schema usingexport BEFORE attempting the upgrade, in case the upgrade fails.The only method of downgrading, or re-running the upgrade is tode-install Statspack, and import a previously made export.

Before running the upgrade script, export the Statspack schema (for abackup), then disable any scripts which use Statspack, as these willinterfere with the upgrade. For example, if you use a dbms_job togather statistics, disable this job for the duration of the upgrade.

If there is a large volume of data in the Statspack schema (i.e. a largenumber of snapshots), to avoid a long upgrade time or avoid an unsuccessfulupgrade:- ensure there is enough free space in PERFSTAT's default tablespacebefore starting the upgrade (each individual upgrade section willdescribe how to estimate the required disk space)

- if you do not use Automatic Undo Management, ensure you specify a largerollback segment when prompted

- if you do not use Automatic Memory Management, ensure you specify a largesort_area_size (e.g. 1048576) when prompted

The upgrade script will prompt you for the rollback segment and sort_area_size.

If you do not need to specify a a rollback segment or sort_area_size, thensimply press return, and ignore the following errors appearing in theupgrade log file:



alter session set sort_area_size =*

ERROR at line 1:ORA-02017: integer value required

set transaction use rollback segment*

ERROR at line 1:ORA-02245: invalid ROLLBACK SEGMENT name

10.2.1. Upgrading the Statspack schema from 9.0 to 9.2

Follow the general instructions in section 10.2. 'Upgrading an existingStatspack schema to a newer release' above.

This release creates new tables and indexes, and requires approx.

20 extra MB.

To upgrade:- ensure you have sufficient free space in the tablespace- disable any programs which use Statspack- backup the Statspack schema (e.g. using export)- run the upgrade by connecting as a user with SYSDBA privilege:SQL> connect / as sysdbaSQL> @spup90

Once the upgrade script completes, check the log files (spup90a.lis andspup90b.lis) for errors. If errors are evident, determine and rectify thecause. If no errors are evident, re-enable any Statspack data

collection or reporting scripts which were previously disabled.

SQL Plan Usage Data Upgrade note:If there is more than one database in a single Statspack schema (i.e.there are multiple distinct dbid's), AND if Level 6 snapshots havebeen taken using the 9.0 release Statspack, then the SQL plan usagedata will be saved, but will not be queried by the sprepsql.sqlSQL report (this is because during the data conversion, it will notbe possible to identify which database first identified a planusage).For more details see 'SQL Plan Usage capture changed' in section9.1. Changes between 9.0 and 9.2.

10.2.2. Upgrading the Statspack schema from 8.1.7 to 9.0


Then, to estimate whether you have sufficient free space to run thisupgrade, execute the following SQL statement while connected as PERFSTAT inSQL*Plus:

select 10 + (2*sum(bytes)/1024/1024) est_space_mb

from dba_segmentswhere segment_name in ('STATS$ENQUEUESTAT');



The est_space_mb column will give you a guesstimate as to the requiredfree space, in megabytes.

To upgrade:- ensure you have sufficient free space in the tablespace- disable any programs which use Statspack- backup the Statspack schema (e.g. using export)

- run the upgrade by connecting as a user with SYSDBA privilege:SQL> connect / as sysdbaSQL> @spup817

Once the upgrade script completes, check the log files (spup817a.lis andspup817b.lis) for errors. If errors are evident, determine and rectifythe cause before proceeding. If no errors are evident, and you are upgradingto 9.2, you may proceed with the upgrade.

Data Compatibility~~~~~~~~~~~~~~~~~~

Prior to release 9.0, the STATS$ENQUEUESTAT table gathered data based onan X$ table, rather than a V$view. In 9.0, the column data within theunderlying X$ table has been considerably improved, and the dataexternalised via the V$ENQUEUE_STAT view.

The Statspack upgrade script spup817.sql migrates the data captured fromprior releases into the new format, in order to avoid losing historical data.

Note however, that the column names and data contained within the columnshas changed considerably between the two releases: the STATS$ENQUEUE_STATcolumns in 9.0 capture different data to the columns which existed in theSTATS$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#

To further emphasise the difference, the column definitions appear below:

STATS$ENQUEUESTAT.GETS - 8.1Reflected the number of enqueue gets, excluding enqueue conversions.This statistic was incremented at the end of a get.

STATS$ENQUEUE_STAT.TOTAL_REQ# - 9.0Is the total number of requests for an enqueue + the number ofenqueue conversions. This statistic is incremented at the beginningof a get request.

STATS$ENQUEUESTAT.WAITS - 8.1Reflected the number of times a session waited for at least 3seconds for an enqueue operation (get or convert). The statisticwas incremented at the end of the wait (either if the enqueue wassuccessfully gotten or if the request timed out). If a session waitedfor less than 3 seconds, this statistic was not incremented.

STATS$ENQUEUE_STAT.TOTAL_WAIT# - 9.0Is the total number of times a session waited for any enqueue operation.



This statistic is incremented at the beginning of the wait.

For these reasons it is not valid to compare Enqueue statistics datacollected pre-9.0, to Enqueue statistics data captured in Oracle9i.

10.2.3. Upgrading the Statspack schema from 8.1.6 to 8.1.7


Then, to estimate whether you have sufficient free space to run thisupgrade, execute the following SQL statement while connected as PERFSTAT inSQL*Plus:

select 1.3*sum(bytes)/1024/1024 est_space_mbfrom dba_segmentswhere segment_name in ('STATS$SQL_SUMMARY','STATS$SQL_SUMMARY_PK');

The est_space_mb column will give you a guesstimate as to the required

free space, in megabytes.The larger the SQL statements in the sql_summary table, the more space willbe released after the upgrade is complete.

To upgrade:- ensure you have sufficient free space in the tablespace- disable any programs which use Statspack- backup the Statspack schema (e.g. using export)- run the upgrade by connecting as a user with SYSDBA privilege:SQL> connect / as sysdbaSQL> @spup816

Once the upgrade script completes, check the log files (spup816a.lis and

spup816b.lis) for errors. If errors are evident, determine and rectifythe cause before proceeding. If no errors are evident, and you are upgradingto 9.0, you may proceed with the upgrade.


If you are running 8.1.6 Statspack and wish to upgrade to 9.2 Statspack, youmust follow the upgrade steps - in the following order:- 10.2.3. Upgrading the Statspack schema from 8.1.6 to 8.1.7- 10.2.2. Upgrading the Statspack schema from 8.1.7 to 9.0- 10.2.1. Upgrading the Statspack schema from 9.0 to 9.2


If you are running 8.1.6 Statspack and wish to upgrade to 9.0 Statspack, youmust follow the upgrade steps - in the following order:- 10.2.3. Upgrading the Statspack schema from 8.1.6 to 8.1.7- 10.2.2. Upgrading the Statspack schema from 8.1.7 to 9.0


If you are running 8.1.7 Statspack and wish to upgrade to 9.2 Statspack, you

must follow the upgrade steps - in the following order:- 10.2.2. Upgrading the Statspack schema from 8.1.7 to 9.0- 10.2.1. Upgrading the Statspack schema from 9.0 to 9.2



11. Oracle Real Application Clusters specific considerations------------------------------------------------------------

11.1. Changing Instance Numbers

The unique identifier for a database instance used by Statspack is thedbid and the instance_number. When in a Real Application Clusters environment,it is possible the instance_number may change between startups (eitherbecause the instance_number initialization parameter is set, orbecause the instances are started in a different order).

In this case, as Statspack uses the instance_number and the dbid to identifythe instance's snapshot preferences, it is important to note that this mayinadvertently result in a different set of levels or thresholds beingused when snapshotting an instance.

There are three conditions which must be met for this to occur:- the instance numbers must have switched between startups- the DBA must have modified the default Statspack parameters used forat least one of the instances

- the parameters used (e.g. thresholds and snapshot level) must not bethe same on all instances

Note that the only way the parameters will differ is if the parametershave been explicitly modified by the DBA after installation, either bysaving the specified values or by using the modify_statspack_parameterprocedure.

It is easy to check whether any of the Statspack snapshot parameters are

different for the instances by querying the STATS$STATSPACK_PARAMETER table.

NOTE:If you have changed the default Statspack parameters you maywish to avoid encountering this problem by hard-coding the instance_numberinitialization parameter for each of the instances of a Clustereddatabase - this will avoid encountering this problem.For recommendations and issues with setting the instance_numberinitialization parameter, please see the Real Application Clustersdocumentation.

11.2. Cluster Specific Report

sprepins.sql can be run to query performance data for any instance which thePERFSTAT schema contains. The report will prompt for a dbid, instance_numberand begin and end snap id's.

This report can be used when importing data from another instance, or in aReal Application Clusters environment to report on an instance which you arenot connected to.

For more information on sprepins.sql, see section 4.2.

11.3 Cluster Specific Data

New Cluster Specific data displayed in Statspack instance report:



- Page 2 of the Statspack report for a clustered instance displays clusterspecific derived statistics.

- Page 3 of a clustered instance Statspack report shows data fromv$dlm_misc.

- Cluster-specific data for Library Cache and Dictionary Cache

- RAC segment statistics

12. Conflicts and differences compared to UTLBSTAT/UTLESTAT------------------------------------------------------------

12.1. Running BSTAT/ESTAT in conjunction to Statspack

If you choose to run BSTAT/ESTAT in conjunction to Statspack, do not dorun both as the same user, as there is a table name conflict - this table

is stats$waitstat.

12.2. Differences between Statspack and BSTAT/ESTAT

Statspack considers a transaction to either finish with a commit or arollback, and so calculates the number of transactions thus:'user commits' + 'user rollbacks'

BSTAT/ESTAT considers a transaction to complete with a commit only, andso assumes that transactions = 'user commits'

For this reason, comparing per transaction statistics between Statspack and

BSTAT/ESTAT may result in significantly different per transaction ratios.

13. Removing the package-------------------------

To deinstall the package, connect as a user with SYSDBA privilege and runthe following script from SQL*Plus: spdrope.g.

SQL> connect / as sysdbaSQL> @spdrop

This script actually calls 2 other scripts:1. spdtab -> Drops tables and public synonyms2. spdusr -> Drops the user

Check each of the two output files produced (spdtab.lis, spdusr.lis)to ensure the package was completely deinstalled.

14. Supplied Scripts Overview------------------------------

Installation

Must be run as a user with SYSDBA privilege



spcreate.sql -> Creates entire Statspack environment (callsspcusr.sql, spctab.sql, spcpkg.sql)

spdrop.sql -> Drops entire Statspack environment (callsspdtab.sql, spdusr.sql)

Are run as a user with SYSDBA priv by the calling scripts (above)spdtab.sql -> Drops Statspack tables

spdusr.sql -> Drops the Statspack user (PERFSTAT)

Are run as PERFSTAT by the calling scripts (above)spcusr.sql -> Creates the Statspack user (PERFSTAT)spctab.sql -> Creates Statspack tablesspcpkg.sql -> Creates the Statspack package

Reporting and Automation

Must be run as PERFSTATspreport.sql -> Generates a Statspack report

sprepins.sql -> Generates a Statspack report for the database andinstance specifiedsprepsql.sql -> Generates a Statspack SQL report for the specific

SQL Hash Value specifiedspauto.sql -> Automates Statspack statistics collection

(using dbms_job)

Upgrading

Must be run as SYSDBAspup90.sql -> Converts data from the 9.0 schema to the

newer 9.2 schema. Backup the existing schema

before running the upgrade. If upgrading fromStatspack 8.1.6, spup816.sql must be run, thenspup817.sql, then spup90.sql

spup817.sql -> Converts data from the 8.1.7 schema to thenewer 9.0 schema. Backup the existing schemabefore running the upgrade. If upgrading fromStatspack 8.1.6, spup816.sql must be run, thenspup817.sql

spup816.sql -> Converts data from the 8.1.6 schema to the8.1.7 schema. Backup the existing schemabefore running the upgrade.

Performance Data Maintenance

Must be run as PERFSTATsppurge.sql -> Purges a limited range of Snapshot Id's for

a given database instance.sptrunc.sql -> Truncates all Performance data in Statspack tables

WARNING - Do not use unless you wish to removeall data in the schema you are using.You may choose to export the dataas a backup before using this script.

spuexp.par -> An export parameter file supplied for exportingthe whole PERFSTAT user.

Documentation



Should be read by the DBA running the scriptsspdoc.txt -> This file contains instructions and

documentation on the STATSPACK package.

15. Limitations and Modifications----------------------------------

15.1. Limitations

As the Statspack schema is updated to reflect the features in thelatest Oracle releases, the schema may change; backward compatibilityis not guaranteed.

15.2. Modifications

All Statspack code is Oracle proprietary and must not be modified. Anymodifications made to Statspack software will render the code anddata captured thereafter unsupported; unsupported changes may result inerrors in data capture or reporting. Instead, please requestenhancements.

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

Date post:	30-May-2018
Category:	Documents
Upload:	ankur-arora
View:	224 times
Download:	0 times

Oracle9i Server Release 9.2 Production ...

Documents