PART 03 — ① レポートヘッダ詳細

レポートヘッダは STATSPACKレポートの最初に表示される総覧ブロックです。ここで全体像をつかみ、次にどのセクションを見るかを決めます。12項目の見方を順に解説します。

1. Database / Instance Information— DBインスタンス情報

何を表すか: DB ID / DB Name / Instance / Inst Num / Startup Time / Release / RAC 等。レポートが「どのDBで取得されたか」を特定するメタ情報。

• 読み方: DBバージョン（Release）とRAC構成を確認。Startup Time がスナップ期間の途中だと再起動が挟まっているサイン。その場合は累積カウンタがリセットされており比較不可。
• 閾値・注意点: RAC=YES なら他インスタンスの STATSPACK も併読すべき。
• 関連セクション: Host Information / Snapshot Information
• 使うシーン: レポート読み始め最初に確認

2. Host Information— ホスト情報

何を表すか: Platform / CPUs / Cores / Sockets / Memory(G)。AAS判定やCPUボトルネック評価の前提値。

• 読み方: Cores 値が AAS 閾値の基準。Memory(G) と Cache Sizes を見比べて SGA/PGA の占有率を推測する。
• 閾値・注意点: CPUs > Cores の場合はHyper-Threadingが有効。AAS の閾値は物理コア数（Cores）で判断するのが適切。
• 関連セクション: Instance CPU / OS Statistics
• 使うシーン: CPU/メモリ系の評価前に必ず確認

3. Snapshot Information— スナップショット情報

何を表すか: Begin/End Snap の番号・時刻・Sessions数・Curs/Sess・Elapsed(mins)・DB time(mins)・Av Act Sess・DB CPU(mins)。集計区間と負荷総量の把握。

• 読み方: AAS = DB Time(s) / Elapsed(s)。Cores 数と比較して余裕を判定。DB CPU(mins) / DB Time(mins) でCPU比率も把握。
• 閾値・注意点: AAS が Cores を超えると CPU ボトルネックの可能性。DB CPU / DB Time が高いほど CPU 支配型のワークロード。
• 関連セクション: Load Profile / Top 5 Timed Events
• 使うシーン: AAS 計算・スナップ期間特定

4. Cache Sizes— キャッシュサイズ

何を表すか: Buffer Cache / Shared Pool の Begin/End サイズ、Std Block Size、Log Buffer。

• 読み方: Begin と End の差でメモリ動的Resize（ASMM）を検知。Begin と End が異なる場合は Memory Dynamic Components で詳細を確認する。
• 閾値・注意点: AWR と異なり Shared Pool の End 値は表示されない場合がある。Log Buffer が小さい（2MB 未満）環境ではredo log space request 待機が発生しやすい。
• 関連セクション: Buffer Pool Statistics / Shared Pool Advisory / Memory Dynamic Components
• 使うシーン: メモリサイジング確認・ASMM 動的変更の検知

5. Load Profile— ロードプロファイル

何を表すか: 1秒・1トランザクション・1Exec・1Call あたりの主要負荷指標。DB全体の処理量を一目で把握する最重要表。

• 読み方: Per Second 列で日常感覚と比較。Logical reads / Physical reads の比でキャッシュ効率を判定。Hard parses / Parses 比が低ければバインド変数が活用されている。
• 閾値・注意点: AWRの Load Profile と列構成はほぼ同じだが「W/A MB processed」（Work Area MB処理量）が加わる。Rollbacks が多い場合はエラー多発やロールバック依存処理を疑う。
• 関連セクション: Instance Efficiency / Time Model System Stats
• 使うシーン: ワークロード性質の把握・比較分析の基準値

6. Instance Efficiency Indicators— インスタンス効率指標

何を表すか: Buffer Hit%・Library Hit%・Soft Parse%・Latch Hit%・Redo NoWait% など、SGA・ライブラリキャッシュの効率を一覧化。

• 読み方: Buffer ≥90%、Library ≥95%、Soft Parse ≥95%、Latch Hit ≥99% が一般的な目安。いずれかが閾値を下回ったセクションを深掘りする。
• 閾値・注意点: AWRと同じ指標だが「Optimal W/A Exec %」が追加。Execute to Parse % が低い場合はカーソル再利用が少なく、session_cached_cursors の引き上げや接続プールの見直しが有効な場合がある。
• 関連セクション: Latch Activity / Library Cache Activity / Shared Pool Statistics
• 使うシーン: 効率劣化のスクリーニング

7. Shared Pool Statistics— Shared Pool 統計

何を表すか: Shared Pool の Memory Usage% / % SQL with executions>1 / % Memory for SQL w/exec>1 を Begin/End で表示。

• 読み方: Memory Usage が 80% 超で Shared Pool 逼迫に注意。% SQL w/exec>1 が低い場合は使い捨てSQL（リテラルSQL）が多い証拠。
• 閾値・注意点: 単独で判断せず Latch Activity / Library Cache と合わせて読む。Begin→End の変化が大きい場合はスナップ期間中に SQL の入れ替えが多かった。
• 関連セクション: Library Cache Activity / Shared Pool Advisory
• 使うシーン: ハードパース過多の傍証・Shared Pool 逼迫の確認

8. Top 5 Timed Events— Top 5 待機イベント

何を表すか: 全セッション（FG+BG）が待たされた上位5イベントを Time(s) 降順で表示。AWRの「Top 10 Foreground Events」に相当するが、バックグラウンドの Idle イベントも含まれる点が異なる。

• 読み方: Idle イベント（LGWR worker group idle / heartbeat redo informer / lreg timer / AQPC idle 等）は無視する。Idle を除いた上位が実際のボトルネック。
• 閾値・注意点: AWRと違い Wait Class の列がない。「%Total Call Time」で相対的な影響度を判定する。CPU time が上位にあれば CPU 支配型のワークロード。
• 関連セクション: Foreground Wait Events / Background Wait Events
• 使うシーン: ボトルネック調査の最初の入口

9. Host CPU— ホストCPU使用率

何を表すか: OS全体のCPU使用率（User/System/Idle/WIO等）とLoad Average。

• 読み方: %WIO（I/O待機によるCPU時間）が高い場合はストレージのレイテンシ問題。%System が %User を超える場合はカーネル処理（システムコール過多）の可能性。
• 閾値・注意点: Begin/End 2点のみの瞬間値。OS Statistics セクションで期間中の統計を確認可能。Load Average が Cores 値を超えている場合は CPU 飽和。
• 関連セクション: OS Statistics / Instance CPU
• 使うシーン: OS レベルでの CPU 状況確認

10. Instance CPU— DBインスタンスCPU使用率

何を表すか: Host Total / Busy 時間に対するこのインスタンスのCPU消費割合。

• 読み方: % of Busy CPU used for Instance で、同じホスト上の他プロセスとの競合を評価。%DB time waiting for CPU が 0 でない場合はリソースマネージャによる絞り込みが発生している。
• 閾値・注意点: Host Total time = Elapsed × CPUs で算出される理論値。% of time Host is Busy が 80% 超なら OS 全体として CPU 不足。
• 関連セクション: Host CPU / OS Statistics
• 使うシーン: DB がホスト CPU をどれだけ使っているか確認

11. Virtual Memory Paging— 仮想メモリページング

何を表すか: 一部の OS 環境（Linux / HP-UX 等）で出力される STATSPACK 固有のセクション。KB paged out per sec / KB paged in per sec でメモリ不足によるスワッピング発生の有無を確認する。AWRには存在しない。

• 読み方: paged out が大きく paged in が小さい場合はメモリがOS外へ追い出されている（メモリ圧迫の予兆）。両方とも大きい場合はスワップが活発に発生している。
• 閾値・注意点: paged out / paged in は環境差が大きいため絶対値より傾向（増加中か）で判断する。継続的に大きい場合は SGA/PGA サイジングまたはサーバメモリの増設を検討。
• 関連セクション: Memory Statistics / OS Statistics
• 使うシーン: メモリ不足・スワッピング調査

12. Memory Statistics— メモリ統計

何を表すか: ホストメモリと SGA/PGA の使用量を Begin/End で比較。

• 読み方: SGA + PGA をホスト物理メモリで割った比率を確認。一般的な推奨上限は 50〜70%。PGA の Begin/End 差が大きい場合は並列処理や大量ソートが発生している。
• 閾値・注意点: % Host Mem used for SGA+PGA が高い場合は仮想メモリページングの発生リスクがある。Virtual Memory Paging セクションと合わせて確認する。
• 関連セクション: PGA Aggr Target Stats / Memory Dynamic Components / Virtual Memory Paging
• 使うシーン: メモリ割当の確認・スワッピングとの因果関係分析