Oracle AutoUpgrade for Patching: Staying Ahead of CSPU and CPU Cycles

Introduction

AI has compressed the time everything takes. Tasks that used to fill a morning now finish in minutes, freeing us to build the next automation and keep things moving. But the same shift happened on the other side of the fence. Attackers who once struggled to write a working script now have the same leverage we do. Everything is at your fingertips, for better and for worse.

That makes keeping systems patched more important than ever. I live in the Oracle ecosystem, and I’d argue database patches sit at the top of that list. Oracle has also changed the rhythm: we now have quarterly Critical Patch Updates (CPU) alongside monthly Security Patch Updates (CSPU).

Oracle patching dates: https://www.oracle.com/security-alerts/cpujul2026.html

Oracle security patches land on the third Tuesday of every month. The next dates are:

• 15 September 2026 (CSPU)

• 20 October 2026 (CPU)

• 17 November 2026 (CSPU)

• 15 December 2026 (CSPU)

Staying ahead of that calendar is not easy. Download, apply, test, repeat – every month. So I went looking for a model that would let me be proactive instead of reactive and cut the time each cycle costs me.

I found it almost by accident. While installing an Oracle Database 26ai home, I got a proper taste of AutoUpgrade, and I’ve been sold on it ever since. The time AutoUpgrade saves on database patching is real.

In this blog, I’ll walk through patching from 19.28 to 19.32 without any hassle.

AutoUpgrade patching is an out-of-place method, so it’s a safe way to patch.

Step 1: Download the AutoUpgrade Tool

Grab the latest AutoUpgrade tool from MOS Doc 2485457.1. Always take the newest build. It’s backward compatible, and the patching features have been moving fast.

To validate, check the AutoUpgrade tool version.

Step 2: Set Up Your Directory Structure

I recommend creating a directory structure like the one below and moving the latest AutoUpgrade tool into it. Keeping the keystore, patches, and logs separated makes the whole thing much easier to troubleshoot later.

This is how it looks after creation:

Step 3: Build the Config File

Everything AutoUpgrade needs lives in one file. No wrappers, no response files, no long command lines to get wrong at two in the morning. You write the config once, and it becomes the record of exactly what you patched and where.

Mine sits alongside the rest of the staging area as patch_19_32.cfg:

Step 4: Load Your My Oracle Support Credentials

AutoUpgrade downloads the patches for you, so it needs your MOS credentials and CSI number. Those go into an encrypted keystore rather than sitting in the config file in plain text:

Step 5: Download the Patches

Ask any DBA where the time actually goes in a patch cycle, and you’ll get the same answer. It isn’t the apply. It’s the hunt. Logging into My Oracle Support, working out which RU you need, then which OJVM goes with it, then whether there’s a Data Pump bundle this quarter, then chasing the right OPatch version – and doing all of it again for the next platform. Half a day gone before you’ve touched a database.

That whole exercise is now one command:

AutoUpgrade reads the patch line from your config, works out what that actually resolves to, and pulls it down for you.

One thing that will stop you cold: you need your CSI number registered in the keystore. Without a valid Customer Support Identifier, the gold image request fails – you’ll get the regular patches from MOS and nothing else. Set the keystore up before you run this, not after.

Here’s the run:

Step 6: Analyze Before You Touch Anything

I never skip this. Analyze is a read-only pass; it inspects the databases, checks the staged patches, and tells you what it plans to do without doing any of it. It’s the cheapest ten minutes in the whole cycle. If something is going to bite you, it usually shows up here rather than three hours into a Saturday night change window.

What I’m specifically looking for: errors it can’t resolve, and any one-off patches sitting in the source home that will need rolling back before the new home can go in. Finding a conflicting one-off during analyze is a scheduling conversation. Finding it during apply is an incident.

Same jar, same config, different mode. That’s the pattern for the whole tool.

This is how the status.html report looks after analysis:

Step 7: Deploy

Analysis came back clean, so it was time to build the home. This is the bit that sold me. One command creates the new 19c home and patches it to 19.32.

Once the job kicks off, type lsj -a 30 at the patch prompt, and it’ll refresh the job table every 30 seconds so you can watch it work.

It works through three stages. First, it extracts the gold image. Then it installs the Oracle home:

Then it starts patching it:

No manual OPatch calls, no unzipping, no chasing patch order. It was going well.

Then It Broke

The OJVM release update killed it.

My first instinct was that AutoUpgrade had done something wrong. It hadn’t, and I got curious about why a patch would fail specifically at the relinking phase.

The answer is sitting right there in the error.

That’s Perl, not Oracle. The OJVM patch runs a Perl script, update_javavm_binaries.pl, to relink the Java VM binaries, and the system Perl 5.32 on this host didn’t have File::Copy in it. Look at the @INC list in the full error, and you can see it searching every library path and coming up empty.

Solution

Install the missing Perl packages using the command.

Sample output:

Once that’s done, validate the module directly rather than assuming the package install did the job:

Sample output:

Clean Up Properly Before You Retry

Here’s the part that’ll bite you. Look at this line in the OPatch output:

OPatch couldn’t roll back what it had half applied. Your target home is now in a broken state, and you can’t just rerun create_home over the top of it. Every failed attempt needs a proper teardown first.

First, detach the broken home from the inventory. Run this from your source home’s OUI, not from the target, because the target home is the one that’s in a bad state:

Then remove the directory and confirm the inventory is actually clean:

You want that grep to return nothing. If it still finds the home, the detach didn’t take, and rerunning create_home will give you a fresh set of problems.

Last piece: clear AutoUpgrade’s own recovery data for the failed job:

Step 8: Run It Again

With Perl sorted and the old attempt cleaned up, it’s the same command as before. Nothing changes except that this time you get a new job ID:

All the steps associate for autoupgrade patching:

And this time it finished:

Job 104, one database, nothing failed. Note the job number has jumped again from 103, which is worth keeping track of if you ever need to go back and clear recovery data.

Don’t skip the root.sh line. AutoUpgrade can’t run it for you, so it hands it back and expects you to run it as root against the new home before you go any further.

AutoUpgrade also writes a summary report in both HTML and plain text:
Here is the HTML output:

Step 9: Verify

You can validate patches by executing opatch lspatches.

Conclusion

AI has compressed the time everything takes, and that cuts both ways. The same leverage that lets us turn a morning’s work into minutes is sitting on the attacker’s desk too, which makes staying patched more important than ever. Oracle has changed the rhythm to match, adding monthly Critical Security Patch Updates in May 2026 on top of the quarterly CPUs. Keeping up with that by hand means downloading patches, staging them, working out conflicts and apply order, and I’ve lost enough hours to that to know I don’t want them back. AutoUpgrade pulls the whole set from My Oracle Support, installs out-of-place, and leaves the running database alone until you’re ready to switch. Yes, it broke on me, but over a missing Perl module on the host, not over anything AutoUpgrade did. Sort out your prerequisites, and the rest really is one command.