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.

Where Is The OJVM Bundle Patch For Oracle Database 23ai?

A customer asked me:

Where do I download the OJVM bundle patch for Oracle Database 23ai? I can’t find it anywhere.

In Oracle Database 23ai, Oracle ships fully updated gold images instead of individual Release Updates. The customer installed the latest gold image and it didn’t contain the OJVM bundle patch:

$ORACLE_HOME/OPatch/opatch lspatches
37701424;OCW RELEASE UPDATE 23.8.0.25.04 (37701424) Gold Image
37701421;Database Release Update : 23.8.0.25.04 (37701421) Gold Image

In Oracle Database 19c, you would be able to see the OJVM bundle patch as a separate patch:

$ $ORACLE_HOME/OPatch/opatch lspatches
35648110;OJVM RELEASE UPDATE: 19.21.0.0.231017 (35648110)
35643107;Database Release Update : 19.21.0.0.231017 (35643107)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

Why is it missing from Oracle Database 23ai gold image and why can’t you download it separately?

OJVM In Oracle Database 23ai

Starting in Oracle Database 21c, there is no longer a separate OJVM bundle patch. Instead, the fixes are fully included in the Release Updates.

… the OJVM component patch has been incorporated within the 21c Database Release Update (RU) patch

Also, there is no longer any interuption or brownout when you start Datapatch. The OJVM fixes are now fully RAC Rolling Installable and Standby-First Installable.

So, just get the newest gold image in Oracle Database 23ai and that’s it.

What About Oracle Database 19c

Let’s just recap the situation when you have OJVM in Oracle Database 19c.

The patch is RAC Rolling Installable
Standby-First Installable (as long as you don’t have Active Data Guard and extensively use OJVM on the standby database)

First, are you using OJVM or can you remove it?

Then, how do you patch OJVM?

Start by downloading the OJVM bundle patch.
1. Use AutoUpgrade and include the OJVM keyword in your patch specification, like patch1.patch=OPATCH,RU,OJVM
2. Use the Download Assistant on My Oracle Support
When you start Datapatch and it applies the OJVM fixes, there is a short brownout while the Java system is reloaded. Any session that tries to use Java at that point will get ORA-29548 but will be able to retry after a few seconds.

Here’s a little video with additional information.

What About Grid Infrastructure?

You should not apply the OJVM bundle patch to your Grid Infrastructure homes.

OJVM PSU is not needed in the Grid home, only in the database home.

Happy patching!

AutoUpgrade New Features: Install Oracle Home on Brand-New, Empty Server

You can use AutoUpgrade to install an Oracle home on a brand-new, empty server.

Previously, AutoUpgrade used an existing Oracle home to determine how to create a new Oracle home. Now, you can use config file parameters to instruct AutoUpgrade on installing the new Oracle home.

This allows you to use AutoUpgrade to prepare a new server for use with Oracle Database.

How To

Preparations

I start with a brand new Oracle Linux 8 system.

This is a test system, so I disable SELinux:
```
sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
reboot
```
- Alternatively, follow the guidelines for SELinux in your organization.

Install the preinstall package and Java (required by AutoUpgrade):

yum -y install oracle-database-preinstall-19c
yum -y install java-1.8.0-openjdk

Additional configurations like mount points and swapfile.

Install Oracle Home

Download AutoUpgrade:

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

Create an AutoUpgrade config file called install-home.cfg:

global.global_log_dir=/home/oracle/autoupgrade/logs
install1.patch=RU:19.27,OPATCH,OJVM,DPBP
install1.folder=/u01/app/oracle/software
install1.target_home=/u01/app/oracle/product/dbhome_1927
install1.home_settings.oracle_base=/u01/app/oracle
install1.home_settings.edition=EE
install1.home_settings.inventory_location=/u01/app/oraInventory
install1.download=no

I have already downloaded the base release and required patches using AutoUpgrade download mode. The files are in an NFS file share which I specify with the folder parameter.
I use the home_settings parameters to specify how I want to install the Oracle home. There are many other settings that I can use.

I start AutoUpgrade:

java -jar autoupgrade.jar -config install-home.cfg -patch -mode create_home

On this system, the oracle user is not allowed to sudo, so I must manually execute the root scripts:
```
/u01/app/oracle/product/dbhome_1927/root.sh
/u01/app/oraInventory/orainstRoot.sh
```
- AutoUpgrade prints the scripts to the console.
- It also writes the scripts into <global_log_dir>/create_home_1/<job-no>/rootsh/rootsh.log.
That’s it! I’ve now installed a new Oracle home and can move on with the creation of a listener, database, and so forth

Appendix

Installing on Microsoft Windows

You can use the same functionality on Windows.

You must use home_settings.account_type to specify the user that runs the Windows service. If you specify a user, then it must exist already. Although runInstaller can create the user for you, AutoUpgrade doesn’t support it.
You should not use home_settings.inventory_location on Windows. On Windows, the Oracle Inventory is always placed in %SYSTEM_DRIVE%\Program Files\Oracle\Inventory.

Installing Java

AutoUpgrade requires Java 8 or Java 11. It doesn’t support newer versions because the tool must be backward compatible. The latest version of AutoUpgrade still supports upgrades from Oracle Database 11g.

I recommend using Oracle Java. This is what we test and develop with, however, other Java packs should be fine as well. I tested the commands in this blog post with OpenJDK.

If you have a license for Oracle Database, you can read about using Oracle JDK/JRE in the License Guide or Oracle Java SE licensing FAQ.

When A Refreshable Clone Takes Over The Service

Following my advice, a customer migrated a database to multitenant using refreshable clone PDB. The CDB was on the same host as the non-CDB.

When we prepare the migration and create the refreshable clone, the users can no longer connect to the source database.

The users were getting ORA-01109: database not open when connecting to the source database.

But this was before the final refresh and before the migration was supposed to happen.

Why did the refreshable clone PDB interfere with operations in the source database?

The Details

The customer has a non-CDB called SALES, which they wanted to migrate into CDB1. They wanted the PDB to keep the original name, SALES.

Any database registers a default service at the listener. The name of the default service is the same as the name of the database.

In this case, the non-CDB registered the sales service:

$ lsnrctl status

Service "sales" has 1 instance(s).
  Instance "SALES", status READY, has 1 handler(s) for this service...

The customer used AutoUpgrade for the migration. When preparing for the migration, they started in deploy mode, and AutoUpgrade created the refreshable clone.

Bear in mind that these steps are preparations only. The switch to the PDB should happen at a later time.

Look what happens to the listener:

$ lsnrctl status

Service "sales" has 2 instance(s).
  Instance "CDB1", status READY, has 1 handler(s) for this service...
  Instance "SALES", status READY, has 1 handler(s) for this service...

The CDB also registers a sales service. It does so because of the refreshable clone PDB with the same name.

The users were connecting to the default service, sales. The listener handed off the connections to the CDB, not the non-CDB.

Since the PDB was still a refreshable clone PDB, it was not open, and users received ORA-01109: database not open.

Besides that, the refreshing process didn’t work either. The refresh of the PDB happens over a database link to the source database. Guess what happened?

2025-05-09T07:25:58.854934+00:00
Errors in file /u01/app/oracle/diag/rdbms/cdb19/CDB19/trace/CDB19_ora_61633.trc:
ORA-17627: ORA-01109: database not open
ORA-17629: Cannot connect to the remote database server
ORA-17627 signalled during: ALTER PLUGGABLE DATABASE FTEX REFRESH...

Yes, it couldn’t connect to the source database either. It ended up trying to connect to itself.

Optimal Solution

The real problem is the connections to the default service, sales. The service with the same name as the database.

This service is not meant for general use. You should create your own service and have your application connect through that.

Why is using default services a bad idea?

You can’t customize the default service.
The default service is for administrative use only.
You easily end up with collisions like this one. This can also happen with two PDBs in different CDBs on the same host.
If you rename the database, you also rename the default service and have to update all connection strings.

Why are custom services a good idea?

Custom services allow you to set many attributes. While this might not be important for a single-instance database, it is essential for Data Guard and RAC.
When you clone a database, a custom service doesn’t follow with it. You have to create the services in the clone when and if it is appropriate.

You can create custom services using DBMS_SERVICE or srvctl. You can find more about that in a previous blog post.

Recommendation

Keep using refreshable clone PDB for migrations. It’s a great way to migrate, patch, or upgrade databases.
Always create your own custom service. Don’t use the default service.

Things to Know

Important Things about Multitenant Migration

And Then …

Other Blog Posts

Non-CDB

CDB

PDB

OCI

Webinar

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

OJVM In Oracle Database 23ai

What About Oracle Database 19c

What About Grid Infrastructure?

How To

Preparations

Install Oracle Home

Appendix

Installing on Microsoft Windows

Installing Java

The Details

Optimal Solution

Other Solutions

Recommendation