ネットワーク遅延が増加すると、MS SQL Serverでテーブルロックが発生しますか？

高遅延ネットワークを介してSQL Serverデータベースを1回呼び出している場合、その遅延のためにテーブルロックが発生しますか？たとえば、テーブルAにいくつかのレコードを照会すると、SQL Serverはそのデータを低速ネットワーク経由で返す必要があります。サーバーがネットワーク経由で応答を送信するか、SQL Serverが送信前にロックを解除する間にテーブルAに読み取りロックが発生します応答？

また、回答のサイズに基づいて答えは異なりますか？数KBと数百MBを返すだけでよい場合、違いはありますか？

明示的にトランザクションを作成し、クエリを実行し、トランザクションを閉じると、トランザクションの期間がレイテンシと相関するため、明らかにテーブルがロックされます。

クライアントがデータを受信するのに長い時間がかかり、SQL Serverが待機する必要があるデータを受信したという確認をSQL Serverに送信する場合、この待機のため、SQL Serverはクライアントから確認を受信しない限り、クエリによって保持されたロックを解除しません。

これは正確ではなく、分離レベルに依存します。

デフォルトREAD COMMITTEDでは、ステートメントの実行中はロックは保持されません。READ COMMITTEDステートメントレベルの読み取り一貫性を提供しません。唯一の保証は、コミットされていないデータを読み取れないことです。行を読み取るために共有ロックが取得および保持され、その後解放されます。

LOBタイプがない場合。

潜在的に非常に大きいLOBタイプは、バッファリングできません。共有ロックは、ステートメントが完了するまで取得および保持する必要があり、基本的にでREPEATABLE READ動作しREAD COMMITTEDます。

高遅延ネットワークを介してMSSQLデータベースを1回呼び出すと、その遅延のためにテーブルロックが発生しますか？

レイテンシーはテーブルロックの原因ではありません。ただし、テーブルロックが取得された場合、レイテンシが長くなります。

私よりもこの仕組みをよく知っている人（@RemusRusanu）を引用するには：

実行が進むと、結果がクライアントプログラムに返されます。行が実行ツリーを「バブル」するので、通常、トップオペレーターはこれらの行をネットワークバッファーに書き込み、クライアントに送信します。結果は、最初に中間ストレージ（メモリまたはディスク）に作成されてからクライアントに返されず、代わりに（クエリの実行時に）作成時に返されます。もちろん、結果をクライアントに送り返すことは、ネットワークフロー制御プロトコルに従います。クライアントがアクティブに結果を消費していない場合（たとえば、SqlDataReader.Read（）を呼び出すことにより）、最終的にフロー制御は送信側（実行中のクエリ）をブロックする必要があり、これにより、実行が中断されますクエリ。[ソース]

結果がSQL Serverが配信できるほど速く消費されない場合、クライアントまたはネットワークが原因である場合、ASYNC_NETWORK_IO待機が累積することがわかります。繰り返しますが、これは取得されるロックには影響せず、保持されている期間にのみ影響します。

マークの答えは多くの混乱を解決しましたが、NetBalancerを使用してレイテンシをエミュレートしてこれをテストした後、調査結果を投稿したかったのです。

ローカルマシンにリモートSQLサーバーを呼び出して、小さなトランザクション内でテーブルに対してSELECTとINSERTの両方を実行させました。リモートマシンで、ローカルSQLインスタンスに接続し、WHILEループを使用してsys.dm_tran_locksテーブルを繰り返し反復し、変更および読み取り中のテーブルのロックを探しました。NetBalancerをサーバーにインストールし、サーバーのネットワーク接続でネットワーク遅延をエミュレートするために使用しました。

私が見つけたものは次のとおりです。

• クライアントに多くのデータを返さないステートメントの場合、遅延はロックに影響しません。 せいぜい数百バイトのデータを返していました。私のマシンのトランザクションには、ロックを保持する250msのWAITFORがあり、ネットワーク遅延を5000msに増やしたとき、ロック期間は250msに近いままでした。
• 大量のデータを返すステートメントの場合、レイテンシはロックに確実に影響します。数万行をクライアントに返しました。レイテンシなしで、ロック期間は短かったです。レイテンシーを増やしたとき、すべてのデータを受信するまでロックが続きました。

このことから、データがネットワークバッファに収まる限り、レイテンシは問題ではないと結論付けています。SQLがネットワークバッファーに大量のデータを配置する必要がある場合、待機時間によりそのバッファーがバックアップされ、SQLはクエリ結果をすべてバッファーに保存できるようになるまでテーブルロックを保持します。

高遅延ネットワークを介してMSSQLデータベースを1回呼び出すと、その遅延のためにテーブルロックが発生しますか？

クエリが起動され、SQL Serverによって完了すると、結果が生成され、出力バッファに配置されてクライアントに送信され、クライアントは出力バッファから結果をフェッチします。SQL Serverは、確認応答がクライアントから受信されない限り、クエリによって保持されているロックを解放しません。ブロッキングを引き起こす可能性があります。

編集：エヴァンは、このMSサポート記事を参照することができます

セクション3

対応するクライアントアプリケーションが完了までにすべての結果行をフェッチしなかったSPIDによるブロック

サーバーにクエリを送信した後、すべてのアプリケーションはすべての結果行をすぐにフェッチして完了する必要があります。アプリケーションがすべての結果行をフェッチしない場合、ロックがテーブルに残り、他のユーザーをブロックする可能性があります。SQLステートメントをサーバーに透過的に送信するアプリケーションを使用している場合、アプリケーションはすべての結果行をフェッチする必要があります。そうでない場合（およびそのように構成できない場合）、ブロッキングの問題を解決できない可能性があります。問題を回避するために、動作の悪いアプリケーションをレポートデータベースまたは意思決定支援データベースに制限できます。