I strongly recommend that you always patch out-of-place. Here’s an example of how to do it on Oracle Grid Infrastructure (GI) and Oracle Data Guard using Standby-First Patch Apply.

Standby-First Patch Apply allows you to minimize downtime to the time it takes to perform a Data Guard switchover. Further, it allows you to test the apply mechanism on the standby database by temporarily converting it into a snapshot standby database.

The scenario:

• Oracle Grid Infrastructure 19c and Oracle Database 19c
• Patching from Release Update 19.17.0 to 19.19.0
• Vertical patching – GI and database at the same time
• Data Guard setup with two RAC databases
  • Cluster 1: copenhagen1 and copenhagen2
  • Cluster 2: aarhus1 and aarhus2
  • DB_NAME: CDB1
  • DB_UNIQUE_NAME: CDB1_COPENHAGEN and CDB1_AARHUS
• Using Data Guard broker
• Patching GI using SwitchGridHome method

Let’s get started!

Step 1: Prepare

I can make the preparations without interrupting the database.

• I ensure my environment meets the requirements for Standby-First Patch Apply.

• I deploy new GI homes to all four hosts.

  • I use the SwitchGridHome method.
  • Very important: I only perform step 1 (Prepare a New Grid Home).
  • I apply the Release Update 19.19.0 as part of the deployment using gridSetup.sh ... -applyRU as described in the blog post.

• I deploy new database homes to all four hosts.

  • I prefer to use brand-new database homes. If you clone an existing database home, be sure to clean it up before you proceed.
  • When I attach the new database home to the inventory, I also apply the Release Update 19.19.0 using runInstaller ... -applyRU.

• I also recompile invalid objects. This can make it easier for Datapatch later in the process:

  PRIMARY SQL> @?/rdbms/admin/utlrp
  

Step 2: Restart Standby in New Oracle Homes

Now, I can move the standby database to the new GI and database homes.

• On the standby hosts, aarhus1 and aarhus2, I first move the database configuration files from the old database home to the new one.

• I change the database configuration in GI. Next time the database restarts, it will be in the new Oracle Home:

  [oracle@aarhus1]$ $OLD_ORACLE_HOME/bin/srvctl modify database \
     -db $ORACLE_UNQNAME \
     -oraclehome $NEW_ORACLE_HOME
  

• I switch to the new GI on all standby hosts, aarhus1 and aarhus2, by executing step 2 (Switch to the new Grid Home) of the SwitchGridHome method.

  • It involves running gridSetup.sh ... -switchGridHome and root.sh.
  • You can perform the switch in a rolling manner or all at once.
  • The switch restarts the standby database instance. The standby database instance restarts in the new Oracle Home.
  • If the profile of grid (like .bashrc) sets the ORACLE_HOME environment variable, I ensure to update it.

• If I had multiple standby databases, I would process all standby databases in this step.

Step 3: Test Standby Database

This is an optional step, but I recommend that you do it.

• I convert the standby database (CDB1_AARHUS) to a snapshot standby database:

  DGMGRL> convert database CDB1_AARHUS to snapshot standby;
  

• I test Datapatch on the standby database. It is important that I run the command on the standby database:

  [oracle@aarhus1]$ $ORACLE_HOME/OPatch/datapatch -verbose
  

• I can also test my application on the standby database.
• At the end of my testing, I revert the standby database to a physical standby database. The database automatically reverts all the changes made during testing:

  DGMGRL> convert database CDB1_AARHUS to physical standby;
  

Step 4: Switchover

I can perform the previous steps without interrupting my users. This step requires a maintenance window because I am doing a Data Guard switchover.

• I check that my standby database is ready to become primary. Then, I start a Data Guard switchover:

  DGMGRL> connect sys/<password> as sysdba
  DGMGRL> validate database CDB1_AARHUS;
  DGMGRL> switchover to CDB1_AARHUS;
  

A switchover does not have to mean downtime.

If my application is configured properly, the users will experience a brownout; a short hang, while the connections switch to the new primary database.

Step 5: Restart New Standby in New Oracle Homes

Now, the primary database runs on aarhus1 and aarhus2. Next, I can move the new standby hosts, copenhagen1 and copenhagen2, to the new GI and database homes.

• I repeat step 2 (Restart Standby In New Oracle Homes) but this time for the new standby hosts, copenhagen1 and copenhagen2.

Step 6: Complete Patching

Now, both databases in my Data Guard configuration run out of the new Oracle Homes.

Only proceed with this step once all databases run out of the new Oracle Home.

I need to run this step as fast as possible after I have completed the previous step.

• I complete the patching by running Datapatch on the primary database (CDB1_AARHUS). I add the recomp_threshold parameter to ensure Datapatch recompiles all objects that the patching invalidated:

  [orale@aarhus1]$ $ORACLE_HOME/OPatch/datapatch \
     -verbose \
     -recomp_threshold 10000
  

  • I only need to run Datapatch one time. On the primary database and only on one of the instances.

• I can run Datapatch while users are connected to my database.

• Optionally, I can switch back to the original primary database on copenhagen1 and copenhagen2, if I prefer to run it there.

That’s it. Happy patching!

Appendix

Further Reading

• Continuous Availability – MAA Checklist for Applications for the Oracle Database
• Oracle Patch Assurance – Data Guard Standby-First Patch Apply (Doc ID 1265700.1)

Other Blog Posts in This Series

• Introduction
• How to Patch Oracle Grid Infrastructure 19c Using In-Place OPatchAuto
• How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place OPatchAuto
• How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place SwitchGridHome
• How to Patch Oracle Grid Infrastructure 19c and Oracle Data Guard Using Standby-First
• How to Patch Oracle Grid Infrastructure 19c Using Zero Downtime Oracle Grid Infrastructure Patching
• Which Method Should I Choose When Patching Oracle Grid Infrastructure 19c
• How to Avoid Interruptions When You Patch Oracle Grid Infrastructure 19c
• Patching Oracle Grid Infrastructure And Oracle Data Guard
• How to Clone Oracle Grid Infrastructure Home Using Golden Images
• How to Roll Back Oracle Grid Infrastructure 19c Using SwitchGridHome
• How to Remove an Old Oracle Grid Infrastructure 19c Home
• Use Cluster Verification Utility (cluvfy) and Avoid Surprises
• A Word about Zero Downtime Oracle Grid Infrastructure Patching
• Why You Need to Use Oracle Fleet Patching and Provisioning
• My Best Advice on Patching Oracle Grid Infrastructure
• Pro Tips