VPN 経由の大きな SQL 結果：行はどこで待つのか

クエリはミリ秒で完了しても、VPN 経由でノート PC に届くまでに数分かかることがあります。サーバーは行をバッファーに書き、接続がそれを運び、クライアントがそれを消費します。これらの段階は順番に進むのではなく重なります。どれもが制限になり得ます。帯域幅を変えたり圧縮を有効にしたりする前に、実際に待っている段階を見つけてください。

三つの段階、一つのストップウォッチ

タイマーを意味の異なる二つの数値に分けます。最初の行が利用可能になった瞬間と、最後の行が消費された瞬間です。最初のページを描画するグリッドは、クエリが始まったことしか証明しません。完全な結果の時間こそ、ユーザーがエクスポートしたり最後までスクロールしたりするときに体験するものです。

クエリ テキスト、パラメーター、接続設定と一緒に両方の数値を記録します。その文脈がなければ、比較は二つの異なる作業の間のものになり、二つの場所の比較にはなりません。

ネットワークより先に待ちを読む

SQL Server は結果の行を出力バッファーに書き、クライアントがそれを取得します。消費が遅いクライアントは、その送信でサーバーを待たせることがあります。待機の種類は ASYNC_NETWORK_IO で、Microsoft のトラブルシューティング ノートは大きな結果とクライアント側の処理を原因の一つに挙げています。待機は送信経路が塞がっていることを示すだけで、理由は示しません。

遅い VPN も要因になりますが、各行を整形したり、ファイルに書き込んだり、バッチの合間に一時停止したりするクライアントも要因になります。待機の名前は次の計測への指針であり、回線についての判定ではありません。

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

カウンターは、何もしていない一時間の後ではなく、制限付きのワークロードを実行している間に読みます。累積カウンターはインスタンス起動以降のすべてのセッションを混ぜてしまうからです。生涯合計ではなく、実行中の差分を比較します。転送中に差分が増えていれば、問いは消費か配送かに絞られます。

両方のクライアントを同じ時計に載せる

データベースに近いクライアントとリモート クライアントから、制限付きのワークロードを実行します。クエリ、パラメーター、結果サイズ、接続設定を同一に保ちます。サーバーの実行時間、グリッドの表示時間、エクスポート時間は三つの異なる時計なので、両側で同じ計測を使ってください。サーバー側の数値とクライアント側のエクスポート タイマーを比べても、検証できない結論しか得られません。

経路が原因に見えるときは、転送中にその特定のフローについて、損失、再送、達成スループットをネットワーク管理者に見てもらいます。一般的な速度テストは別の経路、エンドポイント、並行性パターンを使うことがあります。小さな成功した要求は、持続的な結果転送についてほとんど何も語りません。

経路を責める前にバイトを削る

フィルタリング、集計、必要な列だけの選択は、転送量と、クライアントが各行に対して行う作業の両方を減らします。意図した結果は保ってください。レポートには、画面上の要約にはない詳細が必要なことがあります。

繰り返しのエクスポートでは、データベースに近い承認済みの実行場所が定義済みの出力を書き、それを一度だけ届けることができます。これはワークフローとそのアクセス制御を変えるものであり、共有ホストに無制限のダンプを残す許可ではありません。

圧縮は既定の修理ではありません。サポートとセキュリティは実際のプロトコルと展開に依存し、クライアントがゆっくり展開する圧縮ストリームは体験を悪化させることがあります。まず段階を計測し、その段階に対してサポートされる変更を選んでください。