PART 03 - DB Time と Elapsed Time

「レスポンスが遅い」という一言だけでは原因は絞れません。DB TimeとElapsed Timeの違いを混同したまま調査を始めて遠回りした経験から、両者の関係を整理し直しました。

Elapsed Time（経過時間）

図1: DB TimeとElapsed Timeの関係

スナップショット間隔の実際の壁時計時間（秒）。「現実世界で何秒経ったか」を表します。

例: 60分のレポートなら 3,600秒
これは常に固定値（レポート期間そのもの）

Elapsed Time はAWRレポートの「物差し」です。DB Time やその他の統計値を解釈するとき、Elapsed Time で割って「1秒あたりの値」に正規化すると、異なるレポート間での比較が正確にできます。

DB Time（データベース処理時間）

全セッションが DB 処理に費やした累積時間（秒）。

DB Time = CPU 時間 + 待機時間
複数セッションの時間が合算されるため、Elapsed Time を超えることがある

DB Time > Elapsed Time の場合は、複数セッションが同時に処理していたことを意味します。

例えば Elapsed Time が 3,600秒（1時間）のレポートで DB Time が 10,800秒（3時間分）だった場合、平均的に3つのセッションが常に何らかのDB処理をしていた計算になります。DB Time が小さい（Elapsed Timeより大幅に小さい）場合、その時間帯はDB自体への負荷が低かったことを示します。

AWRレポートの Report Summary セクションには、DB Time の内訳として「% of Total DB Time」が表示されます。CPU time が全体の何%を占めているかが一目でわかります。

平均アクティブセッション数（AAS）

DB TimeとElapsed Timeの関係から、その期間の平均的なアクティブセッション数が逆算できます。

AAS = DB Time / Elapsed Time
-- 例: DB Time = 7,200秒、Elapsed Time = 3,600秒
-- AAS = 7,200 / 3,600 = 2.0 （平均2セッションが常にアクティブ）

着目ポイント: AAS が CPU コア数を大きく上回る場合は要注意！

例えば 16コアのサーバで AAS が 30 なら、CPU が捌ききれず待機が大量発生している可能性が高いです。

AAS の目安として、AAS ≦ CPU コア数 の範囲に収まっていれば概ね健全と言えます。ただし、CPU time の割合が低くほとんどが待機時間の場合は、コア数とAASの比較だけでなく待機イベントの種類も確認する必要があります。

AAS が急激に上昇した時間帯がある場合、その原因をTop 5 Timed Eventsで特定し、SQL Statisticsで問題SQLを絞り込むアプローチが効果的です。

DB Time の内訳イメージ

DB Time は CPU 時間と各種待機時間の合計です。代表的な内訳は以下のようなイメージです。

40% CPU Time: 処理（CPU）
24% User I/O Wait: I/O 待機
16% Concurrency Wait: 同時実行待機
11% System I/O: システムI/O
9% その他の待機: その他

DB Time が大きいほどDBへの負荷が高い。CPU Time の割合が低ければ「待機」が問題であり、何かしらのボトルネックが存在することを示唆します。

Wait Classes の分類

Oracle は待機イベントを次の Wait Classes に分類しています。DB Time に占める各 Wait Class の割合がパフォーマンス問題の方向性を示します。

Wait Class	意味	割合が高い場合の示唆
User I/O	ユーザープロセスのI/O待機	インデックス未使用・フルスキャンの多発
Concurrency	内部ロック競合	同一行への集中アクセス・DDL競合
System I/O	バックグラウンドプロセスのI/O	DBWR・LGWRのI/O性能不足
Commit	COMMIT時のREDO書き込み待機	コミット頻度が高すぎる・REDOディスク遅延
Network	ネットワーク通信待機	クライアント遅延・SQL*Net設定の見直し
Application	アプリ側からのロック待機	enq: TX（行ロック競合）など

実務での活用ポイント

DB Time と Elapsed Time の比較は、性能問題の「深刻度の判断」にも役立ちます。障害報告を受けた際、問題発生時間帯のAWRレポートを開いてまずDB Timeを確認することで、「DBが原因か、アプリが原因か」の初期切り分けができます。

DBが正常でアプリのレスポンスが遅い場合、DB Time は低くElapsed Timeと大きく乖離しないはずです。一方でDBに負荷がかかっている場合は、DB TimeがElapsed Timeを大幅に超えるか、AASが高止まりします。

DB Time・AAS読み方でよくある誤解

誤解	実際
DB Time ÷ Elapsed Time が 1 以下なので「DBに問題なし」と判断する	AASが低くても特定のSQLが長時間占有している場合がある。Wait Classの内訳まで確認して初めて判断できる
CPU Wait ClassがゼロなのでCPUは問題なしと判断する	純粋なCPU処理（CPU time）はWait Classではなく別に計上される。CPU timeはTop 5 Timed Eventsで確認する
AASが高いのでCPUを増やせばよいと判断する	AAS高騰の原因がI/O待ちやロック待ちなら、CPU増強では改善しない。Wait Classで原因のカテゴリを特定してから対処する

PART 03 — DB Time と Elapsed Time