解説

データベースの性能悪化の原因切り分けに関する問題です。表では4つの想定原因それぞれに調査項目a〜dが対応付けられており、cに対応する想定原因は「フラグメンテーションによるディスクI/Oの増加」です。フラグメンテーション（断片化）とは、データの追加・更新・削除を繰り返すうちに、本来連続して格納されるべきデータがディスク上のあちこちに分散してしまう現象です。断片化が進むと、1件のデータを読むために複数の離れた場所へのアクセスが必要になり、ディスクI/O回数が増えて応答性能が悪化します。これを確認するには、データがどの程度断片化して格納されているかという「データの格納状況」を調査する必要があります。したがってエが正解です。なお、aの負荷・通信量の増加には「外的要因の変化の確認」、bの重いSQL実行には「遅い処理の特定」、dのバッファ不足には「キャッシュメモリのヒット率の調査」がそれぞれ対応します。原因と調査手段の論理的なつながりを考えれば、表の全行を整合的に埋められます。

なぜ他の選択肢は違うのか

選択肢 ア

「遅い処理の特定」は、想定原因bの「非定型検索による膨大な処理時間を要するSQL文の実行」に対応する調査項目です。実行時間の長いSQLを洗い出すことで、重い処理が性能悪化の犯人かどうかを確かめます。フラグメンテーションは特定の処理ではなくディスク上のデータ配置の問題なので、遅い処理を特定してもフラグメンテーションの有無は分かりません。

選択肢 イ

「外的要因の変化の確認」は、想定原因aの「同一サーバへの他システムの共存による負荷増加、接続クライアント数の増加による通信量の増加」に対応します。アプリケーションの外側で起きた環境変化を調べる調査であり、ディスク内部のデータ配置状態であるフラグメンテーションの調査手段にはなりません。原因が内部要因か外部要因かという軸で整理すると対応関係が明確になります。

選択肢 ウ

「キャッシュメモリのヒット率の調査」は、想定原因dの「データベースバッファの容量の不足」に対応します。バッファ（キャッシュ）が不足するとヒット率が下がり、ディスクアクセスが増えて性能が悪化するため、ヒット率がその診断指標になります。フラグメンテーションはバッファの大きさとは無関係に、ディスク上の物理的な配置の乱れによってI/Oを増やす現象なので、ヒット率では検出できません。

解くときのポイント

原因と調査項目は「その調査で原因の有無を直接確認できるか」で対応付ける。フラグメンテーション→格納状況、重いSQL→遅い処理、バッファ不足→ヒット率、環境変化→外的要因。