今回のトラブルは、SQL Serverが確保するポート番号を他のプログラムが既に使っていたため、起動できなかったことが原因でした。
今回のシステムではセキュリティ対策のために、SQL Serverのポート番号を規定値から変更していました。この番号が他のプログラムとバッティングしたものと考えられます。どのプログラムと競合したかは、netstatコマンドを使って調査できます(図2)。再起動後に復旧した理由は、再起動時にポートの確保が重複しなかったためだと考えられます。
TCPを利用したソケット通信をする場合、一般的に知られているプロトコルに対して、IANA(Internet Assigned Numbers Authority)という米国の団体がポートを割り当てて管理しています。中でも0〜1023番はウェルノウンポートと呼ばれています。
しかし、ポートが実環境で実際に割り当てられることを保証しているわけではありません。そのため、今回のようにポートのバッティングを起こすことがあります。
TCPのソケット通信を行う場合、ポート番号を指定しない場合には、49152番以降のポートで空いている番号を使います。今回はその中の50000番を利用していました(図3)が、先行して起動したプロセスが既に使用中でした。
今回の問題が再発しないようにするためには、次のような対策を採ります。Windowsのサーバ管理用コマンドとして実装されている「netsh」を用いて、ポートを予約済みにします(図4)。正確には、あるレンジのポートを動的ポートとして確保されないようにする設定です。
ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP for Data Platform(2011〜)。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。
ユニアデックス株式会社所属。Microsoft MVP for Data Platform(2017〜)。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
Copyright © ITmedia, Inc. All Rights Reserved.