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»»

Servicing SQL Server in the Future Expand / Collapse
Author
Message
Posted Tuesday, January 28, 2014 9:27 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, July 25, 2014 11:25 AM
Points: 22, Visits: 159
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.

Post #1535534
Posted Tuesday, January 28, 2014 9:49 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Today @ 6:23 AM
Points: 617, Visits: 2,070
Well the SP has been steadily going away at the Windows level for years.

Just look at the Window's Update Client. Install any OS from the RTM disk/image and then run the Window's updates. There where be hundreds of MB downloaded to get the OS to the current levels.

Years ago MS would just eventually build an SP and then have a few more updates.

So now this is going to the server level services. I wonder what setting an Exchange server looks like?




----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Post #1535546
Posted Tuesday, January 28, 2014 12:12 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, July 25, 2014 11:25 AM
Points: 22, Visits: 159
Jim P. (1/28/2014)
(...) Install any OS from the RTM disk/image and then run the Window's updates. There where be hundreds of MB downloaded to get the OS to the current levels.(...)


agreed. this is also a concern for server admins. having just re-installed Windows 8.0 (back from 8.1) I saw how much updates the OS got in a few months. If everything installed in a single click it would be nice, but I figured some updates have dependencies or can not be installed at the same time - I had to install a bunch, restart, wait windows to update itself, run Windows Update again.... repeat... repeat... repeat... a few time Windows Update would not detect it had just installed a specific update, prompting me to install it again... and again... and again... until it installed something else and after a boot it would get out of this loop.

Sorry for the rant, but if SQL updates become like Windows updates, bad times are coming....
Post #1535579
Posted Tuesday, January 28, 2014 1:19 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 6:57 AM
Points: 422, Visits: 251
I just voted for the service packs.
For about 2 years we were mired down in deploying the CUs as they were released. We tried to keep versions consistent but we quickly realized how hard it was to do so. It takes 3 months to cycle CUs or SPs through our organization (test, operations/non-production, and finally production). Very rarely were we able to maintain consistency.
We were recently issued a mandate to keep versions consistent, so now we only apply service packs.
Post #1535613
Posted Tuesday, January 28, 2014 1:52 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:45 PM
Points: 2,267, Visits: 1,324
I guess I do not care how they get the fix to me or how it is bundled. All I want it to do is work and with each thing they ask us to install or hack that whatever it is that is being changed it gets better.

And I understand that there is a balance in all this software config and update such that we want to have new software to fix the problem but we do not want the confusion of what new software to install or the order of this or that to be the problem.


Not all gray hairs are Dinosaurs!
Post #1535626
Posted Tuesday, January 28, 2014 2:09 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 21, 2014 11:34 AM
Points: 57, Visits: 573
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).
Post #1535630
Posted Tuesday, January 28, 2014 2:17 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 21, 2014 11:34 AM
Points: 57, Visits: 573
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.
Post #1535632
Posted Tuesday, January 28, 2014 2:21 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 21, 2014 11:34 AM
Points: 57, Visits: 573
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).
Post #1535633
Posted Tuesday, January 28, 2014 2:26 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 21, 2014 11:34 AM
Points: 57, Visits: 573
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.
Post #1535634
Posted Tuesday, January 28, 2014 5:31 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 4:10 PM
Points: 33,095, Visits: 15,202
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1535663
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse