Patching a Standby Database Confusion

In my post “all you need to know about Oracle database patching” I wrote the following procedure for patching a physical standby environment (for standby-first patches, assuming serverA is currently the primary and serverB is currently the standby):

• Install the patch on serverB
• Switchover to serverB
• Install the patch on serverA
• Run SQL scripts if needed (on serverB which is the current primary)
• Now you can leave it like this or switch back whenever you’d like

However, there is a confusion in MOS about this.

On Friday (May 22, 2020) I’m going to talk about database patching at ODTUG Learn from Home Series, so I went through this again and found something confusing. When installing RUs (or PSUs in older versions) there are two different MOS notes that contradict each other. Just to be clear, RUs (and PSUs before that) are ALWAYS standby-first patched (as per MOS note 2337415.1).

Note 1265700.1 is titled “Oracle Patch Assurance – Data Guard Standby-First Patch Apply” and talks about standby-first patches (RUs and PSUs included as I mentioned). In this note the installation process goes as I described at the top of this post (install RU on standby, switchover, install on the other server and run SQL scripts).

However, there is another note, note 278641.1, which is titled “How do you apply a Patchset, PSU or CPU in a Data Guard Physical Standby configuration”. This note talks specifically about patchsets and PSUs (and since it applies to versions up to 19.6 I take that RUs as well). In this note the process that is described to install the patches is completely different:

• Disable redo transport
• Patch the standby while leaving the recovery OFF
• Patch the primary
• Enable redo transport and the recovery process
• Run SQL scripts (on the primary)

The problem with this procedure is that it’s not standby-first. This is how you install a non-standby-first patch, and it leads to a longer downtime. Since PSUs and RUs ARE standby-first patches I find this strange.

Moreover, for a non standby-first patch, I would do something else (instead of disabling and enabling the transport and recovery):

• Stop the standby database
• Patch the standby database (but do not start it)
• Stop and patch the primary database
• Start both databases
• Run SQL scripts (on the primary)

Conclusion

I contacted Oracle with this and the support engineer agreed with me and said that both options are valid. So as I see it, the decision is between shorter downtime and simpler process.

For shorter downtime:

• Install the patch on serverB
• Switchover to serverB
• Install the patch on serverA
• Run SQL scripts if needed (on serverB which is the current primary)
• Now you can leave it like this or switch back whenever you’d like

For a simpler process:

• Stop the standby database
• Patch the standby database (but do not start it)
• Stop and patch the primary database
• Start both databases
• Run SQL scripts if needed (on the primary)