I/Oが遅いという相談を受けたとき、Function単位・Tablespace単位・File単位のどこから切り込むかで調査時間が大きく変わります。3つの階層を順に絞り込んでいく分析の流れを整理しました。
I/Oボトルネックの症状
図1: STATSPACKでのI/Oボトルネック診断
以下のサインがあればI/Oボトルネックを疑います。
- Top 5 Eventsに db file sequential read または db file scattered read が上位
- Instance Efficiency の Buffer Hit % が低い（90%未満）
- SQL ordered by Reads で特定SQLが突出
- OS側でディスクI/O使用率が高い
全体フローは PART 01、Wait Eventの基礎は PART 04 — Wait Eventドリルダウン。I/O Statsセクションの定義は PART 06 — Instance Activity / IO Stats 詳細（定義書） を参照。
IO Stat by Function の読み方
IO Stat by Function はI/Oを機能（Direct Read/Write・Buffer Read/Write・LGWR・CKPT・DBWnなど）ごとに分類した統計です。 どの機能がI/Oを引き起こしているかを把握できます。
| 機能 | 意味 | 高い場合の対処 |
|---|---|---|
| Buffer Read | バッファキャッシュを介した読み込み（通常のSQL） | Buffer Cache不足 → PART 07 |
| Direct Read | バッファを介さない直接読み込み（大規模ソート等） | PGA不足・並列クエリ → PART 07 |
| LGWR | REDOログライタのI/O | ストレージ性能不足・log file sync待機増加 |
| CKPT/DBWn | チェックポイント・DBライタのI/O | db_writer_processes増加・ストレージ改善 |
Tablespace IO Stats の読み方
Tablespace IO Stats は表領域単位のI/O統計です。 どの表領域でI/Oが多発しているかを把握します。
| 列名 | 意味 | 注目ポイント |
|---|---|---|
| Av Rd(ms) | 平均読み込み時間（ミリ秒） | 10ms以下が目安。超えたらストレージ性能を確認 |
| Reads/s | 1秒あたりの物理読み込み | 突出した表領域が問題箇所 |
| Blks Rd/s | 1秒あたりの読み込みブロック数 | フルスキャン多発の判断 |
| Writes/s | 1秒あたりの書き込み | UNDO/REDO領域が突出していないか確認 |
File IO Stats の読み方
表領域の中でさらにどのデータファイルでI/Oが多いかを特定します。 特定ファイルへの集中はストレージ配置の見直しサインです。
| 確認内容 | 判断基準 |
|---|---|
| Av Rd(ms) が高いデータファイル | 10ms超 → そのファイルのストレージ性能を確認 |
| Reads が特定ファイルに集中 | ファイルの分散配置を検討 |
| TEMP表領域のI/Oが多い | ソート・ハッシュのメモリ不足 → PART 07 メモリ分析 |
| UNDO表領域のI/Oが多い | 長時間トランザクション or UNDO領域不足 |
セグメント別I/Oの特定
Segments by Physical Reads（Segment Statisticsセクション）でどのオブジェクトが物理I/Oを引き起こしているかを特定します。 詳細は PART 09 — Segment / その他 詳細（定義書） を参照。
| セグメント統計 | 意味 |
|---|---|
| Segments by Physical Reads | 物理読み込みが多いテーブル/インデックス |
| Segments by Logical Reads | バッファキャッシュアクセスが多いオブジェクト |
| Segments by Buffer Busy Waits | バッファ競合が多いテーブル |
I/O診断でよくある誤りとSTATSPACK特有の注意点
I/O問題の診断では、ストレージ強化を急ぐ前にSQL・メモリ起因でないかを確認する必要がある。
| 誤りのパターン | なぜ誤りか | 正しい対処 |
|---|---|---|
| Av Rd(ms) が高いのでストレージ交換を提案する | 特定SQLのフルスキャンが原因の場合、ストレージ改善ではスループット改善にとどまり根本解決にならない | 先にSQL ordered by Readsで物理読み込みの多いSQLを確認。インデックス不足かどうか判断する |
| Buffer Hit %が低いのでBuffer Cacheを即増やす | 非効率なフルスキャンSQLが多い場合、Buffer Cacheを増やしても焼石に水になる | Segments by Physical Readsで対象テーブルを特定し、SQLチューニングまたはインデックス追加を先に実施 |
| STATSPACKのIO by FunctionをAWRのIO Statsと同じと思い込む | STATSPACKのIO by FunctionはAWRとセクション構成が若干異なる。直接/Buffer/LGWR等の分類名が違う場合がある | PART 06 定義書（section/post-06-instance-io.html）で各列の正確な意味を確認してから解釈する |