PART 06 — I/Oボトルネックの読み方
Tablespace / Datafile / Segment I/O — 三層で原因を絞り込む

特定のTablespaceだけI/O待ちが集中しているのに気づかず、インスタンス全体をチューニングしようとして無駄骨を折ったことがあります。Tablespace・Datafileと段階的に絞り込む手順をまとめました。

I/Oボトルネックの症状

以下のサインがあればI/Oボトルネックを疑います。

• Top 5 Eventsに db file sequential read または db file scattered read が上位
• Buffer Cache Hit Ratioが低い（90%未満）
• SQL Ordered by Reads に特定SQLが突出
• OS側でディスクI/O使用率が高い

全体フローは PART 01、Wait Eventの基礎は PART 04 — Wait Eventドリルダウン、メモリとの関係は PART 07 — メモリ分析 を参照。

Tablespace I/O Stats の読み方

Tablespace IO Stats（AWRのIO Statsセクション）は表領域単位のI/O統計です。 どの表領域でI/Oが多発しているかを把握します。

列名	意味	注目ポイント
Av Rd(ms)	平均読み込み時間（ミリ秒）	通常 10ms以下。超えたらストレージ性能を確認
Av Buf Wt(ms)	平均バッファ待ち時間	高い場合はバッファ競合
Reads / s	1秒あたりの物理読み込み	突出した表領域が問題箇所
Blks Rd / s	1秒あたりの読み込みブロック数	フルスキャン多発かどうかの判断

Instance Activity / IO / Buffer Poolセクションの詳細は PART 06 — Instance Activity / IO / Buffer Pool 詳細（定義書） を参照。

Datafile I/O Stats の読み方

表領域の中でさらにどのデータファイルでI/Oが多いかを特定します。 特定のデータファイルに集中している場合はストレージ配置の見直しが必要です。

確認内容	判断基準
Av Rd(ms) が高いデータファイル	10ms超 → そのファイルのストレージ性能を確認
Reads が特定ファイルに集中	ファイルの分散配置を検討（RAID, ASM, ストライピング）
TEMP表領域のI/Oが多い	ソート・ハッシュのメモリ不足 → PART 07 メモリ分析
UNDO表領域のI/Oが多い	長時間トランザクション or UNDO領域不足

セグメント別I/Oの特定

Segments by Physical Reads（Segment Statisticsセクション）で、 どのテーブル/インデックスが物理I/Oを引き起こしているかを特定できます。

セグメント統計	意味
Segments by Physical Reads	物理読み込みが多いオブジェクト（テーブル/インデックス）
Segments by Logical Reads	バッファキャッシュアクセスが多いオブジェクト
Segments by Row Lock Waits	行ロック競合が多いテーブル

セグメント統計の詳細は PART 09 — Segment / その他 詳細（定義書） を参照。

I/O診断の実践Tips

状況	まず確認すべき箇所	典型的な対処
特定テーブルへの物理Readsが突出	Segments by Physical Reads → 実行計画でFULL SCAN確認	適切なインデックス追加、統計情報の更新
db file scattered read（マルチブロック読み込み）が多い	SQL Ordered by Readsで該当SQL特定	フルスキャンが意図的かを判断。意図しないならインデックス追加、意図的なら並列度調整
特定データファイルのAv Rd(ms)だけ高い	Datafile IO Stats → そのファイルが載るストレージを確認	SSD化 / ASMでのファイル再配置 / ストライピング
TEMP表領域のI/Oが多い	実行計画でSORT(DISK)が出ているSQLを探す	PGA_AGGREGATE_TARGETを増やす、SQLのソート削減

対処の方向性