January 28, 2014 at 2:09 pm
Don't forget Steve, that this is also how we got Service Pack 4 for SQL Server 2005 (and you were the initiator):
http://connect.microsoft.com/SQLServer/feedback/details/522122/service-pack-4-for-sql-server-2005
I think it's important to retire a version with a final service pack that includes all of the important fixes. This is a win-win scenario as it gets everyone a fully tested build at the end of release, and it's a much more definitive line in the sand for SQL Server support.
But I also still want the CU model to continue, as it is a viable way for those of us who want (or need) fixes to get them immediately, without having to wait 12, 15, 18 months or more for the next full service pack.
Of course it is up to us to perform regression testing (I would say we should push that on Microsoft to make the CUs more battle-proven, but that would kill the 2-month cycle entirely).
January 28, 2014 at 2:17 pm
Gary Varga (1/28/2014)
I wouldn't want to have to find and install all the relevant CUs.
Of course, CUs are called cumulative updates - this is not a cute name; they're actually cumulative. So if you're on any given branch, you only need to find one CU, it contains all the fixes in the previous CUs for that branch.
January 28, 2014 at 2:21 pm
Nadrek (1/28/2014)
Microsoft is encouraging us to pay continuous per-year fees (like the EA agreements for SA licensing), taking that money, and then failing to provide us with properly tested updates (i.e. service packs)? I find this offensive - we're paying every year, and yet getting less service than when we paid a one-off fee.
You also have to consider that more versions of SQL Server are currently in support simultaneously than at any other time in history, and that is about to get increased by one before dropping by two in June. Yet the size of the SQL Server team remains the same, the complexity of the product has increased, and time is being spent on cumulative updates which you may not want but I can assure you others do. There has to be some give somewhere (oh, and you don't have to buy SA if you don't want it).
As Steve suggested elsewhere in this thread, you need to comment and vote on those Connect items so your voice is heard. Complaining here that "I spend $x and want more service packs for it!" is just lost noise, and that isn't a realistic expectation anyway unless it has numbers behind it (e.g. lots of other people have the same priorities as you).
January 28, 2014 at 2:26 pm
mauriciorpp (1/28/2014)
This is because the DBA can't change the application code when some random CU causes an un-wanted behaviour (because it wasn't tested enough to become a SP).
As a counter-point, did you know that more service packs have been released with bugs, than cumulative updates? I can recall a grand total of 2 CUs that shipped with any problems whatsoever, and at least 4, maybe 5 service packs that shipped with major issues, a couple of them show-stoppers. All this while there are up to 17 or 18 CUs released to every service pack. The major problem is that, in spite of what they promised back in 2005, just about every service pack has had fixes *and* features, while CUs avoid this to a very large extent. Like Microsoft, I also spend a lot more time testing a service pack than a CU, because in comparison, so much has changed.
Not saying that a sloppy CU isn't possible in the future, but to date, the track record speaks for itself.
January 28, 2014 at 5:31 pm
Good points, Aaron, and I agree with you that I want CUs and quality has been good. However the caveats about support, and the fact that bi-monthly is quite fast, mean that this is an issue for support.
Personally I'd also like to see the CU pages include all previous fixes from the last SP/RTM so that people are aware of what's included. They are cumulative, but it's easy to forget that previous fixes are included.
January 28, 2014 at 6:13 pm
Steve Jones - SSC Editor (1/28/2014)
Good points, Aaron, and I agree with you that I want CUs and quality has been good. However the caveats about support, and the fact that bi-monthly is quite fast, mean that this is an issue for support.
Sure, bi-monthly is too fast for some. But annually is also too fast for some, so how do you really meter those to not be "too fast"? Consider too that for someone really dying for a specific fix, even two months is too long. I like that every other month gives me the ultimate flexibility: I can install every single one, I can wait until two, three, six, seven or 18 have accumulated, or I can wait for a service pack.
Steve Jones - SSC Editor (1/28/2014)
Personally I'd also like to see the CU pages include all previous fixes from the last SP/RTM so that people are aware of what's included. They are cumulative, but it's easy to forget that previous fixes are included.
I think you may be onto something here. The only wrinkle is that someone then has to maintain that additional set of information, and that takes time away from fix development, regression testing, etc. That's not my argument, because you and I both know that that's either a simple copy & paste or (hopefully) a slightly different query to get the list at KB generation time, but that's what their argument will be. In any case, if people are reading closely enough that they see the warnings about regression testing etc. then they should also see the message about the cumulative nature of the updates:
Because the builds are cumulative, each new update release contains all the hotfixes and all the security updates that were included with the previous <major version> update release. We recommend that you consider applying the most recent update release.
I included the last sentence, because I find these articles quite two-faced. Here they recommend the latest cumulative update, but earlier in the document they say:
This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. The updates in this package may receive additional testing. 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 package.
I'm so torn; I don't know which recommendation to believe.
January 28, 2014 at 6:20 pm
We did have an instance or two that we were waiting for a fix coming in a CU, and that can be painful.
I'm definitely not advocating doing away with the CU update process, but would like to continue to see SPs roll out. I think this is especially important for a product that's going to be retired (like SP4 for SQL 2005) as this ensures that the most stable version of SQL Server is the one that rides off into the sunset.
January 28, 2014 at 7:53 pm
This is sad news indeed, but from Microsoft not so surprising. Microsoft has never been "fence sitting" (sorry Steve), the only thing that has ever mattered to MS is MS. They push their market where they want it to go, and if we don't want to go there then tough luck. Once in a while an incident happens where they are temporarily swayed, but in this case I believe it is a corporate decision product-wide, not just SQL Server but across-the-board. As an independent (Windows) developer I have seen numerous instances where MS has abandoned previous MS-introduced technologies.
In my case my updates are dictated by my clients, very few apply CU's unless there is a really good reason, and then as others have noted we're not talking a 2-month cycle.
I could go into my client's issues with IE11 vs other browsers, but then IE11 would lose hands down, I used to be a die-hard MS fan ... not so recently
Phil
January 29, 2014 at 1:40 am
aaron.bertrand (1/28/2014)
Gary Varga (1/28/2014)
I wouldn't want to have to find and install all the relevant CUs.Of course, CUs are called cumulative updates - this is not a cute name; they're actually cumulative. So if you're on any given branch, you only need to find one CU, it contains all the fixes in the previous CUs for that branch.
Doh!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 29, 2014 at 1:47 am
mauriciorpp (1/28/2014)
I'm sorry to spoil @gary, but even if he is not directly affected by the CUxSP question, a lot of developers worldwide will be (in time). This is because the DBA can't change the application code when some random CU causes an un-wanted behaviour (because it wasn't tested enough to become a SP).It will be the developer that will carry this burden. And the test-team fellows will feel this even more. So all the professional comunity will be affected at some level by this policy change, because it will affect not only SQL but all MS products.
Even if we don't test anything, installing 10 CUs over a year will cause more downtime than 1 single SP. I don't want to bring my servers down, no matter the reason. It makes me sad to see the server division getting messy because of end-user division changes.
I was being overly simplistic. Artistic licence and all that. Of course, we all know that we are not independent of each other really. I guess my point is that, in general, updating SQL Server is best left to the professionals. I am often lucky enough not to have to get involved in it. It is an additional complexity I can do without.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 29, 2014 at 1:59 am
Service packs vs CU is a pretty moot point for many companies as they dont know about either. They may not even remember which version they have in the first place.
3rd party vendors dont like sticking their necks out to say we recommend anything if they think they are going to get blamed and have to unexpectedly develop a work around. So what do the thousands of small clients do other than not sp/cu
January 29, 2014 at 6:58 am
I agree @Aaron, SPs used to contain new features and require more testing. My point was about the effort to get people involved and documenting the whole process - this administrative overhead always happens, with small or big changes.
@gary, I understand your point. I just used your post as an example to show that more people can be affected by this than the number of us complaining.
Actually I even made a post about this article to help spread the word, as I follow quite a few DBAs (and hope they follow me too! lol): http://thelonelydba.wordpress.com/2014/01/28/what-is-the-latest-sql-server-service-pack/[/url]
January 29, 2014 at 9:19 am
pparsons (1/28/2014)
This is sad news indeed,
What is "sad news"? Microsoft hasn't announced anything officially; in my admittedly naïve interpretation they're just dragging their feet a bit on releasing final service packs for sunsetting versions of SQL Server. They released 2005 SP3 and SP4 under similar pressure that we're applying now for 2008 and 2008 R2. Let's give them a chance to respond before concluding that they must have already made a decision that they will never release another service pack ever, which is what a lot of these doomsday messages sound like.
February 14, 2014 at 9:46 am
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply