Good Luck is Needed with Old Versions

  • Back around 2014, my then employer was putting a case together to move from the last SQL2005 servers.  The thing that clinched it was reliability.

    We worked out we might get perhaps 3 fewer unplanned outages over a two year period.  Even reducing the unplanned outage count by 1 per year would pay for the project, so it went ahead as a no-brainer.

    The upgrade was very timely.  Some application and database changes made soon after the upgrade increased memory requirements to beyond what the box could cope with.  We exploited the new Buffer Pool Extension feature which gave back enough performance to last us until the memory could be upgraded.

    It it aint broke don't fix it seldom takes into account the cost to the business of keeping the old stuff working, it stays focussed on the marginal cost of the upgrade.  When you take into account all the business costs, plus the loss of opportunity in not being able to use new features, then upgrades become much easier to justify.

    In my current job we plan to go live this week with SQL2019 for our development environment, with production following in about 4 weeks.  The high degree of compatibility between releases, plus the desire to present to the business the ability to exploit the latest features gives us the confidence to go ahead on this.

    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

  • Grant Fritchey wrote:

    Jeff Moden wrote:

    I agree with everything you said but, with all the really cool stuff that's been built into SQL Server in the last 8 years, couldn't you have cited a better reason to upgrade other than XE?  Sheesh!

    Honestly, I'm not sure how that slipped in. I think it was a brain fart, not my point at all. Apologies.

    Heh... Been there, done that.  Here's to things that fart in the night and long before coffee. 😀  Thanks, Grant.

    --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)

  • kiwood wrote:

    Here is the question that I wonder - how does it make sense to risk one's livelihood working for a company that doesn't upgrade?

    Any IT entity that does not know how to justify IT expenses is not long for this world.

  • EdVassie wrote:

    Back around 2014, my then employer was putting a case together to move from the last SQL2005 servers.  The thing that clinched it was reliability.

    Security is a good clincher too.

  • I have been sitting here with an upgrade to an Oracle 10 system lingering on the books for the last 2.5 years.  I am thinking of having a little party for the project, when it turns 3 in the fall.  Maybe it is my utter lack of ability to sell a project, maybe it is the department is going at full speed, and can only consider new items.  Probably the former.

    As for the costs of the upgrade getting steeper as you go on, there was a direct upgrade path from 10 to 11.  You can go directly to 12, but only if you are willing to reset everyone's password.  Going to 19 (Oracle did not want to have a version 13 for some odd reason), there may not be a direct path, so you may have to make a pit stop at an intermediate version.  Now come the questions.  Did this error/creeping bug happen in stage 1 or stage 2 of the upgrade?

  • kiwood wrote:

    Here is the question that I wonder - how does it make sense to risk one's livelihood working for a company that doesn't upgrade?

    Great point and, I'm sure, an impossibly hard question to answer. I like paying my mortgage (OK, I don't like it, but it's pay the mortgage or live on the street, so...), which means I'm going to sometimes do things that may not be the best in order to keep paying that mortgage. I get it.

    "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

  •  I like paying my mortgage (OK, I don't like it, but it's pay the mortgage or live on the street, so...)

    I am in the same boat and get the short term aspect of the situation. My wife would be quite upset if I simply quit today. But... one should always consider that the job may not be there tomorrow to pay the mortgage. And having your skills all tied in old software can be a huge damper on the ability to find that replacement job.

    I seriously think more IT people should always keep an eye on future employ-ability. I love my job and have no desire to change. But I also love my living situation more and will not risk that to keep the job. If the job becomes too outdated then it is time to suck it up and find the next one.

  • DinoRS wrote:

    It's not that my Supervisor or the Head of IT don't want to let me upgrade but rather that SQL Server 2019 hasn't been validated yet within this organization and therefore we're stuck with upgrading to 2017.

    Third party vendors are the thorn in our side as far as some upgrades are concerned. We've spun up 2019 for reporting and move some of our work there. That part is in our department's control. Unfortunately, other areas depend on apps from 3rd party vendors. One of them has at least validated their software on 2017 and they seem open to us rolling out 2019 with the database in 2017 compatibility. The other vendor is not so willing to validate anything past 2016. Using that as leverage to get us to upgrade to the latest version of their software to get to 2017. The databases for both these apps are for the same part of the business and live on the same server. Our company is not going to approve the dollars for two different SQL Servers which will only have one database on each. We have to live with the lowest common denominator. So now my job is trying to convince the business to upgrade a software package in order to only be one version behind instead of two.

    I guess it could be worse. This will retire two 2012 servers (QA and Prod) and only leave us with two 2014 servers to retire in the not to distant future. Everything else will be 2016 - 2019.

  • Third party contracts like that are only as good as the last test.

     

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • I am late to this party, but am reminded of a company where I worked as a contractor in 1995. They ran their accounting on a System 36 they had bought in 1983, the year the System 36 came out. It was slow, lacked storage space, and took up a bunch of room. The ledgers had to be printed and copied every month, as part of the new month process was to delete the last month to free up space on the 500MB disk.

    I suggested upgrading to a small AS/400 and a new version of the accounting software for better reliability and performance. The Controller was horrified "We paid $80,000 for that system. There's no way the owner will let us replace it". That was foolish.

  • Same old story.

    Thanks for sharing.

    "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

Viewing 11 posts - 16 through 25 (of 25 total)

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