I have shown you a few ways to patch Oracle Grid Infrastructure 19c (GI). Which one should you choose? Here’s an overview of the pros and cons of each method.
Just Grid Infrastructure Or Also The Database
You can patch:
- Just GI and later on the database
- Or GI and the database at the same time
If possible, I recommend patching GI and database in a separate maintenance operation. Proceed with the database when you are confident the new GI runs fine. If you do it a week apart, you should have enough time to kick the tires on the new GI.
I like to keep things separate. If there is a problem, I can quickly identify whether the GI or database patches are causing problems. The more patches you put in simultaneously, the more changes come in, and the harder it is to keep things apart.
The downside is that you now have two maintenance operations; one for GI and one for the database. But if your draining strategy works and/or you are using Application Continuity, you can complete hide the outage from your end users.
If you have a legacy application or draining is a nightmare for you, then it does make sense to consider patching GI and database at the same time.
In-place vs. Out-of-place
|In-place OPatchAuto||Out-of-place OPatchAuto||Out-of-place SwitchGridHome||Out-of-place ZDOGIP|
|Space usage||Just for the new patches||A new GI home and the new patches||A new GI home and the new patches||A new GI home and the new patches|
|Additional system resources||No||No||No||Yes|
|Node downtime||Significant||Short||Short||None (1)|
|Install multiple patches in one go||No||No||Yes||Yes|
|Grid Home change||No||Yes. New Grid Home location. Scripts and profiles must be updated. New Grid Home to maintain and monitor||Yes. New Grid Home location. Scripts and profiles must be updated. New Grid Home to maintain and monitor||Yes. New Grid Home location. Scripts and profiles must be updated. New Grid Home to maintain and monitor|
|Grid Home origin||N/A||Existing Grid Home is cloned||Fresh Grid Home from base release||Fresh Grid Home from base release|
|Rollback node outage||Significant||Short||Short||None (1)|
- If you are using ACFS or ASM Filter Driver, you must restart the GI stack at one point in time. The node is down for a short period.
I recommend out-of-place patching. There are multiple ways of doing that. Choose the one that suits you best. My personal favorite is the SwitchGridHome method.
There are even more methods than I have shown in this blog post series. I have demonstrated the methods that most people would consider. Evaluate the pros and cons yourself and choose what works best for you.
What’s your favorite? Why did you choose a specific method? Leave a comment and let me know.
Other Blog Posts in This Series
- 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 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
- 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
- MOS note: Supplemental Readme – Grid Infrastructure Release Update 184.108.40.206.x / 18c /19c (Doc ID 2246888.1)
If you decide to patch GI and database at the same time, be aware of the following. The database instance will need to restart two times. First, each instance goes does to switch to the new GI. The second time is when you switch on the last node. Then all database instances are brought down again in a rolling manner and restarted in the new Oracle Home. If you want to control draining yourself, don’t use this method. The second database restarts happens completely automated one after the other. Without any possibility for you to intervene to control draining.