特定のサーバからのみSQL Serverへアクセスできなくなった（起動トラブル）：SQL Serverトラブルシューティング（19）

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

トラブル 14（カテゴリー：起動）：特定のサーバからのみSQL Serverへアクセスできなくなった

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。

トラブルの実例：特定のアプリケーションサーバからのみSQL Serverへ接続できなくなった。もちろん、SQL Serverには何も変更を加えていない。

　表示されたエラーメッセージには「SQL Serverへの接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできません。インスタンス名が正しいこと、およびSQL Serverがリモート接続を許可するように構成されていることを確認してください。 (provider: TCP Provider, error: 0 - システムのバッファー領域が不足しているか、またはキューがいっぱいなため、ソケット操作を実行できませんでした。) (Microsoft SQL Server、エラー: 10055)」と、接続できなかった旨が記載されていた（図14-1）。ちなみに、Windowsのアプリケーションログ（「イベントビューアー」→「Windows ログ」→「Application」）を確認しても、関連すると思われるエラーは記録されていなかった。

図14-1　特定のアプリケーションサーバからのみSQL Serverに接続できないエラーが発生

トラブルの原因を探る

　エラーメッセージには「キューがいっぱいなため、ソケット操作を実行できませんでした」とあります。まず、netstatコマンド（*1）でTCP接続に関する状況を確認してみます。

netstat -nao

　状況を確認すると、かなりたくさんのプロセスがTCPポートを使用していました（図14-2）。

図14-2　たくさんのプロセスがTCPポートを使用していた

　クライアントがTCP通信を行う際は、多くの場合、Windows Serverから動的ポートが割り当てられます。Windows Server 2008以降では、標準で「49152〜65535」が動的ポートの範囲として設定されています。プロセスが使えるポート番号を全て使い切ってしまったら、新たなポート番号が割り当てられなくなります。ポート番号が割り当てられなければTCP通信は開始されず、結果としてSQL Serverに接続できません。

　今回の例では、アプリケーションサーバの動的ポートが枯渇してしまったことが原因と推測されます。

解決方法

　このトラブルの解決方法は、「クライアント（本例ではアプリケーションサーバ）が使用するTCPのポート番号をきちんと確保する」ことです。不要なプロセスを終了して使えるポートを確保する、あるいはnetshコマンドで、使える動的ポートの範囲を広げる手段があります（*2）。

netsh int ipv4 show dynamicport tcp

netsh int ipv4 set dynamicport tcp start=45536 num=20000