Recently, I tweeted about having to restore fourteen databases in SQL Server 2000. I wasn’t surprised to receive some good natured ribbing about still having databases in SQL Server 2000, and I’m okay with that… for the most part. Yes, I know and agree that it is not good (major understatement of the year/decade) to still be on SQL Server 2000. Why? Not just because it is woefully out-of-date, not supported by Microsoft, and plain miserable to deal with at times, but there are some wonderful features in the later versions that it’d be awesome to take advantage of. Not to mention the embarrassment of admitting that, yes, we still use SQL Server 2000. At least we’re not running SQL Server 6.5 or 7.0, right? That I know of, at least. That has got to count for something.
While I’m at it, I might as well
confess mention that we are also running SQL Server 2005, 2008, 2008 R2, and 2012… and Oracle 11gR2.. and MS Access (don’t ask what versions, please. For the love of all things data, please don’t ask!) What? No SQL 2014? Nope. Not yet, anyway. We are painfully aware that having so many versions isn’t necessarily a good thing. Why can’t I do a merge or a CTE? Oh yeah… I’m in a SQL 2000 database. Ick. I am hopeful that we can come up with a good plan in the next year (or so) to somehow consolidate all (at least some!) of these instances into something more recent. At least management is aware of our need to consolidate/ migrate to the current century. It’s a start. Plus there are quite a bit of other important projects in progress at the moment.
So you may be wondering (or not)… for the love of all things SQL why are you still on SQL Server 2000?! I admit that I envy anyone in a position where they can keep upgrading to the newer versions soon after they come out or at least before they
are ridiculed aren’t supported anymore. So what can prevent someone from upgrading? Many things. Others may have different reasons, but some of the major ones I’ve encountered include:
The 90s Called. They Want Their VAX Back. (a.k.a. Higher Priority Projects)
What could be worse than running SQL Server 2000? How about a legacy VAX system from the 1990s? Now what if your core business applications including the database were still running on said VAX system? And what if the five year project to migrate off said VAX turned into a ten+ year project for various reasons and it’s still not done? That is a very long story and I’m not blaming anyone. Stuff happens. Let’s just move on and get it done. Yep. That trumps the SQL Server 2000 boxes by at least a few years. At least most of one of those major applications is on SQL Server… 2005. I know. I know. Yes, that one needs to be upgraded as well. <insert painful sigh here> The good news is we’ve renewed our efforts to get those apps off the VAX much quicker. I’m hoping it’ll happen in the next year or two. Positive thoughts. Positive thoughts. And, no. It’s not going to SQL 2000 or 2005… itsgoingtooracle11gr2orpossibly12c. All kidding aside, I’m okay with that. No, really. I am. The “why” on that one is a bit of a long story, but I’m good with it, and that’s probably where we’ll end up putting everything.
Oh, What a Tangled Web We Weave
Here is another reason why upgrading isn’t so easy or as straightforward as one may think… or hope… or wish. One of our main production SQL Server systems is still running on SQL 2005. I don’t like doing in place upgrades, if at all possible, because of the risks involved. So I’d much rather migrate this system to another box running SQL Server 2012 (at least) or even *gasp* 2014. So what is delaying us from at least moving to another bigger/better/more beautiful box? All the flippin’ interfaces. When I stop to count up all the different applications and systems that access this box and the databases on it, my eyes start to glaze over, my brain starts to throb, and I feel a bit faint. It would be do-able but I strongly believe it would be a fairly large/nightmarish undertaking; one that we must start at some point in this decade soon.
This box contains at least five major databases. Of these five major databases, one very critical database is heavily used by multiple applications for different departments (I’ve counted at least four so far). The interfaces to it (I’ve counted twelve off the top of my head) would have to be analyzed and tested. Their respective databases may need to be upgraded as well at some point. That database is also replicated to two different servers (SQL 2005 and SQL 2008), internal and external. There are jobs to import/export data to/from other servers. There are linked servers from this one to other servers. Other servers link to it as well. Can’t forget the SSRS servers that also use it. At least those are running on SQL 2008 R2.
All together this major system is actually spread across at least eight different servers of various database versions including Ingres, Oracle, SQL 2000, SQL 2005, SQL 2008, SQL 2008 R2, and SQL 2012. To say it’s a bit of a mess is an understatement. And that’s just one system. We currently support over 70 SQL Server instances of various versions, not to mention Oracle
and MS Access. Some are in-house developed and some are vendor-supported. Some we control and some are out of our control.
Kill It! Kill It With Fire!
So how did it get that way? I’m not really sure because I inherited a lot of this and don’t have the background/history as to why certain decisions were made… or I may have just blocked it from memory. It could just be the result of put this here, put this there, and before you know it you have a Frankenstein of a system/environment. Having said that, I’m trying to not focus so much on the “how or why” but more on “where do we go from here?” and “how can we make this better?” “Kill it with fire” is not a preferred option… yet. So please put the pitchforks away… for now.
I am hopeful that we can start on a plan to tackle these out-of-date servers once we’ve finally moved everything off the VAX or even sooner. Unfortunately, it’s going to take some time for all of it. Not to mention production issues that pop up and being pulled in on other important projects (so-and-so bought a new application with a new database and now we have to put it somewhere and figure out the licensing and by the way you need to learn Oracle and you need to learn APEX and SOA and how that’s going to fit into everything and don’t forget we need to migrate those MS Access databases to Oracle because we’re
thankfully not supporting MS Access anymore…)
Please don’t take this wrong. I am actually looking forward to learning more about Oracle and APEX and SOA and whatever comes next. It can just be a bit overwhelming at times. In addition, I don’t say it enough, but I am extremely thankful to have a wonderful and very talented team whom I can count on to help make important decisions and help us get to where we need to be – in the current century or at least somewhere closer, if not beyond. 😀
Here’s To You!
So if you’re on the latest and greatest versions, I commend you. No, seriously. I do. No jokes. No sarcasm. It’s great. Really. It is. However, if you’re like us and are still running on old versions that aren’t supported anymore, I feel for you. It can be painful and challenging. If you’re like me and tend to feel depressed embarrassed by the old technology, don’t be. Instead, hold your head up high. You’re probably doing the best you can with what you’re given and for your specific environment. Some things are out of our control. We can only do our best to get where we need to be. Hopefully, you won’t need a miracle to make it happen – just some support from your peers and quite possibly a few shots of your favorite beverage from time to time. So good luck and may all your databases stay online… and up-to-date.