Some clients cann''t connect to QSL server after restarting SQL service

Question

Some clients cann''t connect to QSL server after restarting SQL service

Viewing 9 posts - 16 through 23 (of 23 total)

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

Vidas Zabinskas Hall of Fame Points: 3258 More actions · Answer 1

John,

I guess my boss will not like me saying "you know it was one of those things" I've read a lot of Microsoft KB where was written a lot of info about "SQL server doesn't exist" error and nothing! The two main things

1. one part of the clients could work while other one not

2. and all became fine after restarting the physical node

make worthless all my readings. Do someone have such info where I could find the priciple of ALIAS operation?

VIdas

John Mitchell-245523 SSC Guru Points: 148809 More actions · Answer 2

Vidas

If you can find the answer to question 1, it may lead you to the answer to question 2. But I'm afraid you're going to have to do some work on this yourself. So, one user could connect but his neighbour couldn't. What is the difference between those two? Are they on different VLANS? Do they use different authentication methods? If some of the users are using Windows authentication, get your network administrator to check the domain controller and DNS server logs.

You say you have two active nodes - do they do the same thing? Maybe some users are connecting to one SQL Server instance and some to the other?

I don't know what you mean by alias operation.

John

Tom Goltl SSCertifiable Points: 5815 More actions · Answer 3

If I remember right the SQL Server Service Manager is not a cluster aware application. You have to use the cluster manager to stop and restart the nodes on the cluster. It's been a while but I think you have to take the services from that machine offline with the cluster manager and then restart with the SQL Server Service Manager. I think you're lucky/it was a fluke that anyone could connect after you restarted. The cluster service probably lost itself when the node went down and it couldn't bring it up on the other node. I have not worked with clustering in a while, but you have to use the cluster aware tools to control those services.

Tom

Vidas Zabinskas Hall of Fame Points: 3258 More actions · Answer 4

John

Our cluster consist of two active nodes which holds two databases (one database per server). One of these DBs must be online 24x7. Users connect to it all the time and I had that problem exactly with this sql server which holds this one.

Now I'll try to bring some clarity about ALIAS what did I mean. I would like to find out why do we need to configure client network utility and server network utility and how does they work. When we configure them we create server alias or like virtual names, wich are used by clients when they connect to server. Maybe do you have some usefull links regarding to this info

Vidas Zabinskas Hall of Fame Points: 3258 More actions · Answer 5

ALZBA

Do you have any links to official MS sites which could prove that fact?

Yelena Varshal SSC-Dedicated Points: 34286 More actions · Answer 6

Hi,

I had a similar case some time ago:

- Restarted SQL Server, but not the Windows Server.

-Some clients could connect and some could not

-Rebooted Windows Server, everyone is happy.

This is what happened by SQL Server log: when I restarted SQL Server service it came up without TCP/IP protocol on port 1433 by the startup messages in SQL Server log "Listening on....." It happened because during the startup this port was already busy according to the Event Log. It is my assumption it was busy with the process that made me to restart SQL Server Service for the first place. So Named Pipes clients were connecting OK while TCP/IP clients were not able to connect.

So I rebooted the whole server and everything was fine, SQL Server came up with TCP/IP on 1433 and everyone could connect.

Regards,Yelena Varsha

Vidas Zabinskas Hall of Fame Points: 3258 More actions · Answer 7

Yelena,

The messages "SQL server listening on xx.xx.xx.xx: 1433." and "SQL server listening on TCP, Shared Memory, Named Pipes." were in the SQL server log. I've checked that after reading http://support.microsoft.com/kb/328383/. DO you have any other thoughts?

Vidas

John Mitchell-245523 SSC Guru Points: 148809 More actions · Answer 8

Vidas

A few things here:

(1) It is OK to start and stop SQL Server 2000 using Enterprise Manager or SQL Server Service Manager, even on a cluster. The Microsoft documentation verifies this. Like I said, I use Cluster Administrator anyway.

(2) You're putting yourself at risk from hackers if you don't change from the default port of 1433, especially if your server is web-facing.

(3) Are your two instances of SQL Server configured to listen on different ports?

(4) You use an alias in the client network utility in order to specify certain connection parameters, for example a non-default port number, or an IP address if the name isn't resolved by DNS. Use the Server Network Utility to configure network libraries - the most common ones are TCP/IP and Named Pipes. Books Online has plenty of information under SQL Server Client Network Utility in the index.

John

Vidas Zabinskas Hall of Fame Points: 3258 More actions · Answer 9

John

>(2) You're putting yourself at risk from hackers if you don't change from the default port of 1433, especially if your server is web-facing

We accept connections from clients only in the our LAN limits

>(3) Are your two instances of SQL Server configured to listen on different ports?

Yes, they are different.