Troubleshooting Connectivitiy #8 - エラー番号からわかる接続失敗原因 :エラー26

Article
01/17/2017

高橋理香
SQL Developer Support Escalation Engineer

みなさん、こんにちは。
このシリーズの前回のポストから2年半以上経過してしまいましたが、まだ書きたいこともあり、終了はしていません！今回は接続時のエラーのうち、特徴的なエラーであるエラー番号 26 と出力されている場合のトラブルシューティングについて紹介したいと思います。

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

エラー 26 の主な原因

SQL Server Browser サービスへの問い合わせが失敗した場合に発生するエラーです。

接続時に SQL Server Browser サービスを使用する仕組みについては、トピック "SQL Server Browser サービス" に説明がありますが、簡単に図解すると次のようになります。

この過程の ⑦ に到達する前に何かしら問題があった場合に返されるエラーが 26 のエラーです。そのため、主な原因は以下の通りです。

SQL Server Browser サービスが開始されていない。
ファイアウォールやルーター等で UDP ポート 1434 がブロックされている。
接続文字列に指定された接続先の名前解決に失敗した。
SQL Server Browser サービスが現在のインスタンスや待ち受けプロトコルの情報を取得できない。
(レジストリへのアクセス権限、不適切なレジストリ設定等)

なお、既定インスタンスは TCP/IP プロトコルでは TCP ポート 1433 で待ち受けるものであると既定で判断されるため、既定インスタンスへの接続時には SQL Server Browser サービスへのアクセスは行われません。そのため、名前付きインスタンスへの接続として処理されている場合においてのみ発生するエラーです。

エラー 26 発生時にまずは確認すること！

原因はともかく、接続を成功させることを目標とする場合には SQL Server Browser サービスへを利用しない接続手法を選択することがエラー 26 への対処となります。SQL Server Browser サービスを利用するのは接続先の SQL Server インスタンスの待ち受けプロトコルや待ち受けポート番号やパイプ名がわからない場合ですので、あらかじめサーバー側のそれらの情報さえ入手できれば、次のような方法で SQL Server Browser サービスを利用せずに SQL Server インスタンスに接続することができます。

接続文字列中に接続に使用するプロトコルや待ち受けのポート番号やパイプ名を明示的に指定する。
接続に使用するプロトコルや待ち受けのポート番号やパイプ名を指定した別名を作成し、接続文字列ではこの別名を使用する。

参考: Troubleshooting Connectivity #5 – セッション確立までの動作 - "名前付きインスタンスへの接続で SQL Server Browser サービスは必須か" のセクション参照

上記のような対処を採用できない (たとえばアプリケーションで使用される接続文字列の変更がすぐには行えないなど) 場合には、次の順番で設定等の不足の確認や対処を行います。

SQL Server Browser サービス起動状態の確認

サービスが起動していなければ名前付きインスタンスの待ち受けプロトコルやポート番号の情報は接続処理で自動的に得ることはできません。そのため、SQL Server 構成マネージャーで SQL Server Browser サービスの稼動状態を確認し、停止している場合にはそれを起動します。
SQL Server 稼動環境のファイアウォール設定や通信経路上のルーター等における通信許可/拒否設定の確認

SQL Server サービスへの問い合わせでは UDP ポート 1434 が使用されるため、ファイアウォールやルーターでこの UDP 1434 との通信がブロックされている場合には名前付きインスタンスの待ち受けプロトコルやポート番号の情報は自動的に得ることはできません。そのため、UDP ポート 1434 の通信が可能となるようファイアウォールやルーター等の設定を変更することが対処となります。
名前解決可否の確認SQL Server Browser サービスは起動しており、UDP ポート 1434 へのアクセスも可能であるはずであるにも関わらずエラーが発生する場合、名前解決に問題があって想定の SQL Server Browser サービスへの問い合わせが行われていない可能性があります。この場合にはまず最初に以下の切り分けを行います。以下の方法で成功する場合には、DNS の登録、もしくは、DNS への問い合わせに問題がないか確認し、その対処を行います。(nslookup コマンドで想定通り名前解決されているか確認するとよいでしょう。)
- 接続文字列中の接続先にホスト名の代わりに IP アドレスを指定する。
- Hosts ファイルに接続先の名前に対して正しい IP アドレスを指定する。
ローカルマシンからの接続、別のリモートマシンからの同じ接続先への接続試行可否の確認SQL Server Browser サービスは起動状態、UDP ポート 1434 へのアクセス可能、名前解決にも問題がないにも関わらずエラーが発生する場合、SQL Server Browser サービスが何らかの要因でリクエストへの応答を返せていないことが原因となっている可能性があります。この場合、SQL Server Browser サービスへのアクセスが必要となるような接続はどのマシンからも失敗することが想定されます。この場合には詳細な調査が必要となりますので、後述の「調査のために採取する情報」に記載の情報の収集の上、サポートへの問い合わせを検討ください。

調査のために採取する情報

エラー発生確認後の切り分け状況によりますが、原因箇所の特定を進めるにおいて必要となる情報の種類や採取手順は次の通りです。

A. 採取する情報の種類

BID トレース
ネットワークトレース
PortQry コマンド実行結果
ping や nslookup コマンド実行結果
レジストリ [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server] 配下の情報
システム情報
イベントログ
SQL Server エラーログ

B. 採取手順

B-1. 事前準備

<PortQry ツールの入手、配置> あらかじめ PortQry ツールをダウンロードし、アプリケーション稼動環境と SQL Server 稼動環境にコピーしておきます。

PortQry ツールを以下のサイトから任意のマシンにダウンロードします。
PortQry Command Line Port Scanner Version 2.0
SQL Server 稼動環境にダウンロードした PortQryV2.exe (自己解凍書庫形式) をのちに本ツールを実行する環境にコピーします。
PortQryV2.exe をダブルクリックで実行し、展開先のパスを指定して [Unzip] します。

<BID トレース採取の各種設定> SQL Server 稼動環境とアプリケーション稼動環境の両方で採取するため、両マシンにてそれぞれ準備を行います。
必要となる準備作業は、以下のブログに記載の 2-1 に記載の手順です。
HowTo: BID トレース – データアクセスアプリケーションのトレースを採取する

上記手順の 2-1-5 では、対象とする ETW プロバイダを以下の通り選択します。

SQL Server 稼動環境: SQLBROWSER.1
アプリケーション稼動環境: SQL Server への接続に使用するプロバイダ (*)

(*) たとえば .NET Framework のアプリケーションで System.Data.SqlClient を使用している場合や Management Studio で接続検証を行っている場合には System.Data.1 と System.Data.SNI.1 を選択します。

B-2. 事象発生時情報採取開始

<SQL Server 稼動環境での作業>

管理者権限のあるユーザーで Windows にログインします。
SQL Server Browser サービスを停止します。
BID トレース採取を開始します。
以下のブログの手順 2-2 に記載の手順を実行します。
HowTo: BID トレース – データアクセスアプリケーションのトレースを採取する
SQL Server Browser サービスを起動します。
以下のコマンドでネットワークトレース採取を開始します。

netsh trace start capture=yes tracefile=<出力先パス>

<アプリケーション実行環境での作業>

管理者権限のあるユーザーで Windows にログインします。
BID トレースの採取を開始します。(SQL Server 稼動環境と同様にブログの 2-2 の手順を実行します。)
ネットワークトレース採取を開始します。(SQL Server 稼動環境と同様のコマンドを実行します。)
エラーを再現させます。

B-3. 事象発生時情報採取終了

<アプリケーション実行環境での作業>

以下のコマンドでネットワークトレース採取を停止します。

netsh trace stop
BID トレースの採取を停止します。先のブログの 2-3 を実行します。

ネットワークトレース採取を停止します。実行するコマンドはアプリケーション実行環境と同じコマンドです。
BID トレースの採取を停止します。アプリケーション実行環境と同様に先のブログの 2-3 を実行します。

B-4. 調査用情報の収集

コマンドプロンプトを開き、PortQry を配置したフォルダに移動してから以下のコマンドを実行し、出力先に指定したファイルを収集します。

portqry -n <SQL Server 稼動環境のホスト名> -e 1434 -p UDP -l <出力先ファイルパス>portqry -n <SQL Server 稼動環境の IP アドレス> -e 1434 -p UDP -l <出力先ファイルパス>

以下のブログを参考に、イベントログ、および、SQL Server エラーログを収集します。
[SQL Troubleshooting] 第1回 : Tips – SQL Server エラーログとイベントログを採取する (SQL 2000 ～ 2014) Ver 2.0
以下のコマンドでシステム情報をファイルに出力し、そのファイルを収集します。

msinfo32 /report <システム情報出力ファイルパス>
レジストリエディタ (regedit.exe) を起動し、以下のキー配下の情報をファイルにエクスポートします。 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server]
先に採取した BID トレースをブログの 2-4 の手順で変換し、元の .etl ファイルと変換後の .csv ファイルを収集します。
先に採取したネットワークトレースを収集します。

<アプリケーション実行環境での情報収集>

コマンドプロンプトを開き、以下のコマンドを実行した結果をテキストファイルに保存、もしくは、スクリーンショットを取得します。

ping <ホスト名>ping -a <IP アドレス>nslookup <IP アドレス>nslookup <ホスト名>