October 24, 2005 at 11:23 pm
Hi,
SQL Server running in my network is online 24 Hours, but users are now complaining that they can't connect to this server in the morning, until someone restart the server. Additionally, SQL Server takes backup regularly in late night hours on another server. Any suggestions about this network problem?
Thanks in advance,
Govind.
October 25, 2005 at 6:08 am
I would not be so hasty to assume this is a network issue! You mention that re-starting the SQL Server corrects the problem!!!! You mentioned backups as well, and this type of activity could cause the SQL Server to become un-responsive. The point I am trying to make it find out exactly when this un-responsiveness is taking place so you can monitor the server during this period using sp_who2 and perfmon for a few examples. Also you need to outline when all your maintenance is running and if it overlaps (DBCC's, Re Indexing, Update Statistics, sp_recompile, backups, and application processes). This may be dependant on hardware, but if you find backups, and other maintenance running at the same time this is more than likely your cause. Do not rule out batch process from the application as well as poor code being a cause as well.
If you have not done so (I hope you are doing maintenance outside of backups):
Define the maintenance that is taking place and document the window needed to accomplish it.
Work with the business units to integrate maintenance into the application.
You may find this is indeed a network issue, but I would do my homework first before you get a bloody nose!
October 26, 2005 at 7:38 am
One way to see if this is a network issue is to have the users who can't connect to the server, do a "ping" to the server. This will indicate if there is a network problem between the user's PC and the server.
To do a "ping" on a Windows PC:
1) Start -> Run
2) Type "ping SERVERNAME" [where SERVERNAME = the name of the SQL server] and hit ENTER (a DOS COMMAND window will open).
If the network is up, this command will return output similiar to the following: Reply from ###.##.#.###: bytes=32 time<1ms TTL 127
I have seen instances where a "ping" to the server will "wake up" the server and SQL connections resume.
Hope this helps.
Norene Malaney
October 26, 2005 at 12:05 pm
In addition to pinging by IP, I'd also try using the servername and the fully qualified servername. If either of these fail it may be a network DNS /WINs issue. Also, when pinging by IP address try one with a '-a' parameter. If this fails to provide an IP address then again, you;ve probably got a DNS issue.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
October 26, 2005 at 1:50 pm
I would first take a look in the Event Logs on the server to see if there is any error or warning messages. I would verify that the SQL Server machine is running well when users are trying to connect and can not. You have to see if there is any process that consumes all server memory or CPU that very well may be because the connections are fine after server reboot. It could be some DTS process or incorrectly written report that starts at night and consumes resources. I have seen both cases in the past. I also would see if you can ping something else from the server machine when logged locally when you can not connect to it (check outbound connections)
Try if you can connect using Terminal Services.
Let us know.
Yelena
Regards,Yelena Varsha
October 26, 2005 at 10:13 pm
Hi All,
Before posting this Q, i've done all such routine inquires like: event logging, pinging, map-sharing and even i'd restarts my client stations. But the only way to resolve this issue for now is to restart the main server
But I am very sure this happens because of heavy data transmissions (Backup on dip time). Regarding simultaneous processing on server while taking backup: no the server is used to be idle while it takes the backup. But let me investigate further.
Thanks for giving time our my query.
Regards,
Govind.
Thanks for
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply