August 25, 2014 at 10:44 pm
Comments posted to this topic are about the item SQL Server Service Engine fails to start after applying CU4 for SQL Server 2008 SP1
August 26, 2014 at 3:51 am
Not seen that one before. Another scary moment is when you update a cluster (e.g. SQL Server 2008R2 for the latest Security Patch). You log back in and it says something around that you have to be an administrator to gain access (even though you are). What it does in the background is it runs a script when you log in to complete the upgrade. Once that has completed it lets you log in as normal (can be a few minutes).
August 26, 2014 at 7:18 am
Thank you for sharing your experience with us. I think we all have been thrown by the last error we see when the actual problem turns out to be something completely different. Reminds me to look deeper into a problem before jumping to the wrong conclusion.
John
August 26, 2014 at 7:20 am
Finishing up scripts in the background without any notification to the user, that's nice Microsoft.
August 26, 2014 at 7:23 am
Definitely looking deeper before jumping to conclusions really helps. Staying calm is hard to do when you can't access your production environment. In this experience, the solution was pretty simple, I'm not sure why the default directory was change but it took me a while to figure this out since the error was a little deceiving. I wish I knew who changed the setting not really to point fingers but to share this experience.:-)
August 26, 2014 at 7:25 am
Another kind of gotcha is if you logged into the Cluster or a Always On using the shared name rather than the individual node name and do an update. As when it flips over, you will be 'thrown off' (the other machine aquires the shared name), but the update is of course still running, you just need to jump back to the machine using its individual name.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply