高ディスクIOレイテンシ（sys.dm_io_virtual_file_stats DMVから））の原因は何ですか？
これらは、sys.dm_io_virtual_file_stats DMVをクエリした結果です。 （わかりやすくするために、いくつかの計算フィールドを追加しています）。
データベース7の特定の基本操作が、データベース6で実行しているコア操作のボトルネックになっていることがわかりました。
たとえば、データベース7にはどこにも使用されていないテーブルがあり、行数が多い（約3億）。データベース6では、数十万件のレコードの一括挿入が1日を通して1時間ごとに発生しています。単純なSELECT COUNT(1) FROM Database7.dbo.UnusedTableInDatabaseを実行すると、戻るのに約10分かかり、特にIO。多くのサーバーリソースを使い果たしているようです。データベース6の挿入ジョブがほぼ停止するまでクロールし、バックログが増加し始めます。
私が知っていることの1つは、データベース7のデータファイルとログファイルが同じ論理ドライブにあることです。データベース6は、データファイルとログファイルが別々のドライブにあるように適切に設定されています。
これらの問題を解決するために、次にどこから掘り始める必要がありますか？
更新：私のサーバーは、プロビジョニングされたIOPS SSD（io1）ドライブを使用してAWSでホストされています。ボリュームあたり最大64,000 IOPSが表示されるはずですが、現在は約2,000 IOPSが表示されていますが、汎用SSD（gp2）ドライブを備えたAWS上にある別のサーバーは約6,000 IOPSを提供しています。
このDMVの私の問題は、timeの重要なコンテキストを見逃しているため、正確に特定するのが難しいことですwhen待ち時間のスパイクが発生します。 VMを実行している場合は、 ディスクレイテンシメトリックを収集するためのPerfmonトレース をセットアップすることをお勧めします。これにより、時間を絞り込むことができます。これがオプションでない場合は、クエリの結果を約5分ごとにユーザーテーブルにプッシュし、デルタをトレンド表示して、スパイクが発生する期間を確認します。
スパイクが発生している時期がわかったら、遅延の原因を 拡張イベント （たとえば、長時間実行されているクエリのキャプチャ）、ジョブ履歴などを介して特定するのが簡単になります。スパイク中にI/Oにローカルに直接影響するものが何もない状況に遭遇したとき、この情報を手にしてAmazonにエスカレーションする必要があります。騒々しい隣人のシナリオが発生するので、何も排除しないでください。
余談ですが、DMVの統計をさらにデータベースファイルに分解したい場合は、このDMVで Paul Randalの投稿 を確認してください。