For most of you this means that they must patch more often. Here are some ideas that can help you ease the burden of patching.

Grab a coffee with your DBA buddies and go over the list. Perhaps you’re missing out.

Patches

Use AutoUpgrade in download mode. This is the fastest and easiest way to get patches. In this demo, Mike downloads 25 patches with just one command. Once you try, you’ll never download patches manually.

Oracle Home

Use out-of-place patching. This allows you to install the new Oracle home in advance. It reduces downtime, is less risky and makes rollbacks easier.
- Use a brand-new home each time.
- If you insist on in-place patching or clone Oracle homes be sure to clean up.
Create and use gold images. Once you’ve created your own gold image, you can deploy it to other hosts faster than installing and patching a new Oracle home.
- Standardize on as few gold images as possible. Ideally, you have only one gold image for a specific Release Update.
Move files out of the Oracle home. You can find many configuration files and such inside the Oracle home. You must copy them to the new Oracle home when you use out-of-place patching – unless you use AutoUpgrade that does it for you.
- Many of these files can be placed outside the Oracle home.

Ensure your application is configured according to the guidelines of the Maximum Availability Architecture. This gives you the possibility of minimizing or hiding the outage from your users.
- Check your connection strings
Implement Application Continuity to hide the outage from your users.

Use Data Guard standby-first patching. It minimizes the interruption to a Data Guard switchover and provides the possibility of testing the patch application.
- You can use AutoUpgrade for the process.
Do rolling patching on RAC databases.
- I prefer using AutoUpgrade over OPatchAuto.
Patch using AutoUpgrade. Take advantage of all the features AutoUpgrade offers:

You can run Datapatch while users are connected. Knowing this you can minimize the outage on single instance databases by allowing users to connect as soon as you’ve restarted the database in the new Oracle home.
Use Datapatch sanity checks to assess the patch readiness of your database.
- Generate the report by running datapatch -sanity_checks.
- It’s a lightweight, non-intrusive check of the database.
Regularly clean up old patching metadata.
- Limit the space used by Datapatch in the SYSTEM tablespace.
If you wonder what Datapatch spends time on, check the Datapatch logs in $ORACLE_BASE/cfgtoollogs/sqlpatch.
Ensure Datapatch patches the most important PDBs first.
- Datapatch patches many PDBs at the same time. This depends on the database CPU_COUNT.
- By default, Datapatch takes the PDBs in order by CON_ID.
- But you can change the order using ALTER PLUGGABLE DATABASE <pdb_name> PRIORITY 1. The lower the priority, the sooner the PDB is processed.
Patch multiple databases at the same time.
- Datapatch works on one database only. But you can start multiple instances of Datapatch to patch multiple databases simultaneously provided you have the CPU resources.
Speed up patching by removing unused components. Check your database using SELECT * FROM cdb_registry.
- Generally, the more components, the longer patching/upgrading takes.

Automate the patching process. Including:
- Rollback
- Removal of old Oracle home
- Listener patching
Tim Hall (ORACLE-BASE) wrote a series of blog posts about automation.
Use AutoUpgrade to automate the patching process.
Use Fleet Patching and Provisioning to automate the patching process.
- A huge benefit for Exadata systems as FPP can patch the entire stack.
- Separately licensed.

Use out-of-place patching and the switchGridHome method.
Check your system with Cluster Verification Utility.
- Available in ORAchk, EXAchk, and Autonomous Health Framework.

Familiarize yourself with the new patch level.
- Use ORAdiff.
- Check the New Features Guide 19c for changes in a specific Release Update.
Oracle tries to avoid plan changes after patching by adding optimizer fixes as installed, but disabled. This increases plan stability.
- Familiarize yourself with the concept and DBMS_OPTIM_BUNDLE.
- For even better plan stability use SQL Plan Management.

Did you find anything useful? Do you have other ideas to make patching easier?

Drop a comment and let’s help each other.

Happy patching!