Segment 系セクション（1〜3）は共通の列構成を持ち、ランキング指標と最終列のみが異なる。まず共通列を整理してから各セクション固有の指標を解説する。
Segments 系セクションの共通列 — 意味と着目点
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Owner | スキーマ所有者名 | 業務スキーマか SYS 等の辞書オブジェクトかで原因の判断が変わる |
| Tablespace Name | セグメント所属表領域 | Tablespace IO Stats の I/O 偏在との照合に使用 |
| Object Name | オブジェクト名（表名/索引名） | SQL Statistics の上位 SQL と照合してオブジェクトと SQL を紐付ける |
| Subobject Name | パーティション/サブパーティション名 | パーティション表の場合に特定パーティションへの集中を確認 |
| Obj. Type | オブジェクト種別（TABLE / INDEX 等） | TABLE なら FTS の可能性、INDEX なら選択性の低い索引アクセスの可能性 |
| %Total | そのランキング指標における全体比率 | 10% 超は 1 セグメントへの集中。30% 超は顕著なホットスポット |
1. Segments by Logical Reads— 論理読込 Top セグメント
何を表すか: 論理 I/O（Buffer Cache からのブロック読み込み）が大きいセグメント上位ランキング。アクセス頻度ホットスポットの把握に使う。
- 読み方: %Total ≥ 10% は 1 セグメントへの集中。TABLE 型なら Full Table Scan の可能性、INDEX 型なら高頻度索引アクセスの可能性がある。
- 閾値・注意点: SYS.COL$ 等の辞書オブジェクトが上位に来るのは DBMS_STATS 実行中では正常。業務オブジェクトに絞って集中度を判断する。
- 関連セクション: SQL ordered by Gets / Tablespace IO Stats / Segments by Physical Reads
- 使うシーン: ホットセグメントの特定・FTS vs. 索引アクセスの判断
項目の意味と着目点 — Segments by Logical Reads
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Logical Reads | Buffer Cache へのアクセス（論理読込）ブロック数 | 全 Logical Reads に占める割合で集中度を評価。SQL ordered by Gets と照合 |
| %Total | 全 Logical Reads に占める割合 | 10% 超で要注目。TABLE 型なら FTS を疑う |
| Obj. Type | TABLE / INDEX の別 | TABLE = FTS または多量更新処理の可能性。INDEX = 高頻度インデックス検索 |
2. Segments by Physical Reads— 物理読込 Top セグメント
何を表すか: ディスクからの物理 I/O が大きいセグメント上位ランキング。Buffer Cache をバイパスしてディスクから読まれたセグメントを示す。
- 読み方: %Total が高い TABLE は Full Table Scan や Direct Read の対象。%Total が高い INDEX は選択性が低い索引アクセスか大量の Range Scan。
- 閾値・注意点: STATSPACK では Threshold（デフォルト 1,000 物理読込）以上のセグメントのみ収集される。1 セグメントが Physical Reads の 50% 超を占める場合は最優先のチューニング対象。
- 関連セクション: SQL ordered by Physical Reads / Tablespace IO Stats / File IO Stats
- 使うシーン: 物理 I/O 集中セグメントの特定・インデックス設計見直し
項目の意味と着目点 — Segments by Physical Reads
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Physical Reads | ディスクから読み込んだブロック数 | 全 Physical Reads に占める割合で I/O の集中度を評価 |
| %Total | 全 Physical Reads に占める割合 | 50% 超の TABLE は FTS が頻繁に発生している可能性が高い |
| Obj. Type | TABLE / INDEX の別 | TABLE が高 %Total = フルスキャン多発。索引追加またはクエリ改善を検討 |
3. Segments by Buffer Busy Waits— バッファ競合 Top セグメント
何を表すか: Buffer Busy Waits が発生したセグメント上位ランキング。同一ブロックへの同時アクセス競合（ホットブロック）の発生場所を示す。
- 読み方: INDEX 型が上位 → 特定の索引ブロックへの書込競合（INSERT 集中）や読込競合。TABLE 型が上位 → ホットデータブロック。
- 閾値・注意点: STATSPACK ではデフォルト Threshold = 100 件。件数が少なくても %Total が大きければ偏在している。Buffer Wait Statistics で Class を確認し対処方法を判断する。
- 関連セクション: Buffer Pool Statistics（Buf Busy Waits）/ Enqueue Activity
- 使うシーン: ホットブロック特定・PCTFREE 調整・索引再構築の判断
項目の意味と着目点 — Segments by Buffer Busy Waits
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Buffer Busy Waits | そのセグメントで発生した Buffer Busy Waits 件数 | 業務への影響は件数より Wait Time で判断。Buffer Wait Statistics と照合 |
| %Total | 全 Buffer Busy Waits に占める割合 | 1 セグメントへの集中が明確な場合はそのオブジェクトがホットスポット |
| Obj. Type | TABLE / INDEX の別 | INDEX で多い場合は REVERSE KEY INDEX やパーティション索引を検討 |
4. Dictionary Cache Stats— ディクショナリキャッシュ統計
何を表すか: 行キャッシュ（Row Cache / Dictionary Cache）の各エントリの Get Requests / % Miss / Mod Reqs / Final Usage を示す。Shared Pool の辞書キャッシュ部分の効率を評価する。
- 読み方: Pct Miss > 2% のエントリが多い → Shared Pool が不足している兆候。dc_objects / dc_segments の Miss が高い → DDL 多発またはオブジェクト数が多い環境。
- 閾値・注意点: dc_table_scns は特殊用途（Flash Cache 関連）なので高 Miss でも問題ない場合が多い。Final Usage が 0 のエントリは実質未使用。Mod Reqs が高い場合は DBMS_STATS や DDL の実行中と判断できる。
- 関連セクション: Library Cache Activity / Shared Pool Advisory
- 使うシーン: Shared Pool サイジング根拠の確認
項目の意味と着目点 — Dictionary Cache Stats
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Cache | 辞書キャッシュエントリ名（dc_objects / dc_segments 等） | dc_objects / dc_segments / dc_users が主要な参照対象 |
| Get Requests | 辞書キャッシュへの参照要求回数 | 参照頻度の高いエントリが Shared Pool の行キャッシュの主要消費者 |
| Pct Miss | キャッシュミス率（%） | 2% 超で Shared Pool サイズ不足を疑う。dc_histogram 系は DBMS_STATS 実行で一時的に高くなる |
| Scan Reqs | スキャン（全件検索）リクエスト数 | 多い場合は辞書オブジェクトの検索コストが高い |
| Mod Reqs | 辞書エントリの変更リクエスト数 | 高い場合は DDL または DBMS_STATS が活発に実行されている |
| Final Usage | 現在キャッシュされているエントリ数 | 0 は未使用。大きすぎる場合はオブジェクト数が多い |
5. Library Cache Activity— ライブラリキャッシュ活動
何を表すか: Namespace（SQL AREA / TABLE/PROCEDURE / BODY / INDEX 等）ごとの Get Requests / % Miss（ハードパース率）/ Pin Requests / Reloads / Invalidations を示す。ライブラリキャッシュの効率とハードパースの発生状況を評価する。
- 読み方: SQL AREA の Pct Miss が高い → Hard Parse が多い（バインド変数未使用・cursor_sharing 設定）。Reloads が多い → SQL が無効化されてリロードされている（DDL 発生や Shared Pool フラッシュ）。Invalidations → DDL による既存 SQL の無効化件数。
- 閾値・注意点: Pin % Miss が Get % Miss より大きい場合はカーソルのピン競合が発生している可能性。SQL AREA BUILD / STATS の高 Miss は統計収集専用の内部 Namespace であり正常。
- 関連セクション: Mutex Sleep Summary / Shared Pool Advisory / init.ora Parameters（cursor_sharing / open_cursors）
- 使うシーン: Hard Parse 多発診断・cursor_sharing 設定評価・DDL による SQL 無効化の確認
項目の意味と着目点 — Library Cache Activity
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Namespace | ライブラリキャッシュ領域の種別 | SQL AREA が最重要。TABLE/PROCEDURE / BODY も定期確認 |
| Get Requests | オブジェクト取得要求数 | 参照頻度。SQL AREA は Executes に近い値になる |
| Get % Miss | Get 時のキャッシュミス率（ハードパースに近い） | SQL AREA で 2% 超は Hard Parse 多発のサイン |
| Pin Requests | オブジェクトのピン取得（実行確保）要求数 | Executes 数に近い値 |
| Pin % Miss | Pin 時のミス率 | 高い場合はカーソルのピン競合の可能性。Mutex Sleep と照合 |
| Reloads | 無効化後の再ロード件数 | 多いと SQL が頻繁に無効化されている。DDL 多発の証拠 |
| Invalidations | DDL 等による SQL 無効化件数 | 多いと DDL が業務 SQL の再コンパイルを引き起こしている |
6. Rule Sets— ルールセット
何を表すか: Oracle Advanced Queuing (AQ) や Oracle Rules Manager が使用するルールセットの評価回数（Evaluations / sec）・リロード・SQL/非 SQL 評価比率。
- 読み方: 通常環境では SYS.ALERT_QUE_R のみが存在し、Eval/sec = 0 であれば AQ ルールは実質未活性。業務で AQ を多用する場合のみ詳細確認が必要。
- 関連セクション: なし（AQ 使用環境のみ）
- 使うシーン: Oracle AQ / Rules Manager を利用しているシステムの調査
項目の意味と着目点 — Rule Sets
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Rule Set Name | ルールセット名（SYS.ALERT_QUE_R 等） | 業務ルールが定義されている場合はそのルールセット名が表示される |
| Eval/sec | ルール評価回数/秒 | 0 は AQ ルールエンジンが実質停止状態。業務 AQ 使用時は CPU 負荷に影響 |
| Reloads/sec | ルールセット再ロード回数/秒 | 高い場合は AQ ルールの定義変更が頻繁に発生している |
| No-SQL Eval % | SQL を使わずに評価できた割合 | 高いほど評価効率が良い |
| SQL Eval % | SQL を使って評価した割合 | 高い場合は AQ ルール評価のSQL負荷が増大する可能性 |