2005年4月某日、リリース間近の性能テストを実施しました。
いつも通り、STATSPACKユーティリティを使用して、パフォーマンスレポートを取得します。
思えば、8i全盛の頃は、まだまだBSTAT/ESTATの方がメジャーだったなあ。
「STATSPACK？よく分からないので、使いません・・・」という状態だった。
しかし、STATSPACKを一度使ってみたら、もうBSTAT/ESTATなんて使えません。
話は戻って、性能テスト時の実際の作業は、こんな感じで進みます。
１．「テスト開始しまーす」の合図で、スナップショット取得コマンドを実行。
２．談笑しながらしばらく待つ・・・
３．「終わりましたー」の合図で、またスナップショット取得コマンドを実行。
４．１と３で取得したスナップショット間のパフォーマンスレポートを生成。
こんな流れで、複数のテストケースを実施していきます。
テスト当日は、大まかなレポート分析を行ない、即時対策可能なものはその場で対応しますが、
基本は、後日詳細まで解析して評価報告書を作成するというのが私のお仕事。
さてさて、STATSPACKの良いところと言えば、やっぱり「Top 5 Timed Events」でしょう。
まず最初に、ここのセクションを見て、問題となりそうな待機イベントが
ないかを確認してみます。
********************************************************************************
＜表示例＞
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 16 75.42
latch free 2,102 2 10.63
control file sequential read 3,013 1 3.42
global cache cr request 612 1 2.44
control file parallel write 286 0 1.53
********************************************************************************
「CPU time」は、待機イベントではなくて、CPU処理時間なので、基本はこの項目が
一番多くなるのが望ましい。
「latch free」が少し割合が高いけど、同じ処理を多重で実行してるから、
ラッチの競合が発生している様子・・・仕方ないか。
という事で、特に問題なさそうですね。
あと便利なところと言えば、キャッシュヒット率等が既に計算された状態で出力される事。
BSTAT/ESTATの頃は、個々の値を持ってきて計算してましたから・・・。
********************************************************************************
＜表示例＞
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 100.00 In-memory Sort %: 100.00
Library Hit %: 100.01 Soft Parse %: 100.00
Execute to Parse %: 67.88 Latch Hit %: 99.86
Parse CPU to Parse Elapsd %: 89.47 % Non-Parse CPU: 94.89
********************************************************************************
さらに、便利なところと言えば、負荷の高いSQLの抽出機能ですね。
「SQL ordered by Gets for DB」や「SQL ordered by Reads for DB」セクションから、
負荷の高いSQLが存在しているかどうかが確認できる。
これによって、SQLトレースを取得しなくても、ボトルネックとなっている
SQLの抽出ができるので、非常に便利ですね。
********************************************************************************
＜表示例＞
SQL ordered by Gets for DB: orcl Instance: orcl1 Snaps: 11-12
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
21,413 49 437.0 40.0 0.40 0.82 818142582
Module: test1.exe
SELECT COL1 from TESTTAB ・・・
********************************************************************************
実行時間（Elapsd Time）が0.82秒で、実行回数（Executions）が49回だから、
１実行あたりの実行時間は・・・大した事ないですね。
後日、詳細のレポート解析を行ないましたが、Oracleとしてのボトルネック箇所は
特に見つからず、目標性能もクリアしていたので、このままリリースする事となりました。
まあ、私が設計したからには、パラメータの調整が必要な事態なんて発生する筈は
ないんですけどね！
というのは言い過ぎですが、常にその位のつもりで設計しないといけませんね。
＜今日のおさらい＞
STATSPACKは便利！以上！
・・・だけでは寂しいので、基本的な使い方を少し残しておこうかな。
◆STATSPACK環境インストールスクリプト
@$ORACLE_HOME/rdbms/admin/spcreate.sql
◆スナップショット取得コマンド
execute statspack.snap (i_snap_level => レベル);
◆レポート作成スクリプト
@$ORACLE_HOME/rdbms/admin/spreport.sql
◆スナップショット削除（delete）スクリプト
@$ORACLE_HOME/rdbms/admin/sppurge.sql
◆スナップショット削除（truncate）スクリプト
@$ORACLE_HOME/rdbms/admin/sptrunc.sql
◆STATSPACK環境アンインストールスクリプト
@$ORACLE_HOME/rdbms/admin/spdrop.sql
※インストール／アンインストールはSYSユーザで実行する。
それ以外はPERFSTATユーザで。