リアルタイム SQL 監視 - Oracle...Oracle Database 11gで導入されたリアルタイムSQL...

リアルタイム SQL 監視

2009 年 12 月


はじめに

Oracle Database 11g で導入されたリアルタイム SQL 監視は、リソース消費量が多く

長時間実行される SQL 文やパラレル SQL 文で発生するランタイム・パフォーマン

スの問題を極めて効果的に特定する手段です。Oracle Enterprise Manager（Oracle EM）

のインタラクティブな画面に SQL 実行の詳細が表示されますが、この情報を取得

するのに使用されるのが、新しい詳細な SQL 統計です。この統計は自動的に追跡

されるようになっており、本番システムのパフォーマンスを低下させることがあり

ません。実行計画の各ステップの統計は、キー・パフォーマンス・メトリック別に

追跡されます。メトリックには、経過時間、CPU 時間、読取りと書込みの回数、I/O

待機時間、およびその他の各種待機時間などがあります。これによりデータベース

管理者は、以前よりも格段に詳細な SQL 実行を分析してから、長時間実行されて

いる SQL を強制終了させるか、完了させるか、チューニングを要請するかを判断

できます。

実装の詳細

Oracle Database のリアルタイム SQL 監視機能では、実行中の SQL 文のパフォーマ

ンスを監視できます。デフォルトでは、SQL 文がパラレル実行された場合、または

1度の実行でCPU時間と I/O時間を合計5秒以上消費した場合に、リアルタイムSQL

監視機能が自動的に開始されます。

V$ビュー

この機能をサポートするために、V$SQL_MONITORビューとV$SQL_PLAN_MONITOR

ビューという 2 つの新しいビューがOracle Database 11gに導入されました1。これら

の新しいビューを次のビューと組み合わせて使用すると、監視中の実行に関する追

加情報が取得できます。

• V$ACTIVE_SESSION_HISTORY

• V$SESSION_LONGOPS

1 SQL 監視の使用方法としてはあまり簡単な方法ではありませんが、Oracle Enterprise Managerのアクティブ・レポートおよび SQL 監視のセクションで同じデータのグラフィカル表示も確

認してください。


2ページ

Oracle Corporation 発行「Real-Time SQL Monitoring」の翻訳版です。

• V$SQL

• V$SQL_PLAN

V$SQL_MONITOR ビューには、V$SQL で使用できる統計のサブセットが含まれます。

ただし、V$SQL とは異なり、監視統計は複数の実行を累計したものではありません。

V$SQL_MONITOR の 1 つのエントリには、SQL 文の 1 回の実行に特化した統計が

保持されます。同じ SQL 文の 2 つの実行が監視されている場合は、2 つの実行それ

ぞれについて別々のエントリが V$SQL_MONITOR に作成されます。

同じ SQL 文の 2 つの実行を一意に識別するために、実行キーと呼ばれる複合キーが

生成されます。この実行キーは3つの属性で構成されており、各属性はV$SQL_MONITOR

の 1 つの列に対応しています。

• SQL 文を識別するための SQL 識別子（SQL_ID）

• 実行開始タイムスタンプ（SQL_EXEC_START）

• この主キーを確実に一意なものにするために内部的に生成される識別子

（SQL_EXEC_ID）

SQL監視データの保存

監視が開始されると、動的パフォーマンス・ビューV$SQL_MONITOR にエントリ

が 1 つ追加されます。当該実行について収集されたキー・パフォーマンス・メトリッ

ク（経過時間、CPU 時間、読取りと書込みの回数、I/O 待機時間、およびその他の

各種待機時間）は、このエントリで追跡されます。これらの統計は、文が実行され

ている間、ほぼリアルタイム（1 秒に 1 回）でリフレッシュされます。実行が終了

すると、監視情報は少なくとも 5 分間 V$SQL_MONITOR ビューに保存されます。

SGAに保存されている SQL監視データがカーソルのエージングによりV$SQLから

削除されることはありませんが、データが存在するのはサイズに制限のあるインメ

モリ・バッファ内であるため、終的には、監視中の新しい文の統計によって上書

きされます。そのため、長時間実行されている SQL 文やパラレル問合せがシステ

ム上に多数存在する場合は、すべての SQL 文が監視される保証はなくなります。

その理由は 2 つあります。インメモリ・バッファの領域に制限があるためと、監視

リストに含まれる SQL 文は必ず 5 分間保存する必要があるためです。ただし、事

実上、このようなことは発生しないようになっています。

SQL計画の監視

リアルタイム SQL 監視では、監視中の SQL 文の実行計画に含まれる各操作の統計

も監視されます。このデータは V$SQL_PLAN_MONITOR ビューに表示されます。

V$SQL_MONITOR ビューと同様に、V$SQL_PLAN_MONITOR の統計は、SQL 文が

実行されている間、1 秒間隔で更新されます。これらの統計も、実行の終了後、少

なくとも 5 分間保存されます。V$SQL_PLAN_MONITOR には、監視されている各

SQL 文に対するエントリが複数保持されます。各エントリは、文の実行計画に含ま

れる 1 つの操作に対応します。


3ページ


パラレル実行の監視

パラレル問合せ、DML 文および DDL 文の監視は、実行が開始されると同時に自動

的に開始されます。パラレル実行に関与している各プロセスの監視情報は、別々の

エントリとして V$SQL_MONITOR ビューと V$SQL_PLAN_MONITOR ビューに記

録されます。

V$SQL_MONITOR には、パラレル実行コーディネータ・プロセス用のエントリが 1

つと、パラレル実行サーバー・プロセス用のエントリがプロセスごとに1つあります。

各エントリに対応するエントリが、V$SQL_PLAN_MONITOR に保持されます。SQL

文のパラレル実行に割り当てられたプロセスは同じ実行のために協調して動作す

るため、これらのエントリには同じ実行キー（SQL_ID、SQL_EXEC_START およ

び SQL_EXEC_ID からなる複合キー）が割り当てられます。したがって、実行キー

で集計すれば、1 つのパラレル実行の統計全体を確認できます。

Oracle Real Application Clusters（Oracle RAC）システムでのパラレル実行はクロス・

インスタンスになるため、V$ビューには現在のインスタンス上で実行されたプロセ

スだけが表示されます。クロス・インスタンス統計を確認するには、GV$ビューを

使用する必要があります。

アクティブ・レポート

Oracle Database 11g Release 2 以降、SQL 監視のレポートにアクティブ・レポート機

能が加わりました。

アクティブ・レポートは、オフライン分析に使用できるインタラクティブなレポー

トです。この機能には Oracle Enterprise Manager のライブ表示と同じレベルの双方向

性があり、さまざまなレベルの詳細情報にドリルダウンできます。たとえば、SQL

監視アクティブ・レポートには、返された行の予想数と実際の数が実行計画のステッ

プごとに表示されます。この情報は、オプティマイザが特定の実行計画を選択した

理由を理解するうえで欠かせない場合があります。

アクティブ・レポートは単一の HTML ファイルとして保存したり、後から参照でき

るようにアーカイブしたりすることができます。また、詳細な分析をしてもらうため

に、たとえばパフォーマンスの問題に詳しい社内の人材やオラクルのサポート担当

者に電子メールで送信するなど、しかるべき人に転送することもできます。

図 1：SQL 監視アクティブ・レポート

アクティブ・レポートを受け取った人は、Oracle Enterprise Manager や Oracle Database

がインストールされていなくてもレポートを表示できます。アクティブ・レポート

は、SQL Monitoring Execution Details ページの上部にある新しいボタン・コントロー


4ページ


ルを使用する方法か、DBMS_SQLTUNE パッケージに含まれる REPORT_SQL_

MONITOR()ファンクションを呼び出す方法で生成できます。

Oracle Enterprise ManagerのSQL監視ワークフロー

Oracle Database 11g の初のリリースに含まれる SQL 監視は、コマンドラインで使

用するものでした。実行中のアクティブな SQL を監視するためのグラフィカル・

ユーザー・インタフェースが初めて登場したのは、Grid Control 10.2.0.5 と Database

Control 11.1.0.7 においてです。基本的には、前述した GV$のデータが集計されて、

Oracle Enterprise Manager の使い勝手の良いインタラクティブな画面に表示されます。

Oracle EM では、SQL 監視データを 3 つの異なるビューで表示します。1 番目のもっ

とも包括的なビューは、システム全体のビューを表示するものでもあり、Performance

ページの下部にあるリンクからアクセスできます。

図 2：SQL Monitoring のリンク

このリンクをクリックすると Monitored SQL Executions ページが開き、そのシステ

ム上で監視中または監視が終了したすべての SQL 文のリストが表示されます。

図 3：Monitored SQL Executions ページ

このページの各行は、監視中または監視が終了した SQL 実行のインスタンスを示し

ます。デフォルトでは、初にもっとも新しい実行から順番に行が表に表示され、

常に初の数行には進行中の SQL 実行が表示されます。このページに表示される情

報は、各実行に関する重要なデータのみで、SQL の ID とテキスト、パラレル DOP な

どのグローバル情報と、ステータス、開始時刻、終了時刻、継続時間、データベース


5ページ


時間の内訳、IO 統計といった実行に関する統計です。このページは定期的にリフ

レッシュされ、進行中の実行の統計が更新されたり、新しく監視が始まった実行の

ためのエントリが追加されたりします。

エントリをクリックすると、Monitored SQL Executions Detail ページにドリルダウン

し、特定の SQL 実行に関する追加情報が表示されます。選択した実行がまだ進行

中の場合は、実行統計をリアルタイムで更新できます。また、計画に含まれる操作

のうち、その時点で実行されているものを確認できます。さらに、SQL に関する多

くの有益な情報を表示できます。表示できるのは、データベース時間の内訳、CPU、

I/O の読取り/書込みの内訳といった実行の SQL レベルの統計、問合せの並列度（DOP）、

実行の開始時刻および終了時刻などです。

図 4：Monitored SQL Execution Details ページ

2 つ目のビューは、SQL 文のさまざまなインスタンスの SQL 監視統計です。この

ビューは SQL Details ページを使用して表示されます。新しい SQL Monitoring タブ

がこのページに導入されました。このタブには、その特定の SQL 文についてこれ

までに監視が行われたすべての実行のリストが含まれます。


6ページ


図 5：SQL Details ページ

3 つ目のビューは、特定のセッションの SQL 監視統計です。このビューは Session

Details ページを使用して表示されます。SQL Details ページと同様に、Session Details

ページにも新しい SQL Monitoring タブが追加されました。このタブには、監視対象

の SQL 文のうち、そのセッションで実行されたものがすべて含まれます。

Session Details ページの Kill Session ボタンを使用すれば、このページからセッショ

ン全体を強制終了させることができるため、SQL 文が暴走してシステム・リソース

が独占され、他のすべてのユーザーに悪影響が出ているような状況をすばやく解決

する手段として使用することもできます。

図 6：Session Details ページ

SQL文に関する情報がさらに必要な場合は、メインのMonitored SQL Executionsペー

ジから SQL Details ページと Session Details ページにアクセスすることもできます。

このように、SQL Monitoring データの 3 つのビューはすべて、Oracle EM 内で相互

にリンクされています。


7ページ


SYSTEM→SQL→SESSION の順に SQL 監視のデータベース・アクティビティを表

示する方法は、この機能で新しく追加されたものではありません。これは Oracle

Database 10g Release 1 以降の Oracle EM の GUI で使用されている主要な手順であっ

て、ここに SQL 監視が完全に統合されただけです。

MONITORED SQL EXECUTION DETAILSページ

ここでは、Oracle Enterprise Manager で新たに使用できるようになったリアルタイム

SQL 監視ユーザー・インタフェースのさまざまなコンポーネントについて、複雑な

パラレル問合せの詳しい例を使用して説明します。この内容は、データベース管理

者の方に、監視対象の SQL 文に関する豊富なランタイム・データを探索する方法

を学んでいただくことを目的としています。Monitored SQL Execution Details ページ

は、Monitored SQL Executions ページから個々の SQL 文をドリルダウンすると表示

されます。

画面の上部、ページ・タイトルの横に、このページで監視されている SQL 文の

ステータス・アイコンがあります。SQL 文のステータスを示すアイコンには、Done、

Running、Failed の 3 種類があります。アイコンの上にマウスを移動すると、アイコ

ンの説明が表示されます。

図 7：監視対象の SQL 文のステータス

また、SQL が失敗した場合は、アイコン・ツールチップを使用して Oracle エラー番

号とエラー・メッセージを表示できるようになっています。この拡張機能は、Oracle

Database 11g Release 2 以降の SQL 監視に導入されています。

次は SQL ID です。SQL ID の上にマウス・ポインタを置くと、実行中の問合せに対

応した SQL テキストが表示されます。


8ページ


図 8：監視対象の SQL 文の SQL テキスト

本番稼働中のシステム上で SQL ID リンクをクリックすると、SQL Details ページが

表示され、その SQL に関する履歴情報だけでなくリアルタイムの情報も表示され

ます。SQL 文が長い場合や SQL 監視の UI からクリップボードに SQL テキストを

コピーする場合は、SQL ID の横にある情報アイコンをクリックします。

図 9：監視対象の SQL 文の SQL テキスト

SQL Text ウィンドウに、SQL テキストの全文と、実行に使用されたバインド変数

に関する情報および変数の値が表示されます。バインド情報は、別のタブで SQL

Text ウィンドウに表示されます。バインド変数に関する情報を知っておくことは重

要です。というのも、SQL の条件の選択性がその値により変化する可能性があるた

めであり、ひいては Oracle オプティマイザにより選択される実行計画と実行統計と

の両方に影響を与えることになるためです。バインド変数を表示する拡張機能は、

Oracle Database 11g Release 2 以降の SQL 監視に導入されています。


9ページ


Overviewボックスの次の項目は"Parallel"です。この項目は問合せの並列度を示します。

この例では、問合せの DOP が 16 になっています。

図 10：監視対象の SQL 文の並列度

この特定の問合せは単一インスタンスの Oracle Database で実行されました。そのた

め、Parallel 行に 1 つの数字だけが表示されています。複数インスタンスをサポート

する Oracle RAC データベースの場合は、この問合せの処理に関与するインスタンス

の数が DOP アイコンの横に表示されます。

図 11：監視対象の SQL 文の並列度

16 という並列度は、この問合せの実行に割り当てられたパラレル・サーバーが 16 台

だけだということを必ずしも意味しません。実際には、パラレル実行サーバー1 組

当たりに割り当てられたパラレル実行サーバーの数を示しています。Oracle では、

単純な問合せの処理には 1 組だけが割り当てられますが、複雑な問合せにはそれぞ

れ 2 組の DOP プロセスが割り当てられます。後者の場合、同じ DOP を使用する理

由（つまり、この例でいえば、32 ではなく 16 を使用する理由）は、たとえ 32 台の

パラレル実行サーバーが割り当てられているとしても、高速化が効率的に行われる

のは 32 台ではなく大 16 台だからです。このような状態になるのは、パラレル実

行の通常のメカニズムによります。つまり、2 組のパラレル・サーバーがデータを

パイプラインで交換するとき、プロデューサまたはコンシューマのいずれかが順番

でアクティブになるためです。

前者の場合の例としては、select * from table_name などの単純な問合せが考

えられます。この場合は、表スキャンに必要なパラレル・サーバーは 1 組だけです。

通常、1 つの操作を並列して実行するというレベルで並列化が発生します（この例

では、表スキャン）。複雑な問合せの場合は、通常、1 つ以上のパイプラインが関

与します。たとえば、前述の単純な選択問合せの結果を使用して集計計算をすると

します。この場合は、全表スキャン操作で取得された行が、GROUP BY 操作に割り

当てられた 2 組目のパラレル・サーバーにパイプラインで送信されます。このよう

にして、1 組目（プロデューサ）から送信されてきたデータが、2 組目（コンシュー

マ）に再配布されます。SQL 計画の図にマークで示した TABLE ACCESS 操作と

GROUP BY 操作をご覧ください。赤い矢印は 2 組のパラレル・サーバーの間で発生

するデータ通信を表しています。


10ページ


図 12：SQL 実行計画の操作と SQL テキストとの関係

"Monitored SQL Execution Details"ページの下部にはいくつかのタブがあります。デ

フォルトで表示される初のタブには、監視されている文の実行計画に関する統計

が行単位で表示されます。

図 13：監視対象の SQL 実行の計画操作

初のいくつかの列（Operation、Name、Estimated Rows and Cost）には、実行計画

に関するオプティマイザの情報が表示されます。

Name 列には、計画操作に関連付けられているオブジェクト名が表示されます。た

とえば、TABLE ACCESS 操作には LINEITEM という名前の表が関連付けられていま

す。:TQ10000 のようなオブジェクト名は、パラレル表のキューの名前を表してい

ます。表のキューというのは、パラレル問合せの実行期間中に作成される一時的な

インメモリ・オブジェクトで、2 組のパラレル・サーバーの間（この例では、:TQ10000）、

または 1 組のパラレル・サーバーと問合せコーディネータの間（この例では、:TQ10001）

でパイプラインを使用して行を交換するメカニズムの基盤です。

Estimated Rows 列には、特定の計画操作の入力になると予測された行数が表示され

ます。この数字は、文のコンパイル時に Oracle Optimizer が予測した値です。


11ページ


同様に、Cost 列には、特定の操作から派生するサブツリー全体についてオプティマ

イザが予測したコストが表示されます。コストは内部的な単位で表現されます。

Timeline から始まる残りの列には、計画の各行について SQL 監視で収集されたラン

タイム統計が表示されます。また、問合せがパラレル実行された場合は、各操作を

実行したパラレル・エンティティの種類も示されます。この情報は、操作名の左側

の小さいアイコンで表示されます。表示されるアイコンの種類は 3 つあり、例にす

べて表示されています。操作を実行しているパラレル問合せコーディネータは明る

い緑色のアイコン、1 組目のパラレル・サーバーは青色のアイコン、2 組目のパラ

レル・サーバーはオレンジ色のアイコンで示されます。この例では、オレンジ色の

アイコンで示されている 2 組目のパラレル・サーバーが、LINEITEM 表をパラレル

でスキャンします。この組に含まれる各サーバーが表のブロックのサブセットをス

キャンし、選択した行のサブセットを事前集計します。事前集計が完了すると、事

前集計された行は青色のアイコンで示される 1 組目のパラレル・サーバーに送信さ

れ、ここで終的な集計がパラレル実行されます。行は、GROUP BY キーの値に基

づいて 2 組のサーバーの間でパイプラインを使用して再配布されます。

Timeline 列には、各計画操作について、問合せの実行の開始時刻を基準にした相対

的な開始時刻と、実際の継続時間が表示されます。問合せの合計ランタイムは列の

ヘッダーに表示されます（この例では 232 秒です）。マウス・ポインタを Timeline

のバーの上に置くと、相対的な開始時刻だけでなく、各操作の継続時間を数値で表

した情報も確認できます。

図 14：SQL 実行の計画操作のタイムライン

計画の行は、問合せの実行の各段階でアクティブになったりそうでなくなったりし

ます。たとえば、ネステッド・ループ結合の右側の操作は複数回実行されるため、

SQL の実行中はビジー状態になったりアイドル状態になったりします。Timeline 列

には、初めて操作がアクティブになった時刻から後にアクティブだった時刻まで

の、アイドル期間を含む合計継続時間が表示されます。操作の実行が 1 秒未満の場

合、タイムラインは表示されません。

Executions 列には、計画の各行が実行された回数が表示されます。この例では、PX

COODINATOR という操作が 33 回実行されたのが分かります。これは、このパラ

レル実行に関与するすべてのプロセスが、この操作を実行するためです。2 組のパ

ラレル・サーバーを使用しており、1 組は問合せコーディネータ・プロセスで使用

しているため、パラレル問合せを実行しているプロセスの合計数は DOP×2 です。


12ページ


この例では DOP が 16 ですが、ある特定の操作を実行しているプロセスは 33 です。

計画に含まれる他の操作は、1 組または 2 組のサーバーを使用してパラレル実行さ

れるため、Executions 列には 16 という、この問合せの DOP と同じ値が表示されま

す。Table Access 操作は、1,296 回実行されているため、ここでは例外です。このよ

うな値になるのは、パラレル・サーバーが LINEITEM 表の異なるブロック範囲をス

キャンするたびに、PX BLOCK ITERATOR 操作によりこの操作が再起動されるた

めです。実際、ブロック範囲がスキャンされるたびに、PX BLOCK ITERATOR 操

作は次のブロック範囲をスキャンするようにパラレル・コーディネータ・プロセス

から要求されます。次の範囲が取得されると、その新しいブロック範囲に対してもう

一度 TABLE ACCESS 操作が実行されます。簡単な計算により、この TABLE ACCESS

操作の粒度が分かります。合計実行回数は 1,296 で、そのすべてで 247GB のデータ

がスキャンされています。したがって、TABLE ACCESS 操作を 1 回実行するたび

に、平均 200MB 弱のデータがスキャンされたことになります。また、各パラレル

実行サーバーが TABLE ACCESS 操作を実行した回数は、1,296÷16 で、平均 81 回

になります。表は、サーバー・プロセスの合計数をはるかに超える多数のブロック

範囲に分割され、スキャン操作に関与しているパラレル・サーバーの間で動的にロー

ドバランシングされます。この仕組みがあるため、一部に他より処理の速いパラレ

ル・サーバーがあったとしても、各サーバーの処理はほぼ同時に終了します。

図 15：Executions 列の数値

Actual Rows 列には、計画操作により実際に取得された行数が表示されます。この

行数には、対応する計画操作に関与したすべてのパラレル・サーバーによる処理分

が累積されています。この数値は、その操作のすべての実行についても累積されて

います。Actual Rows 列と Estimated Rows 列の値は異なる可能性があり、その理由

としては次の 2 つが挙げられます。1 つは、オプティマイザが作成するのは単なる

予測であり、実際のランタイム値とは異なる可能性があることです。もう 1 つの理

由は、オプティマイザが作成した予測は 1 回の実行を基準にしたものであって、累

積されていない場合があることです。これの良い例がネステッド・ループ結合操作

です。この操作では、左側の行数と同じ回数だけ右側の操作が再実行されます。オ

プティマイザは右側のツリーを 1 回だけ実行した場合の行数を予測しますが、SQL

監視では累積された数が表示されます。したがって、2 つの数値に差が出ます。そ

のため、実際に行数と予測行数を比較することは、大きな差異のあるオプティマイ

ザ予測を検出するのにとても役立ちます。このような差異があると、適ではない

計画が選択される可能性があります。適切でない予測を修正するには、問合せでア

クセスされる元のデータベース・オブジェクトの統計が必ず新の状態になってい

るようにします。


13ページ


その他の適切でない予測が原因で適ではない実行計画をオプティマイザが選択し

ているとすれば、多くの場合、SQL Tuning Advisor を実行することで解決できます。

SQL Tuning Advisor は、SQL プロファイルを推奨することで、適ではない実行計

画を正しくします。

図 16：予測行数と実際の行数の関係

この例で分かるように、オプティマイザの予測に大きな差異はありません。

Memory (Max)列には、特定の計画操作のすべての実行で使用されたメモリの大

量の合計が表示されます。この例では、HASH GROUP BY 操作で合計 13MB のメモ

リが消費されています（"図 17：大メモリ列"の赤いボックスで示している部分）。

図 17：大メモリ列

この操作は、"図 17：大メモリ列"に表示されているように、16 回実行されています。

この例では、メモリ内で集計が実行され、全体で 13MB が使用されました。パラレ

ル・サーバー1 台当たり 1MB 弱ということになります。計画の初の方の段階でメ

モリが消費されていませんが、それは、多くの操作が 1 度に 1 行ずつデータを処理

しているためです。したがって、操作に必要なランタイム・メモリが非常に少なく

なり、SQL 監視にはレポートされません。SQL 監視にレポートされるのは、作業領

域で消費される PGA メモリのみであるため、ハッシュ結合、ハッシュ・グループ

化、ソート、ビットマップ・マージ、ビットマップ索引作成のみがレポートされま

す。

Memory （Max）列は、問合せの実行中は単に"Memory"と呼ばれます。この場合、

この列には、特定の時点で操作が消費しているメモリ量が表示されます。問合せが

完了すると、消費されたメモリの大値が表示されます。

Temp （Max）列には、一時領域に関連付けられている計画操作が消費した一時領

域の量が表示されます。値が NULL 以外の場合は、この操作によりディスク I/O が

発生したことを示します。pga_aggregate_target パラメータの値をチューニングする

ことで、ディスクへの I/O を回避できる場合があります。このパラメータのチュー

ニング方法の詳細は、Oracle のチューニング・ガイドを参照してください。

Temp （Max）列は、問合せの実行中は単に"Temp"と呼ばれます。この場合、この

列には、特定の時点で操作が消費している一時領域の量が表示されます。


14ページ


次の IO Requests 列には、計画操作当たりの読取り/書込み要求数が表示されます。

この例では、すべての IO は、LINEITEM 表をスキャンする TABLE ACCESS 操作に

より実行されたことが分かります。マウス・カーソルを IO バーの上に置くと追加

情報が表示されるようになっており、要求数と実際に読み取られたバイト数の他に、

IO 操作の平均サイズ（この例では 863K バイト）が表示されます。

図 18：IO Requests 列

コンテキスト・メニューの一番上の項目を選択することで、IO 要求数とバイト数を

切り替えることもできます。コンテキスト・メニューを表示するには、マウスを右

クリックします。

Cell Offload Efficiency 列は、Exadata ストレージを使用している場合は、IO 効率係

数と関係があります。この例では 77%の改善が達成されていますが、これは、ディ

スクから読み取られた 247GB のデータのうち、58GB のみが IO インターコネクト

経由で送信されているためです。この値は、減少係数の 77%と対応しています。こ

の効率化が実現するのは、通常、射影と選択がオフロードされ、Exadata ストレー

ジ・セルにより直接評価されることによります。そのため、データベース・サーバー

に戻されるのは関連性のある行と列だけになり、IO 帯域幅が節約されます。オフ

ロードの適化が実行されるのは、全表スキャンと索引高速完全スキャンについて

のみです。

図 19：Cell Offload Efficiency 列

この列は、Oracle Exadata V1 に対してワークロードが実行されている場合にのみレ

ンダリングされます。

次のCPU Activity %列は、各操作が消費しているCPUリソースの割合を示します。

この割合は、GV$ACTIVE_SESSION_HISTORY（略称：ASH）を問い合わせ、すべ

ての CPU サンプルに対して各操作の CPU サンプルがどのくらいあるかをカウント

して求めます。この例では、TABLE ACCESS が消費している CPU リソースは 4.65%

のみで、残りのほとんどすべて（95%）を HASH GROUP BY が消費しています。

CPU Activity の位置にマウスを置くと、CPU アクティビティに関する追加情報が表

示されます。選択した操作について取得された CPU の ASH サンプルの数が表示さ

れます。パラレル問合せの場合は、各パラレル・サーバーがアイドル待機状態では

ないと想定して、毎秒サンプリングされる点に注意してください。このような理由


15ページ


により、この例では、実行時間が 240 秒足らずの問合せによるサンプルが 2,912 件

と大量になっています。

ASH の予測の精度は、対象の文について観察されたサンプルの合計数により異なり

ますが、合計サンプル数は合計実行時間に比例します。したがって、実行時間が長

い問合せの方が、計画行別リソース予測内訳の精度は高くなります。また、ASH に

含まれる CPU サンプルは、操作が CPU 上にあったか CPU を待機している状態だっ

た（つまり、OS スケジューラにより実行キューに配置されていた）ことを意味し

ている点にも注意してください。

図 20：CPU Activity 列

この例では、ほとんどすべての CPU アクティビティが、HASH GROUP BY 集計ス

テップで発生しています。

後の列、Wait Activity %は、問合せについての待機アクティビティの分布を示し

ています。たとえば、TABLE ACCESS 操作では、Exadata セルからデータが送られ

てきてからでなければこのデータを処理できないため、ユーザーI/O 待ちが発生し

ます。

図 21：Wait Activity 列

この例では、すべての待機アクティビティが表スキャン・レベルで発生しているた

め、まっさきに気付くのは、この大きい待機アクティビティ・バーのチューニング

が必要だということです。ただし、適切なところにチューニング作業を集中させる

には、大局的に検討する必要があります。ユーザーI/O 待機のチューニング作業に

取りかかる前に、CPU 待機とユーザーI/O 待機が互いにどのように測定されている

かを把握しておく必要があります。そのためには、データベース時間の内訳を調査

するのが正しいやり方です。データベース時間の大半が CPU で発生している場合

は、CPU を適化するのが理にかなっています。


16ページ


図 22：Monitored SQL Execution Details ページの Activity タブ

Activity タブは Monitored SQL Execution Details ページの 3 つ目のタブで、このタブ

にはアクティブ・セッションと時間を対比させたグラフで ASH データが視覚的に

表示されます。ここには、Plan Statistics タブで使われている色とまったく同じ色で

表示されますが、Waits などの色は異なるディメンションに沿って表示されます。

Activity タブは、問合せアクティビティが時間の経過とともにどのように分散する

かを確認するのに役立ちます。また、パラレル問合せの場合は、SQL が完全に並列

化されなかった期間を探すのに役立ちます。

このタブを見て初に気付くおもな点は、CPU 時間が I/O 待機を大きく超えている

ことです。したがって、集中的にチューニングする必要があるのは、I/O ではなく、

もっとも重大な待機クラスです。

検討する必要があるもう 1 つの重要な要素は Maximum CPU 線です。この線は、デー

タベース・インスタンスが稼働しているホスト上に存在する使用可能な CPU の数

を示しています。この例では、8CPU のシステムを使用しているため、Maximum CPU

線は Active Sessions が 8 の位置に引かれています。明るい緑色の領域のうち、この

線より上にある領域では、処理に CPU リソースが使えるようになるまで待機する

時間が発生します。この問合せに対して 16 のパラレル・プロセスが割り当てられ

ていますが、同時に CPU を消費できるプロセスは 8 つのみで、残りの 8 つは CPU

リソースが使用できるようになるまで待機します。この例では、完全に CPU でボ

トルネックが発生しています。そのため、この問合せを高速化するには、SQL 実行

計画を変更するか、CPU リソースを増やすしかありません。

これらの問題点と Plan Statistics タブとを照らし合わせることにより、この問合せが

費やしている時間の大半は、部分集計レベルの CPU アクティビティであるという結

論が得られます。表スキャンで 17 億行が取得されますが、事前集計操作の結果は 54

行だけです。この問合せはもともとリソース消費量が多く、17 億行を集計するのに

大量の CPU リソースが使用されているため、実行速度を上げるには、CPU の数を増

やすか高速な CPU にすることが必要になると考えられます。または、マテリアライ

ズド・ビューを作成し、集計を事前に計算しておくこともできます。この新しいアク

セス・パスを作成すれば、実行時間は目に見えて大幅に改善されるでしょう。

図 23：実際の行数と予測行数の関係


17ページ


ここまでに説明したとおり、インタラクティブなユーザー・インタフェースには、

データベース管理者が問題のある SQL 文を分析するときに活用できる有益な情報

が驚くほどたくさん含まれています。

SQL監視のユースケース

ここでは、実行時にパフォーマンスの問題が発生した SQL 文の 5 種類のユースケー

スを紹介します。リアルタイム SQL 監視を使用すれば、これらのユースケースの

いずれについても、問題の根本原因を見つけることができます。

複雑な問合せ – 大きな計画

リアルタイム SQL 監視のもっとも一般的な適用例の 1 つが、非常に大きな計画を

伴う SQL 文です。SQL 実行計画が大規模になり、複雑すぎて解釈できなくなると、

どのように文が実行されるのか、どこでリソースが消費されるのか、おもに何がボ

トルネックなる可能性があるのかを理解する試みは極めて煩雑になり、手に負えな

いタスクになる可能性があります。大きな計画を伴う SQL 文の例について検討し

ましょう。

図 24：長い SQL の計画


18ページ


"図 24：長い SQL の計画"は、SQL 文に対して Explain Plan を実行して潜在的な問

題を検出する必要があるデータベース管理者にとっては難しいシナリオです。計画

がこのように大きい場合は、データベース管理者をきちんと支援する必要が出てく

るのは明らかです。

リアルタイム SQL 監視を使用すれば、計画の中で重要な部分、つまりもっともリソー

ス消費量が多い計画操作を確認できます。"図 24：長い SQL の計画"を見ると、重

要であることを示す色の帯が横に表示されている計画操作はほんのわずかであることが

確認できます。実行時間が費やされているのはこれらの操作であるため、特にこれ

らに注意する必要があります。視覚的にさらに分かりやすくするために、計画のい

くつかのステップを 1行にまとめることができます（図 25のSORT AGGREGATION

の操作を参照してください）。マウスの 1 回のクリックで、"図 24：長い SQL の計

画"の状態から、図 25 に示すような必須の部分にまで、計画を縮小できました。こ

こでは、TABLE ACCESS FULL 操作が CPU リソースのほとんどを使用して、ORDERS

表、LINEITEM 表の順に処理していることが分かります。そのため、これに続く

チューニング作業では、これらの全表スキャンを少ないリソースで高速に実行でき

るようにするか、または、SQL を修正するかアクセス構造を改善して全表スキャン

が使用されないようにすることを集中して行います。

図 25：同じ大きな計画を SQL 監視でまとめたもの

有効活用されていない索引

2 つ目のユースケースでは、リアルタイム SQL 監視を使用して、索引が十分活用さ

れていない事例を診断します。この例は、一見したところ、索引がある場合はそれ

を使用することで実行計画を改善できるように見えます。ところが、SQL 文のラン

タイム統計を調べたところ、表アクセスを高速化するための索引の選択が違うとこ

ろに現れています（図 26 参照）。

Monitored SQL Execution Details ページのリソース消費量の部分を見ると、ほとんど

の CPU リソース（55%）が INDEX RANGE SCAN 操作に消費されていることが分

かります。この操作をよく調べると、問合せで必要となるわずかなフィルタ処理に

索引が使用されているだけであることが分かります。つまり、88 万行が索引から取

得され、選択されたのはそのうちわずか 6 万件です。ここでデータベース管理者に

気付いていただきたいのは、この問合せがおもに CPU を消費していること、そし

てそのほとんどを INDEX RANGE SCAN 操作が消費していること、それに、フィル


19ページ


タ処理のほとんどはランダム I/O によって表から行が取得された後に実行されてい

るに過ぎないということです。

図 26：不十分な索引計画

図 27：上図の問合せの中で索引を使用する計画操作の部分を拡大した図

あまり時間をかけなくても、図 26 および図 27 の SQL 文の問題には、オプティマ

イザによる索引活用計画が不十分である（"選択的ではない索引"を使用している）

ことが関係しているのを突き止めることができました。索引が実際にはこの問合せ

のパフォーマンスを低下させていることが分かると、この SQL 問合せをチューニ

ングする担当者は、計画の該当する部分に焦点を合わせてチューニング作業を行う

ことができます。

部分的に並列化されているSQLの検出

繰り返しになりますが、SQL 監視の対象となっていたもっとも問題が大きい SQL

問合せは、長時間実行されている SQL 文で、2 番目はパラレル SQL 問合せです。

リアルタイム SQL 監視では、パラレル問合せがどのように実行されるか、特に、

問合せを実行しているパラレル・サーバー間にどのようにワークロードが分散され

るかを調べることができます。


20ページ


図 28：部分的に並列化されている問合せ

図 29：部分的に並列化されている問合せの拡大図

図 28 の例は、2 つのインスタンス上で 8 つの DOP を使用して実行されている問合

せを示しています。上から下に見ていくと、初に問合せコーディネータ（明るい

緑色のアイコン）があり、次に 1 組のパラレル・サーバー（青色のアイコン）があ

り、もう 1 組のパラレル・サーバー（オレンジ色のアイコン）と交代でアクティブ

になります。リソース消費量の部分を見ると、この問合せが消費している CPU 全

体の 82%は、計画に含まれる 1 つの操作が消費していることが分かります。この操

作は、4,002,000 行を戻した TABLE ACCESS FULL 操作で、この操作は連続して実

行されました。この全表スキャンは、パラレル実行されていればもっと短時間で完

了したはずであるため、部分的に並列化された問合せの例であることがはっきりし

ています。

Monitored SQL Execution Details ページの Parallel タブ（図 30 および図 31 参照）は、

パラレル実行に関与したサーバーごとのリソース消費量を示しています。パラレル・

サーバーの組ごとに集計した作業量を比較すれば、パラレル問合せコーディネータ

があとどれだけの作業を実行する必要があったのかを、すぐに確認できます。この

ような状況は明らかに異常です。問合せコーディネータは、作業のほとんどを実行

する代わりに、パラレル実行サーバー間のワークロード分散を調整する必要がある

ため、作業量はわずかになるはずです。このような状況を検出したら、SQL チュー

ニングを担当するデータベース管理者は、問合せを完全に並列化するアクション・

プランを実施します。


21ページ


この例の場合は、LINEITEM 表をパラレルに変更する（alter table LINEITEM parallel

を実行する）だけでかまいません。

図 30：部分的に並列化されている問合せの、パラレル・サーバー全体のリソース消費量

図 31：部分的に並列化されている問合せの、パラレル・サーバー全体のリソース消費量の拡

大図

パラレルDMLの有効化

次もパラレル実行の例です。パラレル実行されると思っていた SQL 文が、実際に

はほとんど順次実行になっており、パラレル・サーバーが 1組だけと問合せコーディ

ネータが 1 つ使用されている例です。このユースケースでは、理由が何であれ、問

合せの DOP は強制的に 4 になるため（FORCE PARALLEL QUERY PARALLEL 4）、

すべての文が 4 方向にパラレル実行されるはずです。ところが、LINEITEM 表に対

する Insert 文は DML 文であり、DML 文はデフォルトではパラレル実行されないた

め、ロード操作がここでのボトルネックになります。

Plan Statistics タブ（図 32 参照）から調査すれば、作業がパラレル・コーディネータ

とパラレル・サーバー・セットの間で均等に分散されていない様子を確認できます。

CPU アクティビティのほとんどは、COUNT STOPKEY についての LOAD AS SELECT


22ページ


操作と PX COORDINATOR 操作で発生しています。明らかなボトルネックを作りだ

している問合せコーディネータが、これら両方の操作を実行しているのです。

図 32：問合せの DOP が強制された DML 文

次の図 33 および図 34 は、パラレル・コーディネータの作業量が圧倒的に多く、

Parallel Set 1 よりほぼ 3 倍多い作業を実行している様子を拡大して表示しているだ

けです。チューニング作業は、この DML 文がパラレル実行されるようにすること

に集中する必要があることが、この時点ではっきりします。これは、セッションの

パラレル DML を有効化し（alter session enable parallel DML）、LINEITEM 表が確

実にパラレル化されるようにする（alter table lineitem parallel）だけで実現できます。

図 33：問合せの DOP が強制された DML 文の Parallel タブ


23ページ


図 34：問合せの DOP が強制された DML 文の Parallel タブの拡大図

PQサーバー・グループ内の偏りの検出

後に紹介する例も、パラレル問合せに関係しています。実際、SQL 監視ではこれ

までにはなかった方法でパラレル SQL 文を実行中に監視できます。そのため、旧

リリースのOracle Databaseで実行していた同等のタスクと比べて短時間でチューニ

ング作業が完了します。

図 35：PQ の偏りが進んだ問合せ

図 36：PQ の偏りが進んだ問合せの拡大図


24ページ


計画の調査では、問合せがパラレル実行されたことを確認した後は、通常、Parallel

タブに切り替えて、問合せの並列度に関するさまざまな側面についてさらに調査し

ます。ここで、すべてのパラレル・セットを展開すると、各セットに含まれるパラ

レル・サーバー間のワークロードの分散状況を確認できます。平均すると、均等に

分散されているように見えますが、Prallel Set 1 を調べてみると、Parallel Server 3 は

Parallel Server 2 の 2 倍、Parallel Server 4 の 8 倍の作業量をこなしている様子が確認

できます。この作業の分散状況は均等ではありません。もっと均等に分散されるよ

うにチューニングする必要があります。

図 37：Parallel タブ：PQ の偏りが進んだ問合せ

図 38：Parallel タブ：PQ の偏りが進んだ問合せの拡大図

ここでは、Activity タブと Parallel タブをチューニング作業に使用する方法を説明し

ます。Activity タブのグラフでは、システムがしばらくアイドル状態になったと思

われる 2カ所のすき間以外は、アクティビティが均等になっているように見えます。

この問題を解決するには、2 つのことに注意する必要があります。1 つ目は、Parallel

タブと Plan Statistics タブを相互に関連付ける必要があることです。


25ページ


ユーザーはこのようにして問題を診断します。Parallel タブでは、1 組のサーバー・

セットに偏りがあります。つまり、1 つのサーバーが他の 3 つのサーバーより多く

の作業を実行しています（図 37 参照）。その組の色（青色）を元に計画を見て、

計画のどのステップがそのパラレル・セットで実行されているかを見つける必要が

あります。2 つ目は、偏りが発生していたときのすき間は Activity タブから見つけ

られるということです。見つけたら、問合せの実行期間の中ですき間が発生した時

点と、Plan Statistics タブのタイムライン情報に基づいて、問題が発生した具体的な

行ソースを見つけることができます。

この例では、GROUP BY の 1 つの値がほとんどの行に含まれ、GROUP BY キーの

値が偏っているため、GROUP BY レベルで偏りが発生します。特定の 1 つ 1 つの値

を 1 つの実行サーバーだけで処理するため、ほとんどの行をこのサーバーで受信し

て集計することになり、この独特の偏りが発生します。

この問合せのチューニング作業は少し面倒です。しかしながら、データベース管理

者が SQL 監視というツールを持っていなかったら、このチューニング・タスクは

ほとんど実行不可能でしょう。このようなケースでは、問合せを記述し直して、集

計処理も UNION ALL ビューに含めるようにする必要があるため、簡単な解決方法

がなかなか見つからないかもしれません。それでも、SQL 監視を使用すれば、少な

くとも問題の根本原因を突き止めることはできます。

図 39：Activity タブ：PQ の偏りが進んだ問合せ

結論

リアルタイム SQL 監視によってインタラクティブに公開されるランタイム統計は

豊富にあります。これらのデータは、実行時間の長い SQL 文やパラレル SQL 文の

監視に使用できます。本書では、この機能の中心概念を説明し、Oracle Enterprise

Manager から提供されるグラフィカル・インタフェースを紹介し、重要かつ困難な

SQL チューニング・タスクの解決を、リアルタイム SQL 監視を使用して支援でき

るユースケースをいくつか説明しました。読者の方々が Oracle Database 11g のこの

素晴らしい新機能を使い始めるときに本書が役立てば幸いです。


26ページ


ライセンス情報

リアルタイムSQL監視機能のライセンスはOracle Tuning Packに含まれています。

（http://download.oracle.com/docs/cd/B28359_01/license.111/b28287 /options.htm - CIHFIHFG）

参考資料

[参考ドキュメント] Oracle® Databaseリファレンス 11gリリース 1（11.1）

（http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ instance_tune.htm -

CACGEEIF）


27ページ


http://download.oracle.com/docs/cd/B28359_01/license.111/b28287%20/options.htm%20%E2%80%93%20CIHFIHFG

http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/%20instance_tune.htm%20-%20CACGEEIF

http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/%20instance_tune.htm%20-%20CACGEEIF

付録A：SQL監視のコマンドラインの使用方法

この付録では、Oracle Enterprise Manager のユーザー・インタフェースを使用できな

いユーザーのために、コマンドライン API を介して SQL 監視を使用する方法につ

いて簡単に説明します。Oracle EM の SQL 監視画面にあるすべてのインタラクティ

ブ機能が使用できるわけではありませんが、コマンドライン・インタフェースを使

用してもデータの抽出は実行できます。

SQL 監視レポートを生成するには、DBMS_SQLTUNE パッケージに含まれる REPORT_

SQL_MONITOR ファクションを実行します。 variable my_rept CLOB; BEGIN :my_rept :=DBMS_SQLTUNE.REPORT_SQL_MONITOR(); END; / print :my_rept

DBMS_SQLTUNE.REPORT_SQL_MONITOR ファンクションにいくつかの入力パラ

メータを渡して、実行、レポートの詳細レベル、レポートのタイプ（'TEXT'、'HTML'

または'XML'）を指定できます。例に示したように何もパラメータを指定しなければ、

監視された後の実行に関するテキスト・レポートがデフォルトで生成されます。

次に示すのは、テキストベースの SQL 監視レポートのサンプルです。


28ページ


このサンプル・レポートについて簡単に説明します。このレポートの Global Information

セクションにある Status フィールドは、この文がまだ実行中であることを示してい

ます。Time Active(s)列は、この操作がアクティブ状態だった期間を示しており、ア

クティブ状態だった初と後の時刻のデルタを秒単位で表しています。Start Active

列は、実行計画の中でその操作が開始された時刻を、SQL 文の実行開始時間と比較

して秒単位で表示します。このレポートでは、ID5 の索引高速完全スキャンが 1 番

目に開始され（Start Active の表示が"+1s"）、初の 82 秒間、実行されました。Starts

列は、実行計画の当該操作が実行された回数を示します。Rows (Actual)列は取得さ

れた行数を示し、Rows (Estim)列はオプティマイザに見積もられたカーディナリティ

を示します。Memory 列および Temp 列は、実行計画内の各操作で消費されたメモリ

量と一時領域を示しています。Activity (percent)列および Activity Detail (sample #)列

は、V$SQL_PLAN_MONITOR ビューと V$ACTIVE_SESSION_HISTORY ビューを

結合して作成されます。Activity (percent)は、実行計画の各操作で消費されたデータ

ベース時間の割合を示します。Activity Detail (sample#)は、そのアクティビティの性

質（CPU、待機イベントなど）を示します。このレポートでは、データベース時間

のほとんど（36.68%）を ID8 の操作（ORDERS に対する TABLE ACCESS FULL）

が消費していることがこの列で示されています。このアクティビティは 73 のサン

プル（28+3+42）で構成されており、その過半数がダイレクト・パス読取りによる

アクティビティで（サンプル数 42）、約 3 分の 1 が CPU のアクティビティです（サ

ンプル数 28）。後の Progress 列は、V$SESSION_LONGOPS ビューから取得した

操作の進捗監視情報を示しています。このレポートでは、ハッシュ結合操作が 87%

完了していることが示されています。


29ページ



2009 年 12 月

著者：Sergey Koltakov

共著者：Benoit Dageville、Peter Belknap

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com

Copyright © 2009, Oracle and/or its affiliates. All rights reserved.

本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく

変更されることがあります。本文書は一切間違いがないことを保証するものではなく、

さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商品性も

しくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するもの

ではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文

書によって直接的または間接的に確立される契約義務はないものとします。本文書はオ

ラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子ま

たは印刷を含むいかなる形式や手段によっても再作成または送信することはできませ

ん。Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商標です。

その他の名称はそれぞれの会社の商標です。0408

リアルタイム SQL 監視 - Oracle...Oracle Database 11gで導入されたリアルタイムSQL...

Documents

Transcript of リアルタイム SQL 監視 - Oracle...Oracle Database 11gで導入されたリアルタイムSQL...