以上のように、遅延している瞬間の情報を見ることによって、そもそもDBサーバーで問題が起きているのかどうかが分かりますし、問題が起きているときのOracleの各サーバープロセスの状態を知ったり、Oracleがリクエストを受け付けて以降の処理で発生している待ち行列を把握したりできます。前述の「合計と平均のマジック」や「瞬間的な待ち行列のマジック」は、この瞬間の情報を採る方法で見破ることができます。注7:実際には、ディスクで待ち行列になっていても同期しているため、Oracle上から判別できるということです。注8:詳しくは後述しますが、CPUリソース不足時には、Oracleの待機イベントの数値が大きくなるという現象が起きます。Oracleは、CPUリソース不足を直接確認するための情報は持っていません。enqueue待ち以外の待機イベントも紹介しましょう。read」が表示されています。このようにディスクからの読み込み遅延も数秒以上のものであれば分かります。ページTOPに戻るSTATSPACKの効果Oracleには、以前からDB全体(正確にはインスタンス)のパフォーマンスを見るためのツール「Bstat/Estat」が付属していました。バージョン8.1.6からは、Bstat/Estatの後継であるSTATSPACKが使えるようになりました。答えは、図6が示すように、ある期間のセッションすべての合計やディスクのアクティビティ、キャッシュヒット率などの情報です。STATSPACKが教えてくれる情報LIST8は、図6に対応する形でSTATSPACKで作成したレポート(抜粋)です。STATSPACKでレポートを作成する際には、いくつかの注意事項を頭に入れておく必要があります。STATSPACKレポートの抜粋まず、レポートに示される数値は“合計”だということです。V$SESSION_WAITビューのように、遅延している瞬間の状況を見ることはできません。短い間隔でレポートをとるのは避けなければなりません。STATSPACKはスナップショットと呼ばれる、あるタイミングごとの統計情報を保存します。そのタイミングはユーザーが指定する(もしくはコマンドを実行する)のですが、その統計情報を保存するのに、ある程度の時間とCPUコストがかかります。注9以上ではSQL文の情報をメモリから検索するので、SQL文が多いシステムでは時間がかかります。そのため、スナップショットは1分以上間隔を空けてとるべきです。間隔を短くしたい場合には、事前にスナップショットの取得にかかる負荷を測っておきます。何も実行していない状態でスナップショットをとり、レポートを見てみるのです。これにより、スナップショット取得時のCPU使用量が分かるので、本番のレポートでは、このCPU使用量を考慮した(減らした)上で分析ができます。ここまで聞くと、STATSPACKは不便なように思えますが、そんなことはありません。不便を補って余りある便利な機能を持っています。STATSPACKはレベル5以上であれば、自動的に目立つSQL文の情報を表示します。全SQL文はもちろん表示できませんが、問題ありそうなSQL文をいくつかの観点でチェックして、上位を表示してくれるのです。注12をデフォルトの「typical」以上にしておけば、そのSQL文の実行にかかった時間とCPU時間が分かります。多くの場合で問題をSQL文レベルで特定できるため、これはとても便利です。注9:このレベルは、情報の細かさを表わす。スナップショットの際に指定できます。注10:SQL文経過(処理)時間。注11:時間情報を取得するかを決定するパラメータ。R2から導入されたパラメータで、取得情報の細かさを決定します。(時間情報はとらない)です」とか、「ダウンが怖いので、ピーク時はパフォーマンス情報をとりたくない」と言う方がいます。これは大変危険で、自動車の運転に例えるなら、少し速くなるからと車のフロントガラスを外し、代わりに頭を伏せて前を見ずにアクセル全開で走っているようなものです。パフォーマンスは多少良いかもしれませんが、トラブルに気が付いたときには手遅れで、大事故を起こしてしまうかもしれません。障害時に原因が分からないこともあるでしょう。企業システムを預かるエンジニアであれば、多少遅くなってもできるだけ情報を集め、避けられる事故は避け、事故が起きても二度と起こさない努力をする姿勢が大切だと思います。遅延原因がDBにあるのかを判断する方法では、プロのSTATSPACKのデータの見方を紹介しましょう。LIST8の3つ目の白抜きの箇所です。session」を見てCPU時間を調べます。time」が表示されていれば、同じものなのでそれを使います。最後に、TOP5で合計したアイドルではない待機イベントの時間とCPU時間とを足します。これが、DBがシステム遅延の原因かどうかを判定するための資料になります。前述したとおり、「CPU時間+アイドルではない待機イベント」が、ほぼDBでの処理時間です。この「CPU時間+アイドルではない待機イベント」がアプリケーションの遅延時間より明らかに小さければ、V$SESSIONやV$SESSION_WAITの情報がなくても「DBは白だ(DBで遅延が起きていない)」と言えます。逆に、アプリケーションの遅延時間(この場合クライアントのレスポンスタイム)とほぼ同じであり、ほかのサーバープロセスで処理を行なっていないのであれば、「DBは黒だ(DBで遅延が起きている)と言えます。それ以外のケースは灰色です。複数のサーバープロセスが処理を行なっていた場合、判定は難しくなります(図7)。複数のサーバープロセスで処理を行なっていた場合は判定が難しい注13:このTOP5は、バージョンによって呼び方が異なります。注14:TOP5にはアイドルイベントは表示されません。切り分けるかでは、判定が灰色のときはどうしたら良いのでしょうか。timeはSQL文ごとの「アイドルではない待機イベント+CPU処理時間」ですから、これがそのアプリケーションのレスポンスタイムとほぼ同じであれば、DBで時間がかかっていると言えます。SQL文を特定できていなくても、SQL文情報は見る価値はあります。遅延していなかったときのデータ(過去のデータ)と比較するという手もあります(LIST9参照)。STATSPACKの差分から原因を探る方法しかし、過去のデータと違いがあったからといって、本当にそこから原因が分かるとは限りません。ケーションの何かが変わっているのかもしれませんし、アプリケーション開発者の「まったく変更はない」という発言が間違っているかもしれません。トラブルシューティングの現場では、性善説は通用しません。扱うのが妥当だと考えます。ートをとるか、V$SESSIONビューやV$SESSION_WAITビューを見て遅延の証拠を押さえてください。SQL文の処理時間を減らすチューニング原因が分かったら、次はチューニングです。チューニングは本特集では説明範囲外ですが、この分析で得られた情報が役に立つので、簡単に紹介します。DBのチューニングでは、SQL文の処理時間である「CPU時間+アイドルではない待機イベント」を減らすという発想をします。CPU時間が占める割合が大きい場合は、実行計画を変えて処理を軽くしない限り、小手先のチューニングでは対処できないでしょう。設計レベルの問題かもしれません。次に、待機イベントが大きい場合には、その待機イベントが起きる仕組みを調べた上で、待機イベントを減らす方法を考えてみてください。こちらのほうが小手先のチューニングが効く可能性はありますが、最悪のケースでは、やはり設計レベルの問題という結論もあり得ます。チューニングの話はこれくらいにして、このような特徴を持つSTATSPACKレポートは、どのようなケースで使えるのでしょうか。ここまでに半分答えを書いてきてしまいましたが、「定常監視と、ほかの業務処理が入ってこない環境下でのSQL文の調査/分析」です。複数の処理が実行されている環境下においても、パフォーマンス調査に使えることはありますが、V$SESSIONビューやV$SESSION_WAITビューも必要となるかもしれません。このSQLトレースの結果は、Oracleの動作モデル図では何に相当するのでしょうか。図8のように、セッション上で実行されたSQL文の処理にかかった時間(CPU時間+アイドルではない待機イベント)と、CPU時間が分かります。図にはないSQL文の実行計画(どのようにデータにアクセスして、どのようにデータを処理したのか)も分かります。「どの待機イベントにどれくらいかかったか」は分かりません。注15:SQLトレースにおいては、その記述が一字一句同じ場合に同一SQL文とみなされます。したがって、バインド変数の値が違う場合でも同一SQL文とカウントされ、情報はサマリーされます。SQLトレースの使いどころLIST10を見てください。SQLトレースの結果(抜粋)です。SQLトレースの結果(抜粋)SQLトレースは、DB全体(正確にはインスタンス)のSQL文について調査することもできますが、負荷が大きい(処理が遅くなる)ため、本番サーバーではできる限り使用を避けるべきです。DB全体のSQL文を調査対象としてしまうと、結果を見るのが面倒で非効率でもあります。セッション単位でも設定可能なものの、これも処理が遅くなるので、できる限り使わないようにすべきです。どのようなケースにSQLトレースは適しているのでしょうか。制限事項を考えると、SQL文が問題であることが分かり、SQL文を特定した後に、開発環境(もしくは商用環境の1セッション)で取得するのが効果的です。少なくとも、問題のあるSQL文かセッションが判明するまでは、SQLトレースの使用はお勧めできません。SQLトレースの代替手段もあります。実行計画を見るだけであれば、Oracle9iから加わったV$SQL_PLANビューが使えます。注16:V$SQLAREAはWHERE句でアクセスする行を絞っても、入っている行数に比例して検索に時間がかかるケースがあります。Netのトレース(SQL*Netのトレースとも呼ばれます)」を一言で言うと、Oracle版パケットキャプチャツールです。このツールは一般にネットワークの障害の際に使用するものと思われていますが、パフォーマンス情報の取得にも使える場合があります。Netのトレースでは、図9に示すように、SQL文が到着したタイミングおよびSQL文の結果を返すタイミング(正確にはOracleレベルでのパケット送受信のタイミング)で、Oracleのクライアントとサーバー間でやり取りされたパケットが記録されます。記録には時間とSQL文(パケットダンプですが)を含めることができますし、DBサーバー側だけでなく、Oracleクライアント側でも記録できます。Netのトレースの結果(抜粋)です。Netのトレースの注意点は処理が遅くなることと、取得できるのはあくまでOracleレベルのパケットダンプであることです。TCPヘッダーなどは見ることができません。SQLトレースの結果(抜粋)処理が遅くなることに関しては、筆者の経験では、最低のレベルであっても30%程度レスポンスが遅くなったことがあります。そのため、障害時には仕方がないものの、本番サーバーのパフォーマンス情報をとる目的で使用するべきではありません。Netのトレースの使い方は、テスト環境において、実際にOracleにSQL文が届いたタイミングと結果を返したタイミングの確認や、データ量が多く(=パケット数が多い)時間がかかっていることの確認程度に限られるでしょう。以上、パート2では、Oracleのパフォーマンスを測定するための各種ツールを紹介しました。それぞれ一長一短ありますので、目的に適したツールを選んで使えるようにしましょう。チューニングも状況の把握から始まります。そのための道具をよく知り、またそれを使いこなせる腕を磨くことが大切です。reserved.無断転載を禁ずこの文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。本書の内容に関連したいかなる損害についても責任を負いかねます。Corporationの登録商標です。Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。新卒や中途採用社員に対し、データベースやOS、ネットワークの講師を5年ほど経験した後、2000年にテクノロジーコンサルティング本部に異動。テクノロジーのコンサルタントとして、主に大規模ミッションクリティカルシステムを担当。ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。OS、ストレージ、ネットワークを学ぶべき」。スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。