8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Patching : Apply a Database Release Update (RU) to Existing Data Guard ORACLE_HOMEs

This article gives an example of applying a database Release Update (RU) to existing Data Guard ORACLE_HOMEs.

You should always check the patch notes before doing any patching. It's always possible some changes have been introduced that make the process differ from that presented here.

Assumptions
Environment
Apply Patch to Node 2
Switchover to Node 2
Apply Patch to Node 1
Run datapatch on Node 2
Switchover to Node 1
Clean Up
Check the Patch History
Rollback the Patch

Assumptions

This article makes some assumptions.

We have an existing Oracle 19c or 21c database data guard setup.
We have a backup of the database and the ORACLE_HOME. We are applying the patch to the existing ORACLE_HOME, so we need a way to fallback if something goes wrong that can't be fixed by rolling back the patch. Alternatively we could patch to a new ORACLE_HOME, which is explained in the linked article.
We've downloaded the relevant OPatch and patch files for this quarter, as listed here.
This setup uses filesystem storage, so we don't have to worry about patching the grid infrastructure.
We start with Node 1 as the primary database and Node 2 as the standby database. We will avoid calling them primary and standby, as their roles will change during the process.

Environment

Set up the environment. This includes the OPatch and patch file names, and the paths. Notice how OPatch has been added to the PATH environment variable.

export SOFTWARE_DIR=/u01/software

# 19c
export OPATCH_FILE="p6880880_190000_Linux-x86-64.zip"
export PATCH_FILE="p34133642_190000_Linux-x86-64.zip"
export PATCH_TOP=${SOFTWARE_DIR}/34133642

# 21c
export OPATCH_FILE="p6880880_210000_Linux-x86-64.zip"
export PATCH_FILE="p34160444_210000_Linux-x86-64.zip"
export PATCH_TOP=${SOFTWARE_DIR}/34160444

export PATH=${ORACLE_HOME}/OPatch:${PATH}

export ORACLE_SID=cdb1
export ORAENV_ASK=NO
. oraenv
export ORAENV_ASK=YES

Apply Patch to Node 2

The two nodes have the following roles.

Node 1 : Primary Database
Node 2 : Standby Database

We start by applying the patch to Node 2, the standby database.

Keep a copy of the existing OPatch, and unzip the latest version of OPatch.

cd ${ORACLE_HOME}
mv OPatch OPatch.`date +"%Y"-"%m"-"%d"`
unzip -oq ${SOFTWARE_DIR}/${OPATCH_FILE}

Unzip the patch software.

cd ${SOFTWARE_DIR}
unzip -oq ${PATCH_FILE}

Shutdown the services run from the ORACLE_HOME.

sqlplus / as sysdba <<EOF
shutdown immediate;
exit
EOF

lsnrctl stop

Apply the patch.

cd ${PATCH_TOP}
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
opatch apply -silent

Start the listener.

lsnrctl start

Start the database in mount mode and enable managed recovery.

sqlplus / as sysdba <<EOF
startup mount;
alter database recover managed standby database using current logfile disconnect;
exit;
EOF

We can't run datapatch as that would break the standby, but if we wanted to evaluate the patch we could do the following.

Convert the standby to a snapshot standby.
Run datapatch on the snapshot standby.
Validate the patch has had no detrimental impact on our system.
Convert the snapshot standby back to a physical standby.
Continue with the patching process.

Snapshot standby is demonstrated here. This article will ignore this evaluation step and proceed with the patching.

Switchover to Node 2

Connect to the primary database (cdb1) on Node 1.

dgmgrl sys/Password1@cdb1

Switchover to the standby database (cdb1_stby).

switchover to cdb1_stby;

When that completes successfully, we are ready to move forward.

Apply Patch to Node 1

The two nodes have the following roles.

Node 1 : Standby Database
Node 2 : Primary Database (datapatch not applied yet)

We apply the patch to Node 1, the current standby database.

Keep a copy of the existing OPatch, and unzip the latest version of OPatch.

cd ${ORACLE_HOME}
mv OPatch OPatch.`date +"%Y"-"%m"-"%d"`
unzip -oq ${SOFTWARE_DIR}/${OPATCH_FILE}

Unzip the patch software.

cd ${SOFTWARE_DIR}
unzip -oq ${PATCH_FILE}

Shutdown the services run from the ORACLE_HOME.

sqlplus / as sysdba <<EOF
shutdown immediate;
exit;
EOF

lsnrctl stop

Apply the patch.

cd ${PATCH_TOP}
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
opatch apply -silent

Start the listener.

lsnrctl start

Start the database in mount mode and enable managed recovery.

sqlplus / as sysdba <<EOF
startup mount;
alter database recover managed standby database using current logfile disconnect;
exit;
EOF

At this point the binary patches have been applied to all nodes, so we are OK to move forward and run datapatch on the primary database.

Run datapatch on Node 2

The two nodes have the following roles.

Node 1 : Standby Database
Node 2 : Primary Database (datapatch not applied yet)

We must run datapatch against the primary database, which is currently Node 2.

cd $ORACLE_HOME/OPatch
./datapatch -verbose

Recompile any invalid objects.

$ORACLE_HOME/perl/bin/perl \
    -I$ORACLE_HOME/perl/lib \
    -I$ORACLE_HOME/rdbms/admin \
    $ORACLE_HOME/rdbms/admin/catcon.pl \
    -l /tmp/ \
    -b postpatch_${ORACLE_SID}_recompile \
    -C 'PDB$SEED' \
    $ORACLE_HOME/rdbms/admin/utlrp.sql

Switchover to Node 1

The two nodes have the following roles.

Node 1 : Standby Database
Node 2 : Primary Database

We could leave it like this, but assuming we want to make Node 1 the primary database again, we connect to the primary (cdb1_stby) on Node 2.

dgmgrl sys/Password1@cdb1_stby

Then switchover to the new standby database (cdb1) on Node 1.

switchover to cdb1;

The two nodes have the following roles.

Node 1 : Primary Database
Node 2 : Standby Database

Clean Up

Clean up the patch software.

cd ${SOFTWARE_DIR}
rm -Rf ${PATCH_TOP}
rm -Rf ${OPATCH_FILE}
rm -Rf ${PATCH_FILE}
rm -Rf PatchSearch.xml

Check the Patch History

We can check the patch history by running the following command.

opatch lsinventory

Rollback the Patch

To rollback the patch we have to repeat the patching process, but instead of applying the patch we rollback the patch.

# 19c
opatch rollback -id 34133642 -silent

# 21c
opatch rollback -id 34160444 -silent

For more information see:

Hope this helps. Regards Tim...

Back to the Top.