1. Enqueue Activity— エンキュー（ロック）活動
何を表すか: ロックタイプ（TX / TM / KO / PS など）ごとの Requests / Successful Gets / Failed Gets / Waits / Wait Time を示す。STATSPACKでは「待機が発生したエンキューのみ」が表示される。
- 読み方: Wt Time (s) が大きいタイプが実害の大きいロック競合。Failed Gets > 0 はロック取得失敗（タイムアウト等）の証拠。
- 閾値・注意点: TX（行ロック）や TM（テーブルロック）は業務アプリ設計の問題に直結。KO（Object Checkpoint）は DBMS_STATS 実行中に多発する内部ロック。
- 関連セクション: Foreground Wait Events（enq: TX —）/ Segments by Buffer Busy Waits
- 使うシーン: ロック競合の種別特定と業務影響評価
代表的な Enqueue Type — 意味と典型シーン
| Type | 意味 | 典型シーン・着目点 |
|---|---|---|
| TX — Transaction | 行ロック競合 | UPDATE/DELETE 競合・デッドロック。Wt Time が大きい場合は業務設計を確認 |
| TM — DML | テーブルレベルロック | FK 制約・DDL 同時実行。Failed Gets があればロック競合が業務に影響 |
| HW — High Water Mark | HWM 拡張競合 | 大量 INSERT 時に発生。PCTINCREASE や NEXT EXTENT の設定を確認 |
| KO — Object Checkpoint | オブジェクトチェックポイント | DBMS_STATS 実行中の内部ロック。業務への影響は通常少ない |
| PS — PX Process Reservation | パラレル実行スレーブ確保 | 並列クエリ起動時の内部調整。Waits が多いが Wt Time が小さければ問題なし |
| SQ — Sequence Cache | シーケンスキャッシュ取得 | CACHE サイズ不足。CACHE パラメータを増やすと競合軽減 |
| US — Undo Segment | Undo セグメント取得 | Undo セグメント数不足。MINEXTENTS を増やすか自動管理に切り替え |
項目の意味と着目点 — Enqueue Activity
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Enqueue Type | ロック種別（TX / TM / KO / PS 等） | 種別により原因と対処が全く異なる |
| Requests | ロック取得要求回数 | 多いほどそのロック種別の処理量が多い |
| Succ Gets | ロック取得成功回数 | Requests との差が Failed Gets に相当 |
| Failed Gets | ロック取得失敗回数 | 0 以外はタイムアウトまたはデッドロック。業務エラーに直結する可能性 |
| Waits | ロック取得に待機が発生した回数 | 待機回数。Wt Time と合わせて重大度を判断 |
| Wt Time (s) | ロック待機の累積時間（秒） | 最重要指標。大きいほど業務への影響が深刻 |
| Av Wt Time (ms) | 1回あたりの平均待機時間（ミリ秒） | 1,000ms 超は単一ロック待機が 1 秒超えを意味する |
2. Undo Segment Summary— Undo セグメントサマリ
何を表すか: 期間全体の Undo 使用量・トランザクション数・最長クエリ実行時間（秒）・最大同時 TX 数・Tuned Retention（保持時間）・Snapshot Too Old / Out Of Space 発生カウントを集計する。
- 読み方: Max Qry Len が 3,600 秒超なら長時間読み取りが存在し ORA-1555 のリスクがある。STO (Snapshot Too Old) > 0 は既に発生済み。
- 閾値・注意点: Min/Max TR（Tuned Retention）は Oracle が自動調整した Undo 保持時間。UNDO_RETENTION パラメータと比較して乖離が大きければ設定の見直しが必要。
- 関連セクション: Undo Segment Stats / init.ora Parameters（undo_retention）
- 使うシーン: ORA-1555 リスク評価・Undo 表領域サイジング
項目の意味と着目点 — Undo Segment Summary
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Undo TS# | Undo 表領域番号 | 複数 Undo 表領域がある環境では特定に使用 |
| Num Undo Blocks (K) | 使用 Undo ブロック数（千単位） | Undo 量の規模感。表領域サイズと照合して余裕を確認 |
| Number of Transactions | 期間中のトランザクション総数 | Load Profile の Transactions と照合 |
| Max Qry Len (s) | 最長クエリ実行時間（秒） | 3,600（1時間）超で ORA-1555 リスク増大。業務バッチが原因か確認 |
| Max Tx Concurcy | 同時実行 TX 数の最大 | 並行ピーク時の Undo 消費量を評価 |
| Min/Max TR (mins) | Tuned Retention の最小/最大（分） | UNDO_RETENTION（秒）と比較。Tuned が大きければ表領域に余裕あり |
| STO | Snapshot Too Old 発生回数（ORA-1555） | 0 以外は既に問題発生。Undo 拡大または長時間クエリの排除が必要 |
| OOS | Out Of Space 発生回数（Undo 表領域満杯） | 0 以外は Undo 表領域が不足。即時拡張が必要 |
3. Undo Segment Stats— Undo セグメント詳細（時系列）
何を表すか: 直近 35 本の UNDOSTAT スロット（約 10 分単位）の Undo ブロック数・TX 数・Max Qry Len の時系列推移。Undo 圧迫がどの時間帯で発生したかを特定する。
- 読み方: Num Undo Blocks が突出する時間帯 ＝ 大量更新の発生ポイント。Max Qry Len が急増する時間帯のクエリを別途調査する。
- 関連セクション: Undo Segment Summary
- 使うシーン: Undo 圧迫の時間帯特定・ORA-1555 発生時刻の絞り込み
項目の意味と着目点 — Undo Segment Stats
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| End Time | スロット終了時刻（約10分単位） | Undo 圧迫の発生時間帯を特定するために使用 |
| Undo Blocks | そのスロット内で使用した Undo ブロック数 | 突出しているスロットが大量更新の発生タイミング |
| Transactions | そのスロット内のトランザクション数 | Undo Blocks と組み合わせて 1TX あたりの Undo 量を算出 |
| Max Qry Len (s) | そのスロット内の最長クエリ実行時間（秒） | 急増したスロットは長時間クエリが存在。ORA-1555 発生の原因調査に使用 |
| Max Tx Concy | そのスロット内の最大同時 TX 数 | 並行ピーク時の Undo 消費量の評価 |
| Tun Ret (mins) | Tuned Retention の値（分） | スロットごとに変化する。短い時間帯は Undo の余裕が少ない |
| STO / OOS | Snapshot Too Old / Out Of Space 件数 | 0 以外のスロットが Undo 問題の発生時間帯 |
4. Latch Activity— ラッチ活動
何を表すか: 全ラッチの Get Requests / % Get Miss / Avg Slps/Miss / NoWait Requests / % NoWait Miss を一覧する。Oracle 内部の共有メモリ保護機構の競合状況を表す。
- 読み方: % Get Miss > 1% かつ Wait Time が有意なラッチが内部競合のホットスポット。単に Miss% が高くても Wait Time = 0 なら実害はほとんどない。
- 閾値・注意点: cache buffers chains は論理 I/O の多さに比例して Get Requests が増える。shared pool の Miss は Hard Parse 多発の兆候。Wait Time が DB Time の 1% を超えるラッチを優先調査する。
- 関連セクション: Latch Sleep Breakdown / Latch Miss Sources
- 使うシーン: 内部ラッチ競合の有無を第一確認
項目の意味と着目点 — Latch Activity
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Latch Name | ラッチ名 | cache buffers chains / shared pool / redo allocation 等が主要ターゲット |
| Get Requests | willing-to-wait モードでの取得要求回数 | 頻度の高いラッチは競合が発生しやすい。論理 I/O 数と相関する |
| Pct Get Miss | Get 取得失敗率（%） | 1% 超で要注目。ただし Wait Time = 0 なら実害は小さい |
| Avg Slps /Miss | Miss 時の平均 Sleep 回数 | 大きいほど競合が激しく CPU を長く手放している |
| Wait Time (s) | 累積ラッチ待機時間（秒） | 最重要指標。DB Time の 1% 超なら調査優先 |
| NoWait Requests | NoWait モードでの取得要求回数 | 即時取得できなければスキップする処理 |
| Pct NoWait Miss | NoWait モードの取得失敗率（%） | 高い場合はラッチ競合が頻繁に発生している |
5. Latch Sleep Breakdown— ラッチ スリープ内訳
何を表すか: ラッチごとの Misses / Sleeps / Spin Gets を miss 件数降順で一覧する。スピンで解決できた競合か、CPU を譲って Sleep するほど重かったかが分かる。
- 読み方: Sleeps 多 > Spin Gets なら重い競合（CPU を手放すほど待った）。逆なら軽い（スピン内で解決）。Sleeps / Misses 比が高いほどラッチ取得の待ち時間が長い。
- 関連セクション: Latch Activity / Latch Miss Sources
- 使うシーン: ラッチ競合の深掘り・チューニング優先順位付け
項目の意味と着目点 — Latch Sleep Breakdown
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Latch Name | ラッチ名 | Latch Activity の Wait Time 上位と照合して優先度を判断 |
| Get Requests | 取得要求回数 | 頻度の参考値 |
| Misses | 即時取得できなかった（スピン/スリープが発生した）回数 | Pct Get Miss × Get Requests に相当 |
| Sleeps | スピンで解決できず CPU を手放した（Sleep した）回数 | 重要指標。Sleeps / Misses が高いほど深刻な競合 |
| Spin Gets | スピン中に取得できた回数（Sleepせず解決） | Misses - Sleeps ≒ Spin Gets。スピンで解決できれば軽微 |
6. Latch Miss Sources— ラッチ ミス発生源
何を表すか: ラッチ取得を試みてスリープした Oracle 内部コード箇所（関数名）を列挙する。Oracle Support SR や深掘り解析に用いる内部情報。
- 読み方: 同一ラッチの Where 複数行 → 複数の内部パスが競合していることを示す。通常運用では「件数」と「どのラッチか」を確認するにとどめ、関数名の解釈は Oracle Support に依頼する。
- 関連セクション: Latch Sleep Breakdown
- 使うシーン: Oracle Support 対応・SR 提出時の添付情報
項目の意味と着目点 — Latch Miss Sources
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Latch Name | ラッチ名 | Latch Sleep Breakdown の上位ラッチと照合 |
| Where（内部関数名） | スリープが発生した Oracle 内部関数名（例: kghfre / kghalo 等） | shared pool の kghfre/kghalo はメモリ確保・解放処理。SR 提出時に有用 |
| NoWait Misses | NoWait モードでの取得失敗回数（その関数から） | — |
| Sleeps | その内部関数でのスリープ回数 | 同一ラッチでどの処理が最も競合しているかを特定 |
| Waiter Sleeps | 待機側セッションのスリープ回数 | Sleeps より多い場合は複数セッションが同一ラッチを待っている |
7. Mutex Sleep Summary— Mutex スリープサマリ
何を表すか: Oracle 11g 以降でラッチより軽量な排他機構として使われる Mutex の競合状況。Library Cache の保護や Cursor の共有・統計取得に広く使われる。
- 読み方: Cursor Pin の Sleeps 多発 → カーソル競合（バインド変数未使用・SQL が多数同時実行）。Library Cache の Sleeps 多発 → Version Count 爆発やハードパース集中。
- 閾値・注意点: AWR と異なり STATSPACK の Mutex Sleep は簡易版。Sleeps 件数は参考値として扱う。Wait Time が DB Time の 1% を超える場合に詳細調査する。
- 関連セクション: Library Cache Activity / Latch Activity（SQL memory manager workarea）
- 使うシーン: カーソル共有問題・Library Cache バージョン爆発の調査
項目の意味と着目点 — Mutex Sleep Summary
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Mutex Type | Mutex 種別（Cursor Pin / Library Cache 等） | Cursor Pin が多い場合はカーソル共有の問題。Library Cache は Version Count 爆発を疑う |
| Location | 取得箇所の内部シンボル名 | Oracle 内部処理位置。SR 対応時に使用 |
| Sleeps | Mutex Sleep 発生回数 | 多い場合は競合が頻繁。Wait Time と合わせて重大度を判断 |
| Wait Time (s) | Mutex 待機の累積時間（秒） | DB Time の 1% 超なら調査優先。0 秒なら実害はほとんどない |