Post reply

Named Pipes vs TCPIP

  • November 15, 2006 at 8:58 am

    #62674

    I have a third party app for which I support. The db server was restarted over the weekend (SQL 2000 Win2000 4 way box 3 GBs of RAM) and ever since than, the end users have been complaining its really slow. Users login via a terminal server connection to the db. When I look at the current activity/process info I notice that all open connections are using Named Pipes as the connection Network Library. I can't seem to force the terminal servers to use TCP/IP. Even from my own workstation, I setup the client connection utility to use TCP/IP for this server but it still opens up a named pipes connect. I checked the sql server logs when the system was brought back up and it says that the server is listening properly on TCP. I don't know if this is causing my slowdown or not.

  • November 15, 2006 at 9:20 am

    #672021

    Are you able to make a connection to the SQL Server using <server name>,<port number>? When you run a netstat -an on the SQL Server, do you see it listening on IP 0.0.0.0 on the port?

    K. Brian Kelley
    @kbriankelley

  • November 15, 2006 at 9:29 am

    #672024

    I am not much of an IP guru so I am not sure what I am looking for. The only local address I see running on port 1433 is... 127.0.0.1:1433 and the foreign address for this is 0.0.0.0 and the state is listening. From my client machine, I can not connect using <server ip>:1433. Returns as invalid connection.

  • November 15, 2006 at 9:39 am

    #672031

    You should be seeing a local address of 0.0.0.0:1433 and listening, unless this is a virtual node on a cluster, in which case you'd see the IP address for the virtual node. Can you telnet to the server IP address and port 1433 (telnet <server IP> 1433)? You won't get anything back if you can successfully connect, just the command prompt will go blank. If you don't successfully connect, you'll get back:

    Connecting To <server IP>...Could not open connection to the host, on port 1433: Connect failed

    K. Brian Kelley
    @kbriankelley

  • November 15, 2006 at 9:41 am

    #672035

    Also, when using a client to connect to SQL Server, use the comma (,) and not the colon ( to distinguish port, if you didn't do so already. Not sure why MS decided to be different, but they did.

    K. Brian Kelley
    @kbriankelley

  • November 15, 2006 at 10:05 am

    #672051

    Oddly enough, I still can't connect using <server ip>,1433 nor can I telnet into the server using port 1433 but........ after a restart, the client connections from the TSs are now connecting via IP.... Huh???

  • November 15, 2006 at 10:12 am

    #672054

    What it likely means is some process had temporarily grabbed 1433 when the server restarted. As a result, SQL Server wasn't able to fully setup listening on 1433. The restart fixed that.

    K. Brian Kelley
    @kbriankelley

  • November 15, 2006 at 10:32 am

    #672056

    Thanks for all your help!!! Performance is back to normal.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply