I’ve already downloaded the patches to download_folder.
I want to create a new Oracle home in the target_home location.
AutoUpgrade copies the settings from the source_home.
After installing the new Oracle home, AutoUpgrade creates a gold image in download_folder. Instead of specifying the name of the gold image, I can also set create_gold_image=yes and let AutoUpgrade generate a name.
I set patch=recommended to get the recommended patches: latest Release Update, OPatch, MRP, OJVM, and Data Pump bundle patches.
I start AutoUpgrade to install the new Oracle home:
AutoUpgrade stores your MOS credentials and other secrets in its own keystore.
It’s convenient to create an auto-login keystore. Otherwise, AutoUpgrade prompts for the keystore password every time it needs a secret. But the auto-login keystore only works on the computer where it was created.
Unless you create a shared keystore. Let’s see how.
Shared Keystore
If you have an existing AutoUpgrade auto-login keystore, remove it:
A short while ago, in a server room far, far away …
… a brand-new, shiny Oracle Exadata Exascale was left unguarded, so I decided to try out a few things.
Here’s how to export to and import from Exadata Exascale storage.
Prerequisites
I create a directory for the Data Pump dump files pointing to the Exascale vault:
create directory dumpdir as '@MYVAULT1/CDB26/SALES/DUMPDIR';
MYVAULT1 is the name of my vault. Notice the @ sign, which denotes Exascale vaults, like + in ASM.
I can specify subdirectories (CDB26/SALES/DUMPDIR) to organize my files. However, there’s no concept of directories in Exascale, so these are really path prefixes.
Unlike a regular file system or ASM, I don’t have to create the matching file system directory.
I create another directory for my Data Pump log files:
create directory logdir as '/u02/app/oracle/admin/CDB26/SALES/logdir';
I can’t use the Exascale directory for log files.
Similar to ASM, I can’t store log files in Exascale.
I create the matching file system directory for logdir:
mkdir -p /u02/app/oracle/admin/CDB26/SALES/logdir
In Oracle RAC, I should place the directory in a cluster file system or ensure that the folder exists on all nodes.
Finally, I create a user to perform the Data Pump jobs:
create user dpuser identified by <password>;
alter user dpuser default tablespace users;
alter user dpuser quota unlimited on users;
grant datapump_exp_full_database to dpuser;
grant datapump_imp_full_database to dpuser;
I write the dump file to my Exascale vault by specifying the database directory (dumpdir) and then the dump file name specification. I’m using the %L wildcard to allow Data Pump to create additional files.
Data Pump must write the log file to a real file system, so I use logdir which points to a local file system.
At the end of the export, Data Pump writes the names of my dump files:
04-AUG-26 11:08:36.114: Dump file set for DPUSER.SYS_EXPORT_SCHEMA_01 is:
04-AUG-26 11:08:36.114: @MYVAULT1/CDB26/SALES/DUMPDIR/myexp01.dmp
04-AUG-26 11:08:36.145: Job "DPUSER"."SYS_EXPORT_SCHEMA_01" successfully completed at Tue Aug 4 11:08:36 2026 elapsed 0 00:01:03
Let me show you how to upgrade an encrypted non-CDB to Oracle AI Database 26ai. Since this release only supports the multitenant architecture, you must also convert it to a PDB.
To preserve the source database for rollback and to minimize downtime, I’ll use AutoUpgrade and refreshable clone PDBs.
How to Upgrade and Convert
AutoUpgrade and refreshable clone PDBs give you the option of moving the database to a different host. If you want to stay on the same host, just imagine source and target hosts are the same.
Start by familiarizing yourself with the restrictions on refreshable clone PDB for non-CDBs.
create user dblinkuser identified by ... ;
grant create session,
create pluggable database,
select_catalog_role to dblinkuser;
grant read on sys.enc$ to dblinkuser;
I need the user so I can connect from the CDB via a database link.
I’ll drop it after the upgrade.
In my target CDB, as SYS, I create a database link connecting to my source non-CDB:
create database link clonepdb
connect to dblinkuser identified by ...
using 'source-db-alias';
2. Analyze
I must run the pre-upgrade analysis on the source system.
I create an AutoUpgrade config file for the analysis. I call it upgrade26-analyze.cfg:
I set source_home to /tmp because it doesn’t exist on the target system. I set source_base to the Oracle base of my target system.
sid is the database that I want to upgrade and convert.
target_cdb is the SID of the database where the non-CDB ends up.
source_dblink.<sid> is the name of the database link and the refresh rate in seconds.
target_pdb_name.<sid> allows me to rename the database. I strongly recommend that you rename the database if your CDB is on the same system. Otherwise, you’ll have a service name collision to deal with.
start_time is when AutoUpgrade performs the final refresh and starts the upgrade/conversion. I set it far out in the future, so I can better control the final refresh using the proceed command. Leave a comment if you know what happens at the specified time. :-)
parallel_pdb_creation_clause.<sid> limits the number of parallel processes used by the CDB to make the initial copy. Set it at a reasonable level that doesn’t overload the source database.
target_pdb_copy_option.<sid> allows me to specify the location of the data files. I use OMF and let the database decide where to put the files.
drop_dblink instructs AutoUpgrade to drop the database link when it’s no longer needed.
I start the AutoUpgrade password console to load the target CDB keystore password:
AutoUpgrade informs me that it can’t run certain preupgrade fixups because the target Oracle home doesn’t exist on the source system. This is expected and ignorable.
Next, I switch to the target system. From the AutoUpgrade console, I instruct AutoUpgrade to proceed with the upgrade:
upg> proceed -job 100
AutoUpgrade performs a final refresh.
Then, it disconnects the PDB from the source.
Then, starts the upgrade and conversion.
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 101 completed
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs restored [0]
Jobs pending [0]
Please check the summary report at:
/home/oracle/autoupgrade/upgrade26/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/autoupgrade/upgrade26/cfgtoollogs/upgrade/auto/status/status.log
This includes the post-upgrade checks and fixups.
I review the Autoupgrade Summary Report. The path is printed to the console:
vi /home/oracle/autoupgrade/upgrade26/cfgtoollogs/upgrade/auto/status/status.log
If you’ve configured Data Guard on your target CDB, you must restore the PDB on all standbys. Check the appendix for details.
That’s It!
With AutoUpgrade, you can easily upgrade your encrypted non-CDB and convert it to a PDB. For maximum protection, AutoUpgrade lets me preserve the source non-CDB in case I need to roll back.
When your maintenance window starts, you must kick users off.
In a previous blog post, I gave an idea on how you can do that. Whatever you do, don’t restart the source database. It’ll break the refreshable clone PDB.
Does It Work Cross-Platform
Refreshable clone PDB does not work for cross-endian migrations (like AIX to Linux), but cross-platform should work fine (like Windows to Linux).
What If My Database Is A RAC Database?
Ensure that all instances can resolve the database link connection identifier and that the database link works from all instances. The CREATE PLUGGABLE DATABASE statement scales out on all instances for the initial cloning.
In your config file, when specifying the sid parameter you must use the SID on the node where AutoUpgrade runs. If my database is called DB19 and it runs on host1 which is instance 1 in my cluster, I’d specify:
upg1.sid=DB191
Recreate services in the target CDB using srvctl. If you have many services, consider export/import of the services.
Other Config File Parameters
The config file shown above is a basic one. Let me address some of the additional parameters you can use.
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.
before_action / after_action: Extend AutoUpgrade with your own functionality by using scripts before or after the job.
Compatible
During plug-in, the PDB automatically inherits the compatible setting of the target CDB. You don’t have to raise the compatible setting manually.
Typically, the target CDB has a higher compatible and the PDB raises it on plug-in. This means you don’t have the option of downgrading.
If you want to preserve the option of downgrading, be sure to set the compatible parameter in the target CDB to the same value as the source CDB.
A customer had to move hundreds of PDBs using AutoUpgrade and refreshable clone PDBs. As a cool customer, they wanted to automate the entire process.
The PDBs are encrypted, so AutoUpgrade needs the source and target TDE keystore passwords. AutoUpgrade stores these passwords in its own keystore until they are needed.
You can manually load the passwords into the AutoUpgrade keystore using the load password console (-load_password).
But loading passwords manually doesn’t fit very well with automation.
The Solution
For security reasons, there is no native way in AutoUpgrade to load these passwords besides typing them manually.
Loading passwords via response files or command line parameters exposes the sensitive information, e.g., in your command history.
But if you accept the risk, you can load passwords using the expect command. You’ll need to place the passwords in clear-text in a file for a short period. When the loading completes, you can remove the file and the passwords are now safely stored in the AutoUpgrade keystore.
Loading Passwords Using Expect
Here’s my AutoUpgrade config file called sales.cfg:
Since the file will contain my passwords, I place it in /dev/shm which is a tmpfs or RAM-based file system. I don’t want the file on persistent storage.
Replace MyS3cr3tPassw0rd# with the password you want for the AutoUpgrade keystore.
Replace ash@weyland-yutani.com with your MOS username.
Replace MyS3cr3tMOSPassw0rd# with your MOS password.
That’s It
With expect you can automate the loading of passwords into the AutoUpgrade keystore.
I consider it safer to load passwords manually, but to fully automate the process you must cut a corner.
I suggest using a unique keystore for each of your AutoUpgrade invocations. This makes it easier to automate. AutoUpgrade can also create a shared keystore that you can create once and then distribute to other servers.
A customer wanted help upgrading and moving to new hardware:
I have an 11g database running on old hardware. I want to upgrade to 19c and move to new hardware. I can’t use Data Guard to move the database because I can’t install 11g binaries on the new hardware.
What do I do?
Data Guard would be the obvious choice, but wasn’t possible here. But we can use RMAN incremental backups.
This allows us to move the database with little downtime and then perform the upgrade.
The Plan
Here’s an overview of the plan:
Perform a level 0 backup of the 11g database.
Restore the backup into a 19c instance on the new hardware.
Prepare the database for upgrade.
Perform a level 1 backup.
Recover the database.
Upgrade the database.
We can perform steps 1-2 in advance and save time during the outage.
Any newer version of Oracle AI Database can restore backups from a previous release. But to upgrade the database, we must be within the limitations for a direct upgrade. Oracle Database 19c supports direct upgrades from 11g.
Step 1: Initial Backup
The database is called UPGR and runs on the old hardware as an 11g database.
On the old system, I start by doing a level 0 backup of the source database:
RMAN> CONNECT TARGET /
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
BACKUP AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 0
DATABASE
FORMAT '/u01/app/oracle/backup/L0_%d_%T_%U.bkp'
PLUS ARCHIVELOG
FORMAT '/u01/app/oracle/backup/L0_%d_%T_%U.bkp'
TAG 'LEVEL0';
BACKUP CURRENT CONTROLFILE
FORMAT '/u01/app/oracle/backup/CTL.bkp'
TAG 'CONTROLFILE';
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
}
I store the backups on an NFS share that’s accessible to the new system as well.
I’m doing a compressed backup. Be sure you’re licensed for that.
You can customize the backup script.
I create a PFile:
SQL> CREATE PFILE='/u01/app/oracle/backup/pfile.txt'
FROM SPFILE;
Step 2: Configure Instance and Restore
I create a new instance on the new hardware. I must use the same name, UPGR.
On the new hardware, I create a PFile for my target instance. I use the original PFile as a template and make the necessary changes. Here’s the PFile that I’ll use:
RMAN> CONNECT TARGET /
RUN {
RESTORE CONTROLFILE
FROM '/u01/app/oracle/backup/CTL.bkp';
}
I restore from the NFS share.
Then, I mount the database and start the restore:
RMAN> CONNECT TARGET /
ALTER DATABASE MOUNT;
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
SET NEWNAME FOR DATABASE TO NEW;
CATALOG START WITH '/u01/app/oracle/backup/' NOPROMPT;
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE UNTIL AVAILABLE REDO;
RELEASE CHANNEL c1;
RELEASE CHANNEL c2;
}
I use Oracle Managed Files (OMF), so I use SET NEWNAME accordingly.
I use CATALOG to tell RMAN where to find the backups.
I restore the database and recover until there’s no more redo.
Step 3: Prepare for Upgrade
Downtime starts now.
On the source system, I create an AutoUpgrade config file, so I can check the upgrade readiness of my database.
RMAN incremental backup is a great feature to reduce downtime when Data Guard is not an option. You can restore to a higher release of Oracle AI Database as long as you stay within the limits for a direct upgrade.
You can enhance the procedure:
Run additional level 1 incremental backup/restores to minimize the time it takes to perform the last one.
Enable Block Change Tracking on the old database to shorten the time it takes to do incremental backups.
Run an additional AutoUpgrade preupgrade check days in advance to get early notice on any showstoppers.
Import: Release 19.0.0.0.0 - Production on Mon Jun 29 06:17:06 2025
Version 19.31.0.0.0
ORA-39002: invalid operation
ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version 44 into a target database with TSTZ version 45.
It all comes down to the TIMESTAMP WITH TIME ZONE (TSTZ) data type.
The database uses the timezone file to translate your TSTZ data to the right time. If the Daylight Saving Time (DST) rules change, a newer timezone file ensures that you still get the right data.
Data Pump refuses to import the data because differing timezone file versions could lead to incorrect TSTZ values.
The Solution
Simple: apply at least Release Update 19.27 and install the Data Pump bundle patch.
Data Pump now converts your TSTZ values when needed. During data, loading Data Pump uses an internal function called ORA_DST_CONVERT that does all the magic. The function can convert between both older and newer timezone file versions. Because each row requires a function call during import, you should expect a small performance overhead. I expect it to be negligible.
Remember, you can install the Data Pump bundle patch online without any downtime.
But I Don’t Have Timezone Data?
If your dump file doesn’t contain any TSTZ data, it’s safe to import even if the timezone file versions differ.
Older versions of Data Pump were overly cautious. Even without TSTZ data, they immediately failed when they detected a timezone file mismatch.
Why Does This Happen?
A few years ago, Oracle started shipping newer timezone file versions with every Release Update. It’s convenient and ensures that you always have the latest files installed.
But when you create a database, it gets the latest timezone file automatically. As you create databases over time, they’ll end up using different timezone file versions.
This is when you start seeing ORA-39405 in Data Pump.
In the good, ol’ days, timezone files were separate patches. Most people didn’t install them, so all of their databases ended up using the same timezone file version.
That’s It
If you have different timezone file versions in your source and target databases, Data Pump must convert your TSTZ columns to match the target database’s timezone file version. This requires at least Release Update 19.27 and the Data Pump bundle patch.
When you provision a new database in Oracle Cloud Infrastructure (OCI), it always comes with the latest timezone file installed.
But in a recent migration, we wanted a database with a specific timezone file version.
Here’s how you can get a new PDB with a custom timezone file.
Using OCI Tooling Doesn’t Work
The OCI tooling uses a template file to provision the database faster. But the template file comes with the latest timezone file. Timezone files are part of the Release Update, so the newer Release Update you’re on, the newer the timezone file is.
Using template files for provisioning means that you don’t get to choose which version of the timezone file you want in your database. Further, the usual hacks like removing timezone files from the Oracle home or using the environment variable ORA_TZFILE won’t work.
The Solution
I’m going to create a new PDB in an on-prem database, export that PDB to OCI and use that as my new PDB.
I start by finding an existing CDB with the desired timezone file, or I create a new one.
select version from v$timezone_file;
VERSION
----------
44
I don’t need to check
The patch level: I’ll sort out any patch differences with Datapatch in OCI.
The components: CDBs in OCI have all components installed.
I create a new empty PDB:
CREATE PLUGGABLE DATABASE PDBTEMPLATE ADMIN USER ADMIN IDENTIFIED BY mys3cr3tpassw0rd!;
I close and unplug my PDB:
ALTER PLUGGABLE DATABASE PDBTEMPLATE CLOSE;
ALTER PLUGGABLE DATABASE PDBTEMPLATE UNPLUG INTO '/home/oracle/pdbtemplate.pdb';
DROP PLUGGABLE DATABASE PDBTEMPLATE INCLUDING DATAFILES;
I transfer the PDB to my host in OCI. In my test, the size of the PDB was 600 MB.
Now, I can create a new PDB using the archive file:
CREATE PLUGGABLE DATABASE PDBNEW USING '/home/oracle/pdbtemplate.pdb';
ALTER PLUGGABLE DATABASE PDBNEW OPEN READ WRITE;
The PDB probably opens with plug-in violations. I ignore this for now.
I need to sort out any patching difference:
$ORACLE_HOME/OPatch/datapatch -pdbs PDBNEW
After a restart I check for plug-in violations:
ALTER PLUGGABLE DATABASE PDBNEW CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE PDBNEW OPEN;
SELECT TYPE, CAUSE, MESSAGE, ACTION
FROM PDB_PLUG_IN_VIOLATIONS
WHERE NAME='PDBNEW'
AND STATUS != 'RESOLVED'
AND NOT (CAUSE='OPTION' AND TYPE='WARNING' AND MESSAGE LIKE '%PDB installed version NULL%');
TYPE CAUSE MESSAGE ACTION
__________ ___________________________ _________________________________________________________________________________________________ __________________________
WARNING is encrypted tablespace? Tablespace SYSTEM is not encrypted. Oracle Cloud mandates all tablespaces should be encrypted. Encrypt the tablespace.
WARNING is encrypted tablespace? Tablespace SYSAUX is not encrypted. Oracle Cloud mandates all tablespaces should be encrypted. Encrypt the tablespace.
The query removes any warnings about components missing in my PDB.
I can ignore the warning about missing encryption of SYSTEM and SYSAUX
Finally, I create an encryption key (or rotate the key if the PDB is already encrypted):
ALTER SESSION SET CONTAINER=PDBNEW;
ADMINISTER KEY MANAGEMENT SET KEY
FORCE KEYSTORE IDENTIFIED BY <keystore-password>
WITH BACKUP;
Last, let’s check the timezone file versions in my CDB:
ALTER SESSION SET CONTAINER=CDB$ROOT;
SELECT CON$NAME, VALUE$
FROM CONTAINERS(SYS.PROPS$)
WHERE NAME='DST_PRIMARY_TT_VERSION'
ORDER BY 1;
CON$NAME VALUE$
___________ _________
CDB$ROOT 45
PDBNEW 44
The CDB uses the latest timezone file version, 45.
My new PDB uses an older timezone file, 44.
That’s It!
This workaround enables you to create PDBs with a custom timezone file version. I can use the same approach if I want a PDB with a specific set of components installed.
If there is network connectivity between the source and target CDB, I could also clone the PDBTEMPLATE over a network link.
Databases Are Fun 