Regular Service

  • skjoldtc (4/28/2010)


    I think Microsoft does admirable job with its SPs. It's a very complicated product and to chastise Microsoft for being "late" is short-sighted. I'd rather they release a correct SP than release something on time that needs to be patched again.

    I agree with you, but we're talking about the fact that they will abandon plans to release a Service Pack, despite the fact that their documentation for CUs says they will, and people expect it. My concern, and complaint, is not that it's late, it's that they don't intend to even build them in some cases.

  • If you have ever looked at the massive FIX list of some of these SP's I think many will come to the conclusion that the SP's are not merely a matter of "maintenance" per say but more a matter of things they left off the car in the first place in the rush to get the product to RTM, and the drivers (us) end up discovering this for them. The customers in the field end up basically being their test-bed. That is very different than "changing the oil" type of "maintenance" per say. I have always wondered about Mickeysoft's QA department anyway. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • TravisDBA (4/28/2010)


    If you have ever looked at the massive FIX list of some of these SP's I think many will come to the conclusion that the SP's are not merely a matter of "maintenance" per say but more a matter of things they left off the car in the first place in the rush to get the product to RTM, and the drivers (us) end up discovering this for them.

    Exactly! To push the car analogy further than Steve ever intended, releasing a Service Pack or a (fully supported and officially recommended) Cumulatie Update is not like chaning tyres and replacing oil, but more like the recent Toyota callbacks to fix defects that were discovered after RTM.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • As long as CUs are being released, there should be a regular SP release.

    When the product becomes so stable that no CUs are created, then no SP is needed.

    Converting oxygen into carbon dioxide, since 1955.
  • Some companies allow CUs to be applied, others only allow applying service packs due to a number of reasons (down time, change management, etc.). However, some of the CUs contain security updates that should be applied almost immediately to every instance. This puts the DBA team in a tough position. The security team wants the CU applied, but the business wants uptime within a stable, non-changing environment.

    It seems to me that service packs are a good compromise answer to this dilemma (if not the only answer), but only if service packs are being released.

  • Releasing CU's and SP's must be incredibly expensive and laborious for MS. And yet, they are freely available to anyone - even those who DON'T own the product. And yet, here we are complaining that we aren't getting our FREE update.

    It's not a free update, it's a fix. And Microsoft makes a nice profit too, considering the license costs of their products.

  • Steve Cullen (4/28/2010)


    As long as CUs are being released, there should be a regular SP release.

    When the product becomes so stable that no CUs are created, then no SP is needed.

    Put much better than I did. Thanks, Steve.

  • I see service packs as a way of correcting unforeseen bugs that occur when a product is finally released, not as a means of servicing my dB. Ideally, the initial release was thoroughly tested and all real-world configurations accounted for, but people are imaginative and ... nothing is ever perfect. So, from my perspective, the lack of service packs is to me a sign of a good solid code base (assuming that the urgent and critical bug reports are near zero). I would rather Microsoft spend time making the products I use better than spending time fixing bugs. Spending your time implementing the features like the Oracle %rowtype is by far preferable to having to fix a bunch of bugs in a service pack.

  • I'm inclined to vote in favor of regular service packs. I'm a DB consultant and, as a rule of thumb, I advise my clients to avoid purchasing a new software package until, at least, the first service pack is released.


    Dave Leach

  • damons (4/28/2010)


    So, from my perspective, the lack of service packs is to me a sign of a good solid code base (assuming that the urgent and critical bug reports are near zero).

    Have you ever reviewed the list of bugs fixed in the CUs?


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • I also vote for SP's on an annual basis. We want to know there's been some solid testing behind these releases.

  • I fully understand the need to have a solid car and a solid computer system, be it my home workstation, my webservers, or the Sql platform. I have also experienced the devestation caused by the loss of all of these items with no notice, and none were related to normal maintenance.

    I also have a unique perspective into your analogy. Before moving into the IT sector I performed regular maintenance on vehicles, with over 10 years of experience in the quick lube industry alone. If you want the math it comes out to about 1/2 million oil changes

    Why this matters is that regular maintenance intervals, I have seen, are not universal. Many people have their minds engraved with the 3000 mile oil change. In most cases this is on the conservative side, and this is generally for the worst case situation on a vehicle with the lowest interval. That same worst case is 5 or 6000 on many vehicles, and 10k on many European cars. Normal intervals are often double that amount. Also, as time has progressed, technology has made items that need less instance now. It used to be 30k for the transmission fluid, now many vehicles are 100k, if at all.

    Next thing is that this is regular maintenance, which is what you do to keep your car running efficiently on the quest for a longer life. There is also unscheduled maintenance, which takes care of items that are not working properly if at all. This would be when a headlight burns out or you blow out a tire.

    This is why your analogy is wrong. CUs and SPs are made to take care of these unsheduled items. Normal maintenance these are not, unless there was a plan for this item to be broke; which though possible is bad business due to the expense of patch distributions which are at no cost with a potential for risk, and also there is the risk of being caught. Though I am not a server guru, I would consider normal maintenance to be making backups, or defragging a hard drive

    Director of Transmogrification Services
  • I disagree with regular service packs with the following justifications:

    Service Packs should be rolled up and tested when the accumulated changes are sufficient to warrant it not just to meet a release schedule.

    A service pack schedule would lead MS to code to the schedule, instead of to need.

    Release schedules also encourage the release of under tested code, which is something I definitely do not want in my SQL Server.

    --

    JimFive

  • According to the Release Services blog SP2 for SQL 2008 will be in Q3 of 2010 and SP4 for SQL 2005 will be in Q4 of 2010.

    http://blogs.msdn.com/sqlreleaseservices/archive/2010/02/12/sql-server-servicing-plans.aspx

  • James Goodwin (4/28/2010)


    I disagree with regular service packs with the following justifications:

    Service Packs should be rolled up and tested when the accumulated changes are sufficient to warrant it not just to meet a release schedule.

    A service pack schedule would lead MS to code to the schedule, instead of to need.

    Release schedules also encourage the release of under tested code, which is something I definitely do not want in my SQL Server.

    --

    JimFive

    There's a danger of this for sure. The flip side is they can just not do them.

    There was an argument made here when MS went to monthly security releases that this would happen. I'd argue that it hasn't happen. There have been a couple issues, but over 5-6 years, I think it's worked. Also, they are on a release schedule for CUs. Those come out every other month. So is that poor tested code?

Viewing 15 posts - 16 through 30 (of 48 total)

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