Let me show you how I patch my Oracle Data Guard configuration. I make it easy using Oracle AutoUpgrade. I patch all at once – all databases at the same time – which means a short downtime. I can use this approach for all patches – even those that are not standby-first installable.

I recommend this approach only when you have patches that are not standby-first installable.

• 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 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
      • 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.

• I connect to the primary database using Data Guard broker and disable redo transport from the primary database:

  DGMGRL> edit database sales_copenhagen set state='TRANSPORT-OFF';
  

• I update listener.ora on both hosts (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 on both hosts:

  lsnrctl reload
  

• Downtime starts!

  • Perform draining in advance according to your practices.
  • Shut down your application.

• Patch the primary database:

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

• Simultaneously, I patch the standby database:

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

• I update my profile and scripts so they point to the target Oracle home.

• When patching completes in both hosts, I re-enable redo transport:

  DGMGRL> edit database sales_copenhagen set state='TRANSPORT-ON';
  

• 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;
  

That’s it.

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

• How To Apply DBRU in a Data Guard Physical Standby Configuration (Non Standby-First Installable) (Doc ID 3039160.1)
• Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.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