Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Service Pack 4 Expand / Collapse
Author
Message
Posted Saturday, December 26, 2009 12:10 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
Comments posted to this topic are about the item Service Pack 4






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #839224
Posted Saturday, December 26, 2009 8:23 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, November 22, 2013 11:05 AM
Points: 3,108, Visits: 2,116
We are a 60/40 SQL 2005/SQL 2000 shop - yes I agree that testing each and every CU is a pain and not possible with over 330+ instances - we go with a new CU anywhere from 3-6 months (unless there is a compelling need). Right now on SQL 2005 we are either at CU 3 or CU 4. As for 2000, well SP4 and a few hotfixes depending on the application

However SQL 2005 SP4 is an absolute must in my opinion.

The primary reason is that we have no intention of looking at SQL 2008. As for SQL 2008 R2, well not at least until until at least SP2 !

Who knows, by that maybe we'll be at SQL 2012 and can play 'the game' again !!!




Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #839238
Posted Sunday, December 27, 2009 3:11 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 1:13 PM
Points: 35,969, Visits: 30,261
I guess I don't understand the supposed dilema here... if Cumulative Updates really are cumulative and include all fixes since the last service pack, isn't that just as good as a service pack? Why not just pick one CU to test and settle for that?

As a sidebar... now you know why some customers just don't like "agile" development methods. The updates are a PITA.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #839245
Posted Sunday, December 27, 2009 12:12 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:46 PM
Points: 5,849, Visits: 12,585
Jeff Moden (12/27/2009)
I guess I don't understand the supposed dilema here... if Cumulative Updates really are cumulative and include all fixes since the last service pack, isn't that just as good as a service pack? Why not just pick one CU to test and settle for that?


MS themselves say they are not as good as service packs, if MS don't guarantee the results of applying CU's, personally I am steering clear of them. Go to the latest SP + any security patches and stick there

Remember how long we had to wait for SQL 2005 SP3 and the campaigning that appeared to be necessary before it was released? It looked at the time as if all the effort went into SQL 2008 release,and perhaps SP4 is suffering a similar fate. SP3 seems pretty stable so I am in no hurry for an SP4, when the backout of a service pack is an uninstall\reinstall who needs the stress?

An SP2 for SQL 2008 would be nice at this point. rather than muddying the waters even more with a release 2

There was never a final service pack for SQL 2000, just a hotfix rollup MS recommended you applied (as opposed to CU's which they don't recommend you apply). Even then there have been post SQL 2000 SP4 security patches (MS08-040) that have had to be applied.



---------------------------------------------------------------------

Post #839280
Posted Sunday, December 27, 2009 1:15 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
The CUs aren't regression tested, and do sometimes introduce issues. SPs include the CUs, plus potential internal fixes for things that were in a customer specific hot fix, or might fix another issue that was noticed. they are also regression tested with the full test suites.

Personally I like the CUs in terms of addressing issues that someone might have, but for keeping patched on the majority of servers, I'd stick with SPs. One a year seemed like too few, but I'd be happy if we could just get that one.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #839286
Posted Sunday, December 27, 2009 4:02 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:49 PM
Points: 2,866, Visits: 1,708
I think of SQL Server/Oracle the way I think of BMW/Mercedes et al. I am paying a premium price for something that comes with certain quality expectations.

Part of those expectations relates to customer service. Quality customer service may be a "cost" to the supplier but is the thing that makes me buy in the first place.

If Product 'x' is only marginally better than Product 'y' and obviously more expensive then it is the periphery and sometimes intangible benefits that make Product 'x' the compelling choice.

I've said it before that costs are easy to measure because they are upfront and clearly visible on a balance sheet. The revenue or benefit is slower to be apparent and may even be hard to measure.

In many ways measuring the benefits is like piloting a hot air balloon. An inexperienced pilot will have them going up and down all over the place because you have to look forward. By the time you start to drop you will continue to drop for some time after you apply corrective measures due to inertia. Similarly you can soar on inertia without realizing that you have very little to sustain you.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #839292
Posted Sunday, December 27, 2009 10:20 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 1:13 PM
Points: 35,969, Visits: 30,261
Thanks for the feedback George and Steve. Didn't know that about CU's. Guess I just got lucky by being lazy... if it's not a service pack or a very specific patch (like security update), it's not going in on my watch.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #839316
Posted Sunday, December 27, 2009 11:11 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, September 08, 2013 5:39 PM
Points: 263, Visits: 862
I'll go one further - I don't think it's acceptable to have service packs. It's an acknowledgement that a product is defective. Only after an unspecified number of updates (and years) will it work correctly. The worst part is that we accept and, in fact, expect it. It's irritating that MS isn't giving us SP4 this year. But it's even worse that we should even have to expect one.


James Stover, McDBA
Post #839323
Posted Monday, December 28, 2009 4:00 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:49 PM
Points: 2,866, Visits: 1,708
James Stover (12/27/2009)
I'll go one further - I don't think it's acceptable to have service packs.


Brave statement. I'm pretty rigorous when writing code but I doubt that even John Carmack could claim to write bug free code.

If you look down the bug list for SQL Server you will see that the vast majority is the sort of stuff that crops up only in specific circumstances. On a large product such as SQL Server, or any other DB system for that matter, the sheer number of possible circumstances make it nigh on impossible to test all possibilities.

Any complex product has bug fixes and, scarily, that includes aeroplanes. See http://www.aaib.gov.uk/publications/index.cfm

When making changes software is just as subject to the law of unintended consequences as anything else. Little systems that function fine in isolation produce behaviours that are unintended and even undesirable when combined.

I saw an engineering show that mentioned that shutting one of 3 tunnels in a busy intersection actually improved the traffic flow. The expected consequence was that it would make rush hour intollerable! It would be really easy to come across this situation in software with a multi-threaded environment.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #839361
Posted Monday, December 28, 2009 6:21 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, September 08, 2013 5:39 PM
Points: 263, Visits: 862
I'm not talking about bug-free code. Practically speaking, that's impossible. I'm talking specifically about the expectation that a software product will require a service pack (or packs) to function correctly. We have been trained by the industry to expect them and we just accept it as standard practice. The software industry should not be exempt from being held to a higher standard just because its products are complex.


James Stover, McDBA
Post #839381
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse