February 18, 2008 at 11:19 am
Ok, a client calls this morning and says he's seeing a database error when hitting his asp.net site. I confirmed this and saw the error had to do with the login failing for the database user defined in the connection string. I checked the web.config and confirmed it hadn't been changed and tried to create a local UDL file to try and connect with that user. The UDL connection also failed. So I'm thinking the client must have changed the database user password but he insists he did not. He also claimed to have logged in using SQL Studio while the site was down with that same user. So at this point I'm convinced that the password must have been changed so I reset it to what it was. I try my UDL file and it now connects. I try refreshing the web site and it's still failing. So I then force a save of the web.config file to force a asp.net recompile (this is an asp.net site using the Ent Lib Data Access framework) and then the site comes back up.
The previous night updates were run and the sql server was rebooted. We checked the management logs in SQL and could see the line items where each database was being started up. We noticed that this site in particular registered a login error after the reboot but before the database was started up. My question is why would the failed connection see, to stick even after the database was then started secs or mins later.
I may be barking up the wrong tree but it seems to me that the fact that the website attempted to connect to the database before the database was started up was the cause of this issue. Just not sure why or how to prevent this in the future. Unless it's best practice to restart the web servers after a restart of the sql server. Btw I am a dev and not a DBA.
February 18, 2008 at 3:51 pm
Best practice would be to stop the web services before rebooting the SQL Server then restart them afterwards. You're basically yanking the rug out from under the app's feet.
At the very least, after restarting the SQL Server, restart the Application Pool that connects to the DB. Not sure if that can be scripted or not. If not, just restart the WWW service (that can be scripted).
MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
February 18, 2008 at 4:17 pm
OOOOO, I can answer this one.
Most likely issue:
The front end had a connection to the database. The server gets rebooted, but the front end is still trying to connect. The server comes up, but not the database, and the front end is still trying to connect. Finally the database comes up and the front end should be able to connect.
User issues. Many times a user will leave an application open on their desktop with a connection to SQL Server. Then they change their password. Their application is still connecting with their old password. While they should ALWAYS close applications when they aren't being used - we know that won't happen - they should be reminded that when they change a password they close, re-open, and log back in.
We usually ask people to reboot their computer as we deal with a few who have several apps open and will only close out of one and still wonder why they have problems.
-SQLBill
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply