http://tech.e2sn.com/oracle-scripts-and-tools/session-snapper の翻訳です。本文書に関する指摘については、原文著者のTanel Poderさんではなく、渡部まで御連絡お願いいたします。
日本語訳：渡部 亮太 (WR at Csus4 dot net)
履歴
- 2012-11-17: 初稿up
- 2012-11-19: 公開先URL変更、誤記修正、ページ表示変更
Session Snapper
Snapperをダウンロードするだけであれば、以下のURLから入手できます：
- http://files.e2sn.com/scripts/snapper.sql
（コピー＆ペーストするのではなく、ファイルを右クリックして、[名前を付けて保存]を使用してください…いくつかのエディタや端末エミュレータは、大きなコンテンツをペーストするときにコードを台無しにするためです。- ORA-06550のエラーに出くわす羽目になるかもしれません！）
でも、私はSnapperの能力と限界をよく理解するため、この記事をざっと読んでみることをお勧めしますよ！
はじめに
Tanel Poderによる、Oracle Session Snapperの構文と例
ASHスタイルのV$SESSIONサンプリングにより、Snapperは、データベース·アクティビティーなどの要因となる上位セッション、上位待機イベント、上位SQL_ID、上位PL/SQLプロシージャをレポートできます。
追記! 私はSnapperにおけるASHスタイルのサンプリングについて話していますが、Oracleの（別途ライセンスが必要となる）ASHについては話していません。これらは、同じコンセプトに基づくものですが、別のツールです。Snapperが行っていることは、昔ながらのPL/SQLを使用した、V$SESSIONビューのサンプリングです。これは、Oracleがあれば "無料で"使える機能です。
データベースに問題が発生したときはいつでも出来るだけ速やかに、自らの手でそれを解決する必要に迫られる現場のDBAのための、迅速かつ簡単に使用できるアドホックなパフォーマンストラブルシューティングツールとなることを意図して、Snapperは作られています。Snapperは、柔軟性のある最初のラウンドのパフォーマンスのトラブルシューティングツールであることを意図して作られています。すなわち、SQLトレースなどの重いオペレーションに頼るのではなく、数秒で簡単に実行できるようなトラブルシューティングのエントリー·ポイント·ツールであることを意図しています。
Snapperはあなたのために魔法を実行しないことに注意してください。Snapperは、スマートなパフォーマンスの推奨事項や、チューニングのアドバイスを提供しません。Snapperが行うことは、事実を（上手に）提示することに過ぎません。V$SESSTATのようないくつかのビューからスナップショットを取得し、あるセッションに対するパフォーマンスカウンタがスナップショットの期間中にどの程度増加したかを示します。さらにSnapper v3は、ASHがするように、スナップショット期間中に取られたアクティブV$SESSIONサンプルの上位レポートを表示します。
Snapperに関するいくつかの重要な点を示します。
- Snapperは、データベース内にオブジェクトを一切作成しません
- Snapperは、単なる無名PL/SQLブロックであり、実行時に解析およびコンパイルされます
- Snapperは、データベーススキーマや設定に対する変更が不要です。
あなたが今読んでいるこのページは、完全な体系的パフォーマンス トラブルシューティングガイドではなく、単にSession Snapperの機能を示すツールページでであることに注意してください。
ここでは、新しいSnapper v3ができることの例をいくつか示します。
Snapperを使用する
最初の例では、問題セッションのSID（または遅延動作中のジョブ）をすでに特定できていると仮定します。ここではそのセッションはSID=144であるとします。すると、以下のようにSnapperを実行できます。
SQL> @snapper ash 5 1 144まだSnapperに慣れ親しんでいない場合、それは4つのパラメータを取ります。
- パラメータ1（ash）では実行される測定の種類 を指定します：
- Snapper v3では、ASHスタイルのサンプリング"ASH"を使用できます。
- Snappoerの全バージョンで、V$SESSTATおよび他のパフォーマンスカウンタのスナップショットをとる "STATS"を使用できます
- パラメータ2（5） スナップショット期間の長さを指定します
- この例では、Sanpperが5秒間セッション アクティビティを測定し、レポートを出力することを意味しています。
- パラメータ3（1）は、 パフォーマンススナップショットの取得とレポートの実行を何度実行するかを指定しています。
- 最初のラウンドのトラブルシューティングには、私は通常、1つのスナップショット/レポートを使います。長期間にわたる複数のスナップショットやレポートを取得するために、大きめの数値を使う場合もあります。
- パラメータ4（144）興味のあるセッションのSIDのSIDです
- 例のようにただ1つのSIDを指定できます- 144
- カンマで区切られた複数のSIDを指定できます - 144,145,200
- インスタンス内のすべてのセッションを意味する"all"を指定できます- all
- 指定された文字列とV$SESSION内の対応する列にマッチするセッションに絞り込むため、user=SYSTEMまたは、program=sqlplus またはmodule= HR のような特殊なオプションを使用できます（許される完全な構文についてはSnapperスクリプトを直接見てください）。
- 最後に、SIDのセットを指定するために"select sid from v$session where username='SYSTEM' and program not like 'sqlplus%'"のような任意のサブクエリを使用できます。
以下の例を参照してください。
Snapper ASHモード
まず、問題となっているバッチジョブセッションのSIDが144であると、すでに識別していると仮定しましょう。SID 144に対して一度、5秒間スナップショットで、ASHのモードでSnapperを実行してみましょう：
SQL> @snapper ash 5 1 144Sampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )-----------------------------------------------------------------------Active% | SQL_ID | EVENT | WAIT_CLASS----------------------------------------------------------------------- 100% | 5htvg1rhy5dfv | enq: TM - contention | Application-- End of ASH snap 1, end=2010-03-22 19:54:09, seconds=5, samples_taken=42PL/SQL procedure successfully completed.ほら、このケースでは、出力は非常に単純になります。何を意味するのか見てみましょう：
- Active % は、実際に測定されたメトリックです- セッションのアクティビティ。Snapperの実行中、出力行にリストされた操作/動作が、応答時間に対してどの程度の時間を費やしたかを示すカラムです。
- したがって、100%とは、このセッション（144）が、その応答時間の100%をSQL_ID 5htvg1rhy5dfvのSQL実行に費やしていたことを意味しています。
- そのSQLを実行している間、全ての期間（Sanppeでのサンプリングの5秒間）において、enq: TM - contention待機イベントにて待機する状況が発生していました。
SnapperのASH機能は、（ちょうどASH自体のように）V$SESSIONを定期的にサンプリングする（大体スナップショットを取る）ことで動作します。セッションが行うすべてのことをキャプチャするわけではありません。しかし、重要な事象はすべてキャプチャします。
例えば、このセッションが本当に上記で述べた操作を100パーセントおこなっていたかどうかか、我々は完全に保障できません。そのSQL_IDの実行にビジーであり、その応答時間の99%だけをそのイベントで待機していて、応答時間の1%は何か他のことをしたかもしれませんSnapperは、2つのサンプルの間に、"その他"の事象が非常に短い期間発生したため、サンプリングによってotherの1%を逃したかもしれず、そのため、キャプチャされませんでした。しかし、多数取得したサンプルの1つにさえも記録されない、非常に短時間で稀な事象が発生する場合は、それほど重大なことにはなりえません。何かが応答時間の50%を占める場合は、必ずその "何か"ハプニングを示すいくつかのサンプル（とら全体の約半分）があるでしょう。
Snapperのレポート出力のフッターには、スナップショット期間の終了時刻、サンプリングを行った秒数、V$SESSIONのサンプル数が表示されます。上記では、Snapperは5秒の間（毎秒8以上のサンプル）、42 ASHサンプルを取得したことがわかります。スナップショット期間が短い（最大10秒）場合は非常に高速でサンプリングし、スナップショット期間が長い場合は測定オーバーヘッドを削減するために、サンプリング周期を下げるように、Snapperは作られています。期間が長い場合は、ちょうどASHのようにサンプリング周期は1Hz、すなわち毎秒1サンプリングになります。
上記の例に引き続き、セッション144はそのすべての時間、エンキューロックを待っていたことが判明したとします。おそらく、今、誰がわれわれをブロックしているか、ロックしようとしているリソースの種類は何かを知りたくなります。待機エンキュー·ロックの場合は、待機イベントの追加の詳細列（P2、P3）が、私たちがロックしようとしていたオブジェクト/リソース（意味については、V$LOCKタイプを見てほしい）に関する追加情報を提供します。だから我々はこの待ち時間に関する詳細な情報を取得するために、V$SESSIONから、P3列をP2をサンプリングしたいです。また、エンキューの場合は、そのセッションがブロックしていたかを確認できるV$SESSIONのBLOCKING_SESSION列（10gから使用可能）をサンプリングできます。
このため、、デフォルトのASH 上位アクティビティのグループ化方法を使う代わりに、ASH =構文を使用して、必要に応じてV$SESSIONの列を指定できます。すべてのV$SESSION列がSnapperで使用可能ではないことに注意してください。最も重要なものは以下のものです。+記号で区切られた列リストで、サンプリングしたい列を指定できます。
SQL> @snapper ash=sql_id+event+wait_class+blocking_session+p2+p3 5 1 144Sampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )-----------------------------------------------------------------------------------------------------------------------Active% | SQL_ID | EVENT | WAIT_CLASS | BLOCKING_SESSION | P2 | P3----------------------------------------------------------------------------------------------------------------------- 100% | 5htvg1rhy5dfv | enq: TM - contention | Application | 162 | 78452 | 0-- End of ASH snap 1, end=2010-03-22 19:55:31, seconds=5, samples_taken=46PL/SQL procedure successfully completed.ほら、すみやかに追加詳細情報を確認できています。ブロッカー セッションのSIDは162です（そして、そのセッションが何をしているかを確認するために、そのセッションにSnapperを実行できます）、私たちのセッションが待機している、ロックされたオブジェクトのオブジェクトIDは78452です。
セッションが、ある１つのSQLを実行し、同じ待機イベントを待機してstuckしているような、上記の例は、Snapperのプロファイリング機能を適切に伝えるものではありません。
別の例を見てみましょう。
SQL> @snapper ash 5 1 156Sampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )-----------------------------------------------------------------------Active% | SQL_ID | EVENT | WAIT_CLASS----------------------------------------------------------------------- 36% | 3jbwa65aqmkvm | read by other session | User I/O 33% | 3jbwa65aqmkvm | direct path read | User I/O 28% | 3jbwa65aqmkvm | ON CPU | ON CPU 3% | 3jbwa65aqmkvm | db file sequential read | User I/O-- End of ASH snap 1, end=2010-03-22 19:50:11, seconds=5, samples_taken=36
明らかに、この場合はセッションが単一の待機イベントを待機してstuckしていません。
上位セッション·アクティビティー·レポートでは、すべてのSQL IDが同じであるため、同一のSQLを実行しているように見えます。ですが、その異なる待機イベントを待機し、またCPUにいくつかの時間を費やしています。
そのセッションのCPU使用率が唯一のSnapperの実行中に28%で、残りの応答時間の72%は、すべての物理IO関連の待機イベント（36パーセント33パーセント3パーセント）に費やされていることがわかります。Snapperの実行中における、そのセッションのCPU使用率は28%だけで、残りの応答時間の72%はすべて物理I/O関連の待機イベント（36パーセント+33パーセント+3パーセント）に費やされていることがわかります。
従って、そのセッションのパフォーマンスをトラブルシューティングするならば、（少なくともSnapperの実行中は）応答時間の100%がSQL_ID 3jbwa65aqmkvmの実行に費やされたこと、実行プロセスの72%がI/O時間であることを知っています。よって、注目すべきSQL文をまさに知っていることになります。
もう一つ例を見てみましょう：
SQL> @snapper ash 5 1 156Sampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )-----------------------------------------------------------------------Active% | SQL_ID | EVENT | WAIT_CLASS----------------------------------------------------------------------- 30% | gvgdv2v90wfa7 | db file sequential read | User I/O 7% | 0bzhqhhj9mpaa | db file sequential read | User I/O 5% | 75621g9y3xmvd | db file sequential read | User I/O 5% | 05s4vdwsf5802 | db file sequential read | User I/O 5% | 5raw2bzx227wp | db file sequential read | User I/O 2% | 0yas01u2p9ch4 | db file sequential read | User I/O-- End of ASH snap 1, end=2010-03-22 19:50:29, seconds=5, samples_taken=43複数の異なる文がレポートされ、かつ、すべての文で著しく長い応答時間を要しており、すべての文でUser I/Oクラスの待機イベントであるので、I/Oサブシステムについて調査するような状況（突然すべてのSQL文で上位の待機としてI/O関連の待機イベントが報告されるような状況）かもしれない。
補足! 注目すべき1つの興味深く重要な点があります - Active %のサンプルの合計は54%にすぎません！これは、このセッションは、サンプリング時間中に（大体）54%だけアクティブであったことを意味します！したがって、残りの時間は、ネットワークを介してアプリケーションから到着する次のリクエストを待ち、アイドル状態だったことになります。このケースでは、データベース·セッションが短時間しかアクティブでないことがわかります。したがって、データベースをチューニングしても意味がありません - 十分に速いデータベースに対して、なぜアプリケーションが新規リクエストを送信しないのか、を確認する必要があります。
セッションのアイドル状態である主な理由は単純です：
- ユーザーが考える時間。ユーザがコーヒーを飲みに行ったか、アプリケーションの実行に十分でないぐらいPCが遅い:-)
- アプリケーションが考える時間。アプリケーションサーバが過負荷になっているときや、アプリケーションサーバのコードに問題があるときに、しばしば発生します。アプリケーションがビジーまたはstuckているため、速くデータベースにリクエストを送信したり、受け取ったデータを処理することができない。
- 最後に、ネットワークのレイテンシとスループット。意図的にこの項目を最後に残しました。なぜなら、ネットワークに問題があるに違いないと即座に決めてかかるのではなく、（ネットワークより上位のレベルに位置づけられる）ユーザーとアプリケーションの実際の動作状況を確認することのほうが有意義であるためです。
すでに書いたように、Snapperはあなたに事実とパフォーマンスの数値を提供するためのツールであることに注意してください。Snapperはあなたのためにパフォーマンスの推奨事項を提供しません。トラブルシューティングとチューニングのための体系的なアプローチを会得する必要があります。Snapperは、それをサポートするツールです。Oracleのパフォーマンスに関するliving bookで、体系的なチューニング＆トラブルシューティングアプローチについて詳しく書く予定です。 （もしくは、私のセミナー に参加してもよいかもしれない 
)
)単一のセッションのスナップショットについてはこれで終了ですが、Snapperはこれ以上のことができます！
複数のセッションを測定したい場合もあるし、事前にSIDがわからない場合もあるし、インスタンス全体の活動を見てみたい場合もあるでしょう。Snapperはこんな状況にも有効です！
3.2 （インスタンス全体の）すべてのセッションに対してASHモードでSnapperを実行する
すべてのセッションのアクティビティを測定するためにSnapperを使用することは簡単です。
SIDではなく、 単にallと指定します。
SQL> @snapper ash 5 1 allSampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )-----------------------------------------------------------------------Active% | SQL_ID | EVENT | WAIT_CLASS----------------------------------------------------------------------- 69% | 3h1z39qtgwc5h | db file scattered read | User I/O 29% | fy8n9175jyj7s | db file scattered read | User I/O 9% | | log file parallel write | System I/O 2% | fy8n9175jyj7s | ON CPU | ON CPU 2% | | control file parallel wri | System I/O-- End of ASH snap 1, end=2010-03-22 17:33:17, seconds=5, samples_taken=45PL/SQL procedure successfully completed.Active% が1つのセッションの応答時間を示していることに注意してください！2つのセッションが応答時間中ロックを待機しているなら、200%が出力されます。
それぞれのセッションがどの程度イベントを待っているかをブレークダウンしたいとしましょう。ASHのパラメータ（下図のように）にSID列を追加することができ、すると上位レポートはSID、待機イベント(event)と待機イベントクラス(wait_class)によってグループ化されます。
SQL> @snapper ash=sid+event+wait_class 5 1 allSampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )--------------------------------------------------------------Active% | SID | EVENT | WAIT_CLASS-------------------------------------------------------------- 95% | 133 | db file scattered read | User I/O 8% | 165 | control file parallel wri | System I/O 5% | 133 | db file sequential read | User I/O-- End of ASH snap 1, end=2010-03-22 17:33:53, seconds=5, samples_taken=40PL/SQL procedure successfully completed.SID 133は、その応答時間の約95%をdb file scatteredで待機し、5%をdb file sequential readで待機していたことを確認してください。 I/O操作の間に発生するCPUの使用時間はとても短いため、SnapperによるV$SESSIONのサンプリングでも見えません。言い換えれば、このセッションでは、Snapperの実行中にはCPUを著しく使用しませんでした。
Snapperで複数のセッションのアクティビティー·レポートを取得する
上で見たような、ただ1つの上位レポートでは十分でない場合があるかもしれません。あなたは、複数の異なる角度（異なる列によるASHサンプルのグループ化）からセッション/インスタンスのアクティビティデータに見たいと思うかもしれません。これが、私はSnapper構文にash1、ash2とash3パラメータを追加した理由です。あなたは1回のSnapper実行で最大4つのASH 上位アクティビティのブレークダウンを表示できます。例えば、負荷の大部分を占めるPL/SQLパッケージがあるかどうかを確認するため、PL/SQLパッケージのobject_idおよびそれに含まれるプロシージャのIDによって、セッション·アクティビティをブレークダウンしたいとします。
（これらの列はV$SESSIONにて10.2.0.3から使用できます）
SQL> @snapper ash=sid+event+wait_class,ash1=plsql_object_id+plsql_subprogram_id+sql_id 5 1 allSampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )--------------------------------------------------------------Active% | SID | EVENT | WAIT_CLASS-------------------------------------------------------------- 70% | 133 | db file scattered read | User I/O 25% | 133 | db file sequential read | User I/O 9% | 165 | control file parallel wri | System I/O 7% | 166 | log file parallel write | System I/O 5% | 133 | ON CPU | ON CPU---------------------------------------------------Active% | PLSQL_OBJE | PLSQL_SUBP | SQL_ID--------------------------------------------------- 43% | | | dv59rkngpa8m1 30% | | | b8qywu6ug00u3 23% | | | fgkm2nvqhyyqh 16% | | | 2% | 5357 | 135 | 82hxvr8kxuzjq 2% | 4345 | 105 | 1gu8t96d0bdmu-- End of ASH snap 1, end=2010-03-22 17:34:51, seconds=5, samples_taken=44セッション·アクティビティのサンプルから、上位プログラム、モジュールおよびアクションを示すレポートを一緒に表示したいとしましょう：
SQL> @snapper ash=sid+event+wait_class,ash1=plsql_object_id+plsql_subprogram_id+sql_id,ash2=program+module+action 5 1 allSampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )--------------------------------------------------------------Active% | SID | EVENT | WAIT_CLASS-------------------------------------------------------------- 100% | 133 | db file scattered read | User I/O 5% | 165 | control file parallel wri | System I/O 2% | 162 | ON CPU | ON CPU 2% | 167 | db file parallel write | System I/O 2% | 166 | log file parallel write | System I/O---------------------------------------------------Active% | PLSQL_OBJE | PLSQL_SUBP | SQL_ID--------------------------------------------------- 77% | | | a5xyjp9gt796s 23% | | | 4g4u44bk830ms 12% | | |-------------------------------------------------------------------------------------------Active% | PROGRAM | MODULE | ACTION------------------------------------------------------------------------------------------- 100% | sqlplus@mac01 (TNS V1-V3) | sqlplus@mac01 (TNS V1-V3) | 5% | oracle@solaris02 (CKPT) | | 2% | oracle@solaris02 (DBW0) | | 2% | oracle@solaris02 (CJQ0) | | 2% | oracle@solaris02 (LGWR) | |-- End of ASH snap 1, end=2010-03-22 17:35:06, seconds=5, samples_taken=43同様にあなたはash3パラメータを使用できます。=および列リストを指定しないでashのパラメータだけ指定すると、デフォルトの上位グループ化が使用されますが、デフォルト設定を変更できることに注意してください。- snapper.sqlファイル内のCONFIGを見てください。
上記のすべては、Snapper v3から使用可能です。しかし、それはSnapperのフル機能の一部にすぎません。上位SQL_IDおよび待機イベントでは十分でない場合があります。セッションがCPU100%であり、何かを待機しているわけではなく、SQL実行計画に明らかに問題がないようなケースです。セッションが本当に何をしているのかを知りたい時です。Oracleの動的パフォーマンスカウンタの出番です - V$SESSTAT統計について話しましょう。
4 Snapper V$パフォーマンスカウンタ / 統計モード
Snapperはバージョン1以来、統計モードを持っています。私がSnapperを書いた当初の理由は、SQLトレースのような従来型のツールや、AWR / Statspackのようなインスタンス·レベルのパフォーマンス·ツールでは有効でない状況に対応するためです。v3から、Snapperは、V$SESSTAT統計情報を自動的に表示しません。 インスタンス全体のトラブルシューティングツールとして使用されることを意図しているためです。 （そして、インスタンス内に非常に多くのセッションが存在する場合は、すべてのセッションについてV$SESSTATを問い合せることは負荷が高いかもしれないため）
V$SESSTATサンプルにドリルダウンしたい場合は、statsパラメータを使用する必要があります。これは、V$SESSTATおよびその他のV$ビューのスナップショットをSnapperに取得させるパラメータです。（または、その代わりにashとstatsの両方を可能にするallを使用できます）
さらに、gatherオプションで 、どの種類の統計をキャプチャするかを指定できます。このオプションについては次のとおりです。（Snapperスクリプトのヘッダーの文書セクションから直接引用しています）、
- セッション·レベルの統計情報：
- s - V$SESSTATからのセッション統計
- t - V$SESS_TIME_MODELからのセッション時間モデル情報
- w - V$SESSION_EVENTおよびV$SESSION_WAITからのセッション待機統計
- インスタンス·レベルの統計情報：
- L - V$LATCHからのインスタンスラッチ取得統計（gets+ immediate_gets）
- e - V$ENQUEUE_STATからのインスタンス·エンキュー·ロック取得統計
- b - x$kcbswからのバッファ取得統計 -10.2までのバージョンで有用
- a - 上記のすべて
gatherオプションが省略された場合（ただし、 statsが有効になっています）、Snapperは、セッションレベル統計 （s、t、w）のみを収集します。
次の例で、私はすべてのセッションからashセッション·アクティビティのスナップショットを取っており、また、Snapperに時間モデル統計（t）とV$SESSTAT統計（s）を収集することを指示しているが、それらには、（統計の）名称に%CPU%文字列を持つ時間モデル統計(tinclude)のみを含まれ、%parse%を含むV$SESSSTAT統計(sinclude)のみが含まれます。
SQL> @snapper ash=event+wait_class,stats,gather=ts,tinclude=CPU,sinclude=parse 5 1 allSampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )---------------------------------------------------------------------------------------------------------------------- SID, USERNAME , TYPE, STATISTIC , DELTA, HDELTA/SEC, %TIME, GRAPH---------------------------------------------------------------------------------------------------------------------- 119, SYS , STAT, parse count (total) , 12, 2.4, 133, SYS , STAT, parse time cpu , 404, 80.8, 133, SYS , STAT, parse time elapsed , 418, 83.6, 133, SYS , STAT, parse count (total) , 11241, 2.25k, 133, SYS , STAT, parse count (hard) , 11241, 2.25k, 159, (J000) , TIME, DB CPU , 859, 171.8us, .0%, | | 161, (MMON) , STAT, parse count (total) , 5, 1, 161, (MMON) , STAT, parse count (hard) , 3, .6, 161, (MMON) , TIME, background cpu time , 8629, 1.73ms, .2%, | | 162, (CJQ0) , STAT, parse count (total) , 1, .2, 162, (CJQ0) , TIME, background cpu time , 3242, 648.4us, .1%, | | 167, (DBW0) , TIME, background cpu time , 142, 28.4us, .0%, | | 170, (PMON) , TIME, background cpu time , 1267, 253.4us, .0%, | |-- End of Stats snap 1, end=2010-03-22 18:02:28, seconds=5-----------------------------------------------------Active% | EVENT | WAIT_CLASS----------------------------------------------------- 105% | ON CPU | ON CPU 17% | db file sequential read | User I/O 2% | log file parallel write | System I/O-- End of ASH snap 1, end=2010-03-22 18:02:28, seconds=5, samples_taken=41PL/SQL procedure successfully completed.上記の出力の上部にて、Snapperのstatsモードが、1秒あたり2250回（たくさんある！）ハード解析を実行しているセッション133を、どうやって簡単にbring outしているかを見て欲しいと思います。。
V$SESSTATにある全ての統計を使用できます。
（Oracleの11.2には、セッションごとに600種類以上の統計があります）例えば、sincludeパラメータに "redo size"を指定したなら、大部分のREDOを生成するセッションを簡単に確認していただろう。
もう1つ注意することとして、下側に出力されたASHセクションでは、単一セッションの応答時間に対して105%のCPUアクティビティが出力されている（これは、CPUを使用する1つ以上のセッションあったに違いないことを意味する）が、STATSセクションの時間モデル統計（type=TIME）ではDB CPUが大きくレポートされていない点があります。ここでの問題は、測定の粒度に起因するものです。時間モデル統計は、データベース·コールの終了時点でV$ビューが更新されますが、（私のテストケースのように）データベース·コールの実行時間が長い場合、V$SESS_TIME_MODELのstatsはデフォルトではおおよそ5秒ごとに更新されます。Snapperの実行時間が短かった（5秒）ため、長時間実行されているデータベース·コールによるセッションにより発生したV$SESS_TIME_MODELのインメモリ配列の更新より前に、スクリプトが終了しました。
60秒のような長いサンプリング時間でSnapperを実行した場合、時間モデル統計が適切に表示されるはずです。
これまで、1つのセッションまたはインスタンス全体でSnapperを実行する方法を説明してきました。特定のユーザ、サービス、またはプログラムのすべてのセッションを監視したい場合もあると思います。これも、Snapperで実現することができます：
インスタンスのセッションのサブセットにSnapperを実行する
v3から、Snapperには特定のユーザー、アプリケーション、サービスなどに属するセッションを指定する便利な方法があります。たとえば、4番目のパラメータとしてSIDを指定する代わりに、単にuser= XYZ （またはusername= XYZと書くことができます:
SQL> @snapper ash=sid+event+wait_class,ash1=sid+sqlid+module,stats,gather=ts,tinclude=CPU,sinclude=parse 5 1 user=SOESampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )---------------------------------------------------------------------------------------------------------------------- SID, USERNAME , TYPE, STATISTIC , DELTA, HDELTA/SEC, %TIME, GRAPH---------------------------------------------------------------------------------------------------------------------- 9, SOE , TIME, DB CPU , 30000, 6ms, .6%, |@ | 17, SOE , TIME, DB CPU , 70000, 14ms, 1.4%, |@ | 21, SOE , TIME, DB CPU , 30000, 6ms, .6%, |@ | 144, SOE , STAT, parse count (total) , 2, .4, 144, SOE , TIME, DB CPU , 370000, 74ms, 7.4%, |@ | 156, SOE , TIME, DB CPU , 50000, 10ms, 1.0%, |@ |-- End of Stats snap 1, end=2010-03-22 18:34:09, seconds=5--------------------------------------------------------------Active% | SID | EVENT | WAIT_CLASS-------------------------------------------------------------- 100% | 21 | read by other session | User I/O 93% | 144 | read by other session | User I/O 83% | 156 | read by other session | User I/O 73% | 9 | read by other session | User I/O 54% | 17 | db file scattered read | User I/O 27% | 9 | db file scattered read | User I/O 27% | 17 | read by other session | User I/O 17% | 156 | db file scattered read | User I/O 17% | 17 | direct path read | User I/O 7% | 144 | ON CPU | ON CPU--------------------------------------------------------------Active% | SID | SQL_ID | MODULE-------------------------------------------------------------- 100% | 21 | 3jbwa65aqmkvm | Process Orders 100% | 9 | 3jbwa65aqmkvm | Process Orders 100% | 144 | 3jbwa65aqmkvm | Process Orders 100% | 156 | 3jbwa65aqmkvm | Process Orders 100% | 17 | 3jbwa65aqmkvm | Process Orders-- End of ASH snap 1, end=2010-03-22 18:34:09, seconds=5, samples_taken=41上記で指定したパラメータ（ashとash1）のおかげで、同一のセッション·アクティビティー·データから異なるブレークダウンを取得できる。ユーザSOE（言い換えると、V$SESSIONにおいてusername= 'SOE'）に属するセッションのみを測定しました。
userに加えて、（自明な）他のパラメータを使用できます：
- username（userと同じ）
- SID
- SPID（pidとospidと同じ）
- program
- machine
- osuser
- module
- action
- client_id
しかし、ANDまたはOR条件でこれらのパラメータを組み合わせることはできません。上記の（便利な）構文を使用するときは、一度に1つのパラメータのみが指定できます
Snapperが監視するセッションを正確に指定したいならば、（注目するセッションを複数のand/or条件を追加したいならば)、（Snapper v1とv2でサポートされている）従来のやり方でセッションを選択できます、赤色のテキストを確認してください。
SQL> @snapper ash=sid+event+wait_class,ash1=sid+sqlid+module,stats,gather=ts,tinclude=CPU,sinclude=parse 5 1 "select sid from v$session where username = 'SOE' and program like 'JDBC%'"Sampling...-- Session Snapper v3.10 by Tanel Poder @ E2SN ( http://tech.e2sn.com )---------------------------------------------------------------------------------------------------------------------- SID, USERNAME , TYPE, STATISTIC , DELTA, HDELTA/SEC, %TIME, GRAPH---------------------------------------------------------------------------------------------------------------------- 9, SOE , TIME, DB CPU , 50000, 10ms, 1.0%, |@ | 17, SOE , TIME, DB CPU , 60000, 12ms, 1.2%, |@ | 21, SOE , TIME, DB CPU , 70000, 14ms, 1.4%, |@ | 144, SOE , TIME, DB CPU , 60000, 12ms, 1.2%, |@ | 156, SOE , TIME, DB CPU , 50000, 10ms, 1.0%, |@ |-- End of Stats snap 1, end=2010-03-22 18:34:32, seconds=5--------------------------------------------------------------Active% | SID | EVENT | WAIT_CLASS-------------------------------------------------------------- 97% | 9 | read by other session | User I/O 74% | 144 | direct path read | User I/O 72% | 156 | db file scattered read | User I/O 72% | 21 | direct path read | User I/O 72% | 17 | direct path read | User I/O 28% | 156 | read by other session | User I/O 26% | 17 | db file scattered read | User I/O 26% | 21 | read by other session | User I/O 26% | 144 | read by other session | User I/O 3% | 9 | db file scattered read | User I/O--------------------------------------------------------------Active% | SID | SQL_ID | MODULE-------------------------------------------------------------- 100% | 21 | 3jbwa65aqmkvm | Process Orders 100% | 9 | 3jbwa65aqmkvm | Process Orders 100% | 144 | 3jbwa65aqmkvm | Process Orders 100% | 156 | 3jbwa65aqmkvm | Process Orders 100% | 17 | 3jbwa65aqmkvm | Process Orders-- End of ASH snap 1, end=2010-03-22 18:34:32, seconds=5, samples_taken=39PL/SQL procedure successfully completed.SQL> コマンドラインにフィットし、1つのnumber列がSIDのリストを返すのであれば、SIDパラメータとして、二重引用符中に任意のサブクエリを記述できます！
さっきの例では、"select SID from V$SESSION where …."を指定していますが、かならずしもV$SESSIONに問い合わせる必要はありません。代わりにE-Business Suite、PeopleSoftやSAPの（現在実行中のバッチジョブのSIDが含まれる）バッチジョブスケジューリングテーブルを問い合わせることもできます。
Snapperをダウンロードする
これはSnapperの可能性の序章に過ぎません！traceオプションを使用すれば、さらに多くのパフォーマンスデータを収集、表示し、トレースファイルに永続化することさえができます！
Snapperの最新バージョンをここからダウンロードできます：
- Snapper V3.5 - http://files.e2sn.com/scripts/snapper.sql
Snapper v3.5は現在ではOracle 9.2をサポートしているため、もはや古いSnapperv2を使用する必要はありません。それにもかかわらず、何らかの理由でそれを必要とすれば、ここにあります：
- Snapper V2 - http://files.e2sn.com/scripts/snapper_v2.sql
追記! 右のファイルのリンクをクリックして、「名前を付けて保存」を使用してください…代わりに大容量コンテンツを貼り付けるときにコードを台無しにいくつかのエディタやターミナルエミュレータなどのコンテンツのコピー＆ペーストの - あなたは、ORA-06550のエラーで終わるだろう）！
参考文献
私はブログで、過去にSnapper v1およびv2に関するいくつかの記事を書いているので、これらを読みたくなるかもしれない（Snapper v3で、構文上の変更点がいくつかあることに注意！）私のブログでのすべてのSnapper関連の記事を見ることができます：
もちろん、
実用的なパフォーマンスチューニングやトラブルシューティングのためにSnapperスクリプトを使う方法を習得したい場合は、その後、私のseminar offeringに注目して欲しい。 （オンラインセミナーはまもなく提供予定！）;-)
フィードバック
私は数年前にオリジナルのSnapperを書いたが、私はまだどれだけ多くの人が実際にSnapperを使用しているか、どのようにSnapperを使用しているかについて、明確なイメージを持っていない。だから、過去（あるいは今）、Snapperがあなたの役にたったならその後、あなたがSnapperを使用した方法を記載した数行のメールを私に送ってください！
-
Tanel Poder
訳注：本文書に関する指摘については、原文著者のTanel Poderさんではなく、渡部 (WR at Csus4 dot net)まで御連絡お願いいたします。
