SQL Server への接続に関する断続的または定期的な問題のトラブルシューティング
ネットワークの安定性は、さまざまなサービスやアプリケーションの円滑な運用に不可欠です。 ただし、ネットワークの問題によってこの安定性が中断される場合があります。 この記事は、断続的または定期的なネットワークの問題とその一般的なエラー メッセージを理解し、対処するのに役立ちます。 これらの問題は不満を抱く可能性がありますが、より適切なトラブルシューティング手法を理解することで、より効果的に解決できます。
最も一般的なエラー メッセージ
断続的な問題は不規則に発生しますが、定期的な問題は予測可能な間隔で発生する傾向があります。 問題の種類を特定することは、トラブルシューティングの最初の手順です。 断続的または定期的なネットワークの問題が発生すると、次のエラー メッセージが表示されることがあります。
- 通信リンクエラー: このエラーは、ネットワーク コンポーネント間の通信の中断を示します。
- 接続タイムアウトの期限切れ: サーバーへの接続がタイムアウトし、サーバーの遅延または使用できないことが示されました。
- 一般的なネットワーク エラー: 一般的なネットワーク エラー メッセージは、多くの場合、ネットワークに関する未指定の問題を示します。
- トランスポート レベルのエラー: このエラーはトランスポート層で発生し、データ転送に関する問題が示唆されます。
- 指定したネットワーク名は使用できなくなりました: このメッセージは、指定したネットワーク リソースに到達できないことを意味します。
- セマフォ タイムアウト: このエラーは、ネットワークでのセマフォの使用に関連するタイムアウト条件を示します。
- 待機操作がタイムアウトしました: 待機操作が許可された時間を超えました。通常は、ネットワークの遅延が原因です。
- ネットワークからの入力ストリームの読み取り中に致命的なエラーが発生しました: このメッセージは、ネットワークからデータを読み取るときに重大なエラーを示しています。
- TDS ストリームのプロトコル エラー: 表形式データ ストリーム (TDS) は、SQL Server で使用されるプロトコルです。 このエラーは、プロトコルに問題があることを示します。
- サーバーが見つからなかったか、アクセスできませんでした: このエラー メッセージは、アクセスしようとしているサーバーが使用できないか、見つからないことを示しています。
- SQL Server が存在しないか、アクセスが拒否されました: このエラーは、SQL Server が存在しないか、SQL Server にアクセスしようとしたときに認証エラーが発生したことを示している可能性があります。
原因
最も一般的な問題は、ウイルス対策、ネットワークの最適化、古いネットワーク ドライバー、不適切なルーターまたはスイッチ、およびアプリケーションのプールされていない接続によるパケットのドロップに関連しています。
ウイルス対策などの一部の原因は証明が難しい場合がありますが、それでも一般的です。 コンピューターをアンインストールして再起動して、明確な証拠なしでそれを証明する必要がある場合があります。 SQL Server の例外の作成も機能する場合があります。 ただし、通常、ウイルス対策をオフにすると、ネットワーク フィルター ドライバーが監視されていない場合でも読み込みが続いているため、機能しません。
トラブルシューティング手順
Note
このプロセスは、SQL Server クライアントとサーバー接続用に設計されています。 SQL Server ミラーリング、Always-On、Service Broker 同期トラフィックなど、ポート 5022 経由のその他の通信はアドレス指定されません。
一般に、トラブルシューティングはデータドリブンである必要があります。これは、より焦点を絞ったコンテキストでの経験的なテストに道を与える可能性があります。 問題が非常に断続的で、ネットワーク トレースのキャプチャが困難な場合は、 非現実的な方法 が最初に適用される可能性があります。
各マシンで SQLCHECK を使用してレポートを収集する
各マシンで SQLCHECK を実行してレポートを生成します。 接続が失敗する理由を特定すると便利です。
クライアントとサーバーでネットワーク トレースを収集する
Windows マシンでは、SQLTRACE を使用してネットワーク トレースを収集します。
トレースを準備して実行するには、次の手順に従います。 手順 2 と 3 は、1 回だけ実行する必要があります。
SQLTRACE の最新バージョンをダウンロードしC:\MSDATA などのフォルダーに解凍します。
SQLTrace.ini ファイルを開き、次の設定をオフにします。
BIDTrace=no、AuthTrace=no、EventViewer=noファイルを保存します。
管理者として PowerShell を開き、ディレクトリを SQLTrace.ps1 を含むフォルダーに変更します。
CD C:\MSDATAトレース コレクションを開始します。
.\SQLTrace.ps1 -start問題を再現するか、エラーが発生するのを待ちます。
トレースを停止します。
.\SQLTrace.ps1 -stop
出力フォルダーは現在のディレクトリに生成され、詳細な分析に使用できます。
Windows 以外のコンピューターでは、TCPDUMP または WireShark を使用してパケット キャプチャを収集します。
SQL Server Network Analyzer を実行する
SQL Network Analyzer UI (SQLNAUI) には、解析および設定オプション用のトレース ファイルを選択するためのグラフィカル インターフェイスが用意されています。 SQL Network Analyzer (SQLNA)からダウンロードします。
クライアント トレースとサーバー トレースを個別に処理します。 トレースをチェーンしている場合は、それらを同時に処理します。 これらのファイルの合計サイズは、コンピューターのメモリの 80% を超えないようにする必要があります。 関連するすべてのトレース ファイルを処理するのに十分なメモリがあることを確認します。
このツールを使用すると、問題の疑いのあるレポートと、Excel で別の調査のために探索できる CSV ファイルが生成されます。
クライアント トレースとサーバー トレースで、一致する会話を見つけようとします。 一般に、IP アドレスとポート番号は一致します。 ただし、接続が任意の種類のネットワーク アドレス変換またはポート マッピングを経由する場合は、より困難になる可能性があり、IPV4 パケット ID を使用して整列し、ペイロードを比較する必要があります。
ネットワーク トレース分析で検索するパターン
NETMON または WireShark で会話がどのように終了するかを確認します。 クライアントとサーバーが同じことに同意するかどうか、または別のストーリーを伝えているかどうかを確認します。
SSL ハンドシェイク中に接続が閉じられた
ServerHello パケットでは、使用される暗号スイートが Diffie-Hellman スイートであり、トラフィックが Windows 2012 以前と Windows 2016 以降の間にある場合、このアルゴリズムは Windows 2016 セキュリティ パッチ以降で変更されます。 この暗号スイートのグループを無効にする必要があります。 詳細については、「Windows で SQL Server に接続すると、アプリケーションで TLS 接続エラーが強制的に閉じられる」を参照してください。
ClientHello の後に接続が閉じている場合は、クライアントとサーバーの間に TLS 1.0 または TLS 1.2 の不一致があるかどうかを確認します。 同じ場合は、両方のマシンで有効な暗号スイートと有効なハッシュを確認します。
詳細については、「 Advanced Secure Sockets Layer データ キャプチャを参照してください。
ドロップされたパケット数
一致した会話の終了を表示します。 再送信されたパケットが多数 (または 10 キープアライブ パケット、1 秒離れた場合) に ACK + RESET が続く場合、または一方がタイムリーな応答を報告し、もう一方が遅延を確認して会話を終了またはリセットする場合、これはネットワーク デバイスに問題があり、パケットが破棄または遅延されたことを示します。
サーバーが会話をリセットしたことを示すクライアント レポートと、クライアントが会話をリセットしたことを示すサーバー レポートが表示される場合もあります。 これは、スイッチまたはルーターが途中から接続を閉じることが原因であり、接続がしばらくアイドル状態になっていることを検出した場合に、キープアライブ パケットを無視するように構成される場合があります。
切断された接続の詳細については、以下を参照してください。
サーバー トレースとクライアント トレースの両方が、クライアント上の問題に同意します
両方のトレースがクライアントで遅延または応答なしを示している場合、またはサーバーの応答を確認した後にクライアントが ACK + RESET を発行した場合、またはログイン シーケンスの早い段階で接続を閉じる場合は、クライアントで BID トレースと NETSH トレースを取得して、TCP/IP スタック内とドライバーが考えている内容を確認する必要があります。 これは、ウイルス対策またはその他のネットワーク フィルター ドライバーがパケットの受信や応答の送信を遅らせる場合に一般的です。 接続タイムアウトは、初期 SYN パケットがネットワーク経由で送信される前に呼び出された DNS 応答が遅いか、セキュリティ API が遅かったことが原因である可能性もあります。
SQL Network Analyzer のエフェメラル ポート レポートを確認し、クライアントが送信ポートを使い切っていないかどうかを確認します。
クライアントが SYN パケットを送信する前に長い遅延がある場合は、クライアントから発信された ACK+FIN によって、TCP 3 方向の開始ハンドシェイクのみを示すパターンがすぐに、または PreLogin パケットの送信後に表示される場合があります。
ネットワーク トレースと BID トレースを収集して、Windows 上のクライアントの問題を分離する
SQLTrace.ini ファイルを開き、次の設定をオンに戻します。
BIDTrace=Yes、AuthTrace=Yes、EventViewer=Yesアプリケーションで使用しているドライバーと一致するようにSQLTrace.iniで
BIDProviderListを構成します。.NET System.Data.SqlClientは既定で有効になっています。 使用しているドライバーでない場合は、行の先頭に#を追加してBIDProviderListを無効にし、ODBC または OLEDB リストの先頭から削除します。 これにより、その種類のサポートされているすべてのドライバーがキャプチャされます。 詳細については、「 INI の構成」を参照してください。ファイルを保存します。
管理者として PowerShell を開き、ディレクトリを SQLTrace.ps1 を含むフォルダーに変更します。
CD C:\MSDATABID トレースを収集する場合は、BID トレース レジストリを初期化します。
Note
BID トレースは既定で有効になっています。
.\SQLTrace.ps1 -setupトレースしているサービスまたはアプリケーションを再起動します。
SQL Server Integration Services (SSIS) パッケージなどの一部のアプリケーションでは、パッケージの実行時に DTEXEC または ISServerExec の新しいインスタンスが起動されるため、再起動は意味がありません。
トレース コレクションを開始します。
.\SQLTrace.ps1 -start問題を再現するか、エラーが発生するのを待ちます。
トレースを停止します。
.\SQLTrace.ps1 -stop
出力フォルダーは現在のディレクトリに生成され、詳細な分析に使用できます。
他の Microsoft SQL Server ドライバーをトレースするには、次の記事を参照してください。 ネットワーク トレースを使用して実行します。
- Linux および Mac ODBC ドライバー BID トレース
- .NET Core SQL ドライバー トレースの収集
- PerfView のダウンロード
- PerfView を使用してトレース ログを収集する
- Microsoft JDBC Driver
サード パーティ製ドライバーをトレースするには、ベンダーのドキュメントを参照してください。
サーバー トレースとクライアント トレースの両方が、問題がサーバー上にあると同意します
両方のトレースがサーバーで遅延または応答を示さない場合、またはサーバーがログイン シーケンスの予期しない時点で接続を閉じた場合、またはサーバーが同時に多数の接続を閉じる場合は、サーバーに問題があることを示します。
最も可能性の高い原因は、サーバー パフォーマンスの低下、MAXDOP の高さ、大規模な並列クエリとブロックです。 これにより、スレッドの枯渇が発生し、ログイン要求がすぐに処理されるのを防ぐことができます。特に、多数の接続タイムアウトが同時に終了し、LoginAck 列に "Late" と表示される場合です。SQL Server ERRORLOG ファイルには、15 秒を超える時間がかかる IO 操作が表示されることがあります。これは、パフォーマンスの問題のもう 1 つの指標です。 ネットワーク トレースでは、TCP 3 ウェイ ハンドシェイクが完了していない可能性があることを示す、6 フレーム以下のリセット レポートに多数の会話が表示される場合もあります。 詳細については、「 接続リング バッファーを収集するを参照してください。
RingBufferConnectivity クエリを実行し、結果を Excel に貼り付けます。 これは履歴リストであるため、問題が発生した後に実行できます。 ただし、ビジー状態のサーバーの場合は、すぐに終了する可能性があります。 低速なサーバーの場合、数日間データが含まれます。
アプリケーションで複数のアクティブな結果セット (MARS) を使用する場合、終了シーケンスの一部として RESET で終了します。 SMP:FIN パケットと ACK+FIN パケットが既にクライアントから送信されている場合、これは問題ありません。 サーバーの SMP:FIN パケットはクライアントからの ACK+ FIN の後に到着し、Windows は接続終了シーケンスの一部として ACK + RESET を発行し、その他のサーバー応答に対して RESET を発行します。
接続プール
詳細については、「 接続プール」を参照してください。
接続プールを使用する場合、通常、ネットワーク トレース内の会話は非常に長くなります。 SQL Server Network Analyzer によって生成された CSV ファイルを使用して、プロトコルとフレームで並べ替えとフィルター処理を行うことができます。 ネットワーク キャプチャが 30 分未満の場合は、開始フレームまたは終了フレームが表示されない可能性があります。 多数の会話が SYN パケットから ACK+FIN パケットまでの 30 フレームより短い場合、これはプールされていない接続を示します。 これらが複数の長い会話と混在している場合は、結果セットの読み取り中に MARS 以外の接続でコマンドを実行することによって、バックグラウンドでプールされていない接続が発生する可能性があります。
エフェメラル ポート レポートには、トレースの有効期間中の新しい接続の数が表示されます。 接続速度は、1 秒あたりの接続数で判断できます。
RESET と ACK + RESET
ACK + RESET は、通常、アプリケーションまたは Windows が接続を中止したときに表示されます。 これは通常、低レベルの TCP エラーが原因です。 パケットは、すぐに送信を停止するように他のコンピューターに通知します。 ただし、サーバーが送信の途中にある場合は、ACK+ RESET の送信後に 1 つまたは 2 つのパケットがクライアントに到着する可能性があります。 ポートが閉じているため、オペレーティング システムは RESET パケットを送信します。 これは、通常のクロージング ハンドシェイクの一部ではない ACK+FIN パケットの後にパケットが到着した場合にも発生します。
一部のサード パーティ製ドライバーは、ACK + FIN ではなく接続を閉じる ACK + RESET パケットも送信します。 一部のプローブ接続でもこれを行うことができます。 ACK+ RESET パケットの前にキープ アライブ パケット、再送信されたパケット、またはゼロ Windows パケットがない場合、ACK+ FIN の通常のクローズが予想されるときにクライアントから送信される場合は、問題がない可能性があります。
NETSTAT を使用してネットワークの問題を分析する
NETSTAT は、データ収集 SQLTrace.ps1 の実行時に自動的に収集されます。
または、コマンド プロンプトでNETSTAT -abon > c:\ports.txtを管理者として実行して、ネットワークの問題に関連する情報を収集することもできます。
ports.txt ファイルには、すべての受信ポートと送信ポート、ポート番号、プロセス ID、およびポートを所有するアプリケーションの名前の一覧が含まれます。 これを使用して、最悪の違反者と、ポートの制限に達したかどうかを確認できます。 メモ帳で Status バー をオンにして、 Word の折り返しをオフにします。 ステータス バーに行数が表示されます。 2 で除算すると、おおよそのポート使用量を取得できます。
TcpTimedWaitDelay と MaxUserPort を調整する
アプリケーションがホスト コンピューター上の送信ポートを使い果たし、アプリケーションにすぐに変更を加えることができない場合は、 TcpTimedWaitDelay を 240 秒から 30 秒に減らすことができます。そのため、送信ポートのリサイクル時間を短縮できます。
Windows 2003 以降では、 MaxUserPortを増やすこともできます。 Windows Vista 以降の場合は、 NETSH コマンドを使用してこれを設定します。 この一定の措置では、プールされていない接続やプールされていないバックグラウンド接続の非効率性は排除されません。また、開発者は、接続プールを使用するようにアプリケーションを変更することを強くお勧めします。
Windows 2008 以降では、既定で、範囲が約 4,000 エフェメラル ポートから 16,000 ポートに増加しました。
詳細については、「 MaxUserPort と TcpTimedWaitDelay の設定を調整するを参照してください。
ウイルス対策またはネットワーク フィルター ドライバーに関連する問題
クライアントからサーバーまたはサーバーからクライアントに送信されるほぼすべてのパケットは、ACK パケットが逆方向に送信されて応答されます。 TCP.SYS レイヤーによって ACK が生成されます。 パケットがクライアントで受信され、クライアント トレースに受信されたことが示されているが、ACK がサーバーに返されない場合、これは、ウイルス対策またはその他のネットワーク フィルター ドライバーがパケットを紛失または破棄したか、(ネットワーク トレース コレクションの最後を過ぎた) 長い間そのパケットを保持していることを示す適切な兆候です。 同様に、サーバー トレースにクライアントからのパケットが表示されていても、ACK がクライアントに送り返されない場合は、サーバー上のサーバーウイルス対策に問題がある可能性があることを示します。
ただし、大量のデータをアップロードまたはダウンロードする場合、フロー制御に役立つ一連のデータ パケットの後に ACK パケットが送信されることがあります。
ウイルス対策とフィルタードライバーは、犯人として証明することは非常に困難です。 経験的なテストはほとんど常に必要です。 ウイルス対策でアプリケーションまたは SQL Server の例外を作成し、48 時間監視して動作が向上するかどうかを確認します。 例外を設定できない場合は、ウイルス対策プログラムをアンインストールして再起動します。 ウイルス対策フィルター ドライバーは引き続き読み込まれるため、通常は無効にしても役に立ちません。 エッジ保護が実施されている場合にのみ、これを最後の手段として行います。
ネットワーク セキュリティ管理者に問い合わせてください。 状況が改善した場合は、ウイルス対策ベンダーと協力して問題を軽減することが必要になる場合があります。 そうでない場合は、他のネットワーク フィルター ドライバーが原因である可能性があります。
Windows ファイアウォールの監査を有効にする
ファイアウォールがパケットを削除したかどうかを判断するには、Windows でファイアウォール監査を。
SQL Server の場合、この問題はクライアントまたはサーバー コンピューターに関連している可能性があります。 ネットワーク トレースには、マシンがパケットを受信したが応答しなかったことが示されます。 その後、パケットが再送信され、再び応答が返されず、最終的に接続がリセットされます。
経験的およびその他のアクション
エフェメラル ポート
エフェメラル ポートの不足は、特にネットワーク上に SYN パケットが表示されない場合に、断続的な接続タイムアウトの比較的一般的な原因です。
サーバー上の受信要求の場合、80 や 1433 などのポートは、クライアント IP アドレスあたり最大 64,000 個の受信接続を受け取ることができ、一般にすべての実用的な目的で "無制限" になります。
一方、送信接続の場合、ポートの数は制限され、すべてのサーバー接続間で共有されます。 Windows Vista、Windows 2008 以降の場合、既定の範囲はポート 49152 から 65535 (2^16 = 16,384 ポート) です。
通常、ポートはオペレーティング システムによって 4 分間 (240 秒) 保持されてから、再利用され、アプリケーションで再利用されます。 これは、悪意のあるソフトウェアによるポート スプーフィングや、そのポートの以前の所有者への新しい接続の誤ったリダイレクトを防ぐためです。 この遅延のため、Windows 2003 では、クライアント アプリケーションは SQL Server に対して 1 秒あたり 17 個の接続を行うだけで、送信ポート範囲は 4 分未満で使い果たされます。 Windows Vista の場合、その数は 1 秒あたり 68 接続に増加します。
IIS などのアプリケーションの場合、各 HTTP クライアントには SQL Server への送信ポートが 1 つ含まれる場合があります。 ビジー状態の Web サーバーでは、負荷が高い場合に送信ポートが不足する可能性があります。 Web ファームは、この状況を軽減できます。
最大サーバー メモリ (MB) を調整する
カーネル メモリの不足に関連する問題を解決するには、 最大サーバー メモリ (MB) を調整します。
オフロードを無効にする
テスト目的で、管理コマンド プロンプトを使用して一部のオフロードを無効にすることができます。
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled
問題が軽減されない限り、これらの設定を長時間無効にしないでください。 Windows 2008 以降では、既定で有効にする必要があります。
その他のオフロードの場合は、ネットワーク アダプターのプロパティに移動して、それらを表示および無効にする必要があります。
VMware ネットワーク バッファーの問題
仮想マシン (VM) を含む ESX ホストには、トラフィックが急増した場合に信頼性の問題を引き起こす可能性がある小さなネットワーク バッファーがあります。 次の VMware の記事では、バッファー サイズを増やす方法について説明します。 再起動は不要です。 この操作は、VM ではなく ESX ホスト コンピューターで行う必要があります。
ESXi のVMXNET3を使用したゲスト OS での大きなパケット損失
さらに、VM を別の ESX ホスト サーバーに移動するか、クライアントとサーバーを同じ ESX ホスト サーバーに移動して、問題が解消されるかどうかを確認してみてください。 その場合は、基本ネットワークの問題です。
VMware スナップショット
エラー中に発生した VMware スナップショットを確認し、無効にします。
ホスト コンピューターで無効になっている Receive Side Scaling (RSS)
RSS が無効になっている場合、SQL Server ホストはすべてのネットワーク要求を処理するために 1 つの CPU のみを使用します。 これにより、他の CPU (および CPU 全体) レベルが低い場合でも、CPU が 100% に急増し、問題が発生する可能性があります。
詳細については、「 受信側スケーリングの概要 および Receive Side Scaling Version 2 (RSSv2)を参照してください。
詳細
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。