March 20, 2012 at 4:02 am
we have a sql 2008 shared cluster server (50-60 applications use it) and a new app requires SP1 + CU2. we are currently on SP1. is there any added risk in going to SP3 or SP3 + the latest CU? some external consultants seem to think that the amount of fixes between SP1 and SP3 expose us to potentially more problems with an update to SP3. i'm not sure i buy that. the consultants are also recommending QA testing of the service pack for all applications but this is not really practical. we have many applications that require front-end application servers for which we do not have a comparable QA server to test with.
it would be interesting to know some of your policies on service pack updates. do you routinely update to the latest or not update unless there is a specific problem. and for service pack updates, do you test apps on a QA server first?
March 20, 2012 at 4:37 am
All changes to SQL Server require in depth testing of every application before the change is made live.
Without testing you're guessing that it'll all work. That's not good enough in any industry that I've worked in; you can't guess, you must know.
March 20, 2012 at 5:48 am
Hehe, I must have worked in some different industries then. 😛
There are obviously some industries/applications where it's important to throw thousands of man hours at each windows security update and patch, but they're few and far between when you do analysis on the cost of doing so vs the risk of problems.
I'd go to SP3 as it solves a few important issues that I've hit (mainly the OPTION(RECOMPILE) bug). SQL SP's work quite hard not to introduce functional change. I tend to read through the known issues, stick the SP onto the most used test environment first and release a few weeks later, but not go through any major regression testing specifically for it.
I'd not apply CU's unless there was a specific bug I was hitting.
March 20, 2012 at 6:08 am
Service packs we would routinely install on Dev and QA systems as they came out. We'd then be able to get a decent evaluation if they were problematic without having to go through an official testing cycle. Usually after a few weeks in Dev, we'd roll the SP out to production during a maintenance window.
CUs would only be applied if we knew we had a bug that they addressed.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 20, 2012 at 12:21 pm
I don't know how you can test every app if you don't have a non prod environment for some. However, applying a CU or a SP you should test no matter what. About all I can say is that you go with SP3. One reason is that if you have a problem and call MSFT for assistance they won't help you being on SP1 CU6... AND there is a security patch MS11_049 that is just below SP3 so you really should get to that version.
March 21, 2012 at 1:24 am
thanks for the comments, guys.
i will go to SP3 and do some weeks worth of testing on some test servers that we have. across these test servers are hosted about 50% of the apps that are hosted on the prod server. the amount of time and money to test the other 50% would be enormous. as long as we have a good rollback plan then it should be fine.
speaking of rollback plans - has there been any discussion of botched SP3 installations and/or failed uninstalls?
March 21, 2012 at 5:11 am
Same process as any rollout or upgrade, you have a solid set of tested backups. The key word in that sentence is tested. Other than that, since the old days of SP2 & SP2a (think I got that right) in SQL 2000, we just haven't seen many total cock-ups due to SPs. I've seen a few when we tried to put the latest SP on SQL Server on an OS that was running a very old version. Had to update the OS first, but that was the recovery. Still, paranoia is not a bad thing here.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply