[Oracle]<性能>DBを重くしているセッションを突き止める - 初級編

よくアプリチームから「何かDB重いんだけど調べてくれない？」と言われるあなた。
下っ端だから話しかけやすいんだろうね。リーダーは今日もむっつり忙しそう。
該当のセッションから犯人をお手軽突き止める方法のメモ。


[前提]
以下の設定が必要（意識してなかった）
・コストベース・オプティマイザを使用を使用している。
・TIMED_STATISTICSまたはSQL_TRACEパラメータをtrueに設定している。
・ANALYZE文またはDBMS_STATSパッケージで、使用するオブジェクトの統計情報を収集する。


[手順]
▼方法１．Enterprise Managerでセッション一覧を表示して「長時間処理」項目に該当するセッションを調べる。端末IDとかユーザIDも一発で調べられて便利
▼方法２．「select * from v$session_longops」を発行して長時間セッションが無いかどうか調べる。以下の項目を見れば現在暴れてるセッションがたぶん一目瞭然。
・START_TIME…操作の開始時刻
・TIME_REMAINING…操作が終了するまでの残りの推定時間（秒）
・ELAPSED_SECONDS…操作の開始からの経過時間（秒）
※v$session_longops…6秒以上掛かる処理（1処理単位）を抽出する動的パフォーマンスビュー。Enterprise Managerはよくわからんけど結局「方法１」に出てきたv$session_longops見てるんだろうなあ


[難点]
1処理単位（トランザクション単位ではない点に注意）で6秒以上の処理しか補足できないので、天文学的な細かい処理を発行しているセッションは長時間処理として捕捉できない。OS上、ディスクの%busyは100で完全にOracleの仕業なのにセッションレベルでの原因究明できずDBAチームとして情けない気分になることうけあい。セッション単位でディスクI/Oの占有率を調べることができれば解決できそうだけど・・・