SQL Serverのサービスが起動しない：その1（起動トラブル）：SQL Serverトラブルシューティング（66）（2/2 ページ）

解決方法

　今回のトラブルは、SQL Serverが確保するポート番号を他のプログラムが既に使っていたため、起動できなかったことが原因でした。

　今回のシステムではセキュリティ対策のために、SQL Serverのポート番号を規定値から変更していました。この番号が他のプログラムとバッティングしたものと考えられます。どのプログラムと競合したかは、netstatコマンドを使って調査できます（図2）。再起動後に復旧した理由は、再起動時にポートの確保が重複しなかったためだと考えられます。

図2　netstatコマンドでポート番号を確認した　IPアドレスの直後にポート番号が表示されている。50000番を使っていたプロセスのIDは9748だった。

　TCPを利用したソケット通信をする場合、一般的に知られているプロトコルに対して、IANA（Internet Assigned Numbers Authority）という米国の団体がポートを割り当てて管理しています。中でも0〜1023番はウェルノウンポートと呼ばれています。

　しかし、ポートが実環境で実際に割り当てられることを保証しているわけではありません。そのため、今回のようにポートのバッティングを起こすことがあります。

　TCPのソケット通信を行う場合、ポート番号を指定しない場合には、49152番以降のポートで空いている番号を使います。今回はその中の50000番を利用していました（図3）が、先行して起動したプロセスが既に使用中でした。

図3　SQL Serverが利用するポート番号の設定画面

　今回の問題が再発しないようにするためには、次のような対策を採ります。Windowsのサーバ管理用コマンドとして実装されている「netsh」を用いて、ポートを予約済みにします（図4）。正確には、あるレンジのポートを動的ポートとして確保されないようにする設定です。

図4　ポート予約とSQL Serverのポートを固定する方法　netshコマンドを使って50000番ポートの動的ポート確保除外を設定した。