📋Steps in this guide1/10

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.

oracle miscconfigurationintermediate

by OracleDba

16 views

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 environment variable.

Code/Command (click line numbers to comment):

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. Unzip the patch software. Shutdown the services run from the . Apply the patch. Start the listener. Start the database in mount mode and enable managed recovery. 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.

Code/Command (click line numbers to comment):

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

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

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

lsnrctl stop

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

lsnrctl start

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

Switchover to Node 2

Connect to the primary database (cdb1) on Node 1. Switchover to the standby database (cdb1_stby). When that completes successfully, we are ready to move forward.

Code/Command (click line numbers to comment):

1
2
3

dgmgrl sys/Password1@cdb1

switchover to cdb1_stby;

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. Unzip the patch software. Shutdown the services run from the . Apply the patch. Start the listener. Start the database in mount mode and enable managed recovery. 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.

Code/Command (click line numbers to comment):

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

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

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

lsnrctl stop

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

lsnrctl start

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

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. Recompile any invalid objects.

Code/Command (click line numbers to comment):

cd $ORACLE_HOME/OPatch
./datapatch -verbose

$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. Then switchover to the new standby database (cdb1) on Node 1. The two nodes have the following roles. - Node 1 : Primary Database - Node 2 : Standby Database

Code/Command (click line numbers to comment):

1
2
3

dgmgrl sys/Password1@cdb1_stby

switchover to cdb1;

Clean Up

Clean up the patch software.

Code/Command (click line numbers to comment):

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.

Code/Command (click line numbers to comment):

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. For more information see: - Critical Patch Updates, Security Alerts and Bulletins - Patching : Apply a Database Release Update (RU) to an Existing ORACLE_HOME - Patching : Apply a Release Update (RU) to a New ORACLE_HOME Hope this helps. Regards Tim...

Code/Command (click line numbers to comment):

# 19c
opatch rollback -id 34133642 -silent

# 21c
opatch rollback -id 34160444 -silent

Comments (0)

Please to add comments

No comments yet. Be the first to comment!