LatchとLockを混同したまま障害報告書を書いて、後から指摘を受けたことがあります。STATSPACK固有のLatch Sleep Breakdownを軸に、両者の違いと競合診断の手順を分けて説明しています。
LatchとLockの違い
図1: STATSPACKでのLatch/Lock競合診断
| 種類 | 概要 | 保持時間 | 主な競合 |
|---|---|---|---|
| Latch | Oracle内部メモリ構造を保護する軽量ロック | マイクロ〜ミリ秒 | バッファキャッシュ、ライブラリキャッシュ |
| Lock（Enqueue） | SQL/DML操作によるユーザーレベルのロック | 秒〜分以上 | 行ロック、表ロック、シーケンス |
全体フローは PART 01。Wait / Undo / Latchセクションの定義は PART 08 — Wait / Undo / Latch 詳細（定義書） を参照。
Latch Activityの読み方
Latch Activity でLatch競合の発生状況を確認します。STATSPACKとAWRで列構成はほぼ同じです。
| 列名 | 意味 | 注目ポイント |
|---|---|---|
| Get Requests | Latch取得要求数 | — |
| Pct Get Miss | 取得失敗率 | 0.1%超が問題の目安 |
| Avg Slps/Miss | ミスあたりの平均スリープ回数 | 高いほど深刻な競合 |
| NoWait Requests | ノーウェイトモードの要求数 | — |
| Latch名 | 原因 | 対処 |
|---|---|---|
| cache buffers chains | 特定ブロックへのアクセス集中（ホットブロック） | 対象テーブルのパーティション化、フリーリスト増加 |
| library cache | ハードパース多発 | バインド変数使用、cursor_sharing設定 |
| shared pool | 共有プール断片化・サイズ不足 | shared_pool_size増加 |
| row cache objects | データディクショナリキャッシュ不足 | shared_pool_size増加 |
Latch Sleep Breakdown — STATSPACKの特徴
Latch Sleep Breakdown はSTATSPACKに固有のセクションです（AWRには存在しません）。 Latchのスリープ（待機）をスリープ回数ごとに分布表示することで、競合の深刻度をより詳細に把握できます。
| Sleeps 列の見方 | 意味 | 診断 |
|---|---|---|
| Sleeps 1（1回スリープで取得成功） | 軽度の競合 | 許容範囲の可能性あり |
| Sleeps 2〜3（複数回のスリープ） | 中程度の競合 | 対象Latchの原因調査を開始 |
| Sleeps 4以上 | 重度の競合（深刻） | 緊急対処が必要 |
💡 Latch Sleep Breakdown の活用方法
Latch Activity の「Pct Get Miss」が低くても、Latch Sleep Breakdown で Sleeps 4以上が多い場合は特定タイミングで激しい競合が発生している可能性があります。Latch Activity との組み合わせで判断してください。
Enqueue Activityの読み方
| Enqueue種類 | 意味 | 原因と対処 |
|---|---|---|
| TX (Transaction) | 行レベルのトランザクションロック | コミット遅延・長時間トランザクション → コミット頻度見直し |
| TM (DML) | テーブルレベルのDMLロック | 外部キー制約のインデックスなし → FK列にインデックス追加 |
| ST (Space Transaction) | 空間管理のロック | セグメントの自動拡張が頻発 → 初期サイズ調整 |
| HW (High Water Mark) | セグメントHWM更新のロック | 大量INSERT → APPEND hintsや配列INSERT |
Buffer Wait Statisticsの読み方
STATSPACKでは Buffer Wait Statistics が 定義書 PART 07（Advisory / Memory） に含まれています（AWRはPART 08に対応）。 詳細は PART 07 — Advisory / Memory Statistics 詳細（定義書） を参照。
| Class | 意味 | 対処 |
|---|---|---|
| data block | 通常データブロックの競合 | ホットブロック → パーティション化、INITRANS見直し |
| segment header | セグメントヘッダーの競合 | フリーリスト（FREELIST GROUPS）の増加 |
| undo header / undo block | UNDOブロックの競合 | UNDOセグメント数の増加 |
STATSPACK Latch・Lock診断でよくある誤り
| 誤り | 何が起きるか | 正しい対処 |
|---|---|---|
| Latch Activityだけ見てSleep分布を確認しない | Pct Get Missが低くても特定タイミングで激しい競合が出ていると気づかない | Latch Sleep BreakdownのSleeps 4以上を必ず確認して深刻度を判断する |
| library cache latchを見てShared Poolを増やす | 原因がハードパース多発ならサイズ増加では根本解決にならず、断片化が進んで悪化するケースもある | バインド変数の使用状況と Hard Parses数をSQL Summaryで確認してから対処する |
| TX Enqueueを見てLOCK TABLE文を疑う | 実際はコミット遅延や長時間トランザクションによる行ロック待ちだった場合に的外れな調査をする | Top SQL (by Waits) で enq: TX – row lock contention を持つSQLと保持側トランザクションを特定する |