一貫性のある SQL Server ネットワーク接続の問題
Note
トラブルシューティングを開始する前に、 前提条件 を確認し、チェックリストを確認することをお勧めします。
この記事は、SQL Server でのネットワーク接続エラーのトラブルシューティングに役立ちます。 これらのエラーは一貫性があり、毎回繰り返し可能です。 SQL Server が TCP を有効にしない、接続をブロックしているファイアウォールなど、いくつかの構成の問題を示しています。 このトラブルシューティングでは、ほとんどのデータ センターで最も一般的な接続の種類であるため、リモート TCP 接続に重点を置いていますが、多くの手法は名前付きパイプにも適用できます。
一般的なエラー メッセージ
最も一般的なエラー メッセージは次のとおりです。
-
通信リンクエラー。
-
一般的なネットワーク エラー。
-
指定されたネットワーク名に到達できません。
-
SQL Server が存在しないか、アクセスが拒否されました。 (これは認証エラーになる場合もあります)
-
SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。 サーバーが見つからないかアクセスできません。 インスタンス名が正しいかを確認し、さらに SQL Server が構成されリモート接続が許可されていることを確認します。
-
指定されたサーバー/インスタンスを検索中にエラーが発生しました。
-
SQL Server Microsoft SQL Server への接続を開けませんでした。エラー:53。 ネットワーク パスが見つかりませんでした。
-
ターゲット マシンがアクティブに拒否したため、接続できませんでした。
問題の範囲を対象領域に絞り込む
次の手順は、トラブルシューティングを対象領域に絞り込むのに役立ちます。
- クライアント: アプリケーション、接続文字列、ドライバー (トランスポート層セキュリティ (TLS) 1.2 が不足しています)、SQL エイリアス (64/32 ビット)、ホスト ファイル、不適切なドメイン ネーム システム (DNS) サフィックス (フル ネーム接続、短い名前が失敗)。
- SQL Server: データベース エンジン、有効なプロトコル、ファイアウォール。
- ネットワーク: DNS エイリアス、ゲートウェイ、ルーター、ファイアウォール。
1. SQL Server Management Studio (SSMS) と TCP を使用して SQL Server にローカルで接続できますか?
たとえば、tcp:sqlprod01.contoso.com,1433
など、tcp:<ServerName>.<DomainName>.COM,1433
という形式で接続文字列を使用します。
Note
tcp
サーバー名の前に追加する必要があります。
"はい" の場合、SQL Server は正常に動作します。 この問題は、 ファイアウォール、 network、または client に関連しています。
そうでない場合、問題は SQL サーバー サービスに関連しています。
2. telnet を使用してクライアント マシンから SQL Server ポートに接続できますか?
たとえば、SQL Server インスタンスへの telnet 接続を確立するコマンドは telnet <ServerName>.<DomainName>.COM 1433
。
該当する場合、この問題は、 ドライバー/プロバイダー、セキュリティ/Secure Sockets Layer (SSL)、SQL エイリアス、または アプリケーションに関連しています。
そうでない場合、問題は hosts ファイル、network、またはファイアウォールに関連手順 1 が機能します。
telnet
コマンドとして使用できない場合は、Windows 機能として追加します。 これには再起動は必要ありません。新しいバージョンの Windows には、 Test-NetConnection PowerShell コマンドがあります。
たとえば、コマンド
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
を使用して、SQL Server インスタンスへのネットワーク接続をテストします。
3. 手順 2 で動作する場合、UDL ファイルを使用してサーバーに接続できますか?
"はい" の場合、問題はアプリケーション (正しくない接続文字列など)、またはアプリケーションで使用されるプロバイダー (Universal Data Link (UDL) ファイルで使用されているプロバイダーと異なる場合) に関連しています。
そうでない場合、問題は clients に関連しています。
4. 他のクライアントは SQL Server に接続できますか?
該当する場合、問題は、 ファイアウォール、 network、TLS 1.2、または client に関連しています。
そうでない場合、問題は ファイアウォール または serverに関連しています。
5. クライアントは他のサーバーに接続できますか?
該当する場合、問題は、 ファイアウォール、 network、TLS 1.2、または server に関連しています。
そうでない場合は、 ファイアウォール、、 network、または TLS 1.2 に関連する問題。
SQL Server サービス
問題が SQL Server サービスに関連している場合は、次の手順に従います。
サービス プロセス (sqlserver.exe) が Task Manager で実行されていることを検証。 (または、複数のインスタンスがインストールされている場合は、SQL Server 構成マネージャー または services.msc で確認してください)。
実行されていない場合は、インスタンスを開始してみてください。 ミラー化またはクラスター化された構成の場合は、プライマリ ノードまたはアクティブ ノード上にあることを確認します。 フェールオーバーにクラスター マネージャーを使用するか、クラスターを常にオンにして、リソースがオンラインであることを確認します。
アプリケーション イベント ログ、クラスター ログ、または SQL Server ERRORLOG ファイルが、実行可能な致命的なエラーを示しているかどうかを検証します。
必要なプロトコルがSQL Server 構成マネージャーと SQL Server ERRORLOG ファイルで有効になっていることを確認します (次のサンプルを参照)。
有効でない場合は、有効にして SQL Server を再起動します。 リモート接続が許可されている場合は、常に TCP を有効にする必要があります。
2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv6> 1433]. 2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv4> 1433]. 2013-11-20 09:42:03.94 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\KJ]. 2013-11-20 09:42:03.94 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$KJ\sql\query].
SSMS、UDL、または
ODBC データ ソース管理者接続では、次の形式でサーバー名を指定して、SQL Server Browser をバイパス tcp:<ServerName>.<DomainName>.com,1433
。Note
完全修飾ドメイン名 (FQDN)、
tcp:
、ポート番号を使用して接続を作成することは、最も信頼性と回復性に優れた方法です。tcp:
は小文字にする必要があります。接続が成功した場合:
- SQL Server ブラウザーが実行されていることを検証します。 SQL Server がポート 1433 でリッスンしている既定のインスタンスである場合は、実行している必要はありません。 ポート番号を削除しても、引き続き機能させることができます。
tcp:
プレフィックスを削除すると失敗する場合は、既定で名前付きパイプ経由で接続している可能性があります。 サーバー名としてnp:hostname\<ServerName>
を使用して検証できます。- NetBIOS 名を使用できない場合は、ネットワーク構成で NetBIOS 名または正しくない DNS サフィックスをオーバーライドする SQL エイリアスが存在する可能性があります。 また、32 ビットのエイリアスを確認します。
SSMS が接続できない場合は、UDL ファイル 接続するか ODBC データ ソース管理者 経由で接続してみてください。
- ホスト名の代わりに、サーバーの IP アドレスを使用してみてください。 サーバーがクラスター化されておらず、"any" でリッスンしている場合は、127.0.0.1 の使用を試みることもできます。
- 別のドライバーを試してください。 新しいドライバーは TLS 1.2 をサポートし、より良いエラー メッセージを表示します。
tcp:<ServerName>.<DomainName>.com,1433
、np:<ServerName>.<DomainName>.com\<InstanceName>
、またはlpc:<ServerName>.<DomainName>.com\<InstanceName>
など、さまざまなプロトコルを試してください。 SQL Server 構成マネージャーを使用して変更します。 次に、SQL Server を再起動し、 ERORLOG ファイルを使用して変更を確認します。- SQL Server (2014 以前) は TLS 1.2 をサポートするようにアップグレードされていますか? クライアントは TLS 1.2 をサポートするようにアップグレードされていますか? これらのプロトコルは有効になっていますか?
- すべての Windows マシンで、SQL Server 構成マネージャーまたはcliconfg.exeで SQL エイリアスを確認します。 64 ビットと 32 ビットのエイリアスを確認します。
- ERRORLOG ファイルで、データベースが使用できない、復旧中などのエラー メッセージがないか確認します。
NETSTAT
出力を確認して、SQL Server が想定されるポートを所有しているかどうかを検証します。 たとえば、管理者のアクセス許可を持つコマンド プロンプトからNETSTAT -abon > c:\temp\ports.txt
を実行します。
SQL Server が 1433 以外のポートを使用している場合:
ポート番号を指定して接続できるが、ポート番号を省略しない場合、これは SQL Server ブラウザーの問題です。 つまり、SQL Browser サービスは、接続先の SQL Server インスタンスの正しいポート番号を指定できません。 また、SQL Browser サービスを再起動して情報を更新する必要がある場合もあります。
ポート番号を指定しても接続できない場合、これはリモート接続時にのみ発生します。これはファイアウォールの問題です。 ファイアウォールの設定を確認し、ポートが受信接続と送信接続に許可されていることを確認する必要があります。 また、SQL Server アプリケーションまたはサービスがファイアウォール経由で通信できるようにファイアウォール規則を作成する必要がある場合もあります。
Always On を使用している場合、リスナーに接続しても SQL Server Browser は使用されないため、接続文字列でポート番号を指定する必要があります。 それでも問題が解決しない場合は、通常の SQL ポートでプライマリ ノードに直接接続してみてください。 それが機能する場合、問題はリスナーに関連しています。
上記のどの方法も機能しない場合は、SQL Server コンピューターを再起動します。
最悪のシナリオは、SQL Server サービスを停止し、新しいインスタンスをインストールするか、マシンを再構築してから、データベースを再アタッチするか、バックアップから復元することです。 SSISDB データベースなどの transparent データ暗号化 (TDE) を使用する場合は、この手順を実行する前に暗号化キーが保存されていることを確認してください。 リビルドは、難しい問題の根本原因分析よりも速くなる場合があるため、オプションとして提供されます。 クラスター化されたインストールの場合、代替ノードでノードを実行している間にノードを再構築できるため、影響が少なくなる可能性があります。
ファイアウォール
一般に、ファイアウォールの既定の動作では、SQL Server と SQL Server Browser のポートがブロックされます。 その場合、リモート接続は失敗し、ローカル接続は成功します。 Test-NetConnection
を使用してテストします。 サポートされているすべてのバージョンの Windows で使用できます。
Test-NetConnection <ServerName> -Port 1433
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
ERRORLOG ファイルで、SQL Server がリッスンしているポートを確認してください。 telnet
を Windows 機能として追加して有効にする必要がある場合があります。 これには再起動は必要ありません。 SQL Server も TCP でリッスンしている必要があります。 PortQry
は、Microsoft ダウンロード サイトからダウンロードできます。 SQL Server ブラウザーを使用している場合は、ファイアウォールと SQL Server TCP ポートで UDP ポート 1434 が開いていることを確認します。
ネットワーク
クライアントまたはアプリケーション サーバーは、別のコンピューター上の SQL Server に接続できます。 特定のネットワークまたはサブネット上の複数のクライアントが、サブネットの外部または別の特定のサブネット内のサーバーへの接続で問題が発生している可能性があります。 ネットワーク ファイアウォールによって、特定のクライアントが特定の SQL Server に接続できなくなる可能性があります。 たとえば、クライアントは他の SQL Server に接続でき、他のクライアントは問題のある SQL Server に接続できます。
VPN
この問題が仮想プライベート ネットワーク (VPN) でのみ発生し、ノート PC が社内に持ち込まれた場合には発生しない場合は、VPN ベンダーが問題を解決する必要があります。 クライアントとサーバーのネットワーク トレースを取得できます。これは、VPN が原因で発生している問題の種類を示すのに役立ちます。 たとえば、破棄されたパケットは最も可能性の高いパケットです。 VPN は、クライアントとサーバーの間の内部ルーティングを変更して、接続をブロックしている別のネットワーク デバイスに公開することもできます。 中間デバイスでネットワーク トレースを収集すると、ネットワークを分割して問題を特定するのに役立ちます。 tracert コマンドによってルーティングが表示される場合があります。
クライアント
問題がクライアントに関連している場合は、次のインジケーターが表示されることがあります。
他のクライアントは、通常どおりサーバーに接続できます。
このマシンから接続できるアプリケーションはありません。
UDLまたはODBC データ ソース管理者を使用して接続することはできません。
これは、送信ファイアウォール規則または正しくない既定の DNS サフィックスが原因である可能性があります。 次に例を示す完全修飾サーバー名を使用してテストしてみてください。
Test-NetConnection <ServerName> -Port 1433 Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
これは TLS の問題である可能性があります。 たとえば、サーバーは TLS 1.2 を使用し、クライアント ドライバーはアップグレードされていません。
ホスト ファイル エントリ、SQL エイリアス、または別のサーバーへの接続を指示する DNS エイリアスが存在する可能性があります。 pingと
telnet
を使用します。 動作していてもドライバーが失敗した場合は、SQL エイリアスまたは TLS の問題が疑われます。
Driver
問題がドライバーに関連している場合は、別のドライバーを試してください。
一部のドライバーが動作し、他のドライバーが失敗した場合は、TLS の問題が疑われます。 最新のドライバー ( Microsoft OLE DB Driver for SQL Server ODBC Driver 17 for SQL Server など) をダウンロードし試してください。
.NET を使用している場合は、最新バージョンのフレームワークを使用していることを確認してください。 それでも失敗した場合は、より良いエラー メッセージが表示されます。 また、SQL Server に依存しない最新バージョンの SQL Server Management Studio をダウンロードして、任意のクライアントにインストールすることもできます。 これにより、
SqlClient .NET
クラスが使用されます。
User
問題がユーザーに関連している場合は、別のユーザーがこのマシンにログインします。
接続が成功した場合は、失敗したユーザーの違いを確認します。 たとえば、Windows ユーザー プロファイルが破損しているか、ユーザーが別の組織単位 (OU) またはドメインに属している可能性があります。
複数のドメインのユーザーがいる場合は、サーバーと同じドメインのユーザーを使用してみてください。 通常、ユーザーの問題により認証エラーが発生し、別のトラブルシューティング ワークフローが発生します。
認証の問題でない場合は、プロセス モニター ログを使用して、接続に影響するローカルのアクセス許可の問題を特定できます。 たとえば、ユーザーがデータ ソース名 (DSN) を持っているか、別のドライバーへの何らかの種類のレジストリ リダイレクト、ローカルのアクセス許可の制限、または接続エラーを説明している可能性があります。
アプリケーション
特定のアプリケーションのみが失敗し、UDL ファイルが成功した場合は、ドライバーの問題であるか、アプリケーションの接続文字列が正しくない可能性があります。 アプリケーション開発チームまたはサード パーティベンダーに接続文字列を確認してもらう。 www.sysinternals.com
からプロセス エクスプローラーを使用して、顧客が不明な場合に使用されているドライバーを確認できます。
キャプチャするトレース ツール
クライアントとサーバーのネットワーク トレースをキャプチャします。 クライアントとサーバーの両方で同時に SQL トレースを実行します。
NCAP ドライバー WireShark をインストールして、クライアントとサーバーが同じコンピューター上にあるときにトレースします。
組織には、関与できる独自のネットワーク インフラストラクチャ チームがあり、キャプチャを実行するための推奨トレース ツールがある場合があります。 Network Monitor (NetMon.exe)または WireShark と互換性のある形式で保存されている限り、任意のツールを使用できます。 PCAP 形式が最も一般的です。
詳細
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。