Servicing SQL Server in the Future

  • Comments posted to this topic are about the item Servicing SQL Server in the Future

  • As 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: 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."

    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.


    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Testing 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.

  • As 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.

  • I 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.

  • It'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.

  • I 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... UGH

    It 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.

  • 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.

  • Steve Jones - SSC Editor (1/28/2014)

    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.

    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 🙂


    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • 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.

    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.

  • 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.

  • 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.

  • 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....

  • 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.

  • 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!

Viewing 15 posts - 1 through 15 (of 28 total)

You must be logged in to reply to this topic. Login to reply