April 28, 2010 at 10:43 am
Microsoft isn't perfect, and no application is truely 100% complete. SP's save a lot of time (especially when updating fresh installs).
I agree on the 6-month sp then one per 12 months cycle.
April 28, 2010 at 10:52 am
I am in the opinion that SPs are critical, CUs are for the cases where you experience a specific issue treated by the CU.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 28, 2010 at 11:18 am
It would be pointless for me.
I am the lone dba/software person in a large non-profit with responsibility for more than 40 systems. Some built, some bought, various architectures.
I simply do not have time to devote to 'preventative maintenance' for features I might not even be using. If I had just one person, I could see the benefit but it currently would just be lost time for me.
I have to keep to "patch if warranted, otherwise ignore."
It's most unfortunate that MS software requires so much of this kind of thing. That's the real problem!!!
April 28, 2010 at 11:38 am
vickiy (4/28/2010)
It's most unfortunate that MS software requires so much of this kind of thing. That's the real problem!!!
I am inclined to agree with you. They aren't known as "Mickeysoft" for no reason. They tend to let the user community do their bulk testing for them so they can make their RTM's quickly and on schedule. This, in my humble opinion does not fall under the "maintenance" umbrella of SP's, but more of the "fix what got left out at the factory" umbrella of SP's. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
April 28, 2010 at 12:26 pm
Also, they are on a release schedule for CUs. Those come out every other month. So is that poor tested code?
Based on the "Only install this if you have one of the listed issues" text: YES this is under tested (not necessarily poorly tested) code that is being released on a schedule to accommodate people that have specific issues and can't wait for a fully tested SP release. The benefit of a CU over individual patches is that it avoids dependency problems among the patches themselves. (Also, assuming that some people actually install the individual patches, the items in the CU have had some field testing)
--
JimFive
April 28, 2010 at 12:36 pm
Jim,
I think you're confused. The patches are built upon other changes, and contain the previous CUs. They're just not overly tested.
CU5 for SS2K8 SP1 isn't built on SP1, it's built on code that has changed in CU4. OR CU3 and potentially some CU4 stuff. The code base changes, so it's hard to keep a handle on how things are set. That's why the build numbers change, and keep incrementing. You are getting rolled up changes.
April 28, 2010 at 1:02 pm
I usually only worry about the Service Packs unless I have a specific issue that a CU fixes. That being said if Microsoft were to do the same type of regression testing they do on SP's for CU's then I'd be ok without them releasing yearly SP's but could wait until they released it.
When a product reaches end of life or close to it there should be a rollup SP that goes through all the regression testing.
I don't think they should release Service Packs just to release service packs on a timely basis. It seems to have worked out so far that there have been enough substancial changes in the CU's to warrant yearly service packs.
---------------------------------------------------------------------
Use Full Links:
KB Article from Microsoft on how to ask a question on a Forum
April 28, 2010 at 1:45 pm
bwillsie-842793 (4/28/2010)
I vote for SP's on a regular basis. My gut instincts tell me that cherry picking CUs is going to cause me problems at some point.
I also look forward to regular Service Packs for SQL Server.
April 28, 2010 at 6:23 pm
chrisn-585491 (4/28/2010)
Releasing CU's and SP's must be incredibly expensive and laborious for MS. And yet, they are freely available to anyone - even those who DON'T own the product. And yet, here we are complaining that we aren't getting our FREE update.
It's not a free update, it's a fix. And Microsoft makes a nice profit too, considering the license costs of their products.
How are the updates not free? Microsoft sells and earns revenue on the product, not post-release updates (not counting SA). Also, if you read the SQL EULA in detail, you will know their legal obligation basically ends with the initial sell. Commercial pressure and competition "force" them to release updates - which surely comes at a considerable expense. I strongly suspect this is why we are getting SQL 2008 R2 (with separate licensing) rather than another SQL 2005 SP. I also suspect we will see less SP's in future and more second or even third generation releases - with separate licensing.
James Stover, McDBA
April 29, 2010 at 12:46 am
James Stover (4/28/2010)
Also, if you read the SQL EULA in detail, you will know their legal obligation basically ends with the initial sell.
I don't know much about US law. In fact, I don't know much about any law. But I do know that under Dutch law, a buyer can legally expect the bought product to function "as may be reaonably expected" for "a reasonable time". If not, the buyer has a right to get a free repair or replacement. While these articles are usually associated with physical stuff and production defects, it applies to all products.
And no contract may ever include a clause that overrides a legal obligation; such clauses are automatically void. So whatever is in the EULA, Microsoft is still under a legal obligation to fix bugs for free. At least here in the Netherlands and in other countries that have similar buyer protection laws. Are there no such laws in the United States?
April 29, 2010 at 6:16 am
Steve Jones - Editor (4/28/2010)
Jim,I think you're confused. The patches are built upon other changes, and contain the previous CUs. They're just not overly tested.
CU5 for SS2K8 SP1 isn't built on SP1, it's built on code that has changed in CU4. OR CU3 and potentially some CU4 stuff. The code base changes, so it's hard to keep a handle on how things are set. That's why the build numbers change, and keep incrementing. You are getting rolled up changes.
Steve,
Perhaps it is a semantic problem, but a Patch is an individual fix, a CU is an accumulation of patches (from the previous SP) and an SP is a stable package of the accumulated patches and may include additional functionality.
The biggest benefit of an SP is that it gives developers a guaranteed base to develop against.
--
JimFive
April 29, 2010 at 7:38 am
Maybe, but the SP isn't necessarily that which CU 4 is developed against. Neither is an individual patch. They might be developed again CU3 or CU2. Otherwise it would be an incredible merge operation with so many branches of the SP code.
Those CUs are not necessarily well tested, and sooner or later we will hit a bug that gets through the testing. If too many people are applying the CUs, then it's a large argument from the Oracle and DB2 people that SQL Server has issues. I don't want to see that.
What I want is for Microsoft to deliver a high quality product throughout its lifecycle. Which means regular testing of patches and a delivery mechanism to customers.
April 29, 2010 at 8:36 am
As bwillsie put it, I am always leery of CU cherry picking because I am concerned that something is missing. On another note, to choose the correct CU, you have to do additional research to determine if the issue in the CU actually applies to what "broke" in the application.
I am another vote for the regular SP.
April 29, 2010 at 7:31 pm
Hugo Kornelis (4/29/2010)
James Stover (4/28/2010)
Also, if you read the SQL EULA in detail, you will know their legal obligation basically ends with the initial sell.I don't know much about US law. In fact, I don't know much about any law. But I do know that under Dutch law, a buyer can legally expect the bought product to function "as may be reaonably expected" for "a reasonable time". If not, the buyer has a right to get a free repair or replacement. While these articles are usually associated with physical stuff and production defects, it applies to all products.
And no contract may ever include a clause that overrides a legal obligation; such clauses are automatically void. So whatever is in the EULA, Microsoft is still under a legal obligation to fix bugs for free. At least here in the Netherlands and in other countries that have similar buyer protection laws. Are there no such laws in the United States?
OK, so I took a few minutes to review the SQL 2008 EULA and you are correct, we can expect the product to work as expected. However, MS also reserves the right to just refund the purchase of the software rather than fix it. In any event, there still isn't a promise to release updates/patches on any kind of schedule. You automatically agree to these terms when you install the product, so complaining that you aren't getting a service pack every year (or whenever) is really your problem, not theirs.
I'm playing Devil's Advocate because this isn't the first service pack rant and nobody ever seems to argue the other side. Maybe with enough pressure, Microsoft will commit to regular SP releases. I think this would be a mistake (for them), but they might bow to customer pressure.
James Stover, McDBA
April 29, 2010 at 9:30 pm
My vote is for more regularity for SQL Service Packs.
Of course I don't want the quality to drop. But as been previously noted there is a discrepancy in how far to trust CU's. Some sql sites and bloggers keep track of each cu, with the implication of installing them to keep up-to-date. But the caution discourges this ... so which is it? The CU's are quite stable or they aren't?
Regards
David
Viewing 15 posts - 31 through 45 (of 48 total)
You must be logged in to reply to this topic. Login to reply