PART 09 — ⑦ Segment / その他 詳細

Segment系セクション（1〜6）は共通の列構成を持ち、ランキング指標と最終列のみが異なります。まず共通列を整理してから、各セクション固有の指標を解説します。

1. Segments by Logical Reads— Top セグメント（論理読込順）

何を表すか: 論理I/O が大きいセグメント（表/索引）上位。アクセス頻度ホットスポット。

• 読み方: %Total ≥10% は1セグメントへの集中。索引なら効果あり、表なら Full Scan の可能性も。
• 閾値・注意点: セグメント名から処理を推定する力が必要。SQL_ID と紐付けるには別途確認。
• 関連セクション: Top SQL by Gets / Tablespace IO Stats
• 使うシーン: ホットセグメント特定

2. Segments by Physical Reads— Top セグメント（物理読込順）

何を表すか: 物理I/O が大きいセグメント。キャッシュに乗らない頻繁アクセス対象。

• 読み方: Buffer Pool拡張 or KEEP プール配置の候補が見える。索引で大量の物理読込は索引設計の見直し対象。
• 関連セクション: Top SQL by Reads / Buffer Pool Advisory
• 使うシーン: 物理I/Oホットスポット

関連: Segments by Physical Read Requests（要求数ベース）、Segments by Direct Physical Reads（PQ/LOB等のDirect Read）、Segments by Physical Writes / Write Requests / Direct Writes（書込側の同様ランキング）も同形式で出力されます。

3. Segments by UnOptimized Reads— Top セグメント（UnOpt Reads）

何を表すか: Smart Scan を経由しなかった物理読込が多いセグメント。Exadata 環境で重要。

• 読み方: ここに上がるセグメントは Smart Scan 対象外アクセスを受けている。索引アクセスのスキャン量が多いケース等。
• 閾値・注意点: Exadata 以外では UnOpt = Phys Reads。
• 関連セクション: Top SQL by Phys Reads (UnOpt)
• 使うシーン: Exadata最適化漏れ調査

関連: Segments by Optimized Reads（Smart Scan/Flash Cache経由の読込ランキング）も対をなす。

4. Segments by Table Scans— Top セグメント（テーブルスキャン）

何を表すか: Full Table Scan が発生した表の上位。索引設計不足や非効率SQLの示唆。

• 読み方: 業務表が頻繁にスキャンされていれば、索引追加候補。
• 関連セクション: Top SQL by Reads / Top SQL by Elapsed Time
• 使うシーン: 索引設計改善検討

5. Segments by DB Blocks Changes— Top セグメント（更新ブロック数）

何を表すか: ブロック更新が多発したセグメント。REDO生成量にも影響。

• 読み方: 更新ホットな表/索引を特定。索引更新が多ければ索引選定見直し。
• 関連セクション: Instance Activity (db block changes) / Top SQL (UPDATE系)
• 使うシーン: 更新偏在の調査

6. Segments by Row Lock Waits— Top セグメント（行ロック待ち）

何を表すか: 行ロック競合が発生したセグメント。Application 設計問題の検出に直結。

• 読み方: 上位セグメントの更新パターン（重複更新・カウンタ列等）を見直し。enq: TX - row lock contention と紐付けて分析。
• 閾値・注意点: 件数の絶対値より、業務ピーク時の比率で判断。
• 関連セクション: Enqueue Activity (TX) / Foreground Wait Events
• 使うシーン: ロック競合の根本原因特定

関連: Segments by ITL Waits（INITRANS不足）、Segments by Buffer Busy Waits（ホットブロック）も同形式で出力されます。

7. Dictionary Cache Stats— ディクショナリキャッシュ統計

何を表すか: データディクショナリ（dc_*）のキャッシュ別ヒット率・Final Usage。

• 読み方: % Miss が常時高い（≥5%）Dictionary Cache は Shared Pool 全体（LCではなく）の容量不足。
• 閾値・注意点: 一般的に Library Cache Activity の方が問題になりやすい。
• 関連セクション: Library Cache Activity / Shared Pool Statistics
• 使うシーン: DC問題の調査

8. Library Cache Activity— ライブラリキャッシュ活動

何を表すか: ライブラリキャッシュの Namespace 別（SQL Area / Body / Cluster / Index 等）統計。

• 読み方: SQL Area の Pin Pct Miss が高いとライブラリキャッシュ枠不足 or プラン爆発。Invalidations は統計収集や DDL でカーソル無効化された回数。
• 閾値・注意点: Reloads は再パース、Invalidations は強制無効化。両方多いとシステム安定性に懸念。
• 関連セクション: Soft Parse % / Library Hit % / Mutex Sleep Summary
• 使うシーン: Library Cache 問題の調査

9. Resource Limit Stats— リソースリミット統計

何を表すか: processes / sessions / enqueue_locks 等の Initial Allocation / Limit / Current/Max Utilization。

• 読み方: Maximum Utilization が Limit に近いリソースは枯渇リスク（起動パラメータの引き上げを検討）。
• 関連セクション: init.ora Parameters
• 使うシーン: リソース枯渇予防

10. init.ora Parameters— 初期化パラメータ

何を表すか: 起動時の初期化パラメータの一覧。Begin/End で値の変化があれば End Value 列に表示。

• 読み方: Begin と End で End Value が出るパラメータは期間中に変更されたもの。意図しない変更の検出に有用。
• 閾値・注意点: Hidden Parameter（_*）は通常含まれない。
• 関連セクション: Memory Dynamic Components
• 使うシーン: 設定確認・変更検知

関連: init.ora Multi-Valued Parameters は複数値を持つパラメータ（例: cursor_sharing の複数指定）専用に同じ3列で出力されます。

11. ADDM Task— ADDMタスク（詳細）

何を表すか: ADDM が生成した詳細な分析結果。Finding / Recommendation / Action がツリー構造で記載される。

• 読み方: Top ADDM Findings で気になった項目をここで深掘り。Impact（秒数）と Recommendation の具体性を見る。
• 閾値・注意点: 推奨内容が一般的すぎる場合もあるので、Foreground Wait Events 等で裏付けを取る。
• 関連セクション: Top ADDM Findings
• 使うシーン: 自動診断結果の確認