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| 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.shAfter 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 -verboseFinal 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 -verboseBelow 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 -verboseConclusions
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!
2 Responses
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
Thanks for your kind words, Daniel!
Best regards,
Enrique