Statspackとは？
公式定義：
A set of SQL, PL/SQL, and SQL*Plus scripts that allow the collection, automation, storage,
and viewing of performance data. This feature has been replaced by the Automatic Workload Repository.
パフォーマンスデータを収集、自動化、保存、レビューするためのSQL、PL/SQLとSQL*Plusスクリプトセットである。
この機能は自動ワークロードリポジトリ（AWR）によって置換えされた。
明らかにこれからのOracleリリースではStatspackは更新されないと予想しますが、
かなり優秀なツールなので今更ですが、最新のOracle11gR2のspdoc.txtを読んでいきます。
0. Introduction and Terminology
--------------------------------
0. 導入及び関連用語
To effectively perform reactive tuning, it is vital to have an established
baseline for later comparison when the system is running poorly. Without
a baseline data point, it becomes very difficult to identify what a new
problem is attributable to: Has the volume of transactions on the system
increased? Has the transaction profile or application changed? Has the
number of users increased?
効率良くパフォーマンスチューニングするためには、システムベースラインを確立し、
システムの動きが鈍いときにベースラインと比較できる。システムベースラインが
存在しない場合、新しい問題の特定に困る：
システムのトランザクション量は増加したか？
トランザクションのプロフィール又はアプリケーション変更されたか？
ユーザ数増加したか？
Statspack fundamentally differs from the well known UTLBSTAT/UTLESTAT
tuning scripts by collecting more information, and also by storing the
performance statistics permanently in Oracle tables, which can later
be used for reporting and analysis. The data collected can be analyzed
using the report provided, which includes an 'instance health and load'
summary page, high resource SQL statements, as well as the traditional
wait events and initialization parameters.
Statspackは根本的に有名なUTLBSTAT/UTLESTATチューニングスクリプトと異なり、
より多くの情報収集し、パフォーマンス統計が長期的にOracleテーブルに保存
され、後ほどのレポート作成と分析に役立つ。収集したデータはレポートに
使用され、「インスタンスヘルス＆ロード」サマリページ、ハイリソースSQL文、
従来通りの待機イベント、初期化パラメータ等が含んでいる。
Statspack improves on the existing UTLBSTAT/UTLESTAT performance scripts
in the following ways:
Statspackは既存のUTLBSTAT/UTLESTATスクリプトより改善された点は：
- Statspack collects more data, including high resource SQL
(and the optimizer execution plans for those statements)
・StatspackはハイリソースSQL文を含み、より多くのデータを採取する。
（及びそれらのオプティマイザ実行プラン）
- Statspack pre-calculates many ratios useful when performance
tuning, such as cache hit ratios, per transaction and per
second statistics (many of these ratios must be calculated
manually when using BSTAT/ESTAT)
・Statspackは予めたくさんの有用な性能比率を計算し、例えば
トランザクション毎のキャッシュヒット率
（BSTAT/ESTATの場合は手動計算となる）
- Permanent tables owned by PERFSTAT store performance statistics;
instead of creating/dropping tables each time, data is inserted
into the pre-existing tables. This makes historical data
comparisons easier
・PERFSTATスキーマに属す永続テーブルにパフォーマンスデータが保存される。
毎回作成・削除テーブルの代わりに、データは既存のテーブルに挿入される。
履歴として比較しやすくなる。
- Statspack separates the data collection from the report generation.
Data is collected when a 'snapshot' is taken; viewing the data
collected is in the hands of the performance engineer when he/she
runs the performance report
・Statspackはデータ収集とレポート作成を分かれて行う。
取得したスナップショットからデータが採取され、パフォーマンスエンジニア
によって、レポートが生成される。
- Data collection is easy to automate using either dbms_job or an
OS utility
・DBMS_JOB又はOSツールを使わずにデータ収集の自動化が実現しやくなった。
NOTE: The term 'snapshot' is used to denote a set of statistics gathered
at a single time, identified by a unique Id which includes the
snapshot number (or snap_id). This term should not be confused
with Oracle's Snapshot Replication technology.
注意：「スナップショット」という用語は毎回統計集計時生成されたセットのことで、
スナップショット番号（又はSNAP_ID）の様な一意IDで識別される。
この用語と Oracle のスナップショット レプリケーション テクノロジを
混同しないでください。
How does Statspack work?
Statspackの仕組み
Statspack is a set of SQL, PL/SQL and SQL*Plus scripts which allow the
collection, automation, storage and viewing of performance data. A user
is automatically created by the installation script - this user, PERFSTAT,
owns all objects needed by this package. This user is granted limited
query-only privileges on the V$views required for performance tuning.
Statspackはパフォーマンスデータを収集、自動化、保存、レビューするための
SQL、PL/SQLとSQL*Plusスクリプトセットである。インストールスクリプトを実行
すると、専用ユーザが自動的に生成され、パッケージ必要なオブジェクトは全部
このユーザPERFSTATに属している。パフォーマンスチューニングを行えるよう
このユーザに制限されたV$ビュークエリのみの権限が与えられる。
Statspack users will become familiar with the concept of a 'snapshot'.
'snapshot' is the term used to identify a single collection of
performance 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.
Statspackユーザはスナップショットの概念に熟知しているでしょう。
「スナップショット」は単一のパフォーマンスデータ集合を表現する用語で、
各スナップショットが取得時に生成されたスナップショットIDによって一意識別
され、新しいスナップショットを取得する度に、新しいIDが生成される。
The snap_id, along with the database identifier (dbid) and instance number
(instance_number) comprise the unique key for a snapshot (using this
unique combination allows storage of multiple instances of a Clustered
database in the same tables).
データベースID（DBID）及びインスタンス番号（INSTANCE_NUMBER）と共に、snap_idは
スナップショットを一意識別するためのキーとなる。（この一意の組合せを使用すれば
クラスタ化した複数のインスタンスの情報同じテーブルに保存できる）
Once snapshots are taken, it is possible to run the performance report.
The performance report will prompt for the two snapshot id's the report
will process. The report produced calculates the activity on the instance
between the two snapshot periods specified, in a similar way to the
BSTAT/ESTAT report; to compare - the first snap_id supplied can be
considered the equivalent of running BSTAT; the second snap_id
specified can be considered the equivalent of ESTAT. Unlike BSTAT/ESTAT
which can by its nature only compare two static data points, the report
can compare any two snapshots specified.
スナップショットが取得されると、パフォーマンスレポートの作成が可能になる。
パフォーマンスレポートの処理時２つのスナップショットIDが要求される。
BSTAT/ESTATと似ているが、レポートは指定された２つのスナップショットIDの期間中
の活動を計算する。比較すると、最初のスナップショットIDはBSTATに等しく、二番目
のスナップショットIDはESTATに相当する。BSTAT/ESTATと異なるのは単純に２つ静的の
データポイントを比較するのではなく、指定した任意２つのスナップショットの比較
が可能である。
1. Enterprise Manager (EM), Automatic Workload Repository (AWR) and Statspack
------------------------------------------------------------------------------
１、エンタプライズマネージャ（EM）、自動ワークロードリポジトリ（AWR）とStatspack
Enterprise Manager
------------------
エンタプライズマネージャ
Statspack allows you to capture Oracle instance-related performance data, and
report on this data in a textual format.
StatspackはOracleインスタンス関連のパフォーマンスデータを取得し、テキストベースの
レポートを生成する。
For EM managed databases in 9i, Oracle Enterprise Manager uses Statspack data
and displays it graphically. Starting with 10g, Enterprise Manager instead
uses data collected by the Automatic Workload Repository (AWR). AWR
data is internally captured and stored by Oracle 10g databases.
9iのEM管理データベースでは、Statspackデータを使って描画している。10gからのEMは
代わりにAWRのデータを使用する。AWRデータは内部で採取し、Oracle10gデータベース
に保存される。
For more information about Oracle Enterprise Manager visit the Oracle website
oracle.com --> Database --> Manageability
更なる情報を求める場合はOracleWEBサイトにアクセスしてください。
Automatic Workload Repository and Statspack
-------------------------------------------
自動ワークロードリポジトリ及びStatspack
The Automatic Workload Repository (AWR) is an integrated part of the Oracle
server. Its purpose is to collect server-related performance data
automatically every 60 minutes (by default) when the statistics_level
parameter is set to 'typical' (or 'all'). As the data is collected by the
server itself, the Automated Database Diagnostic Monitor (ADDM) component of
the server uses this data automatically to diagnose performance issues.
DBAs and performance engineers can access the performance recommendations
by using EM, or view the captured data in the AWR report, which is similar to
the Statspack Instance report.
自動ワークロードリポジトリはOracleサーバと統合した一部である。その目的は
statistics_levelが「typical」（又は「all」）に設定された場合、
６０分間隔（デフォルト）でサーバ関連のパフォーマンスデータを収集すること。
データはサーバ自身が収集するため、自動データベース診断モニタ（ADDM）コンポーネント
がこのデータを利用してパフォーマンス問題を診断する。
To compare, Statspack is a manually installed and configured set of SQL and
PL/SQL scripts which gather performance statistics. The data gathered
is used by DBAs and performance engineers to manually diagnose performance
problems.
比較すると、Statspackは手動でインストールされたパフォーマンス統計を収集する
SQLとPL/SQLのセットで、収集されたデータもパフォーマンスエンジニアによって
手動で診断を行う。
The AWR schema was initially based on the Statspack schema, but has since been
modified. Because of this shared history, there are some similarities
(e.g. concept of a snapshot, similar base tables). However, AWR is
separate from Statspack.
AWRスキーマはStatspackスキーマをベースに変更を加わった。共通の歴史があるため、
いくつか類似点がある。（例：スナップショットの概念、基本テーブルの類似）
但し、AWRはStatspackから独立している。
For more information on using AWR, please see the Oracle 10g Server
Performance Tuning Guide. For license information regarding AWR, please
see the Oracle database Licensing Information Manual.
AWRの更なる情報を求める場合、Oracle 10gサーバパフォーマンスチューニングガイド
に参照してください。
If you are going to use AWR instead of Statspack, and you have been using
Statspack at your site, it is recommended that you continue to capture
Statspack data for a short time (e.g. one month) after the upgrade to 10g.
This is because comparing post-upgrade Statspack data to pre-upgrade Statspack
data may make diagnosing initial upgrade problems easier to detect.
もしStatspackを使用中だが、その代わりにAWRを利用したいなら、１０ｇへアップグレード
後にも短期間（一ヶ月程）Statspackを取得することをお勧めする。これは、
アップグレード前と後のデータを比較するとアップグレードの問題診断に役立つ。
WARNING: If you choose to continue Statspack data collection after
upgrading to 10g, and statistics_level is set to typical or
all (which enables AWR collection), it is advised to stagger
Statspack data collection so it does not coincide with AWR
data collection (AWR data collection is by default is every
hour, on the hour). Staggering data collection should be done
to avoid the potential for any interference (e.g. stagger data
collection by 30 minutes).
警告： １０ｇへアップグレード後もStatspackでデータ収集したい場合、もし
statistic_levelが「typical」又は「all」に設定（AWR有効）されているなら、
Statspack収集時間とずれがあり、AWRとデータ収集と一致しない
（AWRはデフォルト１時間の間隔）。それぞれ干渉する恐れがあるので
収集時間をずらしたほうが良い（例：30分間隔収集へずらす）Long term, typically, there is little reason to collect data through both
AWR and Statspack. If you choose to use AWR instead of Statspack, you should
ensure you should keep a representative set of baselined Statspack data for
future reference.
長い間、通常StatspackとAWR両方を使用する理由は一つある。AWRをStatspackの代替にするなら
将来参考するための代表的なStatspackベースラインデータを保持すべきである。
(To be continued...)
（つづく・・・）
