導入・構築事例 サポートサービス  パフォーマンストラブルの解消 [STATSPACK取得時の改善ポイント]

Oracleソリューションサービス 専用サイト TOP導入・構築事例 > サポートサービス パフォーマンストラブルの解消[STATSPACK取得時の改善ポイント]

Statspackレポートの解析などを行い、改善の必要性を調査しました。

パフォーマンストラブルの解消[STATSPACK取得時の改善ポイント]

運用
性能テストを行っており、本番並みのトランザクションを流しSTATSPACKを取得しました。この状態は正常な状態か、改善しなければならない場合は改善ポイントを教えてください。
運用
問合せの内容は、改善ポイントを教えてください、というものでした。お客様は、STATSPACKを取得し、インスタンス効率セクションを分析してたところ、 「Parse CPU to Parse Elapsd(エラプスド) %」の値が0.00%ということに気づき、その値が正常なものかどうか、カスタマサポートセンタに問合せされました。
STATSPACKは、データベース統計とSQLに関する情報を収集します。このSTATSPACKにより、統計に関するレポートを生成します。
ページトップへ
STATSPACKレポートの解析(1/3)
  • STATSPACKレポート
    Summary Page出力レポートで最も重要な最初の部分
    チューニングに有効な統計情報の値を集約
  • 統計データの内容
    1.データベース基本情報
    2.スナップショット情報
    3.キャッシュ・サイズ
    4.ロード・プロファイル
    5.インスタンス効率(CPU・共有プール)
    6.トップ5待機イベント
生成したSTATSPACKレポートの最初のページ(Summary Page)には、パフォーマンス・チューニングに有効な値が集約されています。
Summary Pageを構成している内容は、
・はじめに、今回のレポートを取得した環境についての基本的な情報(データベース、スナップショット、キャッシュ・サイズ)が表示され、
・その後にロード・プロファイル、
・インスタンス効率、
・トップ5待機イベント のセクションが続きます。
ページトップへ
STATSPACKレポートの解析(2/3)
  • インスタンス効率
    インスタンスの仕様状態を各項目ごと%で表示
Statspackレポートの解析(2/3)
インスタンス効率は、インスタンスの使用状態を各項目ごと%で表示します。
基本的には、ここに表示される全ての値を100%に近づけることがチューニングのゴールです。
これらの値が低い場合、それぞれの項目に対応する初期化パラメーターを調整、または関連セクションをさらに調査します。
ページトップへ
STATSPACKレポートの解析(3/3)
  • トップ5待機イベント
    待機イベントのうち待機時間の長い順にTOP5を表示(R9.2からCPU時間を含む)
Statspackレポートの解析(2/3)
  • 主な待機イベント例
    -db file scattered read,db file sequential read
    SQL文の記述方法、ディスクIOに問題がある可能性があります。SQL文、ファイルIOなどのセクションを検査して下さい。
    -latch free
    サーバがラッチを要求し、そのラッチを直ちに得ることができない場合、latch freeが上位に表示されます。ラッチに関するセクションを検査して下さい。
    -free buffer waits
    サーバがバッファを要求しているときに、即座に使えるバッファがないときに発生します。db_block_buffersが小さいか、I/O要求が少ない可能性があります。
    -buffer busy wait
    サーバがアクセスしたいバッファに何らかの理由(共有できない方法で使用中など)でアクセスできないときに発生します。Buffer Wait セクションを検査して下さい。
トップ5待機イベントは、待機イベントの待機時間を比較し、その待機時間が長い順にTOP5を表示します。 R9.2からはCPUTIME(CPU時間)も、待機イベントと共に待機時間を比較されます。 そして、CPUTIMEと各イベントの待機時間を比較することにより、 CPU時間よりも待機時間が長いイベントを中心に、チューニングを効率よく行っていくことができます。
ページトップへ
センタでの調査
STATSPACKレポート(インスタンス効率セクション)
センタでの調査
お客様の言われていたとおり、インスタンス効率の「Parse CPU to Parse Elapsd %」の値が0.00となっていました。そのため、どのような場合に0となるのか、調査を進めていきました。
ページトップへ
進捗状況
進捗状況
  • 各値は
    -parse time cpu :
    文に対する全ての解析コール、実行コールまたはフェッチコールでかかったCPU時間の合計
    -parse time elapsed :
    文に対する全ての解析コール、実行コールまたはフェッチコールでかかった経過時間の合計(Oracleの WAIT 時間が含まれる)
  • parse time cpu/parse time elapsed
    解析に費やされる時間のうちのどのくらいが、ラッチなどのリソースに対する待機でなく解析操作自体によるものかを示します。比率1は良好であり、経過時間が競合率の高いリソースを待機するために費やされなかったことを示します。
ページトップへ
進捗状況
お客様からいただいた実行計画の確認
進捗状況
ページトップへ
進捗状況
インスタンス効率とトップ5待機イベントセクションを確認
進捗状況
「Parse CPU to Parse Elapsd」は0ですが、他のメモリ関連インスタンス効率は目標となる100%に値が近いため、特に問題はありません。
また、待機イベントの上位5項目を見ると、「CPU time」が最上位で、これも問題ありません。他のSTATSPACKレポートの項目を見ましても通常のOracleにおける動作の結果であると読み取れたので問題ないことが確認されました。
ページトップへ
結果報告
結果報告
Perse cpu to perse elapsed% が0になったのは、 Perse cpu to perse elapsed% の計算式で用いるparse time cpuが0になっていためです。ただし、 parse time cpuやparse time elapsedなどの統計データは、1/100秒未満の時間も0とみなされることもありますので、それにより0になった可能性もあります。

この、 parse time cpuを parse time elapsedで割った率が低い場合は、ラッチによる待機を確認し、チューニングを行っていきますが、今回の場合は、
parse time elapsedについてそれほど大きなものではないので、問題ないと考えます。
また、バッファヒット率やキャッシュヒット率、soft Psrseの値がほぼ100%と高いため、メモリ関連でも特に問題ありません。
さらに、待機イベントの上位5項目を見ても、 cpu timeが最上位であり、これはCPUがSQLの処理に要した時間を示していますので、これも問題ありませんとお伝えしました。
ページトップへ
(C)Hitachi solutions, Ltd. 2017. All rights reserved.