大規模なSELECTが他のステートメントをブロックしないようにするにはどうすればよいですか？
SQL Azureデータベースには、1日に1回実行するような大規模なSELECTステートメントが含まれています。重いSELECTステートメントには、ロックのヒントが含まれていません。最近、製造中にいくつかの屋台が見られました。これがsys.dm_exec_requestsはその期間表示されていました...実行時間が最も長いクエリはSELECTであり、PAGEIOLATCH_SH待機タイプ。次は他のクエリでした-ほとんどの場合INSERTステートメントはPAGEIOLATCH_EX待機タイプ。すべてがすぐに完了するのではなく、数十秒間実行されます。そのため、基本的にその重いSELECTだけで他のクエリが中断されます。
どうすれば解決できますか？重いSELECTの実行が遅くても問題ありませんが、他のクエリが中断されるべきではありません。
主なオプションは次のとおりです。
SELECTクエリを調整して、使用するI/Oリソースを減らします。- 静かな時間にクエリを実行します。
- データベースの別のコピー（読み取り可能なセカンダリなど）でクエリを実行します。
- I/Oが制限されたリソースプールでクエリを実行します ここで説明 *。
- I/O容量が大きいサイズ/階層に移動します。
補足：この回答では [〜＃〜] rcsi [〜＃〜] やSIなどの分離レベルの使用については触れていません。それらはロックブロッキングに適用され、質問にはそれへの参照が含まれていません：PAGEIOLATCH_XX待機は、物理I/Oでの待機に関連付けられています。
*この機能は、Azure SQLデータベースでは使用できない場合があります。