August 6, 2008 at 3:01 pm
Here's the situation: I'm getting ready to build two new SQL 05 instances, both for third party applications. One will be an in-place upgrade from SQL 2K and the other will be a brand new server.
My question is this: should I apply cumulative updates as a matter of course? And if so, which one? CU8, because it's the most recent, or something older that might be a little safer?
Our only other production instance of SQL 05 is at 9.00.3054.
Based on what I've found online, the conventional wisdom seems split.
One school of thought says that you should apply the next most recent Cumulative Update on a regular basis. After all, SP2 is no good w/out further updates, and we'll likely be waiting a looooong time for everything to be rolled up into SP3.
The other side says don't install them unless you absolutely must, and then only after testing. This is basically the warning from MS and it makes sense because (if I understand this correctly) service packs are regression tested and cumulative updates are not.
Both arguments have merit, but neither one points to an obvious answer in my case. I've had a couple minor issues on our existing 9.00.3054 box that seemed to call for a hotfix, but I was scared off by the disclaimers - the issues were fairly minor and the workarounds seemed easier than obtaining and testing a hotfix for a production server.
But for the new servers I'm leaning towards applying a recent CU. My reasoning is that I've wanted a hotfix before but it was too inconvenient to apply one, so I might as well install a Cumulative Update while I have the chance (i.e. while I already have scheduled downtime and we'll be testing for/against SQL 2005 anyway). Is this approach asking for trouble, or being proactive?
Also, can CUs be uninstalled individually, or would I have to completely uninstall and reinstall to fall back to 9.00.3054?
Many thanks,
--MIJ
August 6, 2008 at 4:08 pm
We have been pretty stable on our production box using CU7 (build 9.0.3239.0). We haven't gone to CU8 because it didn't seem like there were enough things to warrant an upgrade on that one, so I can't speak to that update. We were having several performance issues before we went to CU7 so we are pretty happy with it.
August 6, 2008 at 4:18 pm
I have all ten of my SQL Server 2005 instances using CU7 (build 9.0.3239) and have not had any issues.
Has anyone had any issues with a Cumulative Update?
-----
James Cornell
Kainell Database Specialists
http://www.kainell.com
August 6, 2008 at 4:39 pm
So that's two votes for CU7. Thanks, guys.
James, did you apply the CU just to have a recent update, or were there specific issues that CU7 was intended to fix (like, for example, the performance issues mentioned by hill4m)?
Also, are either of you running Reporting Services? (probalby should have mentioned that we will be using SSRS in my original post)
August 6, 2008 at 4:43 pm
It started out for a specific issue on two instances but then I ended up applying to the rest after testing in dev. Three of the instances are running Reporting Services.
-----
James Cornell
Kainell Database Specialists
http://www.kainell.com
August 7, 2008 at 12:50 pm
Excellent. Thanks for the reply.
Last follow-up question: I notice that there are two installation files, one for the CU and one for the SQL Native Client. I'm assuming they should both be installed, right? I can't find any reason not to run the SQL Native Client update as well, but maybe there's a reason they're separate...
August 7, 2008 at 12:57 pm
The purpose for them being separate is so that you can install the Native Client update on client machines. We were having some issues with client machines using an Access application attached to the SQL Server and had to update the native client as well to fix some of the issues. I don't believe you have to install the native client as well. I think that the cumulative update will update this already.
August 7, 2008 at 3:04 pm
hill4m (8/7/2008)
The purpose for them being separate is so that you can install the Native Client update on client machines. We were having some issues with client machines using an Access application attached to the SQL Server and had to update the native client as well to fix some of the issues. I don't believe you have to install the native client as well. I think that the cumulative update will update this already.
OK, that makes sense that there would be a separate install for clients and only one install for the server. Although after installing the CU I don't know what I'd look for to tell if it changed or not (the sqlncli.dll appears unchanged). But anyway, just to be clear, I shouldn't need to touch any client PCs (with the native client installer) unless there's a problem (please correct me if that's wrong).
Thanks again for your help.
August 7, 2008 at 3:22 pm
MIJ (8/7/2008)
OK, that makes sense that there would be a separate install for clients and only one install for the server. Although after installing the CU I don't know what I'd look for to tell if it changed or not (the sqlncli.dll appears unchanged). But anyway, just to be clear, I shouldn't need to touch any client PCs (with the native client installer) unless there's a problem (please correct me if that's wrong).Thanks again for your help.
The SQL Native Client for CU7 is 2005.90.3042.00. I believe in this latest CU, the native client was not changed so you may have already had the latest native client. You can go into the ODBC Data Sources in Control Panel and check the Drivers tab to check the version number. We have only updated the client PC's native client if they have had issues, so some of the client PCs do not currently have the latest version and some do. If you see a specific user having issues with the application, you can try upgrading their native client to make sure that isn't the issue. I try to keep the latest native client on my PC so that we can test it and already have it downloaded in case someone does have an issue.
August 7, 2008 at 3:42 pm
hill4m (8/7/2008)
The SQL Native Client for CU7 is 2005.90.3042.00. I believe in this latest CU, the native client was not changed so you may have already had the latest native client. You can go into the ODBC Data Sources in Control Panel and check the Drivers tab to check the version number.
Great, that matches what I'm showing on our new install, so we must be all up to date. I was looking at the file properties version number of the dll before and it didn't change. It's the same number, but seeing it in the ODBC Data Source admin puts it nicely in context.
Thanks,
MIJ
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply