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

Home » Articles » Misc » Here

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.

Related articles.

Assumptions

This article makes some assumptions.

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.

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.

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.

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.

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.

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.

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.