oracle statspack とは 4

① Statspack取得時のセッション数を確認する。 ② Load Profile からアプリケーションの傾向を把握する。 ③ Instance Efficiency Percentages からインスタンス効率をチェックする。 ④ Report Summaryで待機イベントを確認する。 ⑤ ④で問題がありそうな待機イベントの統計情報を確認する。 ⑥ SQL ordered から遅いSQL、実行回数が多いSQLなどを確認する。 よく読まれている記事. Oracleデータベースの性能対策の重要な機能、「Statspack」や「Oracle Enterprise Manager 10g Diagnostics Pack」(※オプションライセンス)の利用ポイントをお伝えします。使わないと"もったいない"機能です！(Diagnostics Packの有無による違いはここ) statspack 詳細レポート（sprepsqlスクリプト）の作成と見方 statspack 詳細レポートを出力すると、実行されたsql 文の実行統計と実行計画 の調査ができる なお、statspack 詳細レポートを出力するスクリプト実行には、実行したsql 文 に対するold_hash_value 値が必要である <> datapump impdpコマンド(インポート)のまとめ （197,266 view）. 今回のLevel 7のレポートではLogical ReadsとPhysical Readsのセグメント情報しか表示されていませんが、その他のセグメントに関係するイベントが発生していれば、その情報もレポートに表示されます。, 先ほどは、Level 5と7の違いしか説明しませんでしたが、Level 5と6の違いがSQL詳細情報です。Level 6ではStatspack SQLレポートを作成することでSQLの詳細情報を知ることができます。 Statspack SQLレポートを作成するには、既に作成済みのStatspackレポートを参照しながらsprepsql.sqlで作成します。ここでは先ほど作成したLevel 7のレポートを参照してStatspack SQLレポートを作成しています（図1-4）。Statspackレポートの「SQL ordered by …」の欄にはそれぞれの単位で悪かった順にSQLの一覧が表示されます。ここではCPUの処理時間が最も長かったSELECT文を分析することにしましょう。sprepsql.sqlを実行すると、spreport.sqlと同様に開始・終了のSnap Idと出力ファイル名の入力を要求されます。違いはhash_valueの入力です。分析したいSQLのHash Value（9i までは単純にHash Valueであったが、10gでは“Old”Hash Valueと表示が変わった）をStatspackレポートから調べ、その値を入力しましょう。, 実際に作成したレポートがこちらになります。 statspackのインストールと使い方。 Enterprise Edition、Diagnostics Packライセンスがあればstatspackを使用せず、AWRを使用する。 ただし、そのような恵まれたプロジェクトに入ることは少ないため、statspackは未だに現役かつ重要。 単純に利用量が増えて領域不足となっているのであればいいですが、表や索引の断片化によって領域不足となってるケースもあります。 通常のユーザー表領域とは表領域の使用ロジックが違うため、ユーザー表領域と同じ監視方法では正しく監視できません。 いかがでしょう。実行されたSQLの処理時間（Elapsed Time）、検索されたレコード数（Rows processed）等の情報に加え、実行計画まで確認することができます。SQL Traceで実行計画を確認したい場合、SQL Traceをセットすることによるオーバーヘッドが無視できませんでした。また、Explain Planによって、実行計画を調査することも可能ですが、実際のSQLが実行された時と、Explain Planを実行した時とでは既に実行計画の内容が変わってしまっていることもあります。これらの課題をStatspack SQLレポートが解決してくれました。ただし、Statspackの場合は、Statspack自身が遅いと判断したSQLしかスナップショットに保存されません。つまり、対象期間内に実行された全てのSQLを分析できるわけではありません。またSQL TraceのほうがStatspackのSQLレポートより詳細な情報を取得することができます。StatspackとSQL Traceは要件に応じて使い分けましょう。, Statspackの詳細説明は9iまではマニュアルの「パフォーマンス・チューニング・ガイドおよびリファレンス」に記載されていますが、$ORACLE_HOME/rdbms/admin/spdoc.txtも一度参照してみてください。全て英語で書かれているのですが、「パフォーマンス・チューニング・ガイドおよびリファレンス」に記載されていないことも一部記述されています。また、10gからはStatspackの記述がマニュアルから削除されてしまったため、spdoc.txtがより重宝です。 //RTOC 特定のセッションを手動で強制終了させる方法 （126,375 view）. l'�Cyu�\_�k6?�eM���`K�z��������� V$SESSIONを定期的に取得、保存する仕組みを作成する必要あり, ASHを分析することで可能 %���� statspackの取得レベル. HTMLまたはテキスト形式のレポート, V$SESSION(V$SESSION_WAIT）を分析することで可能 Statspackは、Oracle Database 8iから提供されているデータベース性能診断ツールです。追加費用なし、かつエディションの制限なしに利用可能なため、だれでも使用できます。 Statspackは、Oracleの性能分析をするためのレポートを作成するOracleデータベース標準のツールです。 OracleデータベースのOracle8iから登場し、Enterprise Editionだけでなく、Standard Editionでも使用できるため、全ての環境で使用することができます。 ASHによって自動取得 endobj Oracleデータベースの性能対策の重要な機能、「Statspack」や「Oracle Enterprise Manager 10g Diagnostics Pack」(※オプションライセンス)の利用ポイントをお伝えします。使わないと"もったいない"機能です！(Diagnostics Packの有無による違いはここ) では、スナップショット間隔を短くすればするほどよいのでしょうか。もちろんそんなことはありません。スナップショットの処理そのものの負荷を考慮する必要が当然あります。ここではそれを見てみましょう。そこで、先ほどの1回目と2回目の試験期間を比較対象としたAWR期間比較レポートを確認します。作成したレポートはこちらです。, まずTop 5 Timed Eventsセクションを確認します（図3-15）。今回の実験では、スナップショット取得間隔（トータル取得回数）を変えて計測しましたが、図3-15 から、スナップショット取得回数を増やすにともない CPU Timeとdb file scattered readが増えていることが見て取れます。これは スナップショット取得のために、内部表や索引を読む分だけ、db file scattered readが若干あがり、その分のCPUtimeが上がったことに起因しています。スナップショットの間隔を短くすることで情報量が増えますが、逆にCPU負荷が上がるということがいえます。, 図3-15 AWR期間比較レポートTop 5 Timed Events(拡大画像を表示), 次に、Top 5 Segments Comparisonセクションを確認します（図3-16）。試験SQLのアクセス対象であるEMP1表はほとんど差がないのに対し、WRH$の文字列で始まるオブジェクトに対するアクセスが増えていることがわかります。これらのオブジェクトはAWRの内部表に対する索引です。つまり、スナップショット回数が増えたことでこれらのアクセスも増えたということになります。, AWRのスナップショットはShared Poolのデータを参照しているので、Shared Poolにない情報は保存できません。SQLの情報を多く保存したいのであれば、スナップショットを作成する間隔を短くするなどの工夫が必要であることがわかります。しかし、スナップショットの負荷も無視できないため、情報量を増やすことと負荷を下げることは、トレードオフの関係にあることを意識する必要があります。そこで、「通常運用時は1時間に1回程度とし、より詳細な情報を取得する必要がある場合のみスナップショットの間隔を短くする」などの工夫が必要となります。基本的なこととして、「AWRは実行されたすべてのSQLを保存することを目的とした機能ではない」ことを忘れないようにしましょう。, Statspackのスナップショットにはさまざまなパラメータが用意されていると前回説明しましたが、AWRにも同じようなパラメータが用意されています。すでに、第1回「4.1 Automatic Workload Repository (AWR) 」の「（補足）収集レベルについて」でAWRのスナップショット・パラメータについて説明しましたが、ここでは、まだ説明していないパラメータについて説明したいと思います。それがDBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGSのTOPNSQLパラメータです。このパラメータは、スナップショット実行時に収集されるSQL数のしきい値を設定することができます。StatspackではSQL数を制御するパラメータが多数存在していましたが、AWRではこの1つに集約され、シンプルになりました。, 「Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス10g リリース2（10.2）」の「DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGSプロシージャのパラメータ」説明抜粋より抜粋, Top N SQLのサイズ。 SQL基準（経過時間、CPU時間、解析コール、共有可能メモリ、バージョン・カウント）ごとにフラッシュするTop SQLの数。この設定の値は、統計レベルまたはフラッシュ・レベルによる影響を受けず、AWR SQLコレクションに対するシステムのデフォルト動作より優先されます。 この設定の最小値は30で、最大値は100000000です。NULLを指定すると、現在の設定が維持されます。, ユーザーはDEFAULT、MAXIMUM、Nの値を指定できます。ここで、Nは、SQL基準ごとにフラッシュするTop SQLの数です。 DEFAULTを指定すると、システムは統計レベルTYPICALのTop 30および統計レベルALLのTop 100のデフォルト動作に戻ります。 MAXIMUMを指定すると、システムはカーソル・キャッシュ内のSQLの完全なセットを取得します。 数値Nを指定することは、NUMBER型を使用してTop N SQLを設定することと同じです。 この引数にNULLを指定すると、現在の設定が維持されます。, 仮にTOPNSQLを大きな値にしていても、「4.1 スナップショット間隔の工夫」の実験のとおりShared PoolにそのSQLが存在しなければAWRにSQLを保存することができません。Shared PoolにSQLが十分に残っている状況で、AWRに保存するSQLの数を調節したい場合にTOPNSQLを設定しましょう。なお、4.1の実験はTOPNSQLを10000に増やした設定で実験しました。デフォルト設定値は、「TOPNSQLパラメータの説明」のとおりstatistics_level = typicalの場合は30です, これまで、3回にわたってStatspackおよびDiagnostics Packを使用したOracleデータベース性能監視機能について説明しました。そのなかでも、2回目、3回目ではあるシナリオをベースとした実際の分析手法を説明しました。今回取り扱ったシナリオの性能問題となった原因は、さまざまなケースにかならず当てはまるというわけではありません。しかし、StatspackやAWRレポートなどの分析方法そのものはさまざまなケースに当てはまるポイントを中心に説明しているため、多くのケースで役に立つものと考えています。とはいえ、実際に分析するという経験はとても重要です。私自身、これまで膨大な量のStatspackレポートを分析してきたからこそDiagnostics Packの便利さを理解していると感じています。, また、「4 AWRスナップショット」でも説明しているとおり、StatspackやAWRは実行されたすべてのSQLを保存するための機能ではありません。性能監視機能に限ったことではありませんが、大切なのはそれぞれの機能の特徴をよく理解し、その時に必要とされるもっとも適した機能を選択することです。, 性能分析手法と分析のための道具（機能）を知っているか、知っていないかによって、技術者としての能力に大きな差が生まれます。皆様にとって今回のこの記事がその知識を増やすことに少しでもお役立ていただけたのであれば幸いです。まだこれらの機能を使用してみたことのない方もぜひお試しください。, 4.4 Automatic Workload Repository(AWR)ビュー, select emp1no, ename from emp1 where emp1no = 15996, select emp1no, ename from emp1 where emp1no = 15993, select emp1no, ename from emp1 where emp1no = 15990, select emp1no, ename from emp1 where emp1no = 15999, select emp1no, ename from emp1 where emp1no = 15987, select emp1no, ename from emp1 where emp1no = 15984, select emp1no, ename from emp1 where emp1no = 19914, select emp1no, ename from emp1 where emp1no = 15989, select emp1no, ename from emp1 where emp1no = 15983, select emp1no, ename from emp1 where emp1no = 15992, 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。, Oracle Database 10g Release 2 Enterprise Edition（10.2.0.3.0）, SQL ordered by Reads DB/Inst: O102EE1/o102ee1 Snaps:1119-1120, -> End Disk Reads Threshold: 1000 Total Disk Reads:1,411, -> Captured SQL accounts for 210.0% of Total Disk Reads, -> SQL reported below exceeded 1.0% of Total Disk Reads　←★注目, 検索条件のリテラル値が異なるため、個々のSQL文は違うものと判断されていた。結果として、AWRレポートのSQL ordered by CPU Timeなどで上位にランクされず、原因の特定が難しかった。, StatspackレポートやAWRレポートの各SQL Orderedセクションに、この問題のSQLが上位にランクされなかったのはなぜか（SQL Ordered by Reads以外のセクションに表示されなかったのはなぜか）, 2万回も実行したのに、AWRビューの検索結果では1076件しか見つからなかったのはなぜか, ただし、実行させるSelect文はリテラルを使用し、リテラル値を0から9999まで順番に実行させる（バインド変数未使用であり、Oracleデータベースへはすべて異なるSQLとして認識させる）, 1回目：テスト・アプリケーションの開始、終了それぞれ1回ずつスナップショットを作成, 2回目：テスト・アプリケーションの開始、終了それぞれ1回ずつに加え、実行中にも数回スナップショットを作成, 1回目の試験の結果では、emp1no列の条件として指定したリテラル値が大きいもののほうが多い（6780がもっとも小さい値であり、9999に近づけば近づくほど抜け落ちている番号が少ない）。, 2回目の試験の結果ではSnap IDが小さいものにはリテラル値も小さい値のものが保存されている（1回目に保存されていなかった6780以下のものも保存されている）。.