To upgrade or not to upgrade? That’s the question!

 

Saturday’s post about 19c generated a lot of feedback on a number of my social media networks. To generalise, you could probably split the responses into two camps.

Of course, this discussion applies equally to other technologies, including the middle tier and development frameworks. It can also be applied to people’s attitudes to patching, as well as to upgrades.

We don’t want to upgrade.

I totally get why people think this is a viable option. Such arguments might include:

  • Stability is more important than new features. With new versions come new bugs and new instabilities.
  • We don’t have time/resources to test our application against the new version.
  • The cost (in time and resources) of upgrading is not worth the pay-off of being at the new version. It’s cheaper to pay for extended support than upgrade.
  • The version we are using has all the features we need, so upgrading is a waste of time.
  • Our customers don’t care about new versions.
  • We do all our business logic in the middle tier, so the DB is just a bit bucket. New features are irrelevant.

We want to upgrade to the latest versions.

This is closer to my position, with a few important caveats.

  • You have to have time to learn the new version, so you can get the most out of it, and not fall foul of new features that do things you might not expect.
  • You need to test your application properly against it, to make sure the new version doesn’t break anything. This seems to be the biggest sticking point for companies that haven’t invested in automated testing. A lacklustre approach to testing your application will often result in a disastrous upgrade.

So why would you bother? This is where I do my totally biased sales pitch. ๐Ÿ™‚

New versions contain new features, some of which actually work. ๐Ÿ™‚ There are headline new features that are just marketing bumf and irrelevant to me, but there are also some really useful things, which make life easier for you and your company. Look what’s happened just for online operations in the last few versions. I know some of these features have saved loads of downtime for people.

I tend to think development new features drive change more than DBA new features, because they outwardly affect more people in the company. For people who do development in the database, the last few releases have included a lot of really useful things. Let’s look at just one of them that is dear to my heart.

If you know what is in the new releases and you don’t find anything compelling, then a choice to stay where you are is fine. We don’t all want the same things, and different opinions are fine. If you are just sticking with what you’ve got because you can’t be bothered to learn the new stuff, and you are content to do the same thing you’ve always done forever, I think you are selling yourself and your company short. Just my opinion though.

I’ve already declared my bias towards upgrades. Why? Because many of the problems I come across actually come from not staying up to date with versions and/or patches. The rest of the industry keeps moving, and somehow DBAs want to be totally static. I don’t understand that. Caution is good. Static is bad IMHO! ๐Ÿ™‚

Cheers

Tim…

Author: Tim...

DBA, Developer, Author, Trainer.

One thought on “To upgrade or not to upgrade? That’s the question!”

  1. Likely because dbas are at the front-end of “it’s the database”, the common expression used by every IT newb dabbling in using databases as stacking places for unstructured data (aka JSON and OO stuff).
    You’d be hard pressed to find among those one who understands what 1st-normal-form means and why is it important to avoid unnecessary “big data”…
    The current state of IT is a total disgrace, with every newb an instant expert because they “read in a web site this is the way to do things”.
    Until that changes, you’ll find most dbas avoiding upgrades: they know what comes with that.
    And let’s not go into the egregious bugs that have plagued every new release of Oracle since 9i…
    (again: of course, the fault of the dbas…)

Comments are closed.