Some notes about the SQL Server Service Pack Installation Engine. I like it – a lot. The new engine goes to great lengths to prevent my having to bounce a physical server to apply a service pack. No matter how you slice it, it takes less time to stop and restart a service than restart the server.
You will reach a point in the installation where a dialog similar to the following displays:
If I were to suggest one change for the SQL Server Service Pack installer, I would suggest disabling the Next button until the check is complete on this “Checking for locked files” screen. A lot of people have been conditioned by disabled buttons to click-if-it’s-enabled. So they see the Next button available and just click through this step. The step allows you to do this and stops the check for locked files. However…
- Some Service Pack (or hotfix) patches may not be applied as a result.
- You may be required to reboot the server to complete the Service Pack (or hotfix) installation.
So for now, no blindly clicking the Next button!
When locked files are discovered the dialog displays something like the following:
My advice: Stop here, open the Services console and stop each of the identified services manually. After each has been stopped, click the Refesh button and you should see the next screenshot:
If you do not see this screenshot, you haven’t stopped all the impacted services. Rinse and repeat until you get a “No locked files found” message. Then click the Next button.
As installation progresses you will see a screen similar to the following:
This screen shows you what’s being updated and gives an indication of progress. Progress indications good.
When the Installation Progress indicates all is complete, click the Next button to proceed. A summary displays all SQL Server-related services and their Service Pack / HotFix disposition:
Be sure to restart the services you manually stopped before proceeding!
This explains why some service pack installations don’t “take.” If you believe you’ve installed an SSIS SP, for instance, but are still seeing that pesky issue that was supposedly resolved, this could be why.
:{> Andy
I agree with all of your comments if the instance is is not clustered. However, we’ve had innumerable headaches trying to install service packs for clustered instances. We haven’t found a consistent manner of application that ensures that the service pack will install correctly. I personally had a situation after an upgrade where if the instance was on one node it reported that it was SP2, but on the other it was RTM. I think there’s some work to be done on this.
Hi Ben,
You are correct: This post is about non-clustered instances of SQL Server. That’s an important distinction. Thanks for pointing it out.
:{> Andy
I’ve actually had much better luck on clusters with SP2 and post-SP2 hotfixes. SP1 was very hit or miss… mostly miss. I had the exact same issue that Ben Thul described… one node reported SP1, the other RTM. So, we tended to favor the SP1 node, obviously, failing back over to it whenever we had an incident that should have only incurred a single failover. On that cluster the situation was resolved by SP2 (though in hindsight I don’t know how or why it worked so smoothly).