SQL 2000 Cluster Network IP change
There is a known issue with SQL 2000 Cluster when you change IP address on the cluster. Some registry keys do not get applied with correct data. You must follow the instructions provided by Microsoft for SQL 2000 and secondly and very important.. YOU MUST USE THE SQL 2000 CD when you change IP. You cannot do it over network. This has caused many problems at our site, until yesterday when we successfully updated SQL 2000 cluster with new IPs. We got one small snag though. We got an error message:
2009-03-18 00:22:15.17 server SuperSocket Info: Bind failed on TCP port 1433.
2009-03-18 00:22:15.34 server SQL server listening on Shared Memory, Named Pipes.
2009-03-18 00:22:15.34 server SQL Server is ready for client connections
Microsoft has a work around for this but that's now what we did. Our server admin looked in the log for the cluster and found that a registry key was not updated with new IP. He copied the data from the hive and then we were good. Just to summarize, this error means SQL port is being used by another application. I ran nmap to see if it was actually used and no it wasn't. However, after the manual intervention, all was good. Here is a sample of what it should look like:
2009-03-18 01:37:19.87 server SQL server listening on 10.1.1.111: 1433.
2009-03-18 01:37:19.89 server SQL server listening on TCP, Shared Memory, Named Pipes.
2009-03-18 01:37:19.89 server SQL Server is ready for client connections
See the difference? It is not obvious unless you trying to use ODBC. SQL will still run but any application using ODBC will not be able to connect to database. You can all try to test this by logging in to Management studio with:
tcp:10.1.1.111,1433
if doesn't work, check in the log to see the message "listeningon TCP".
Enjoy.
2009-03-18 00:22:15.17 server SuperSocket Info: Bind failed on TCP port 1433.
2009-03-18 00:22:15.34 server SQL server listening on Shared Memory, Named Pipes.
2009-03-18 00:22:15.34 server SQL Server is ready for client connections
Microsoft has a work around for this but that's now what we did. Our server admin looked in the log for the cluster and found that a registry key was not updated with new IP. He copied the data from the hive and then we were good. Just to summarize, this error means SQL port is being used by another application. I ran nmap to see if it was actually used and no it wasn't. However, after the manual intervention, all was good. Here is a sample of what it should look like:
2009-03-18 01:37:19.87 server SQL server listening on 10.1.1.111: 1433.
2009-03-18 01:37:19.89 server SQL server listening on TCP, Shared Memory, Named Pipes.
2009-03-18 01:37:19.89 server SQL Server is ready for client connections
See the difference? It is not obvious unless you trying to use ODBC. SQL will still run but any application using ODBC will not be able to connect to database. You can all try to test this by logging in to Management studio with:
tcp:10.1.1.111,1433
if doesn't work, check in the log to see the message "listeningon TCP".
Enjoy.
Comments
http://www.sqlservermasters.com/