March 26, 2011 at 1:18 pm
Comments posted to this topic are about the item Patch Week
March 26, 2011 at 9:06 pm
Interesting editorial Steve, and one that is nicely timed for me.
I got into an argument with an Architecture guy during the week who was asking why I wasn't applying CU to the Production servers. My reasoning for not doing this was because of this continued message MS post on the CU pages "Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2008 service pack that contains the hotfixes in this cumulative update package. "
I'd be interested in hearing how many people apply CU and those who don't.
March 27, 2011 at 11:25 am
I think it's split. I know a number of people that apply CUs regularly, but it seems MS is trying to slowly get away from SPs. We have CU #13 without a new Service Pack CTP, which makes me think they're not putting many resources into SPs.
At the same time, we have CU6 for R2 and no CTP for the first Service Pack. Granted the RTM quality of R2 was very high, IMHO, and I don't see any large issues that people need to address, but there have been a lot of minor fixes and a rollup is needed.
March 27, 2011 at 1:17 pm
+1 to the "not a fan of the CU vs. SP release schedule" camp.
As already mentioned, it appears that the Service Pack release schedule plays second fiddle to the Cumulative Updates. I don't have the time to test the CU's against the many custom apps our company uses and few of the 3rd party app vendors we use do either. One unwritten rule had been to not upgrade to the next SQL release until SP1 came out, but the delay & unpredictability of that update has made that rule too painful to swallow.
That said, the apparent stability of 2008 R2 is top-notch and I generally regarded it as a SP for SQL 2008 anyway, so that jump was easier to make. In my experience, 2005 was a very stable and mature product too... almost all the concerns I needed addressed via. updates or service packs were because of UI issues or immature products like Reporting Services.
My main beef with the "new" update, service pack & SQL product release schedule is that shows a general disregard of real-world usability and maintenance. "Real-world" DBAs are not in the business of testing product updates; we're tasked with delivering data to our business users, helping our application developers build better & more efficient tools and ensuring the integrity of the data and hardware under our watch. If a feature is going to be changed from one release to the next, be sure the new version is actually more useful, not just more integrated or pretty looking.
March 28, 2011 at 6:10 am
I continue to go with the earlier post that Microsoft recommends only installing CU's if you experience an issue that the CU fixes. I have too many SQL Servers running to patch them all with every CU that comes out.
I will say though that when I build a new one I usually install it with the latest SP and CU that exists just so it starts out at the highest build level. The initial testing of putting it into use will flush out any issues.
March 28, 2011 at 6:58 am
When you have a large number of instances to support patching them all every 8 weeks is out of the question. we don't have the DBA resources and the business would not accept the outages.
Service packs please.
---------------------------------------------------------------------
March 28, 2011 at 7:20 am
george sibbald (3/28/2011)
When you have a large number of instances to support patching them all every 8 weeks is out of the question. we don't have the DBA resources and the business would not accept the outages.Service packs please.
I AGREE! I have a difficult enough time keeping up with service packs. I am way behind on that. With all of the purchased apps we have we have to have the software company first come out with a version of the software that is certified on the new service pack. Then, once all of the different databases on that SQL Server have new versions of that software implemented then and only then can we upgrade to the next service pack. This can take a very long time. Some software companies I talk with don't even know what CU's are.
March 28, 2011 at 9:03 am
If MS wants to go with the CU approach, then MS should design the system such that CU's can be applied (and rolled back!) realtime, without any outage. Preferably include a trivial way to automate this from the command line, as well, perhaps even with a built-in one-off scheduler (i.e. "2008SP2CU4 /runat:20110329030000")
FYI: Novell Netware allowed kernel changes to be made while the system was up and under load decades ago; as I understand it, so do mainframes.
March 28, 2011 at 5:44 pm
Steve Jones - SSC Editor (3/27/2011)
At the same time, we have CU6 for R2 and no CTP for the first Service Pack. Granted the RTM quality of R2 was very high, IMHO, and I don't see any large issues that people need to address, but there have been a lot of minor fixes and a rollup is needed.
I don't understand what you are saying is needed, each CU is a rollup of everything before it. Essentially Microsoft could just change the new from CU6 to SP1, if they decided that is what they wanted.
We have had enough issues that were resolved by CUs that we have gone to installing the CUs on our Dev server a week after it comes out, and then if everything is still going good after a month it is installed on the Production server. (Most of our production processes run every day on the Dev server so we get lots of testing in.)
I personally dislike the CU/SP setup because if you needed something from a recent CU when an SP is released it is likely that you would have to wait a couple months before that fix gets put into a CU for the new SP. (So in our case we have to install CU1 along with every new SP.)
If I had to make a choice between CUs and SPs I would go with the CUs. (We can't wait for SPs to get the issues resolved, and CUs are way more manageable than the old HotFix process.)
March 28, 2011 at 5:49 pm
Nadrek (3/28/2011)
If MS wants to go with the CU approach, then MS should design the system such that CU's can be applied (and rolled back!) realtime, without any outage. Preferably include a trivial way to automate this from the command line, as well, perhaps even with a built-in one-off scheduler (i.e. "2008SP2CU4 /runat:20110329030000")FYI: Novell Netware allowed kernel changes to be made while the system was up and under load decades ago; as I understand it, so do mainframes.
I just can't imagine it being worth the effort, if you can't deal with downtime for the updates you need to go with an HA solution because you will always need updates even if only security related ones. Just try to imagine how they would deal with installing an update while a 7 hour query was in process when they made major changes to the DB engine. (Sounds like a disaster waiting to happen to me.)
March 29, 2011 at 4:15 am
UMG, you talk about THE development server and THE production server, do you only have one of each? If that is the situation you can afford to apply and fully test the CUs in your environment, if you have a whole raft of servers that is just not feasible, so you need fully tested upgrade points, which the SPs provide.
If you are at the latest CU and then an SP comes out which will not by its nature contain all the previous CUs, then you do not need to apply the SP, you get no benefit from it, you can afford to wait until the post SP CU comes with all rollups.
So people need to do what best suits their infrastructure - but whilst CUs still come with a health warning its SPs for me and I only apply a CU if it fixes an issue we are suffering from.
---------------------------------------------------------------------
March 29, 2011 at 7:58 am
UMG Developer (3/28/2011)
...Just try to imagine how they would deal with installing an update while a 7 hour query was in process when they made major changes to the DB engine. (Sounds like a disaster waiting to happen to me.)
That's easy to imagine; transactions started prior to time X get the prior version, transactions started on or after time X get the new version. Thus, any one execution of an atomic transaction uses exactly one version of the DB engine.
March 29, 2011 at 1:35 pm
Nadrek (3/29/2011)
That's easy to imagine; transactions started prior to time X get the prior version, transactions started on or after time X get the new version. Thus, any one execution of an atomic transaction uses exactly one version of the DB engine.
I think it is just way more complicated than you are thinking. For instance locks would have to be shared between DB engines, and I assume each engine would require it's own buffer cache, among other things.
March 29, 2011 at 1:42 pm
george sibbald (3/29/2011)
UMG, you talk about THE development server and THE production server, do you only have one of each? If that is the situation you can afford to apply and fully test the CUs in your environment, if you have a whole raft of servers that is just not feasible, so you need fully tested upgrade points, which the SPs provide.
There are a few other production SQL Servers, but one of them is only used by a "third-party" application and we can only install "supported" updates on it. The others are fairly minor and can be updated anytime after the update has been tested on the development server. (Yes one development server serves as the development environment for all the production servers.)
So yes it is easier for us than for people with lots of servers. But I think going with CUs gives you the option of choosing when you want to review an update and apply it to everything, as well as easy access to the bug fixes. (And the documentation on what things are broken in the prior versions.)
April 1, 2011 at 11:29 am
CUs do give you a good option, but they are not exhaustively tested, and they call that out on the pages for them. A service pack is more than a rollup of the CU patches. It also gets more testing. It can have improvements that CSS thinks will reduce costs, and it runs through a CTP cycle with customers.
So while I like the idea of patches every other month that are tested a little, I think a yearly service pack is needed to ensure things are well tested, and you also have a baseline to install to for new servers. There are lots of people that do not want to blindly install CUs, they have to do their own testing, and it's easy to forget what's in CU1, CU2, etc when you see CU9 is the latest.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply