How Long Before You Upgrade?

  • Cody K (4/11/2014)


    I think you are MEANT to do a full backup, begin a trace to record a day of work, take another backup, and then use replays to compare the end results. Right? But, not many people appear to have gone into depth with examples of how to do the "best practice"... so few do it.

    You're spot on Cody. Here are some of the things that I did when I performed the upgrade to 2012 and plan to do it all again for 2014. It's really not that hard. Just a little time consuming.

    • Trace replays against Data Engine and Analysis Services databases. I collect queries for a couple weeks and play them back as fast as the new servers can handle them. A little load testing while you're at it never hurts. 😀
    • Process all the Analysis Services databases. It's real easy to write a PowerShell script to loop through all the DBs and process them. I'll try to remember to post my script when I find it (or rewrite it :ermm:).
    • Run a good cross-section of the SSIS packages. Really, you should run them all if you can. We have very fine-grained packages and last time I counted there were over 1,700 of them. I work with the developers to identify a batch that exercises all the special cases and custom components we use.
    • Reporting Services is probably more of a manual process. Our SSRS implementation is using SharePoint Integrated Mode so our SP team manages that and I don't have to get involved too much there.

    [font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
    Business Intelligence Administrator
    MSBI Administration Blog

  • I work for a health system (2 hospitals) and I support over 20 servers with SQL 2000 on them. Of course I support over 200 servers........

  • Yep. I am in this boat. We have 7 dbs still in SQL 2000, 5 of which will be moved to 2008R2 next week. We still have a small amount in SQL2005 and a few of these we have upgrade plans for this year and a few more next year. We don't have SQL2012 yet here at all except for a sandbox play server. As far as home grown dbs why should we upgrade to SQL2012 now, might as well wait till SP1 comes out for SQL2014... as far as purchase apps our hands are tied to what is certified and when we decide to have a project, have the $$ and manhours to upgrade. We have over 300 prod dbs here now with 500 more in the next 2 years. As I have told my boss, if we did absolutely nothing except upgrade dbs to SQL2014 beginning today we would never have them all upgrade by the time the next version comes out. I thought Microsoft said each new version would be 3 years apart.... From my notes SQL2012 came out in May 2012, and SQL2014 came out in April.... that isn't three years! Our one store facing SQL Server had 50 databases on it and we began the upgrade project of moving/upgrading or replacing the 50 dbs from SQL2000 on it in Nov 2011 and will complete it next week. When you are dealing with a 24X7 highly avail. system that is critical to the business it isn't easy or quick to upgrade. We basically took each app/database one at a time and went through DEV, TEST and PQA and then Prod. The easiest ones first and the last group the most difficult.

    I have been telling everyone that this over 2 year upgrade project took us from two versions old to today of now being two versions old. Kind of sad when you think about it in those terms.

  • We are running all 2008R2, with plans to begin upgrade to 2014 Q4 or 2015Q1. But we are doing the upgrade to SQL at the same time we also introduce new hardware and go fully virtual. Just makes sense to get all the testing and upgrades done in one sweep.

    Last year I did quite a few interviews as part of changing job. One place I interviewed (company and location withheld to protect the guilty), when I asked them what version of SQL they where running: "Well..... we have some 2012, some 2008R2, some 2008, mostly 2005, quite a few 2000 and 7. Oh and I think there are some 6.5 servers around here somewhere." I politely declined the position.

  • A LOT of companies are going to be in the mixed versions of SQL Server boat. I know of many myself.

    I think going forward over the next 10 years this is only going to get worse. Reason I say that is as more SQL Servers pop up and more become critical systems the more time and $$ it is going to take to upgrade them all. Pile on top of that tighening IT budgets and very quick turnaround from Microsoft on new versions too.

    5 years ago we only had about 120 SQL Server DBS, now we are about 300 and within 2 years we will be at 500.

  • My company currently runs an SQL 2000 instance to support ERP software. We tried to upgrade just the database a few years ago, but the ERP vendor said it would not work unless we upgrade their software as well. Of course, an ERP software upgrade involves not only IT; but finance, manufacturing, etc.... at least a six month process involving many hours by many people.

    It took us a few years to get upper management on board for an ERP upgrade, which means a huge commitment across the whole company. We are now in the middle of that process which will bring our database up to SQL 2012. No pain, no gain.

  • We've been on SQL 2008R2 for about 3 years. I don't see us upgrading for a long time. The licensing costs alone are expensive not to mention in our case we still have plenty of headroom. Unlike others we only have a few dbs.

  • We have a massive system that we implemented in 2010 that has a handful of SQL2005 dbs as its back end. The application is running on Win2003 32 bit servers and the entire thing needs upgraded. It has been talked about but is a huge undertaking which requires a LOT of peoples hours and a pretty expensive one from a capital prospective as well. Last year and this year it was not approved and we are trying to get the project approved for next year.

    So, I feel your pain.

  • I recently told some geek friends I want my MacPro 1,1 to last 10 years. The processor and board are woefully out of date but it has 15 GB of RAM and I replaced the hard disks. Their response was, "it's not a car."

    I think people understand and accept the risks of hardware failure better than software failure. At my last job with SQL 2000, the server itself had been built in 2005. It was not clear to me whether it was moved from another 2000 server or an earlier version. When the warranty on the server expired, they P2V'ed it and started running it in VMware. But as of mid-2013, the SQL version was still 2000.

    Towards the other end of the spectrum are the CIOs who want to wait for SP1. What we've seen recently is that Service Packs are no longer being released the same way. But I think Microsoft will still release SP1 and perhaps go to endless CUs after that.

  • Gary Varga (4/11/2014)


    I'd have to say that I have seen deprecated features, such as DTS like David.Poole mentioned, are a barrier to upgrading. This is a technology agnostic issue as I have seen the same issue holding back upgrades and migrations due to differing technologies such as .NET.

    I think those are good points. Like David said, I have seen DTS packages hinder an upgrade far too often. IN addition, there are the problems with vendor support. Some vendors will not support any version of SQL Server beyond SQL 2000 for their software. That is really unfortunate.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • A majority of our approx. 200 instances are still 2005 or 2008. Only this past 6 months have we put 2012 in production on a handful of systems.

    We have about 30 on SQL 2000, and yes, actually a couple of SQL 6.5 servers :crazy: that were placed in production in the late 1990's that are still humming.

    We have a mix of in house developed applications as well as the typical corporate support type systems. It has been many years since anyone was able to maintain the application code for the old 1990's applications that were supposed to be "retired" several times over the last 10 years, but it just hasn't happened.

  • Mostly we're on SQL 2008 R2 with a couple of SQL 2005 and only one remaining legacy server at SQL 2000. But our main issue is having databases that are still in older compatibility modes, including SQL 2000 (80). We're planning an upgrade to SQL 2012 to finally get caught up as much possible. But I don't think I'd recommend going to SQL 2014 any time soon. Getting to 2012 will be accomplishment enough for us.

    - webrunner

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

  • I was brought into my current company as a production/support DBA on the help desk. Until then I hadn’t seen how the development side works.

    The SW was clinical and financial for nursing homes. The amount of moving parts was crazy. We had to keep up with regular improvements as well as updates to government regulation changes. They had about ten developers state side and they contracted the side dev (such as reporting) out to India. There were about, maybe, five QA types. I think the front-end was C# and they used IE7 for the main form windows and the back-end was SQL 2005. There was never really sold enough to make it profitable over about seven years. It is now as dead as a doornail.

    One of the issues that we were running into just before it was shutdown was the tightened security in IE8 was a nightmare to overcome and the devs had just started working on it.

    We could have probably moved to SQL 2008 somewhere in there, but the QA staff would have been sucked into weeks, if not months, of testing everything, and probably would have still missed something; and still trying to keep up with normal development testing, and the patch testing.

    So sometimes it isn’t that the SW company doesn’t want to upgrade, it’s where to allocate the resource compared to the profit margin.



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

    A little bit of this and a little byte of that can cause bloatware.

  • The title of the article is "How Long Before You Upgrade"? I think a better question/title might be "How long before you change to a newer version"? While those two questions sound the same to most people, they are quite different to me because of deprecation. While there are a lot of "cool" things that have come out and some are actually useful, there have also been some work-horses (IMHO) that have been deprecated, removed, horribly modified, or just flat out dropped with no replacement (although MS insists that SSIS, SSRS, and some other choice 4 letter words is an adequate replacement) and some on very short notice or no notice at all.

    To wit, what many people have called an "upgrade", I many times consider to be a forced "downgrade" that I'm compelled to adopt and pay for.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Jeff Moden (4/11/2014)


    The title of the article is "How Long Before You Upgrade"? I think a better question/title might be "How long before you change to a newer version"? While those two questions sound the same to most people, they are quite different to me because of deprecation. While there are a lot of "cool" things that have come out and some are actually useful, there have also been some work-horses (IMHO) that have been deprecated, removed, horribly modified, or just flat out dropped with no replacement (although MS insists that SSIS, SSRS, and some other choice 4 letter words is an adequate replacement) and some on very short notice or no notice at all.

    To wit, what many people have called an "upgrade", I many times consider to be a forced "downgrade" that I'm compelled to adopt and pay for.

    I admit that it took me a few months to adapt from SQL 2000 to SQL 2005 (especially living in a split environment of the EM and SSMS. Once I adapted though, I never wanted to go back. To me that was an actual upgrade once I got used to it. The other side of it is the intellisense in SQL 2008 compared to 2005 doesn't really buy me more than saving a few keystrokes. There is no "leap" that I can really tell.

    Yes you can tell me about memory usage efficiencies and such, but no matter how much more efficient it is, if the same crappy programming is behind it, it doesn't really help.



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

    A little bit of this and a little byte of that can cause bloatware.

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

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