SQL Serverへの接続に関する断続的または定期的な問題のトラブルシューティング
ネットワークの安定性は、さまざまなサービスやアプリケーションの円滑な運用に不可欠です。 ただし、ネットワークの問題によってこの安定性が中断される場合があります。 この記事は、断続的または定期的なネットワークの問題とその一般的なエラー メッセージを理解し、対処するのに役立ちます。 これらの問題はイライラする可能性がありますが、理解を深め、適切なトラブルシューティング手法を使用して、より効果的に解決できます。
最も一般的なエラー メッセージ
断続的な問題は不規則に発生しますが、定期的な問題は予測可能な間隔で発生する傾向があります。 問題の種類を特定することは、トラブルシューティングの最初の手順です。 断続的または定期的なネットワークの問題が発生すると、次のエラー メッセージが表示される場合があります。
- 通信リンクエラー: このエラーは、ネットワーク コンポーネント間の通信の中断を示します。
- 接続タイムアウトの期限切れ: サーバーへの接続がタイムアウトし、サーバーの遅延または使用不能が示唆されました。
- 一般的なネットワーク エラー: 一般的なネットワーク エラー メッセージは、多くの場合、ネットワークに関する不特定の問題を示します。
- トランスポート レベルのエラー: このエラーはトランスポート層で発生し、データ転送に関する問題が示唆されます。
- 指定されたネットワーク名は使用できなくなりました。このメッセージは、指定されたネットワーク リソースに到達できないことを意味します。
- セマフォ タイムアウト: このエラーは、ネットワークでのセマフォの使用に関連するタイムアウト条件を示します。
- 待機操作のタイムアウト: 待機操作が許可時間を超えました。通常はネットワーク遅延が原因です。
- ネットワークからの入力ストリームの読み取り中に致命的なエラーが発生しました:このメッセージは、ネットワークからデータを読み取るときに重大なエラーを示します。
- TDS ストリームのプロトコル エラー: 表形式データ Stream (TDS) は、SQL Serverで使用されるプロトコルです。 このエラーは、プロトコルに問題があることを示します。
- サーバーが見つからなかったか、アクセスできませんでした: このエラー メッセージは、アクセスしようとしているサーバーが使用できないか、見つからないことを示しています。
- SQL Serverが存在しないか、アクセスが拒否されました: このエラーは、SQL Serverが存在しないか、SQL Serverにアクセスしようとしたときに認証エラーが発生したことを示している可能性があります。
原因
最も一般的な問題は、ウイルス対策、ネットワークの最適化、古いネットワーク ドライバー、不適切なルーターまたはスイッチ、およびアプリケーション内のプールされていない接続によるパケットドロップに関連しています。
ウイルス対策などの一部の原因は証明が難しい場合がありますが、それでも一般的です。 明確な証拠なしで、それを証明するためにコンピュータをアンインストールして再起動しなければならない場合があります。 SQL Serverの例外の作成も機能する可能性があります。 ただし、通常、ウイルス対策をオフにすると、ネットワーク フィルター ドライバーが監視されていない場合でも読み込みが続いているため、機能しません。
トラブルシューティング プロセス
注:
このプロセスは、クライアントとサーバーの接続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実行する
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 Keep-Alive パケット、1 秒離れた場合) に ACK+ RESET が続く場合、もう 1 つはタイムリーな応答を報告せず、もう 1 つはメッセージ交換の遅延と終了またはリセットを確認した場合、これはネットワーク デバイスの問題を示し、パケットは破棄または遅延されます。
また、サーバーが会話をリセットすることを示すクライアント レポートと、クライアントが会話をリセットすることを示すサーバー レポートが表示される場合もあります。 これは、スイッチまたはルーターが途中から接続を閉じることが原因であり、接続がしばらくアイドル状態であることが検出された場合に、パケット Keep-Alive 無視することが多い場合に、そのように構成される場合があります。
切断された接続の詳細については、次を参照してください。
サーバー トレースとクライアント トレースの両方が、クライアント上の問題に同意します
両方のトレースでクライアントに遅延または応答が表示されない場合、またはサーバーの応答を確認した後にクライアントが 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アプリケーションで
BIDProviderList使用 している ドライバーと一致するようにSQLTrace.iniで を構成します。.NET System.Data.SqlClientは既定で有効になっています。 使用しているドライバーでない場合は、行の先頭にを追加#して無効BIDProviderListにし、ODBC または OLEDB リストの先頭から削除します。 これにより、その種類のサポートされているすべてのドライバーがキャプチャされます。 詳細については、「 INI 構成」を参照してください。ファイルを保存します。
管理者として PowerShell を開き、ディレクトリを SQLTrace.ps1を含 むフォルダーに変更します。
CD C:\MSDATABID トレースを収集する場合は、BID トレース レジストリを初期化します。
注:
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 つの指標です。 ネットワーク トレースでは、6 フレーム以下のリセット レポートに多数の会話が表示される場合があります。これは、TCP 3 ウェイ ハンドシェイクが完了していない可能性があることを示しています。 詳細については、「 接続リング バッファーの収集」を参照してください。
クエリを 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+ RESET パケットを送信して、ACK+ FIN ではなく接続を閉じます。 一部のプローブ接続でもこれを行うことができます。 ACK+RESET パケットの前に、Keep-Alive パケット、再送信パケット、またはゼロ Windows パケットが先行せず、ACK+FIN の正常な終了が予想されたときにクライアントから送信される場合は、問題ない可能性があります。
NETSTAT を使用してネットワークの問題を分析する
NETSTAT は、データ収集 のSQLTrace.ps1 を実行すると自動的に収集されます。
または、管理者としてコマンド プロンプトでを実行NETSTAT -abon > c:\ports.txtして、ネットワークの問題に関連する情報を収集することもできます。
ports.txt ファイルには、すべての受信ポートと送信ポート、ポート番号、プロセス ID、およびポートを所有するアプリケーションの名前の一覧が含まれます。 これを使用して、最悪の違反者とポート制限に達したかどうかを確認できます。 メモ帳でステータス バーをオンにし、ラップWordオフにします。 ステータス バーには行数が表示されます。 2 で除算すると、おおよそのポート使用量を取得できます。
TcpTimedWaitDelay と MaxUserPort を調整する
アプリケーションがホスト コンピューター上の送信ポートを使い果たし、アプリケーションをすぐに変更できない場合は、240 秒から 30 秒まで減らすことができます TcpTimedWaitDelay 。そのため、送信ポートをより迅速にリサイクルできます。
Windows 2003 以降の場合は、 を増や MaxUserPortすこともできます。 Windows Vista 以降の場合は、コマンドを使用して NETSH これを設定します。 この一連のアクションでは、プールされていない接続やプールされていないバックグラウンド接続の非効率性は排除されません。また、開発者は、接続プールを使用するようにアプリケーションを変更することを強くお勧めします。
Windows 2008 以降の場合、範囲は既定で約 4,000 個のエフェメラル ポートから 16,000 ポートに増加しています。
詳細については、「 MaxUserPort と TcpTimedWaitDelay の設定を調整する」を参照してください。
ウイルス対策またはネットワーク フィルター ドライバーに関連する問題
クライアントからサーバー、またはサーバーからクライアントに送信されるほぼすべてのパケットは、ACK パケットが逆方向に送信されて応答されます。 TCP.SYS レイヤーによって ACK が生成されます。 クライアントでパケットが受信され、クライアント トレースに着信が示されていても ACK がサーバーに返されない場合、これは、ウイルス対策またはその他のネットワーク フィルター ドライバーがパケットを紛失または破棄したか、(ネットワーク トレース収集の終了を過ぎた) 長い間保持されていることを示す良い兆候です。 同様に、サーバー トレースにクライアントから送信されるパケットが示されていても、ACK がクライアントに送信されない場合は、サーバー上のサーバーウイルス対策に問題が発生している可能性があることを示します。
ただし、大量のデータをアップロードまたはダウンロードする場合、フロー制御に役立つ一連のデータ パケットの後に ACK パケットが送信される可能性があります。
ウイルス対策とフィルタードライバーは、原因として証明することは非常に困難です。 経験的テストはほとんど常に必要です。 アプリケーションまたはウイルス対策SQL Serverの例外をCreateし、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 では、クライアント アプリケーションは 1 秒あたり 17 回の接続しかSQL Serverできません。送信ポート範囲は 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 スナップショットを確認し、無効にします。
ホスト コンピューターで無効になっている受信側スケーリング (RSS)
RSS が無効になっている場合、SQL Server ホストは 1 つの CPU のみを使用してすべてのネットワーク要求を処理します。 これにより、CPU が 100% に急上昇し、他の CPU' (および全体的な CPU) レベルが低い場合でも問題が発生する可能性があります。
詳細については、「 Receive Side Scaling and Receive Side ScalingVersion 2 (RSSv2)の概要」を参照してください。
詳細
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示