Let me show you how I patch my Oracle Data Guard configuration. I make it as easy as possible using Oracle AutoUpgrade. I reduce the interruption by doing standby-first patch apply with a switchover.

• My Data Guard configuration consists of two databases:
  • SID: SALES
  • Databases: SALES_COPENHAGEN and SALES_AARHUS
  • Hosts: copenhagen and aarhus
  • Primary database: SALES_COPENHAGEN running on copenhagen

Preparations

You should do these preparations in advance of your maintenance window. They don’t interupt operations on your databases.

• I download the patches using AutoUpgrade.

  • Create a config file called sales-download.cfg:

    global.global_log_dir=/home/oracle/autoupgrade-patching/download
    global.keystore=/home/oracle/autoupgrade-patching/keystore
    patch1.folder=/home/oracle/autoupgrade-patching/patch
    patch1.patch=RECOMMENDED,MRP
    patch1.target_version=19
    patch1.platform=linux.x64
    

    • folder tells where to store the patches. This location is an NFS share accessible to all hosts.
    • patch=RECOMMENDED,MRP means the latest available Release Update, Data Pump Bundle Patch, OJVM Bundle Patch and Monthly Recommend Patches.

  • Start AutoUpgrade in download mode:

    java -jar autoupgrade.jar -config sales-download.cfg -patch -mode download
    

    • I can download the patches from any computer. It doesn’t have to be one of the database hosts, which typically don’t have internet access.

• I verify all patches are standby-first installable and my configuration meets the requirements for standby-first patch apply.

• I create a new Oracle home on all hosts.

  • Create a config file called sales.cfg:

    global.global_log_dir=/home/oracle/autoupgrade-patching/sales
    patch1.source_home=/u01/app/oracle/product/19.3.0.0/dbhome_1
    patch1.target_home=/u01/app/oracle/product/19/dbhome_19_26_0
    patch1.sid=SALES
    patch1.folder=/home/oracle/autoupgrade-patching/patch
    patch1.patch=RECOMMENDED,MRP
    patch1.download=no
    

    • Start AutoUpgrade in create_home mode:

    java -jar autoupgrade.jar -config sales.cfg -patch -mode create_home
    

    • AutoUpgrade also runs root.sh. It requires either:
      • oracle user has sudo privileges
      • Or I’ve stored the root credentials in the AutoUpgrade keystore
      • Else, I must manually execute root.sh.

• Optionally, but recommended, I run an analysis on the primary database:

  [oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -patch -mode analyze
  

  • Check the findings in the summary report.

Patching

Proceed with the following when your maintenance window starts.

• Update listener.ora on the standby host (see appendix). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.

• I reload the listener:

  [oracle@aarhus] lsnrctl reload
  

• Patch the standby database:

  [oracle@aarhus] java -jar autoupgrade.jar -config sales.cfg -mode deploy
  

  • I don’t disable redo transport/apply.

• Optionally, test the application of patches using a snapshot standby database.

• interruption starts!

• Switch over to SALES_AARHUS:

  DGMGRL> switchover to sales_aarhus;
  

  • Perform draining in advance according to your practices.
  • Depending on how your application is configured, the users will experience this interruption as a brown-out or downtime.

• Update listener.ora on the new standby host (copenhagen). I change the ORACLE_HOME parameter in the static listener entry (suffixed _DGMGRL) so it matches my target Oracle home.

• I reload the listener:

  [oracle@copenhagen] lsnrctl reload
  

• Patch the new standby database (see appendix):

  [oracle@copenhagen] java -jar autoupgrade.jar -config sales.cfg -mode deploy
  

• Verify the Data Guard configuration and ensure the standby database is receiving and applying redo:

  DGMGRL> show database SALES_COPENHAGEN;
  DGMGRL> show database SALES_AARHUS;
  DGMGRL> validate database SALES_COPENHAGEN;
  DGMGRL> validate database SALES_AARHUS;
  

Post-Patching

• Connect to the new primary database and execute Datapatch. You do that by calling AutoUpgrade in upgrade mode:

  [oracle@aarhus] java -jar autoupgrade.jar -config sales.cfg -mode upgrade
  

Happy Patching!

Appendix

Static Listener Entry

In this blog post, I update the static listener entries required by Data Guard broker (suffixed DGMGRL). My demo environment doesn’t use Oracle Restart or Oracle Grid Infrastructure, so this entry is mandatory.

If you use Oracle Restart or Oracle Grid Infrastructure, such entry is no longer needed.

Further Reading

• Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.1)
• Oracle Patch Assurance – Data Guard Standby-First Patch Apply (Doc ID 1265700.1)

Other Blog Posts in the Series

• Introduction
• How To Patch Oracle Data Guard Using AutoUpgrade For Non-Standby-First Installable Patches
• How To Patch Oracle Data Guard Using AutoUpgrade And Standby-First Patch Apply With Restart
• How To Patch Oracle Data Guard Using AutoUpgrade And Standby-First Patch Apply With Switchover
• Avoid Problems on the Primary Database by Testing on a Snapshot Standby