実録！ DBA1.0 vs. DBA2.0 障害対応対決

Oracle管理者のための「時間術」

　

Round2：ボトルネック調査対決

「業務アプリの反応が遅くなって仕事にならない！」

　何の前触れもなく突然こんな電話がかかってきた（もしくはかけた）経験はないだろうか。DBA 1.0とDBA 2.0では電話を受けた後の対応がどう違うか見てみよう。

DBA 1.0の対応：「もう1回発生したら分かるかも」

と、連絡を受けた場合、DBA 1.0はリモートデスクトップ、telnet、ssh、サーバ端末などを使って、サーバのリソースの使用率を調べ、SQL*Plusから各種のスクリプトを投入してロックの状態やデータベースの負荷の調査に入る。すぐに調査を開始したが、どうやら負荷はすでに下がっているようで原因は特定できなかった。

　問い合わせ元に現在の状況を確認すると、現在は問題ないらしい。

　問い合わせ元は原因が分からず、再び業務アプリケーションが遅くなる可能性に頭を抱えながらもしぶしぶ了承するしかなかった。

DBA 2.0の対応：問題のクエリを即、究明

　と連絡を受けた場合、DBA 2.0はEnterprise Manager Database Controlに接続してデータベースの状態を即座に確認する。

●手順1　パフォーマンスの表示

　［パフォーマンス］タブを開くと直近の負荷がグラフ表示されている。22時45分から3分間くらい負荷が高くなっている部分があるので、そのあたりのトップアクティビティを調べてみる。

●手順2　トップアクティビティ

　トップアクティビティは、指定した期間の範囲で時間がかかっているSQLなどを特定するために使用できる。どうやら該当時間帯は、scottユーザーのUPDATE文で時間がかかっているようだ。もし、業務アプリケーションの利用IDがscottユーザーなのであれば、このUPDATE文のところで遅くなっていたと思われる。

●手順3　トップアクティビティ

　SQLIDをクリックするとそのSQL文がどのようなことで時間を使っているかが分かる。今回のケースでは「row lock contention」つまり同じレコードを更新しようとしてロック解除待ちになって時間がかかっているということになる。

　タネを明かせば、いろいろなSQL文を投入したが思ったように負荷が上がってくれなかったため、意図的に複数の端末から同一レコード更新を起こし、なおかつ先に更新した方のトランザクションのCommitを行わず、同一レコードのロック解除待ちを意図的に落としてアクティビティを上げた。その状況を数回のクリックで見事特定できたことになる。

最後に：少ない作業コストで状態把握を

　Enterprise Manager Database Controlは、内部的にSQL文を駆使してGUIに表示する情報を取得し、GUIでの操作も内部的にはコマンドとスクリプトとして実行している。しかし、そこまでGUIを回避しコマンドラインにこだわる利点を見いだすことは難しい。GUIにより統合的に全体を見渡し、少ない作業コストでさまざまな切り口でOracle Databaseの状態を把握できるEnterprise Manager Database Control のGUIの利便性はそれくらい特筆ものだからだ。

4/4

Index
Oracle管理者のための「時間術」
	Page 1 ・かつてOracleメンテナンス担当は三重苦だった!? 　9iまでの「職人芸」とそれ以降 ・Round0：障害対応対決〜両者のスペック 　DBA 1.0のシステム構成 　DBA 2.0のシステム構成
	Page 2 ・Round1：障害対応対決 　DBA 1.0の障害対応：達人クラスで作業時間5分
	Page 3 　DBA 2.0の障害対応：誰がやっても4分以内！
	Page 4 ・Round2：ボトルネック調査対決 　DBA 1.0の対応：「もう1回発生したら分かるかも」 　DBA 2.0の対応：問題のクエリを即、究明 ・最後に：少ない作業コストで状態把握を

Databaseフォーラム全記事インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）