I am a big fan of Oracle Data Guard Standby-First Patch Apply. You can:
- Reduce downtime to the time it takes to perform a switchover.
- Test the patching procedure on the standby database.
I received an interesting question the other day:
I have the following two Data Guard configurations. I want to patch all the databases using standby-first patch apply. How do I do that when I have primary and standby databases running out of the same Oracle home on the same machine?

Requirements
In this case, the databases are on 19.17.0, and the customer wants to patch them to 19.23.0.
To use standby-first patch apply, you must meet a set of requirements, one being:
Data Guard Standby-First Patch Apply is supported between database patch releases that are a maximum of one year (1 year) apart based on the patch release date.
Here are the release dates of the following Release Updates:
- 19.17.0: October 2022
- 19.23.0: April 2024
So, in this case, the customer can’t use standby-first patch apply directly. There is a year and a half in between. They need to patch cycles in this case:
- Patch to 19.21.0 (release October 2023)
- Patch to 19.23.0 (release April 2024)
In the future, they should apply patches more often to avoid ending up in this situation again.
Patching Oracle Home
The customer has one Oracle home on each server from where both databases run. On any server, there is a primary and a standby database (from two different Data Guard configs).
The customer uses in-place patching. If they patch the entire Oracle home, it means one of the primary databases is now on a higher Oracle home than its standby database, which is not allowed. The standby database is the only one which may run on a higher patch level.
Using the above configuration with primary and standby databases running out of the same Oracle home, you can’t use in-place patching and standby-first patch apply.
The customer must switch to out-of-place patching to achieve this. Then you can patch standby databases first, then the primaries.
Plus, you get all the other benefits of out-of-place patching.
Datapatch
Once all the databases in a Data Guard configuration run in the new Oracle home, you still haven’t completed the patching process:
A patch or patch bundle is not considered fully installed until all of the following actions have occurred:
- Patch binary installation has been performed to the database home on all standby systems.
- Patch binary installation has been performed to the database home on the primary system.
- Patch SQL installation, if required by the patch, has been performed on the primary database and the redo applied to the standby database(s).
You must do the above steps in the specified order, and the last step is to execute Datapatch:
$ $ORACLE_HOME/OPatch/datapatch
Step-by-step
You can use AutoUpgrade to patch Oracle Data Guard.
That’s interesting case Daniel. In order to apply the patch in place, Can I do a switchover to the second db2 in the sense of have both databases in standby binary server2 then apply the patch as usual?
LikeLike
Hi,
That’s a good point. You could do that. However, it means that one server hosts all the primary databases. It will put more load on it, which might reduce throughput.
Further, you’d need an additional interuption, i.e. switchover, to make it work. If the application doesn’t behave well to the switchover, it might be a pain.
But good point. However, you should REALLY get away from in-place patching.
Regards,
Daniel
LikeLike
Yes Daniel you’re correct, out of place it’s the best an recommend way. However, The client where I work right now they usually do a switchover from time to time and stayed in DC for the next 6 months and so on. Means the apps work on both sites.
LikeLike
Hi,
That’s a fair point. However, if you can fine tune the switchover process, it will really pay off later on.
Regards,
Daniel
LikeLike
Hi Daniel,
In your summary, in the step 4, you suggest to do a switchover to the standby DB.
Once done that, the NEW primary will be running on a ORACLE_HOME version > NEW standby ORACLE_HOME version. This scenario would violate the restriction of stby O_H always >= prim O_H until finishing the patching, wouldn’t it? Is that exception supported?
Regards,
LikeLike
Hi Carlos,
That’s a good catch. You are in that situation for a short period of time while the primary restarts to the same Oracle home. That’s fully supported.
But running with such a config for “regular” operations is not, and further, you can’t run Datapatch until all databases are on the same patch level.
Regards,
Daniel
LikeLike