SQLServerCentral.com / Editorials / SQLServerCentral.com / Servicing SQL Server in the Future / Latest PostsInstantForum.NET v2.9.0SQLServerCentral.comhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 03 Mar 2015 14:20:39 GMT20RE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxLooks like MS is listening.[url=http://blogs.msdn.com/b/sqlreleaseservices/archive/2014/02/13/update-on-the-service-pack-plans-for-sql-server.aspx]http://blogs.msdn.com/b/sqlreleaseservices/archive/2014/02/13/update-on-the-service-pack-plans-for-sql-server.aspx[/url]Fri, 14 Feb 2014 09:46:06 GMTJeremyERE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]pparsons (1/28/2014)[/b][hr]This is sad news indeed,[/quote]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.Wed, 29 Jan 2014 09:19:57 GMTaaron.bertrandRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxI 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): [url=http://thelonelydba.wordpress.com/2014/01/28/what-is-the-latest-sql-server-service-pack/]http://thelonelydba.wordpress.com/2014/01/28/what-is-the-latest-sql-server-service-pack/[/url]Wed, 29 Jan 2014 06:58:19 GMTmauriciorppRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxService 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/cuWed, 29 Jan 2014 01:59:37 GMTYet Another DBARE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]mauriciorpp (1/28/2014)[/b][hr]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.[/quote]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.Wed, 29 Jan 2014 01:47:51 GMTGary VargaRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]aaron.bertrand (1/28/2014)[/b][hr][quote][b]Gary Varga (1/28/2014)[/b][hr]I wouldn't want to have to find and install all the relevant CUs.[/quote]Of course, CUs are called [b]cumulative updates[/b] - 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.[/quote]Doh!!!Wed, 29 Jan 2014 01:40:45 GMTGary VargaRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxThis 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 recentlyPhilTue, 28 Jan 2014 19:53:01 GMTpparsonsRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxWe 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.Tue, 28 Jan 2014 18:20:45 GMTMatt SlocumRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]Steve Jones - SSC Editor (1/28/2014)[/b][hr]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.[/quote]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.[quote][b]Steve Jones - SSC Editor (1/28/2014)[/b][hr]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.[/quote]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:[quote]Because the builds are cumulative, each new update release contains all the hotfixes and all the security updates that were included with the previous &lt;major version&gt; update release. We recommend that you consider applying the most recent update release.[/quote]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:[quote]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.[/quote]I'm so torn; I don't know which recommendation to believe.Tue, 28 Jan 2014 18:13:09 GMTaaron.bertrandRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxGood 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.Tue, 28 Jan 2014 17:31:03 GMTSteve Jones - SSC EditorRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]mauriciorpp (1/28/2014)[/b][hr]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).[/quote]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.Tue, 28 Jan 2014 14:26:03 GMTaaron.bertrandRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]Nadrek (1/28/2014)[/b][hr]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.[/quote]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).Tue, 28 Jan 2014 14:21:11 GMTaaron.bertrandRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]Gary Varga (1/28/2014)[/b][hr]I wouldn't want to have to find and install all the relevant CUs.[/quote]Of course, CUs are called [b]cumulative updates[/b] - 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.Tue, 28 Jan 2014 14:17:38 GMTaaron.bertrandRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxDon't forget Steve, that this is also how we got Service Pack 4 for SQL Server 2005 (and you were the initiator):[url]http://connect.microsoft.com/SQLServer/feedback/details/522122/service-pack-4-for-sql-server-2005[/url]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).Tue, 28 Jan 2014 14:09:56 GMTaaron.bertrandRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxI 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.Tue, 28 Jan 2014 13:52:39 GMTMiles NealeRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxI 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.Tue, 28 Jan 2014 13:19:55 GMTMatt SlocumRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]Jim P. (1/28/2014)[/b][hr](...) 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.(...)[/quote]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....Tue, 28 Jan 2014 12:12:52 GMTmauriciorppRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxWell 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?Tue, 28 Jan 2014 09:49:12 GMTJim P.RE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxI'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.Tue, 28 Jan 2014 09:27:10 GMTmauriciorppRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxMicrosoft 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. CU's are not tested as well as service packs, and are thus not comparable as a "replacement". I want that testing to have been done, even if it does miss things, before deploying updates.Tue, 28 Jan 2014 09:17:24 GMTNadrekRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspx[quote][b]Steve Jones - SSC Editor (1/28/2014)[/b][hr]If you want service packs, let Microsoft know. I think they're on the fence right now, but it takes some voices voting to get them to continue with SPs.Vote on Connect, pass the word to co-workers and friends.[/quote]For all my bravado about never having to do things like installing SQL Server in reality I have done from time to time. I wouldn't want to have to find and install all the relevant CUs. I guess if I can imagine being in that situation, albeit not very likely, then someone is going to end up in that position somewhere so my votes were for them :-)Tue, 28 Jan 2014 09:16:20 GMTGary VargaRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxIf you want service packs, let Microsoft know. I think they're on the fence right now, but it takes some voices voting to get them to continue with SPs.Vote on Connect, pass the word to co-workers and friends.Tue, 28 Jan 2014 09:08:13 GMTSteve Jones - SSC EditorRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxI could not agree more with Steve's post. I have been a DBA for a very long time now and the thought of eliminating service packs does not settle well with me. I realize that CU updates are released regularly, however; how many of you have installed one of these updates and encountered issues having to wait for the next update to fix the issue. I read about them on a regular basis and when I do I couldn't be more thankful that I didn't install the update. I typically wait for the service pack because by the time it is released all of those problems that were caused in the CU's are fixed. Yes, it is also time consuming to install these CU's on a regular basis and in an environment that is 25x7 that is not something that can be done. Another major downfall.. cu's are not inclusive.. so if you miss one... UGHIt seems to me that Microsoft is falling down on the job. They want more money for their software and expect to take less quality for that added cost. Give us a complete package, all inclusive, that has been tested for months that we can have confidence in... this would be the Service Pack. Tue, 28 Jan 2014 08:29:06 GMTB's-DataRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxIt's not just US as DBAs that have to deal with SP vs CU, it's all the vendors for the DBs we run. I have very few vendors that specify a CU level -- always a SP level.So installing a CU isn't "just as easy" as testing a system first -- it's either convincing the vendor that the CU is OK, or applying the CU and running the risk of being unsupported. Having worked on the vendor side, I can say that most prefer to put their time into developing their product, not retro-testing a CU.Therefore *IF* MS is moving toward a CU system, they first have to make that policy extremely and unarguably clear to the vendor community.Tue, 28 Jan 2014 08:20:26 GMTTony++RE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxI like the idea of Service Packs. A roll up of further tested CUs bundled together. My guess is they are moving resources away from creating SPs and into new version work. Think of how many man hours it would take to put together and test a SP for SQL2008, SQL2008R2, SQL2012 all at the same time. Personally today, when I build a new server for SQL 2008R2 I patch it to SP2 and CU7 and that is my starting point which is June of 2013.Tue, 28 Jan 2014 08:04:28 GMTMarkusRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxAs a DBA it sounds great to say we should have the flexibility to apply CUs or SP as necessary. The difficulty is when external entities(i.e. PCI-DSS) demands that all servers be at the most recent patch level to be in compliance. The Ivory Tower types who write the PCI standards prefer blanket statements like this, rather than fretting over whether a particular patch has anything to do with security or not.Tue, 28 Jan 2014 07:47:40 GMTStephen MerkelRE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxTesting is not something you just assume, and in most organizations it is preferred (if not mandated) to have all servers on the same level.Even in a small environment, you usually load and test on a separate machine.If you kept up with every CU, and tested thoroughly, some places would be in a constant state of upgrade.Dev, QA, Prod - with a week in each, you get the picture.It takes out a big variable if you have to move things from one server to another.I can see where having CU's available - you have more visibility of some fixes you might be more interested in, gives you a choice.It is better than hotfixes.I think Service Packs still have a place.If nothing else, designating a CU as a SP might make it easier to pick a spot to upgrade when you have multiple servers.And certainly makes checking and knowing exactly what level those servers are at much simpler.The more of the complete stack you leverage, the more it may matter.Just using SQL is vastly different than when you add SSAS, SSRS, SharePoint, Tabular, etc. into the mix.Much more testing and validation needs to occur.So I like the flexibility CU's can give, but think SP's can make managing easier.Bigger stake in the ground for those who may be looking for that.Tue, 28 Jan 2014 06:27:54 GMTGreg Edwards-268690RE: Servicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxAs a developer, as opposed to you hard working DBAs, I care little about Service Packs, CUs or even hotfixes to SQL Server. It is another area where I rely on you DBAs to know your stuff and reasonably apply it both technically as well with engagements with suppliers (such as Microsoft) not only for your benefit but also that of the community. Thanks.Half way through reading this editorial I thought that I was not best placed to pass any kind of judgement until I read this:[quote]...as long as this paragraph appears on CU pages, I do not think we should recommend CUs to DBAs. "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 2012 service pack that contains the hotfixes in this package."[/quote]This means that the question of "Does this SQL Server installation have the latest patches?" becomes ambiguous as the answer could be "Yes" when it fully is "Yes, all the applicable CUs have been applied which happens to be none of them".This is an unsatisfactory situation.Tue, 28 Jan 2014 02:45:08 GMTGary VargaServicing SQL Server in the Futurehttp://www.sqlservercentral.com/Forums/Topic1535287-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/106564/">Servicing SQL Server in the Future</A>[/B]Mon, 27 Jan 2014 20:54:01 GMTSteve Jones - SSC Editor