Good Luck is Needed with Old Versions

  • P Jones wrote:

    Reading these posts makes me feel better about only having SQL Server 2016 (and an exit plan for it) and procrastinating over upgrading my Windows 8.1 tablet because it works as it is. Migrations are scary so good luck to anyone on old software and hardware especially with that first hurdle of getting approval from those holding the purse strings.

    Yep, it is scary. For good reason. Upgrades can break stuff. Newer isn't always better. I don't recommend that you get the latest and greatest (?) without testing and validation.

    HOWEVER!!!

    I still come back to, old software isn't just a little slower or a little less capable. It's vulnerable. Hardware failures can impact the software. Associated software can fail. The older it gets, the more brittle it becomes. It becomes an inherent risk.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • sean redmond wrote:

    What about the appliance argument? Namely, there's an application running on SQL Server 2008 & Windows Server 2003 that runs purely in-house and is not connected to the Internet. If we leave it alone, the likelihood of it breaking is less than that of us upgrading it. And if we upgrade it, it will cost money with the new hardware requirements, new licence fees and possibly having to pay developers for hundreds of hours because the old frameworks are no longer supported. We have an old server kept aside as replacement hardware & the original install media. If it ain't broke, don't fix it.

    I've come across this argument online and my standard response is to put it into VMs. The core point made though, is that if it works and is kept internal, does it really need to be upgraded?

    Maybe not.

    It's still going to be getting more and more brittle over time. And the older it gets, the harder the upgrade process becomes. There's no easy answer here, not really.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Perry and David, you know I agree.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • It's still going to be getting more and more brittle over time. And the older it gets, the harder the upgrade process becomes. There's no easy answer here, not really.

    Agreed. Contingency plans need to be drawn up balancing the cost of upgrading, the cost of replacement or the cost of an alternative of the service in question. At what point or under what conditions do you start with the follow-on system so that the failure of the legacy system is not a setback for the company?

    An example has since come to mind, although not in the DB world. A guy I knew worked in a printery and they had an expensive, high quality scanner from the Israeli company Scitex (I believe it was). The drivers for it ran on Mac OS 9 on a Power Macintosh G4 from the year 2000 and it worked well. I talked with him about it around 2012 or so and they weren't sure what to do. Drivers, he said, were no longer available and while they had the money for a new PC or a Mac Pro, they were forbidden to upset the running system. The plan was, he reckoned, to let it naturally die and then get a new high-end scanner. These things are very pricey though. And a Power Mac G4 in 2012 must have been (relatively)  slow.

    • This reply was modified 6 months, 4 weeks ago by  sean redmond.
  • My last company did a lot of engineering and testing. One thing they found is that most computer hardware failures occurred during startup. Evidently computers can just run forever, but when the power cycles, you find all the faults that have been building up. So, for really old hardware, it can fine. Just fine. And then there's a power outage due to weather and BOOM!!

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Grant Fritchey wrote:

    My last company did a lot of engineering and testing. One thing they found is that most computer hardware failures occurred during startup. Evidently computers can just run forever, but when the power cycles, you find all the faults that have been building up. So, for really old hardware, it can fine. Just fine. And then there's a power outage due to weather and BOOM!!

    Ye Gods that made me twitchy.  I can remember moving hardware to a new custom built server room.  All equipment was powered off on Friday night, the move was over the weekend and switch on was at 05:00 Monday morning.  About 30% of the servers failed, mainly due to broken HDDs.

    The post-mortem revealed that the oil around the bearings in the HDD had set solid in a combination of age and the accumulation of swarf over its execution time.  If we hadn't powered off the servers, or switched them on as soon as we moved them from on building to the other we would have been OK.

    In another organisation the SysAdmins were pushing for us to migrate one of the oldest DB servers and its contents.  The case from the chief SysAdmin was that the physical size of the old server consumed quarter of a rack.  They could replace the one ancient server with 4 new rack mounted servers, each one many multiples of the processing power of the original and requiring far less electricity and cooling to run.  I think the new servers, although mid-range, were powerfull enough to run a ridiculous number of additional VMs.

    When ancient hardware eventually breaks it becomes disaster recovery time rather than "planned outage".  Also, with ancient hardware your internal stocks dwindle until you are running a production system on something where your DR strategy is not worth the paper it is written on.  Your DR strategy needs to change with the dwindling availability of parts.

Viewing 6 posts - 31 through 35 (of 35 total)

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