Why if it’s not broke don’t fix it does not work for databases (or anywhere in IT for that matter)

One of the hotly debated items among IT professionals is the age-old question,”When should the database be updated?” At Buda Consulting we always like to make sure our clients are running the latest, secured and supported versions of any software in any environment we manage.  This includes software products from Oracle’s database and Microsoft’s SQL Server to PostgreSQL. But we have noticed that this has not always been the case when we come into a client’s company and perform our global product health check.  

In my experience I have worked with DBA’s and System administrators who have always said if it is working we should not touch it and I can understand why some professionals and managers may feel this way.  When your database or application is offline it creates stress as administrators are tasked with getting the service(s) back online as soon as possible.  The idea is if we do not touch anything it should just work without issue but experience shows this is not always the case.  When it comes to databases specifically, not touching a db from time to time can have catastrophic results.  

As DBA’s if we did not look at your database’s tablespace stats, we would never know when your instance was about to run out of space at the tablespace or filesystem/ASM disk group level.  Not noticing this would result in your database eventually not being able to write data which would result in your application/database crashing.  

Another excuse (yes, that is what I call not upgrading your software!) I hear from time to time is new software versions introduce bugs.  That is true but almost all software versions will introduce bugs.  Most bugs are usually outlined in the KNOWN BUGS section of a software release’s readme while others have yet to be discovered.  The part this excuse does not take into account is that new software usually fixes bugs and security exploits that were not patched in the older version of the software. Whenever you are in doubt contact Buda Consulting for a database security assessment.

Let’s determine “When should the database be updated?”

As someone who has worked in both the private and public industries of IT, I have seen the dire consequences of failing to keep your software up to date.  This is a widespread problem in most public sector entities as most do not generate revenue but provide a service for the citizens of said state.  Because money is usually very scarce most IT budgets tend to get trimmed to the detriment of the agency.  I have seen time and time again where a mainframe service was not maintained over the years because the original administrators of the platform either moved on or retired. Because these admins were the ones that implemented the platform, once they left the knowledge of administering and maintaining the platform left with them.  

This caused new staff who did not know about the platform to just “keep the lights on” and not patch the environment in fear of breaking something that was not broken.  Over time the software running the platform moved further away from the latest version of the platform until a direct upgrade path to the new platform was impossible without vendor intervention or consulting services.  Once the vendor is involved you can expect the cost of the upgrade to not be cost effective.  I have seen quotes for upgrade work as high and two (2) million dollars to upgrade mainframe systems that could have easily been avoided had both old and new administrators put forth their best effort to make sure the platform was always running the latest software.  

It is industry best practice, especially when it comes to databases, that moving to a new software version should only be done after the release of the first service pack.  For instance as of the writing of this article Oracle’s latest database software is on version 21c.  Once  service pack one of 21c (21cR1) is released, all companies using 21c base release or older software versions should have started creating an upgrade plan that should be implemented in no less than six months to a year.  Like I explained above, by not keeping your software upgraded to the latest version you put your company at risk of having to spend a lot of money down the line to hire an outside company to come in and perform the upgrade as you are no longer able to easily upgrade from one version to the next.  

So if you are running Oracle Database versions 11g or 12c, it’s time to start planning an upgrade to at least 19c or 21c.  If you are running Microsoft SQL Server 2016 it’s time to start planning an upgrade to at least SQL Server 2017 CU 24 or SQL Server 2019 CU 11.  We cannot stress enough that the old if it’s not broken don’t fix it methodology needs to go away.  In the age of constant security breaches it is very important, now more than ever, to keep your software up to date with the latest patches to make sure you are protected against the worst of the software exploits that are running around the interwebs.

And if you like this article, please share it with your colleagues and subscribe to our blog to get the latest updates. Schedule a 15 minute call with Buda Consulting today.