Learn to patch the way God intended (S1E2)

In the previous episode we showed how to apply patches directly on the Oracle Home in use, a process known as in-place patching, a process that has proven to be time consuming, tedious, and demanding a long suspension of service time.

Fortunately there is a better way to apply patches, which is presented below.

Out-of-place patching

This name is given to the recommended way of applying patches, which involves working on a new Oracle Home (hereinafter OH) that will contain the patched executables.

Let’s see how a patching cycle is developed under this modality.

Initial situation

We have a server called server1, in which Oracle Database Server 19c is installed, in an Oracle Home called DBHome1, which supports a single instance database.

$ echo $ORACLE_HOME
/u01/app/oracle/19.0.0/db_1
This OH has the following patches applied:
34765931 database release update 19.18.0.0.0
34786990 ojvm release update 19.18.0.0.0
34777391 jdk bundle patch 19.0.0.0.230117
35573556 database mrp 19.18.0.0.230718
34972375 datapump bundle patch 19.18.0.0.0

1

2

Creation of a new Oracle Home

A directory is created that will later be associated with an Oracle Home named DBHome2.

$ mkdir /u01/app/oracle/19.0.0/db_2

Oracle Database installation

Unzip the Oracle Database 19c base software in the newly created directory.

$ export DB_HOME=/u01/app/oracle/19.0.0/db_2
$ export STAGE=/stage

$ unzip -oq ${STAGE}/LINUX.X64_193000_db_home.zip -d ${DB_HOME}
$ rm -rf ${DB_HOME}/OPatch
$ unzip -oq ${STAGE}/p6880880_190000_Linux-x86-64.zip -d ${DB_HOME}

After this we have the Oracle Database 19.3 binaries in the new directory.

3

4

Patching the new Oracle Home

The following patches are applied:

36233263 database release update 19.23.0.0.0
36199232 ojvm release update 19.23.0.0.0
36195566 jdk bundle patch 19.0.0.0.240416
36701173 database mrp 19.23.0.0.240618
36420641 datapump bundle patch 19.23.0.0.0
$ ${DB_HOME}/runInstaller -silent -printtime \
-waitforcompletion -ignorePrereqFailure \
ORACLE_HOME_NAME="DBHome2" -applyRU ${STAGE}/36233263 \
-applyOneOffs ${STAGE}/36199232,${STAGE}/36195566,${STAGE}/36420641 \
-responseFile ${DB_HOME}/install/response/db_install.rsp \
INVENTORY_LOCATION=/u01/app/oraInventory \
UNIX_GROUP_NAME=oinstall \
ORACLE_BASE=/u01/app/oracle \
oracle.install.option=INSTALL_DB_SWONLY \
oracle.install.db.InstallEdition=EE \
oracle.install.db.OSDBA_GROUP=dba \
oracle.install.db.OSBACKUPDBA_GROUP=backupdba \
oracle.install.db.OSDGDBA_GROUP=dgdba \
oracle.install.db.OSKMDBA_GROUP=kmdba \
oracle.install.db.OSRACDBA_GROUP=racdba \
oracle.install.db.rootconfig.executeRootScript=false

$ opatch napply ${STAGE}/36701173 -oh ${DB_HOME} -silent

$ sudo /u01/app/oracle/19.0.0/db_2/root.sh

After this we have the Oracle Home DBHome2 containing the Oracle Database 19.23 binaries.

Suspension of service

In order to use the new OH, the database must be shutdown as a first step.

SQL> shutdown immediate;

5

6

Database patching

The environment variables are updated to reference the new OH, and after that you can continue with the database catalog update, using the datapatch utility.

$ export ORACLE_HOME=/u01/app/oracle/19.0.0/db_2
$ export PATH=${ORACLE_HOME}/bin:${PATH}:.

SQL> startup;

$ datapatch -verbose

Final situation

You have the database operating normally, from the new Oracle Home DBHome2.

7

Advantages of out-of-place patching

1. Minimum downtime

Since a new Oracle Home is being used, all the time it takes to prepare it does not affect the availability of the service, unlike in-line patching.

The suspension of the service is limited to the moment in which the new binaries must be used, with the change of OH, and with it the update of the catalog with datapatch:

SQL> shutdown immediate;

$ export ORACLE_HOME=/u01/app/oracle/19.0.0/db_2
$ export PATH=${ORACLE_HOME}/bin:${PATH}:.

SQL> startup;

$ datapatch -verbose

Below are the times I recorded in my test environment, where I only applied Release Updates/RU (no Monthly Recommended Patches/MRP or additional one-offs). Both the time taken for the in-place and out-of-place options are shown:

It is evident that the time increases almost exponentially with the application of a new RU in-place, while for out-of-place the time is much shorter and stable.

2. Minimum space consumption

Below is the space consumed that I recorded in my test environment, where I only applied the Release Updates/RU (no additional Monthly Recommended Patches/MRP or one-offs). It shows both the space taken for the in-place and out-of-place option:

Since for each patch applied, Oracle must obtain a backup of all the modified objects, it is evident that the space occupied increases with the in-place application of each new RU, while for out-of-place the space is much smaller and stable.

3. Simplicity in the event of rollback

If for some reason we need to undo the patching application, we simply need to go back to the previous OH and update the catalog, again with minimal suspension of the service:

SQL> shutdown immediate;

$ export ORACLE_HOME=/u01/app/oracle/19.0.0/db_1
$ export PATH=${ORACLE_HOME}/bin:${PATH}:.

SQL> startup;

$ datapatch -verbose

Conclusions

While perhaps not the most widely used by DBAs, out-of-place patching is by far the most efficient, requires little disk space, and what’s even better: it has the lowest service downtime.

In the next episode we will see how to further simplify out-of-place patching, so stay tuned!

Did you find this article interesting, did you have any doubts, do you want to suggest a topic to cover, leave me your comments or contact me me right now!

2 Responses

  1. Very cool article. Out-of-place patching is definitely the best way to patch your Oracle Database.

    I really like the layout and graphics in the article. Very nice!

    Kudos!

    Regards,
    Daniel

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts

Learn how to identify the row involved in the occurrence of the wait even "enq: TX - row lock contention"
Learn how to resolve the CRS-2304 GPnP profile signature verification failed error when starting an 11.2 database on a 19c cluster.
Learn how to fix corrupted permissions on an Oracle Home, either Oracle Grid or Oracle Database Server.

Need Help?

Fill in these details and I will be in touch as soon as possible.