STATS PACK
スナップショット・モニタを使用すると、ある一定の期間におけるデータベースの動作を識別できます。
例えば、メモリがどのように使用されているか、ロックがどのように獲得されているか、といった情報を得ることができます。
スナップショット・モニタは、構成を微調整したり、問題（例えばステートメントの実行時間が長い）を識別したりするための手法として利用されます。
例えば、メモリがどのように使用されているか、ロックがどのように獲得されているか、といった情報を得ることができます。
スナップショット・モニタは、構成を微調整したり、問題（例えばステートメントの実行時間が長い）を識別したりするための手法として利用されます。
◆データ取得までの流れ
◆スナップショット・レベル
レベル０ ：一般的なパフォーマンス統計情報 レベル１ ：各レベル＋ アドバイス情報（R9.2.0～） レベル５ ：レベル１＋ SQL文統計情報 レベル６ ：レベル５＋ SQL詳細（実行計画）情報（R9.0.1～） レベル７ ：レベル６＋ セグメント情報（R9.2.0～） レベル１０：レベル７＋ 親ラッチ、子ラッチ情報
◆スナップショット起動
●起動例
#!/bin/sh
sqlplus perfstat/perfstat_1 <<END
execute statspack.snap( i_snap_level=>7);
exit
END
sqlplus perfstat/perfstat_1 <<END
execute statspack.snap( i_snap_level=>7);
exit
END
※PERFSTATユーザー
インストール・スクリプトを実行すると自動的に作成されるSTATSPACK専用ユーザーです。
このユーザーは、インストールで作成される全てのPL/SQLコード、作成されるオブジェクト
(表、制約、パッケージなど)を所有し、スナップショット取得の際に必要な[[V$表]]へのselect権限が
付与されます。
インストール後、STATSPACKを使用する(スナップショット取得、レポート作成、データ削除)
には、すべてこのユーザーに接続して実行します。
◆レポート分析
StatsPackで作成したレポートには、多くの情報が含まれています。
パフォーマンスの観点で特に注目すべきポイントになる項目は次の項目です。
パフォーマンスの観点で特に注目すべきポイントになる項目は次の項目です。
・ロードプロファイル(スループットと負荷)
・インスタンス効率
・トップ5待機イベント
・SQL
・インスタンス効率
・トップ5待機イベント
・SQL
■Summaryページ
STATSPACKの出力レポートの最初の部分はSummaryページと呼ばれ、チューニングの的を絞る
ために有効な内容、統計値が集約されています。
始めにデータベースの基本情報、開始・終了スナップショットの情報、そして初期化パラメータ・ファ
イルに指定されているキャッシュ・サイズに関するパラメータ値が表示されます。
ために有効な内容、統計値が集約されています。
始めにデータベースの基本情報、開始・終了スナップショットの情報、そして初期化パラメータ・ファ
イルに指定されているキャッシュ・サイズに関するパラメータ値が表示されます。
■ロード・プロファイル
異なるスナップショット間で作成された2つ以上のレポートを使用して仕事量の比較する際に有効
なセクションです。ただし、システムがまったく異なる仕事量を処理していた場合、それらのレポート
の比較は有効ではありません。
毎秒の統計情報(Per Second)からは、2つのレポートの比較によりスループットの変化が分かりま
す。
例えば、Redo size、Block changes、%Blocks changed per read が著しく増加している場合は、
insert/update/delete処理がより多く行われたことになります。
同様に、2つのレポートでトランザクションごとの統計情報(PerTransacion)を比較することにより、
アプリケーション特性の変化を識別することができます。
なセクションです。ただし、システムがまったく異なる仕事量を処理していた場合、それらのレポート
の比較は有効ではありません。
毎秒の統計情報(Per Second)からは、2つのレポートの比較によりスループットの変化が分かりま
す。
例えば、Redo size、Block changes、%Blocks changed per read が著しく増加している場合は、
insert/update/delete処理がより多く行われたことになります。
同様に、2つのレポートでトランザクションごとの統計情報(PerTransacion)を比較することにより、
アプリケーション特性の変化を識別することができます。
●Load Profile例
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 28,980.53 268,788.06
Logical reads: 749.03 6,947.09
Block changes: 201.86 1,872.18
Physical reads: 8.28 76.79
Physical writes: 12.98 120.42
User calls: 134.29 1,245.52
Parses: 27.06 250.99
Hard parses: 0.00 0.03
Sorts: 0.31 2.92
Logons: 0.00 0.02
Executes: 54.46 505.11
Transactions: 0.11
% Blocks changed per Read: 26.95 Recursive Call %: 4.14
Rollback per transaction %: 0.20 Rows per Sort: 172.23
■インスタンス効率
指定したスナップショット間におけるインスタンスの使用状態を、％で表示します。各項目の説明は以下のとおりです。
| Buffer Nowait | バッファに要求を出したときに、即座に使用可能だった割合 |
| Buffer Hit | 必要なデータがバッファ上にあった割合 |
| Library Hit | 必要なSQL、PL/SQLがライブラリ・キャッシュにあった割合 |
| Redo NoWait | redo logに要求を出したときに、即座に使用可能だった割合 |
| In-memory Sort | ソートがメモリ内で行われた割合 |
| Soft Parse | 全ての解析のうち再利用可能なものの割合 |
| Latch Hit | 全てのラッチのヒット率 |
| Execute to Parse | 1-(解析回数/ 実行回数) SQL実行に対し解析が行われなかった割合 |
| Parse CPU to Parse Elapsd | 解析CPU時間/ 解析の合計時間 |
| Non-Parse CPU | 1-(解析CPU時間/ 全CPU時間) |
ここに出力されるすべての値が100%に近づくように、Oracleの主要パラメータを調整します。
バッファに関してはdb_cache_size、ライブラリ・キャッシュおよびSQL解析時間に関しては
shared_pool_size、Redoに関してはlog_bufferなど、それぞれの項目に関連するパラメータを見直してください。
バッファに関してはdb_cache_size、ライブラリ・キャッシュおよびSQL解析時間に関しては
shared_pool_size、Redoに関してはlog_bufferなど、それぞれの項目に関連するパラメータを見直してください。
ここに著しく低い値が出ていたり、パラメータを変更しても改善が見られない場合は、レポートの後に出力される関連セクションを調査してさらに原因を追求していきます。
●インスタンス効率例
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.95 Redo NoWait %: 100.00
Buffer Hit %: 98.89 In-memory Sort %: 100.00
Library Hit %: 99.99 Soft Parse %: 99.99
Execute to Parse %: 50.31 Latch Hit %: 99.90
Parse CPU to Parse Elapsd %: 93.22 % Non-Parse CPU: 90.50
■インスタンス効率（共有プール）
| Memory Usage % | 使用された共有プールの割合 |
| % SQL with executions>1 | 再利用されたSQL文の割合 |
| % Memory for SQL w/exec>1 | ２回以上実行されたSQL文が使用したメモリの割合 |
●インスタンス効率（共有プール）
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 30.68 31.41
% SQL with executions>1: 66.61 68.88
% Memory for SQL w/exec>1: 48.50 54.86
■トップ５待機イベント
Summaryページの中でも最も注目すべきセクションです。ここには、セッションの待機時間が最も長いイベントが表示されます。
待機イベントのうち、Wait Timeの大きい順にトップ５までを表示
待機イベントのうち、Wait Timeの大きい順にトップ５までを表示
●トップ５待機イベント
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file parallel write 3,659 2,785 24.50
log file sync 3,353 1,927 16.95
buffer busy waits 6,907 1,334 11.74
log file parallel write 7,456 1,304 11.48
CPU time 1,141 10.04
-------------------------------------------------------------
Wait Events for DB: LAND Instance: LAND Snaps: 11 -12
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
■SQL
このセッションでは、アクセスしたバッファ数やディスクへのアクセス回数が多いといったリソース使用率の高いSQLが表示されます
(ファイルに出力するためのバッファ数やアクセス回数などのしきい値は、任意に設定できます。)
(ファイルに出力するためのバッファ数やアクセス回数などのしきい値は、任意に設定できます。)
