Database Patch News — November 2021

Database Patch News — November 2021

Welcome to Database Patch News, Buda Consulting’s newsletter of current patch information for Oracle and Microsoft SQL Server. Here you’ll find information recently made available on patches—including security patches—and desupported versions.

Why should you care about patching vulnerabilities and bugs? Two big reasons:

  1. Unpatched systems are a top cyberattack target. Patch releases literally advertise vulnerabilities to the hacker community. The longer you wait to patch, the greater your security risk. 
  2. Along with running a supported database version, applying the latest patches ensures that you can get support from the vendor in case of an issue. Patching also helps eliminate downtime and lost productivity associated with bugs. 

Here are the latest patch updates for Oracle and SQL Server:

Oracle Patches:

October 2021 Quarterly Patch Updates:

21c – Release Update 21.4 is available (33239276 & 33197565)

19c – Release Update 19.13 is available (33192793 and 33192694)

18c – Release Update 18.14 is available (32524152 and 32552752)

12cR2 – Release Update OCT 2021 is available (33261817 and 33192662)

Regular support ends in Mar 2023 and extended support ends in Mar 2026.

12cR1 – Release Update 211019 is available (33128590 and 33192628)

Regular support ended in July 2019 and extended support ends in July 2021.

11gR4 – Patch Set Update 201020 is available (31720776)

Regular support ended in October 2018 and extended support ended December 31, 2020.

SQL Server Patches:

SQL Server 2019

Cumulative update 13 (Latest build) Released October 5, 2021

Mainstream support ends Jan 7, 2025

Extended support ends Jan 8, 2030

 

SQL Server 2017

Cumulative update 27 (Latest build) Released October 27, 2021

Mainstream support ends Oct 11, 2022

Extended support ends Oct 12, 2027

 

SQL Server 2016 Service Pack 3

Release date: September 15, 2021

Mainstream support ends Jul 13, 2021

Extended support ends Jul 14, 2026

 

SQL Server 2014 Service Pack 3

Cumulative update 4 Release date: Jan 12, 2021

Mainstream support ended Jul 9, 2019

Extended support ends Jul 9, 2024

 

Note: All other SQL Server versions not mentioned are no longer supported.

 

Database Patch News — November 2021

Database Patch News — July 2021

Welcome to Database Patch News, Buda Consulting’s newsletter of current patch information for Oracle and Microsoft SQL Server. Here you’ll find information recently made available on patches—including security patches—and desupported versions.

Why should you care about patching vulnerabilities and bugs? Two big reasons:

  1. Unpatched systems are a top cyber attack target. Patch releases literally advertise vulnerabilities to the hacker community. The longer you wait to patch, the greater your security risk. 
  2. Along with running a supported database version, applying the latest patches ensures that you can get support from the vendor in case of an issue. Patching also helps eliminate downtime and lost productivity associated with bugs. 

Here are the latest patch updates for Oracle and SQL Server:

Oracle Patches:

July 23, 2021 Quarterly Patch Updates:

21c – Released January 13, 2021, Version 21.1; no Quarterly patch yet

19c – Release Update 19.12 is available (32895426 and 32876380)

18c – Release Update 18.14 is available (32524152 and 32552752)

12cR2 – Release Update 210720 is available (32916808 and 32876409)

Regular support ends in Mar 2023 and extended support ends in Mar 2026.

12cR1 – Release Update 210720 is available (32917447 and 32876425)

Regular support ended in July 2019 and extended support ends in July 2021.

11gR4 – Patch Set Update 201020 is available (31720776)

Regular support ended in October 2018 and extended support ended December 31, 2020.

 

SQL Server Patches:

SQL Server 2019

Cumulative update 11 (Latest build) Released June 10, 2021

Mainstream support ends Jan 7, 2025

Extended support ends Jan 8, 2030

 

SQL Server 2017

Cumulative update 24 (Latest build) Released May 10, 2021

Mainstream support ends Oct 11, 2022

Extended support ends Oct 12, 2027

 

SQL Server 2016 Service Pack 2

Cumulative update 17 Release date: March 29, 2021

Mainstream support ends Jul 13, 2021

Extended support ends Jul 14, 2026

 

SQL Server 2014 Service Pack 3

Cumulative update 4 Release date: Jan 12, 2021

Mainstream support ended Jul 9, 2019

Extended support ends Jul 9, 2024

 

Note: All other SQL Server versions not mentioned are no longer supported.

When Should The Database Be Updated?

When Should The Database Be Updated?

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.

Database Patch News — November 2021

Database Patch News — March 2021 (Issue 7)

Welcome to Database Patch News, Buda Consulting’s newsletter of current patch information for Oracle and Microsoft SQL Server. Here you’ll find information recently made available on patches—including security patches—and desupported versions.

Why should you care about patching vulnerabilities and bugs? Two big reasons:

  1. Unpatched systems are a top cyber attack target. Patch releases literally advertise vulnerabilities to the hacker community. The longer you wait to patch, the greater your security risk. 
  2. Along with running a supported database version, applying the latest patches ensures that you can get support from the vendor in case of an issue. Patching also helps eliminate downtime and lost productivity associated with bugs. 

Here are the latest patch updates for Oracle and SQL Server:

Oracle Patches:

January 19, 2021 Quarterly Patch Updates:

21c – Released January 13, 2021, Version 21.1; no Quarterly patch yet

19c – Release Update 19.10 is available (32218494 and 321266828)

18c – Release Update 18.13 is available (32204699 and 32126855)

12cR2 – Release Update 210119 is available (32228578 and 32126871)

Regular support ends in Mar 2023 and extended support ends in Mar 2026.

12cR1 – Release Update 210119 is available (32132231 and 32126908)

Regular support ended in July 2019 and extended support ends in July 2021.

11gR4 – Patch Set Update 201020 is available (31720776)

Regular support ended in October 2018 and extended support ended December 31, 2020.

 

SQL Server Patches:

SQL Server 2019

Cumulative update 9 (Latest build) Released Feb 2, 2021
Mainstream support ends Jan 7, 2025
Extended support ends Jan 8, 2030


SQL Server 2017

Cumulative update 23 (Latest build) Released Feb 24, 2021
Mainstream support ends Oct 11, 2022|
Extended support ends Oct 12, 2027


SQL Server 2016 Service Pack 2

Cumulative update 16 Release date: Feb 11, 2021
Mainstream support ends Jul 13, 2021
Extended support ends Jul 14, 2026


SQL Server 2014 Service Pack 3

Cumulative update 4 Release date: Jan 12, 2021
Mainstream support ended Jul 9, 2019
Extended support ends Jul 9, 2024


SQL Server 2012 Service Pack 4

Release date: Oct 5, 2017
Mainstream support ended Jul 11, 2017
Extended support ends Jul 12, 2022

Note: All other SQL Server versions not mentioned are no longer supported.

 

How Poor Communication Brought an Oracle System Down

It was very cold and early on a Monday morning when I received a call from one of my fellow system administrators. He reported that one of our production databases would not come back online after the server hosting the database was restarted. 

Most DBAs would start investigating this issue by looking at database alert logs. But my experience led me to ask my fellow system admin the following question: “What changes did you make on the server prior to the reboot?”

It was his answer to that question that allowed me to quickly understand the issue and fix it in just a few minutes. 

Apparently the system admin (not the DBA) was conducting vulnerability testing and, as a result, made a change to the main listener.ora file that disabled all databases from being able to dynamically register to Oracle database listeners. 

By default, an Oracle database will try to dynamically register to an Oracle database listener on port 1521. This registration process allows connections to the database from outside of the server. The database was online and operational, but because the dynamic registration option was disabled it could no longer register to the listener. So no users could connect to the database.

The fix for this was adding a static listener to the listener.ora for the database hosted on the server, thus allowing it to receive connections. Once the static listener was added, all users were able to connect to the production database without error.

The Technical Problem\

Let’s break this incident down in more detail:

This is the original Listener file 

LISTENER=

  (DESCRIPTION=

    (ADDRESS_LIST=

      (ADDRESS=(PROTOCOL=tcp)(HOST=MyServer)(PORT=1521))

      (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))

The administrator added one line (see below in red):

LISTENER=

  (DESCRIPTION=

    (ADDRESS_LIST=

      (ADDRESS=(PROTOCOL=tcp)(HOST=MyServer)(PORT=1521))

      (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))

DYNAMIC_REGISTRATION_LISTENER=OFF

This prevented any databases that do not have a static listener specified in the listener.ora file from accepting connections..

The Technical Solution

To correct the problem, I added a static listener to the listener.ora file (see below in red):

LISTENER=

  (DESCRIPTION=

    (ADDRESS_LIST=

      (ADDRESS=(PROTOCOL=tcp)(HOST=MyServer)(PORT=1521))

      (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))

DYNAMIC_REGISTRATION_LISTENER=OFF

SID_LIST_LISTENER=

(SID_LIST=

    (SID_DESC=

      (GLOBAL_DBNAME=MyDBName)

      (ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1)

      (SID_NAME=MySID))

)

You can find detailed information about the listener file for Oracle version 19c here.

The Communication Problem

We have mentioned in this blog before that almost all problems with technology projects are the result of poor communication. This principle holds here as well. Because the system administrator did not keep any of the DBAs on our team “in the loop” about their vulnerability testing, or the resulting changes, those changes caused production downtime.  

The Communication Solution

Any change to a server, database, or application must be communicated to all responsible parties beforehand. In fact, a better approach in this case would have been to ask the DBA to make the change to the listener file rather than the administrator making the change himself. This would have ensured that an experienced DBA had reviewed the change and understood the potential impact.

The moral of the story is: Keep your DBAs in the loop when you’re making system changes. It’s our job to proactively prevent database issues others might miss.

A Word on Database Security

While an action taken by the system administrator caused a problem in this situation, it should be applauded from a database security standpoint that vulnerability testing was conducted because it exposed a potential vulnerability (the dynamic registration). It is a best practice to disable dynamic registration unless it is necessary for the organization, and unless the associated risk is mitigated by other practices, such as changing the default listener port.  

Database vulnerability testing is a crucial part of a comprehensive IT security plan and is often overlooked. For the reasons described above, the process should always include a member of the DBA team. See a few of our Database Security related blogs here