本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「特定のサーバからのみSQL Serverへアクセスできない場合の対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、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」)を確認しても、関連すると思われるエラーは記録されていなかった。
エラーメッセージには「キューがいっぱいなため、ソケット操作を実行できませんでした」とあります。まず、netstatコマンド(*1)でTCP接続に関する状況を確認してみます。
netstat -nao
状況を確認すると、かなりたくさんのプロセスがTCPポートを使用していました(図14-2)。
クライアントが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
ユニアデックス株式会社所属。Microsoft MVP Data Platform(2011〜 )。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を行っていた。2016年4月よりIoTビジネス開発の担当となり、新しい仕事に奮闘中。ストレッチをして柔らかい身体を手に入れるのが当面の目標。
ユニアデックス株式会社所属。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
Copyright © ITmedia, Inc. All Rights Reserved.