April 30, 2015 at 9:49 am
Xavon (4/30/2015)
An interesting point on this; PCI PADSS (credit card industry rules) require that the system be under support. So if your 2005 database holds credit card information, even if it is temporary and highly encrypted, you will still have to upgrade to 2008 or higher by 2016/04/12 or be out of compliance and incur the associated penalties.
Great point, and certainly this is a reason to upgrade. Of course, if you're storing PCI data, you should get off 2005 to get to better encryption algorithms, and perhaps implement TDE.
April 30, 2015 at 9:57 am
lshanahan (4/30/2015)
In the comments of the SQL Server Blog article someone mentioned the cost issue, to which the team quickly responded by pointing to a study by Forrester Consulting (commissioned by Microsoft) claiming that the costs would be recouped in less than a year.The study itself tosses around terms like "risk-adjusted ROI", "net present value" "productivity increases" and so forth.
At which point my BS detector started screaming like a banshee. If someone can't explain how I'll recoup my investment in two sentences or less without using a single accounting term, then what you're really saying is "Yeah, we know it's expensive and we really don't care."
I, too, find this to be suspect. My guess is that in some narrow niches, this is true. If I can consolidate instances, if I take advantage of manageability changes, perhaps. However I think you need to be careful here, especially now that licensing has changed dramatically. If I go from a 4 CPU, 4 core machine on 2005 (4 licenses), I'd be looking at a 16 license machine today on the same hardware. Granted, I could replace the hardware, but I'm incurring more costs.
Certainly the latest T-SQL changes could mean that my app could get much more work done, perhaps more tran/sec, which means less hardware or more revenue, but I have to be able to take advantage of that. In most of the older instances I've used, I can't necessarily use more power. I can't afford the code changes, the manageability is set, etc. If I needed more power or the other items, I've probably already upgraded.
April 30, 2015 at 10:00 am
Ed Wagner (4/30/2015)
Great timing for this article. I'm planning the installation of a new server and it'll be 2012, not 2014. As much as I'd like to move to 2014, I can't say with confidence that it's mature enough for production yet. I heard that SP1 was taking down servers, which is pretty sad.The botched SP release is nothing new. My 2005 server is at SP3. When I tested the installation of 2005 SP4 on a test server, it broke SQL Server - part was at SP3 and part at SP4. After digging through logs and researching the problem, the solution from MS was to uninstall SQL Server and then reinstall it and patch it up to SP3. In my book, that's not a solution and it's certainly nothing I'd install in production. Going back further, we can look at the debacle with SQL 2000 SP3 and 3a.
These events (2000 SP3, 2005 SP4, 2014 SP1) all tell me that I'm comfortable being behind the curve a bit. I'd much rather opt for safety and stability instead of the newest features and coolest functions. Of course, I know the new functions can be used to do things more efficiently, but I place a very high value on stability.
Here's what I'd say. If you're moving to a fairly similar use of features from 2005 to a new version, go to 2014. The new stuff doesn't affect the way things work. It's stable, it works well. There haven't been and fundamental issues with 2014 that have been shown.
As far as the SP bug, it was a narrow bug, limited to the SSIS catalog. Plenty of people, I'd say the majority, don't use this, so they won't have issues. For those that do, certainly they're stuck at a CU, pre-SP1, for now.
However SP bugs could be released (or CU bugs) with any version at any time. That's not a reason to avoid upgrading. It's a reason to test well before you apply a patch, or be conservative and give the patches some time for others to test.
April 30, 2015 at 10:01 am
Iwas Bornready (4/30/2015)
When I ask our DBA about upgrading he just asks why. He says it is too expensive unless there is a compelling reason. We are on 2008 R2 and he says it is secure and functioning well. So here we sit.
Check and mate.
As neat as it is to work with the latest features, most of the time I manage server instances, the upgrade doesn't allow me the chance to do that.
April 30, 2015 at 10:07 am
Wayne West (4/30/2015)
I'm curious: how often does Oracle come out with a new major version, or IBM with DB2?
They do it differently. When I used to manage all of these, DB/2 did more point releases and service packs, including features. MS had pressure not to use SPs for features, so they stopped, which I appreciate.
Oracle uses a combination, and adds letters, so they'll 10, 10g, 10c, etc, which are really versions in some sense. I think their cycle is a bit slower, but not a lot. They also seem to revel in the confusion they can create with numbering and obfuscation
May 3, 2015 at 5:36 am
I know of a case where DBA work was outsourced. Everything ran more-or-less OK until some very old hardware hosting a very old version of some mission critical software went pop. The problem was that the version was so old that no-one in the outsourced team had any experience with the particular DB platform version that was supposed to be supported. It took a long time to fix the problem and the business repercussions were not pleasant.
The thing that was overlooked was that outsourced staff are just like us. They want to get their hands on the new toys. Would you accept a job offering you the chance to work on SQL2000?
So there are hidden costs to not upgrading.
Another case I heard was where there was a seven figure project to upgrade a piece of hardware. One year on IT had to go cap in hand to ask for another seven figure sum to upgrade again. What had happened was the first upgrade was to the highest version that supported the legacy systems it had to interact with. Unfortunately that version went out of support within 12 months and it absolutely was a system you wouldn't want to run without support.
In short, look at the bigger picture, its not just about the cost of the system in isolation
May 4, 2015 at 10:14 am
David.Poole (5/3/2015)
The thing that was overlooked was that outsourced staff are just like us. They want to get their hands on the new toys. Would you accept a job offering you the chance to work on SQL2000?
What's the pay?
I completely agree that it isn't just the cost of software. I've run into a few environments that were paying very highly for VAX, COBOL, and other experience because they could only hire contractors, and those were expensive.
However, I can't say it was a bad decision as long as they weren't dependent on one person. Who knows what the cost might have been to rewrite or upgrade the entire system.
It's not a system in isolation, but it also can be a few systems and not all. Would you work on SQL 2000 if there were SQL 2012 systems there? Would you refuse a job that had 2000/2005 instances along with others?
It's not a simple answer.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply