Waiting for SP1

  • Comments posted to this topic are about the item Waiting for SP1

  • I think that the days of Microsoft releasing buggy 1st releases is past.

    The best move that I have done recently was install SQL Server 2008 when released. This was so much more stable than 2005 and finally made all of the effort in rewriting our DTS into SSIS as the right decision.

    I installed R2 when first available. It has been rock solid from day one. 64 bit forever !

    Finally installed SP1 for R2 last week only because I thought it was about time that I did some Housekeeping on what is in reality a system that is so reliable that I tend to neglect it a bit. Also because I'm starting to think about upgrading to 2012 only because my Boss is getting pressure from Microsoft about changing our Licensing Plan before 1st April and the new Charges.

    In summary I might have waited for SP1 in the past but not anymore.

    David

  • This autumn an evaluation begins where I work, one of Swedens largest insurance companies, to try out sql server 2012. If it goes well, we'll upgrade.

  • I plan to switch as soon as possible. The SSIS improvements alone are worth any upgrade pain we go through.

    For BI we want Crescen...errg...umm... PowerView, and BISM, though having to have to separate SSAS instances (one for Vertipaq the other for standard SSAS is annoying).

    Always on will be nice, but not necessary for us since we've already got clustered instances to begin with, and after playing with Always On, it's just not that important. There's still a short period when the one server takes over for the other.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • I'm "one of those" waiting for SP1. Funny - my MS contact just ask me about SQL 2012 last week and that's exactly what I told him.

    Might change my mind if I want to deploy "AlwaysOn", but until then, I'll sit back and wait.

    Cindy

  • Currently testing 2012EE on a VM.

    The move from SS2005EE to 2012EE makes a lot of sense - compression being an essential feature, together with the new T-SQL built-in's for looking back and forward in rowsets - something we're really needing so we can give our Users easy access to trending and perhaps rolling averages.

    Having nuked replication, which was severe overkill for the multi-db schema I inherited, I'm a little reluctant to go back to it as it was an IO killer. However, Always-On with readable secondaries for Reporting Services is very attractive - simply because it saves having another machine with an $8K Standard license. Net $19K additional upgrade cost might get by...

    The licensing change is a royal pain! Just when we thought we could get to a 6x2 box for $27K, we're hit with "we need more profit! (really?)" from Bill's boys - BAD MOVE IMO. SMB's just don't have deep pockets - don't THEY know that or are the big boys all they care about now?

  • Having lived and worked with Microsoft software (and others) since the '80s, waiting for SP1 makes sense if you don't have an urgent need to upgrade to 2012. (Burned twice, shame on me.) There are still issues with release software that don't get fully discovered until a larger base of users push it to the limit. Also you can sit back and let other folks figure out any configuration wrinkles, conflicts, how-tos and "best practices". So get to work late-Beta Testers!

  • Years ago it did make sense to wait for SP1, but those days have been over for at least 7 years now.

    I work at a company that was on SQL Server 2000 in 2008 and we were deciding what to upgrade to. We started our planning before SQL Server 2008 went RTM and had to get something installed in our development environment by mid-2008. We are an e-commerce company and do not make changes to Production in Q4 unless absolutely necessary. So the upgrade would be in early 2009 and we had a good 4 months to test whatever we were upgrading to (2005 or 2008) in several environments. By late 2008 SQL Server 2008 had been RTM for a bit and we were still 2 - 3 months from doing the upgrade in Production. We discussed moving to 2008 which mainly meant re-testing everything in development and QA environments, but 99% of what we needed to change for 2008 had already been done via our testing on 2005. Our then IT Director said, "No Microsoft software is Production-ready prior to SP1 so NO". So we are currently on 2005 and have been bemoaning not being able to use lots of 2008 features for 3 years now. Of course, we also have some PostgreSQL servers and were upgrading those in late 2009. We upgraded to a new version that had been out for just a week but THAT was ok because, as the IT Director said, "it's open-source and that community fixes problems quickly".

    So we are about to start testing SQL Server 2012 in development with plans to upgrade Production later this year.

    Given the many CTPs and RC0, it doesn't make much sense anymore to wait. Yes, there will be bugs but that doesn't set it apart from any other software. And SP1 will be out soon enough, maybe a few months after we have this in Production, so it wouldn't have really mattered to hold off anyway.

    SQL#https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
    Sql Quantum Lifthttps://SqlQuantumLift.com/ ( company )
    Sql Quantum Leaphttps://SqlQuantumLeap.com/ ( blog )
    Info sitesCollations     •     Module Signing     •     SQLCLR

  • Given the many CTPs and RC0, it doesn't make much sense anymore to wait. Yes, there will be bugs but that doesn't set it apart from any other software. And SP1 will be out soon enough, maybe a few months after we have this in Production, so it wouldn't have really mattered to hold off anyway.

    Budget is the best reason. If you don't want to pay extra for the increased licenses and don't currently have the resources to test and evaluate a new version, why not let the early adapters take a few arrows?

  • There's also the middle of the road "Wait for the early adopters to report back" approach, which can be good for RTM and SP's alike. Waiting for SP1 isn't a bad idea for the cautious, but it does put you quite a ways behind the tech curve. On the other hand, installing the RTM in the first week of release puts you out on the bleeding edge (and if you don't think it does, go and read what some of the recent RTM CU's have fixed, then re-evaluate).

    I'd also say that the 2012 per-core licensing model has made very major changes in hardware considerations. For one, in general you pay twice as much for any single-core or dual-core CPU's you have left. For another, Microsoft has begun following Oracle farther into the byzantine labyrinth of "machine power" pricing; many of the current high core count, low clock speed processors are now tremendously inefficient in terms of TCO, given the new pricing model. It may be cheaper to buy either new processors (lower core count at the highest clock speed available for that generation of a particular design), or even entire new servers, given license savings at Enterprise and Datacenter per-core costs.

    Upgrading existing hardware in place is something we should evaluate very carefully in TCO terms. Assuming, of course, Microsoft fails to follow Oracle even deeper into the maze of twisty passages.

  • chrisn-585491 (3/18/2012)


    Given the many CTPs and RC0, it doesn't make much sense anymore to wait. Yes, there will be bugs but that doesn't set it apart from any other software. And SP1 will be out soon enough, maybe a few months after we have this in Production, so it wouldn't have really mattered to hold off anyway.

    Budget is the best reason. If you don't want to pay extra for the increased licenses and don't currently have the resources to test and evaluate a new version, why not let the early adapters take a few arrows?

    I was just looking at it from a technical perspective.

    I do agree that the new pricing model is a bit crappy. But I don't see how letting early adopters "take a few arrows" does anything to change the equation. The amount of testing needing to be done won't (or shouldn't) dramatically change. And if I don't have the resources now to test a new version, that doesn't mean I am waiting for SP1 or that I will have those resource in 6 months or however long it takes for SP1 to come out.

    But I do understand holding off in general, regardless of SP1, to figure out how to best deal with the new pricing model if your hardware does not play into the new model all that well.

    SQL#https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
    Sql Quantum Lifthttps://SqlQuantumLift.com/ ( company )
    Sql Quantum Leaphttps://SqlQuantumLeap.com/ ( blog )
    Info sitesCollations     •     Module Signing     •     SQLCLR

  • Having been involved in the SQL 2012 TAP program and tested numerous private and public releases, I am happy that SQL 2012 RTM is ready for Production use.

    We have not tested all of the new featues, but everything we have tested that was in both SQL 2008 R2 and SQL 2012 works fine. On some of the new features we tested we logged some Connect tickets to make some of the parameters externalised and changeable instead of internal and fixed, but this may come eventually and it would not stop us using SQL 2012 as it stands.

    SQL 2012 also harmonises the code base between Azure and in-house installs. Microsoft have already said they expect to add more functionality to Azure and make this available to SQL 2012 in-house installs via optional function packs. Therefore adoption of SQL 2012 will enable you to take advantage of function packs when they offer your business a commercial advantage, and not adopting SQL 2012 locks you out of this agility.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • Solomon Rutzky (3/18/2012)


    chrisn-585491 (3/18/2012)


    Given the many CTPs and RC0, it doesn't make much sense anymore to wait. Yes, there will be bugs but that doesn't set it apart from any other software. And SP1 will be out soon enough, maybe a few months after we have this in Production, so it wouldn't have really mattered to hold off anyway.

    Budget is the best reason. If you don't want to pay extra for the increased licenses and don't currently have the resources to test and evaluate a new version, why not let the early adapters take a few arrows?

    I was just looking at it from a technical perspective.

    I do agree that the new pricing model is a bit crappy. But I don't see how letting early adopters "take a few arrows" does anything to change the equation. The amount of testing needing to be done won't (or shouldn't) dramatically change. And if I don't have the resources now to test a new version, that doesn't mean I am waiting for SP1 or that I will have those resource in 6 months or however long it takes for SP1 to come out.

    But I do understand holding off in general, regardless of SP1, to figure out how to best deal with the new pricing model if your hardware does not play into the new model all that well.

    I can agree that the RTM is more likely to have "arrows", but we've had plenty of SPs that have broken things as well. Not sure the SP argument makes sense anymore since the platform is very stable. Now if they do a major rewrite, ala SQL Server 2005, perhaps.

  • I think it depends on the applications you are running as well. SQL Server 2012 is just coming out. Many 3rd party software packages may not support SQL Server 2012 when first released, meaning these systems have to wait for vendor approval before they can be upgraded. Once that happens, then you have to get the business to buy off on the upgrade. By that time SP1 will most likely have been out for a while.

  • I work for farmers. It was hard enough dragging them into the 20th century, let alone the 21st. SQL? isn't that the sound a pig makes? Why would you want our computers to make the same sound? You computer guys...

    We have been delaying upgrades for a couple years now, so I suspect that by the time we get around to upgrading, maybe next year, we will install SQL2012 SP1. Because it will be old and reliable by then.

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

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