Upgrade Oracle Database 19c CDB to Oracle AI Database 26ai

Let me show you how you upgrade an entire container database, including all PDBs, to Oracle AI Database 26ai.

How to Upgrade

I’ve already prepared my database and installed a new Oracle home. The maintenance window has started, and users have left the database.

This is my AutoUpgrade config file:
```
global.global_log_dir=/home/oracle/autoupgrade/logs/CDB19
upg1.source_home=/u01/app/oracle/product/19
upg1.target_home=/u01/app/oracle/product/26
upg1.sid=CDB19
```
- sid contains the name of SID or my database.
- I specify the source and target Oracle homes. I’ve already installed the target Oracle home.
- Check the appendix for additional parameters.
I start AutoUpgrade in deploy mode:
```
java -jar autoupgrade.jar -config CDB19.cfg -mode deploy
```
- AutoUpgrade starts by creating a guaranteed restore point to protect my database.
- Then, it analyzes the database for upgrade readiness and executes the pre-upgrade fixups. Next is the actual upgrade, followed by post-upgrade checks and fixups.
While the job progresses, I monitor it:
```
upg> lsj -a 30
```
- The -a 30 option automatically refreshes the information every 30 seconds.
- I can also use status -job 100 -a 30 to get detailed information about a specific job.

In the end, AutoUpgrade completes the upgrade:

Job 100 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs restored                  [0]
Jobs pending                   [0]

---- Drop GRP at your convenience once you consider it is no longer needed ----
Drop GRP from CDB19: drop restore point AUTOUPGRADE_9212_CDB191927000

Please check the summary report at:
/home/oracle/autoupgrade/logs/CDB19/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/autoupgrade/logs/CDB19/cfgtoollogs/upgrade/auto/status/status.log

This includes the post-upgrade checks and fixups, incl. updating /etc/oratab and Grid Infrastructure configuration.

I review the Autoupgrade Summary Report. The path is printed to the console:

vi /home/oracle/autoupgrade/logs/CDB19/cfgtoollogs/upgrade/auto/status/status.log

I take care of the post-upgrade tasks.
I update any profiles or scripts that use the database.
When I’m done testing the database – including application testing – and I decided that a rollback is not needed, I’ll drop the GRP:
```
SQL> drop restore point AUTOUPGRADE_9212_CDB191927000;
```

That’s It!

With AutoUpgrade, you can easily upgrade your entire CDB.

Check the other blog posts related to upgrade to Oracle AI Database 26ai.

Happy upgrading!

Appendix

What If My Database Is A RAC Database?

There are no changes to the procedure if you have an Oracle RAC database. AutoUpgrade detects this and sets CLUSTER_DATABASE=FALSE at the appropriate time. It also updates the Grid Infrastructure configuration.

For warp-speed upgrades, take a look at distributed upgrade.

What If I Use Oracle Restart?

No changes. AutoUpgrade detects this and automatically updates the Grid Infrastructure configuration.

What If My Database Is Encrypted

You must use an auto-login keystore. AutoUpgrade checks this during the pre-upgrade analysis.

Multitenant Upgrade

A few words about an upgrade of an entire CDB. AutoUpgrade first upgrades the root container. When that completes, it will upgrade the seed container and your PDBs. The latter part happens in parallel.

So, upgrading a CDB is always slower than just upgrading a single PDB. If you’re tight on time, consider upgrading just the PDB. This is called an unplug-plug upgrade.

Other Config File Parameters

The config file shown above is a basic one. Let me address some of the additional parameters you can use.

drop_grp_after_upgrade: AutoUpgrade doesn’t drop the GRP after the upgrade. This allows you to roll back even after a successful upgrade if your application testing reveals a problem. However, it means that you must manually remember to drop the GRP. Otherwise, you’ll eventually run out of space in FRA, and that will halt your database. Set this parameter to yes, and AutoUpgrade drops the GRP if the upgrade completes without problems.
timezone_upg: AutoUpgrade upgrades the database time zone file after the actual upgrade. This requires an additional restart of the database and might take significant time if you have lots of TIMESTAMP WITH TIME ZONE data. If so, you can postpone the time zone file upgrade or perform it in a more time-efficient manner.
raise_compatible: If you want to raise the initialization parameter COMPATIBLE immediately after the upgrade, you can use this parameter. Don’t use if you have standby databases, because there’s a specific procedure for raising COMPATIBLE in a Data Guard configuration. Don’t use it if you want to keep the option of downgrading.
before_action / after_action: Extend AutoUpgrade with your own functionality by using scripts before or after the job.
em_target_name: Allow AutoUpgrade to create blackouts before restarting the database and to update the target configuration after the upgrade. Requires a local installation of emcli. See this blog post for details.
rman_catalog_connect_string: Relevant for databases that store backup metadata in a recovery catalog. Upgrades the recovery catalog schema following an upgrade. See this blog post for details.

How to Prepare Your Oracle Database for Release 26ai

Here is a list of things to check and carry out while preparing for Oracle AI Database 26ai.

These tasks are not mandatory, but I recommend them based on my experience. It increases your chances of upgrading successfully.

Weeks Before

Versioning

Oracle AI Database 26ai introduces a new versioning schema. Although 26ai replaces 23ai, in the database, the version remains the same:

After upgrade to 26ai, the version remains 23.0.0.0.0:

SQL> select version from v$instance;

VERSION
-------
23.0.0.0.0

If you check version_full, you’ll see that the second digit reflects the new version:

SQL> select version_full from v$instance;

VERSION
-------
23.26.0.0.0

Platform Certification

Ensure that the new release supports your operating system. When available, you can check it in the installation guides. However, you can find the most up-to-date information in the Product Certification Matrix tab in My Oracle Support.

Clients

Check which clients are connecting to the database and ensure their client driver versions are compatible with Oracle AI Database 26ai. The client/server interoperability matrix gives you an overview of which clients work with which servers.

Client	Database 26ai	Database 19c
26ai	Yes	Yes
21c	Yes	Yes
19c	Yes	Yes
18c	No	Yes
12.2.0.1	No	Yes
12.1.0.2	No	Yes
11.2.0.4	No	Yes

19c supports much older clients compared to 26ai. If you’re using such old clients, start upgrading them right away. This also applies to database links.

Optionally, monitor the database over time to generate a list of clients connecting.

AutoUpgrade

Get the latest version of AutoUpgrade from My Oracle Support. I recommend that you always use the latest version. AutoUpgrade is fully backward compatible, so any newer version can upgrade older releases of Oracle AI Database.

Upgrade Readiness

Run AutoUpgrade in analyze mode to determine your database’s upgrade readiness. Check the summary report for findings with no fixups. Such findings must be dealt with manually.

You can run the analysis even before you install the new Oracle home. Simply specify target_version=26 in your AutoUpgrade config file, and AutoUpgrade knows which checks to run.

Dictionary Check

Check the dictionary in your most important databases. You can run a dictionary check together with an AutoUpgrade analysis. In your config file:

upg1.run_dictionary_health=full

Or, you can run it separately using DBMS_DICTIONARY_CHECK.

Behavior Changes

Review the upgrade guide for information on deprecated and desupported features, plus any behavior changes.

Also, use ORAdiff to check for changes between your current release and 26ai. Use the Report menu item to generate a report that you can share with your company.

It’s also a good idea to look at the new reserved keywords. Especially, those marked as reserved. Don’t use those keywords in object/column names, queries, or the like.

Grid Infrastructure

If Grid Infrastructure manages your database either in RAC or Oracle Restart configuration, you should upgrade it as well. If you can tolerate an additional maintenance window, I’d recommend upgrading Grid Infrastructure in advance.
Grid Infrastructure 26ai can manage databases from 19c and onwards. Any older database must be moved away from the system.
I recommend keeping the GI and database patch levels in sync. If you want to upgrade the database to 26.1, then upgrade GI to the same Release Update. If that’s not possible, at least keep it within two Release Updates.

Days Before

Statistics

Gather dictionary and fixed objects statistics:

begin
   dbms_stats.gather_fixed_objects_stats;
   dbms_stats.gather_schema_stats('SYS');
   dbms_stats.gather_schema_stats('SYSTEM')
end;

I prefer gathering schema stats rather than dictionary stats. I’ve seen a few edge cases solved by schema stats, and generally, current stats on SYS and SYSTEM are sufficient.
Gather statistics no earlier than seven days before the upgrade. If AutoUpgrade determines your statistics are older than that, it will gather them as part of the upgrade. This extends downtime unnecessarily.
If you’re curious, you can find details about the importance of fixed objects statistics in a blog post by Maria Colgan.

Install Oracle Home

You can use AutoUpgrade to:

In release 26ai, the Oracle homes that you download are already patched with the latest Release Update and OPatch.

On the Day of Upgrade

Backup

If time allows, run a level 0 backup. If not, you have to settle with a level 1.

Don’t run the backups inside your maintenance windows; that’s a waste of downtime. Start the backup in advance, so it finishes just before the maintenance window begins.

AutoUpgrade automatically creates a guaranteed restore point before starting the upgrade.

Scheduler

Normally, it is not necessary to disable the scheduler. But in some situations, it can be beneficial.

That’s It

You are now ready to begin your journey to Oracle AI Database 26ai and its many exciting new features.

Check the other blog posts related to upgrade to Oracle AI Database 26ai.

Happy upgrading!

RAC Rolling Patching in Autoupgrade – Looking for Early Testers

Support for RAC rolling patching in AutoUpgrade has been on our wishlist for a while. Finally, our developers are about to write the last lines of code.

We plan to release the feature next year, but we’d like to get some early feedback on the functionality.

If you’d like to give it a try, here’s your chance.

What Do You Get

Early access to the functionality.
The latest version of AutoUpgrade, plus the code for RAC rolling patching.
Introduction to the feature and a short description of how it works.
Possibility to provide feedback and influence our decisions.
A big THANK YOU for helping us.

What Do We Expect

You have time and resources to test the functionality in your own environment.
You will report the errors as service requests using My Oracle Support.
You can share the AutoUpgrade log files.

What We Hope

If you like the feature, you will help us spread the message.
We’d also love it if you could provide a quote, a video, or even a reference story.

How

Send me an e-mail at daniel.overby.hansen (a) oracle.com.
Add a few words about your setup and such.
I can’t guarantee that everyone will be able to help us.

I’m really excited about this feature, and I know many of you are waiting for it.

Upgrade to Oracle AI Database 26ai

Get ready for the future and enjoy the many new cool features in Oracle AI Database 26ai. It is just an upgrade away.

This blog post gives you a quick overview of the upgrade to Oracle AI Database 26ai. Plus, it is the starting point of a whole series of blog posts with all the details.

Things to Know

You can upgrade to Oracle AI Database 26ai if your database runs 19c or 21c.
- If you have an older database, you must first upgrade to 19c and then upgrade again to 26ai.
- If you’re on 23ai, you can just patch the database; no upgrade needed, no need to re-certify your app.
Oracle AI Database 26ai supports the multitenant architecture only. If your database is a non-CDB, you must also convert it to a pluggable database as part of the upgrade.
Although the Multitenant Option requires a separate license, you can still run databases on the multitenant architecture without it. Oracle allows a certain number of pluggable databases in a container database without the Multitenant Option. Check the license guide for details, and be sure to set max_pdbs=3 if you don’t have the license.
Oracle AI Database 26ai is the next long-term support release. It means you can stay current with patches for many years. At the time of writing, Premier Support ends in December 2031, but check Release Schedule of Current Database Releases (Doc ID 742060.1) for up-to-date information.
In Oracle AI Database 26ai, AutoUpgrade is the only recommended tool for upgrading your database. Oracle desupported the Database Upgrade Assistant (DBUA).
You can also use Data Pump or Transportable Tablespaces to migrate your data directly into a 26ai PDB. Even if the source database runs on a lower release and in a non-CDB. In fact, you can export from Oracle v5 and import directly into a 26ai PDB.

Important Things about Multitenant Migration

The multitenant conversion is irreversible. Not even Flashback Database can help if you want to roll back. You must consider this when planning for a potential rollback.
For smaller databases, you can rely on RMAN backups. However, for larger databases, a restore may take too long.
For rollback, you can use a copy of the data files:
- The CREATE PLUGGABLE DATABASE statement has a COPY clause, which copies the data files and uses the copies for the new PDB.
- Refreshable clone PDB can minimize the time needed to copy the data files by doing it in advance and rolling forward with redo.
- Use image copies of your data files and roll forward with RMAN.
- Use a standby database for rollback.
- Storage snapshots
Depending on your Data Guard configuration, the plug-in operation needs special attention on your standby databases. If you have standby databases, be very thorough and test the procedure properly.
In the worst case, you can break your standby databases without knowing it. Be sure to check your standby databases at the end of the migration. I recommend performing a switchover to be sure.
The multitenant conversion requires additional downtime. Normally, I’d say around 10-20 minutes of additional downtime. But if you have Data Guard and must fix your standby databases within the maintenance window, then you need even more time.

And Then …

Over the coming months, I will publish several blog posts with step-by-step instructions and other info. Stay tuned!

By the way, this blog post was originally posted a while ago for Oracle Database 23ai, but we all know what happened there. So, let’s start over with Oracle AI Database 26ai.

Happy upgrading!

How to Fix Errors in AutoUpgrade Download Mode

If you’re a frequent visitor to my blog, you’ll know I’m a big AutoUpgrade fanboy – especially the download mode, which can save you hours of downloading patches on My Oracle Support.

Recently, I was preaching to another customer, and when they finally gave in, here’s what happened:

We gave it a shot, but we keep running into errors when we try the download mode.

So, let’s see how we can solve the most common problems.

My Oracle Support

You must have an Oracle SSO account.
That account must be linked to a Customer Support Identifier (CSI) that has an active support agreement.
In that CSI, you must have the privilege to download patches. The MOS administrator in your organization can help you with that.
- In User Details, select the appropriate Support Identifier, set the Patches drop-down to Download.
If AutoUpgrade tells you that your username or password is incorrect:
```
*Connection Failed - You entered an incorrect user name or password.* 
```
- You should ensure that you’re using the latest version of AutoUpgrade. We recently fixed a bug for passwords with certain special characters.

Network Connectivity

AutoUpgrade must connect to the following servers:
Those servers are part of a Content Delivery Network (CDN), so expect changing IP addresses. Base your firewall rules on DNS names rather than IP addresses.

You can connect via a proxy:

export https_proxy=https://proxy.weyland-yutani.net:8080
java -jar autoupgrade.jar ... -mode download

Common Errors

*Request to https://login-ext.identity.oraclecloud.com failed with response code [403]*

Open your firewall. Allow traffic based on DNS names, not IP addresses.
Optionally, connect via a proxy server.

*unable to find valid certification path to requested target*

Check the workaround described in Autoupgrade Patching Fails To Download Patches With Error “Unable To Find Valid Certification Path” (Doc ID 3082396.1).
InsaneDBA, aka Osman, wrote a good blog post on this topic – especially for those of you on Windows.

*SSL peer shut down incorrectly*

Check firewall settings and security groups to ensure they permit SSL traffic on the required ports.

Windows

If AutoUpgrade requires that you use an elevated command prompt (the run as administrator thing) when you use download mode, you should update to the latest version of AutoUpgrade. It no longer requires this.

Happy downloading!

How To Upgrade 100 PDBs And Move Them To Another Server

The other day, I helped a customer with an interesting case:

We have a 19c CDB with 100 PDBs running on old hardware. We need to upgrade and move the PDBs to a new server with Oracle Database 23ai. We would like to move the PDBs in batches.

Here’s how I would do that using AutoUpgrade and refreshable clone PDBs.

How To

In each PDB, you must create a user that you can use for the database link:

create user dblinkuser identified by dblinkuser;
grant create session to dblinkuser;
grant select_catalog_role to dblinkuser;
grant create pluggable database to dblinkuser;
grant read on sys.enc$ to dblinkuser;

Repeat this process for every source PDB.

In the target CDB, create a database link in the root container for every PDB:
```
create database link clonepdb1
connect to dblinkuser
identified by dblinkuser
using 'sourcehost/pdb1';
```
- Repeat this process for each PDB and assign a unique name to the database link.

Create an AutoUpgrade config that upgrades a batch of the PDBs. In this case, PDBs 1-4:

global.global_log_dir=/home/oracle/logs
global.keystore=/home/oracle/keystore

upg1.sid=CDB19
upg1.target_cdb=CDB23
upg1.source_home=/u01/app/oracle/product/19
upg1.target_home=/u01/app/oracle/product/23
upg1.pdbs=PDB1,PDB2,PDB3,PDB4
upg1.source_dblink.PDB1=CLONEPDB1 1800
upg1.source_dblink.PDB2=CLONEPDB2 1800
upg1.source_dblink.PDB3=CLONEPDB3 1800
upg1.source_dblink.PDB4=CLONEPDB4 1800
upg1.target_pdb_copy_option.PDB1=FILE_NAME_CONVERT=NONE
upg1.target_pdb_copy_option.PDB2=FILE_NAME_CONVERT=NONE
upg1.target_pdb_copy_option.PDB3=FILE_NAME_CONVERT=NONE
upg1.target_pdb_copy_option.PDB4=FILE_NAME_CONVERT=NONE
upg1.target_pdb_name.PDB1=PDBNEW1
upg1.target_pdb_name.PDB2=PDBNEW2
upg1.target_pdb_name.PDB3=PDBNEW3
upg1.target_pdb_name.PDB4=PDBNEW4
upg1.parallel_pdb_creation_clause.PDB1=2
upg1.parallel_pdb_creation_clause.PDB2=2
upg1.parallel_pdb_creation_clause.PDB3=2
upg1.parallel_pdb_creation_clause.PDB4=2
upg1.start_time=01/10/2026 02:30:00

In source_dblink you specify the name of the database link that you previously created. You must assign the right database link to the right PDB. The following number (1800) is the refresh rate in seconds. You can adjust that accordingly.
In this example, you’re using Oracle Managed Files, and FILE_NAME_CONVERT=NONE allows the target CDB to automatically generate new file names.
I recommend renaming the PDB to avoid any confusion. You can do that with target_pdb_name.
Also, limit the number of parallel processes that the target CDB can use to copy the PDB over the network. The file copy happens for all PDBs at the same time, so in this case, the target CDB should have at least 8 CPUs. Also, take the resources of the source CDB into consideration.

Run AutoUpgrade in analyze mode on the source database host. This checks the PDBs for upgrade readiness:
```
java -jar autoupgrade.jar -config upgrade.cfg -mode analyze
```
Run AutoUpgrade in deploy mode on the target database host:
```
java -jar autoupgrade.jar -config upgrade.cfg -mode deploy
```
- The target CDB now starts to copy the PDBs over.
- After that, it periodically refreshes the PDBs with redo from the source database.
- It doesn’t proceed with the actual upgrade.
- Instead, it waits until you reach the time specified by the start_time parameter.
Downtime starts now
Run AutoUpgrade in fixups mode on the source database host. This runs recommended and required pre-upgrade fixups in the PDBs:
```
java -jar autoupgrade.jar -config upgrade.cfg -mode fixups
```
Instruct AutoUpgrade to move on with the upgrade even though the start_time hasn’t been reached yet:
```
upg> proceed -job <job-number>
```
AutoUpgrade now performs a final refresh to bring over the latest changes. Then, it upgrades the PDBs concurrently. It will upgrade CPU_COUNT/2 at the same time. You can tweak that using catctl_options.
Be sure to stop the source PDBs that are running in the 19c CDB.

That’s it! You’ve now moved and upgraded the first batch of PDBs. You can repeat the process with the next batch.

In One Batch

Technically, you can put all PDBs into the same configuration file and move/upgrade them all at the same time.

However, you might as well use Data Guard to build a standby database and then perform an upgrade of the entire CDB.

However, if possible, I would recommend moving/upgrading the PDBs in batches.

Final Words

AutoUpgrade and refreshable clones are a perfect match.

What would you recommend? Leave a comment and let me know what you would suggest.

AutoUpgrade New Features: A Very Easy Way To Generate A Config File

I use AutoUpgrade everyday. Wake me up in the middle of the night and I can write one for you in the dark.

… But it might not be the case for everyone.

So, here’a quick way to generate an AutoUpgrade config file.

Auto Config

Set the environment to the Oracle Database you want to patch or upgrade:

$ env | grep ORA
ORACLE_SID=UPGR
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/19

Call AutoUpgrade with -auto_config parameter:
```
java -jar autoupgrade.jar -auto_config
```
- You can also specify the database using the -sid <mydb> parameter.
AutoUpgrade creates a sample config file named auto_config.cfg.
- It is a basic config file with the most essential parameters already filled out from the environment, like sid, source_home and logging directories.
- If you have multiple candidate Oracle homes, AutoUpgrade adds all of them as a comment, and you can easily select the one you want
```
#upg1.target_home=/u01/app/oracle/product/21
#upg1.target_home=/u01/app/oracle/product/23
```
- All other parameters are added as comments with a description on their usage. You can uncomment those that you need.
Use AutoUpgrade to patch or upgrade your Oracle Database.

Final Words

If you need a more elaborate config file, you can also try Marcus’ AutoUpgrade Composer.

Happy AutoUpgrading!

AutoUpgrade New Features: Create Oracle Home Path Dynamically

Some customers prefer to install Oracle homes in a path that indicates the patch level, like:

/u01/app/oracle/dbhome_1928

1928 indicates this is Oracle Database 19c with Release Update 28. If you use AutoUpgrade to create your Oracle home, you can specify that path in your config file:

patch1.target_home=/u01/app/oracle/dbhome_1928

To ease automation, AutoUpgrade can dynamically determine the target Oracle home using placeholders. After downloading the patches, it checks which Release Update it will apply.

patch1.target_home=/u01/app/oracle/dbhome_%RELEASE%%UPDATE%

Easier Patching

Take a look at this config file

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
global.folder=/home/oracle/patch-repo
patch1.source_home=/u01/app/oracle/product/dbhome_1927
patch1.target_home=/u01/app/oracle/product/dbhome_%RELEASE%%UPDATE%
patch1.sid=FTEX
patch1.patch=RECOMMENDED

patch=RECOMMENDED or even patch=RU would always get the latest Release Update. At time of writing, that would be 19.28.
target_home contains the placeholders. After AutoUpgrade determined that 19.28 is the latest Release Update, it would dynamically determine the Oracle home path.
You would still need to update source_home in the config file. It will change after each run because you use out-of-place patching.

Now, you can just start AutoUpgrade every quarter:

java -jar autoupgrade.jar \
     -config FTEX.cfg \
     -patch \
     -mode deploy

AutoUpgrade downloads the latest Release Update and builds a new Oracle home for your – with a dynamically created path reflecting the Release Update.

Ain’t that easy?

Other Release Updates

What if you want to install an older Release Update. That works too:

patch1.target_home=/u01/app/oracle/product/dbhome_%RELEASE%_%UPDATE%
patch1.patch=RU:19.27,OPATCH

This will install the Oracle home in:

/u01/app/oracle/product/dbhome_19_27

Even Easier

Here’s another way. It requires that the environment is set correctly and works entirely without a config file.

export ORACLE_SID=FTEX
export ORACLE_HOME=/u01/app/oracle/product/19
export AU_LOG_DIR="/home/oracle/autoupgrade-patching/log_"`date +%Y%m%d_%H%M%S`
java -jar autoupgrade.jar \
     -config_values "global.global_log_dir=$AU_LOG_DIR,global.folder=/home/oracle/patch-repo,download=no,target_home=/u01/app/oracle/product/dbhome_%RELEASE%%UPDATE%,patch=RECOMMENDED" \
     -patch \
	 -mode deploy

AutoUpgrade takes sid and source_home from the environment variables ORACLE_SID and ORACLE_HOME.
Then you specify other parameters as a comma-separated list using -config_values.
Notice the target_home with placeholders in the long list of parameters.
The AutoUpgrade logging directory uses a timestamp to ensure a new one is used on each invocation.

Final Words

It’s now easier to automate creation of Oracle homes using AutoUpgrade.

Do you think this feature is useful? Do you need other replacement variables?

AutoUpgrade New Features: Patch OCW Component In Oracle Home

Every Oracle home contains an Oracle Clusterware (OCW) component. It’s used to interact with Grid Infrastructure when you are using Oracle Restart or Oracle RAC. But even when you don’t use those, the component is still part of your Oracle home.

The Database Release Update doesn’t update the OCW component in your Oracle home. You must use the Grid Infrastructure Release Update for that.

In AutoUpgrade, it is easy to update the OCW component. Let’s see how it works.

How To Also Patch The OCW Component

My database hasn’t been patched for a while:

$ORACLE_HOME/OPatch/opatch lspatches

35648110;OJVM RELEASE UPDATE: 19.21.0.0.231017 (35648110)
35787077;DATAPUMP BUNDLE PATCH 19.21.0.0.0
35643107;Database Release Update : 19.21.0.0.231017 (35643107)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

I’ve never updated the OCW component, so it’s still on the patch level of the base release, 19.3.0.0.0.

I use the latest version of AutoUpgrade:

wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

I create an AutoUpgrade config file, FTEX.cfg:

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
patch1.source_home=/u01/app/oracle/product/19
patch1.target_home=/u01/app/oracle/product/19_27
patch1.sid=FTEX
patch1.folder=/home/oracle/patch-repo
patch1.patch=OPATCH,RU,OCW,DPBP,OJVM

By adding OCW to the patch parameter, AutoUpgrade also downloads the GI Release Update and updates the OCW component.

I patch the database:

java -jar autoupgrade.jar -config FTEX.cfg -patch -mode deploy

When AutoUpgrade completes, I check the new patch level:

$ORACLE_HOME/OPatch/opatch lspatches

37499406;OJVM RELEASE UPDATE: 19.27.0.0.250415 (37499406)
37654975;OCW RELEASE UPDATE 19.27.0.0.0 (37654975)
37777295;DATAPUMP BUNDLE PATCH 19.27.0.0.0
37642901;Database Release Update : 19.27.0.0.250415 (37642901)

Notice how the OCW Release Update is now 19.27.0.0.0.

Some Details

When AutoUpgrade downloads patches, because I specified OCW, it will also download the GI Release Update:

 --------------------------------------------
 Downloading files to /home/oracle/patch-repo
 --------------------------------------------
 DATABASE RELEASE UPDATE 19.27.0.0.0
     File: p37642901_190000_Linux-x86-64.zip - LOCATED
 
 DATAPUMP BUNDLE PATCH 19.27.0.0.0
     File: p37777295_1927000DBRU_Generic.zip - LOCATED
 
 GI RELEASE UPDATE 19.27.0.0.0
     File: p37641958_190000_Linux-x86-64.zip / 83%

Including OCW is a smart way of downloading the GI Release Update. You can use it to patch your Grid Infrastructure.
In Oracle Database 23ai, you can download fully updated gold images. Besides having the latest Release Update, they also come with fully updated OCW components.

Is It Needed?

Should you update the OCW component when you patch your Oracle Database? Is it needed if you don’t use Oracle Restart, Oracle RAC, or Oracle ASM?

It is optional, but even if no GI Stack (ASM, Clusterware or RAC) is used inside the server, it is recommended not to ignore the security patches of the installed components. And apply the most recent OCW Patch.

How to apply OCW Release Update patches on db_home non-RAC / non-ASM (Doc ID 2970542.1)

Mike Dietrich has a good point as well:

As I neither use RHP/FPP or any of the HA components nor EM in my tiny little lab environments, I’m pretty certain that I won’t need the OCW bundle. But this may be different in your environments. And it doesn’t harm to apply it of course.

Adding the Oracle 19.14.0 OCW / GI bundle patch to my database home

Further, I know many customers who never patch the OCW component and haven’t run into related problems.

My recommendation: Update the OCW component when you patch your Oracle Database. Using AutoUpgrade it is so easy, that there’s no reason not to.

Happy patching!

The Easiest Way To Download Patches for Oracle Grid Infrastructure

Whether you patch Oracle Grid Infrastructure manually, using your own automation, or Oracle Fleet Patching and Provisioning, it all starts with downloading the patches.

Although AutoUpgrade doesn’t patch Grid Infrastructure, it can still download the latest version of OPatch and the GI Release Update.

How To Download Grid Infrastructure Release Update

I have already configured the AutoUpgrade keystore and saved my My Oracle Support credentials. You find instructions on how to do that here (search for Creating an AutoUpgrade Keystore).

I download the latest version of AutoUpgrade:

wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

I create a config file called get-gi-patches.cfg:

global.global_log_dir=/home/oracle/autoupgrade/logs
global.keystore=/home/oracle/autoupgrade/keystore

patch1.patch=RU,OPATCH,OCW
patch1.target_version=19
patch1.platform=LINUX.X64
patch1.folder=/home/oracle/autoupgrade/patches

I create the folder for the patches (config file parameter folder).
```
mkdir -p /home/oracle/autoupgrade/patches
```

I download the patches by starting AutoUpgrade in download mode:

java -jar autoupgrade.jar -config get-gi-patches.cfg -mode download

Here’s the output from AutoUpgrade:

AutoUpgrade Patching 25.3.250509 launched with default internal options
Processing config file ...
Loading AutoUpgrade Patching keystore
AutoUpgrade Patching keystore is loaded

Connected to MOS - Searching for specified patches

-----------------------------------------------------
Downloading files to /home/oracle/autoupgrade/patches
-----------------------------------------------------
DATABASE RELEASE UPDATE 19.27.0.0.0
    File: p37642901_190000_Linux-x86-64.zip - VALIDATED

GI RELEASE UPDATE 19.27.0.0.0
    File: p37641958_190000_Linux-x86-64.zip - VALIDATED

OPatch 12.2.0.1.46 for DB 19.0.0.0.0 (Apr 2025)
    File: p6880880_190000_Linux-x86-64.zip - VALIDATED
-----------------------------------------------------

That’s it! After a few minutes, I’ve downloaded the latest GI Release Update and OPatch. GI RELEASE UPDATE 19.27.0.0.0 – p37641958_190000_Linux-x86-64.zip OPatch 12.2.0.1.46 for DB 19.0.0.0.0 (Apr 2025) – p6880880_190000_Linux-x86-64.zip

Is it really that easy? Yes, it is…

I can now patch my GI Oracle home – for Oracle RAC Database and Oracle Restart.

Happy patching!

Appendix

I Want To Download A Previous Release Update

Rather than downloading the latest Release Update, you can choose to download a specific Release Update. You can specify that in the patch parameter:

patch1.patch=RU:19.26,OPATCH,OCW

Notice how the RU keyword has a suffix specifying the exact Release Update.

How to Upgrade

That’s It!

Appendix

What If My Database Is A RAC Database?

What If I Use Oracle Restart?

What If My Database Is Encrypted

Multitenant Upgrade

Other Config File Parameters

Weeks Before

Versioning

Platform Certification

Clients

AutoUpgrade

Upgrade Readiness

Dictionary Check

Behavior Changes

Grid Infrastructure

Days Before

Statistics

Install Oracle Home

On the Day of Upgrade

Backup

Scheduler

That’s It

What Do You Get

What Do We Expect

What We Hope

How

Things to Know

Important Things about Multitenant Migration

And Then …

Other Blog Posts

Non-CDB

CDB

PDB

OCI

My Oracle Support

Network Connectivity

Common Errors

Windows

How To

In One Batch

Final Words

Further Reading

Auto Config

Final Words

Easier Patching

Other Release Updates

Even Easier

Final Words

How To Also Patch The OCW Component

Some Details

Is It Needed?

How To Download Grid Infrastructure Release Update

Appendix

I Want To Download A Previous Release Update