SQL ServerのPAGEIOLATCH_SH待機タイプとは何ですか？
トランザクションの途中で長い時間がかかっているクエリがあります。プロセスのwait_typeを取得すると、PAGEIOLATCH_SHになります。
この待機タイプは何を意味し、どのように解決できますか？
から MSDN ：
PAGEIOLATCH_SHタスクが
I/O要求内にあるバッファーのラッチで待機しているときに発生します。ラッチ要求は共有モードです。長い待機時間は、ディスクサブシステムの問題を示している可能性があります。
実際には、これはほとんどの場合、大きなテーブルの大規模なスキャンが原因で発生します。インデックスを効率的に使用するクエリではほとんど発生しません。
クエリが次のような場合：
Select * from <table> where <col1> = <value> order by <PrimaryKey>
、(col1, col_primary_key)に複合インデックスがあることを確認してください。
持っていない場合は、INDEX SCANが選択されている場合は完全なPRIMARY KEYが、col1のインデックスが選択されている場合はSORTが必要です。
どちらも非常にディスクI/Oが大きなテーブルでの操作を消費します。
PAGEIOLATCH_SH待機タイプは、通常、断片化または最適化されていないインデックスの結果として発生します。
多くの場合、PAGEIOLATCH_SH待機タイプが多すぎる理由は次のとおりです。
- I/Oサブシステムに問題があるか、設定が間違っています
- 高いI/Oアクティビティを生成している他のプロセスによるI/Oサブシステムの過負荷
- 不良インデックス管理
- 論理ドライブまたは物理ドライブの誤解
- ネットワークの問題/遅延
- メモリープレッシャー
- 同期ミラーリングとAlwaysOn AG
高いPAGEIOLATCH_SH待機タイプの解決を試みるために、次を確認できます。
- SQL Server、クエリ、およびインデックス。非常に頻繁に、これは過剰な
PAGEIOLATCH_SH待機タイプの根本原因として見つかる可能性があります。 - I/Oサブシステムのトラブルシューティングにジャンプする前のメモリ不足
AlwaysOn AGでミラーリングまたは同期コミットの安全性が高い場合、PAGEIOLATCH_SHの増加/過剰が予想されることに注意してください。
このトピックの詳細については、記事 過剰なSQL Server PAGEIOLATCH_SHの待機タイプの処理 を参照してください。