基本情報技術者 2013年 春期 午前（科目A） 問17

データ格納状況の確認【午前解説】

正解の理由

解法ステップ

1. 基本メトリクス収集：iostat、vmstat、sar、iotop等でI/O待ち（%iowait）、平均待ち時間、キュー長を確認。
2. アクセスパターン把握：ランダム読み書きが増えているかを確認し、フラグメンテーションの可能性を評価。
3. ファイルシステム側診断：filefrag（Linux）、fsutil（Windows）等でファイルのextent数や断片状態を確認。
4. DB側診断：インデックス断片化、テーブルの空きページ比、ページ密度（fillfactor）、bloat（Postgresのpgstattuple）を測定。
5. 切り分けと対処：物理配置が原因ならインデックス再構築、テーブル再編成、ファイルシステムのデフラグやデータ移動を検討。SSD環境では意味合いが変わるため注意。

# LinuxでのI/O概要
iostat -x 5 3

# ファイルの断片数確認（例）
filefrag -v /var/lib/mysql/ibdata1

# PostgreSQLでテーブル膨張確認（拡張が有効な場合）
# psql -c "SELECT * FROM pgstattuple('schema.table');"

選択肢別の誤答解説

• ア: 遅い処理の特定
  解説：遅いSQLやスロークエリの特定は「非定型検索で処理時間が長い」原因（b）を調査する際に有効ですが、フラグメンテーションによる物理I/O増加を直接検出する手段ではありません。
• イ: 外的要因の変化の確認
  解説：同一マシンに他システムを置いた、接続クライアント増加など外的要因（a）の確認は重要ですが、フラグメンテーション（c）そのものを示す調査項目にはなりません。
• ウ: キャッシュメモリのヒット率の調査
  解説：キャッシュヒット率の低下はバッファ容量不足（d）やアクセスパターンの変化を示しますが、物理ファイルの断片化が原因かどうかを特定するには不十分です。
• エ: データの格納状況の確認
  解説：物理的にファイルやデータページが細かく分散しているか（extent数、断片化、インデックスの空きページ）を直接検査できるため、フラグメンテーションによるI/O増加の原因特定に最も適しています。

よくある誤解

• キャッシュヒット率（バッファヒット）だけを見ればフラグメンテーションの有無がわかる：バッファヒットは重要ですが、物理配置の悪化はキャッシュ外アクセスを増やすため、別途格納状況の確認が必要です。
• ディスクI/Oが増えたらまずOSや他プロセスの確認だけで十分：外的要因確認は必要ですが、データ配置の問題はOS側からは見えにくくDB内部診断が不可欠です。
• インデックス再作成すれば必ず改善する：多くは効果がありますが、ファイルシステムの断片化やSSD/ストライピング配置など別要因が残る場合もあります。

補足コラム

FAQ