At Oracle AI World next month, we have some pretty cool things to show you. But in between all our sessions and labs, we still have time to meet you.
We want you to get the most out of Oracle AI World and we are there to answer all your questions. We can help you with:
Upgrades
Patching
Migrations
AutoUpgrade
Data Pump
Cloud Premigration Advisor Tool
The Small Things
For quick questions, informal conversations, or even a selfie, come visit us at the Oracle AI World Hub.
Our team will have a dedicated booth next to the other database booths, and someone will be there throughout the event. Stop by and say hello – we’d be happy to talk.
The Bigger Things
For more complex questions or topics that require a deeper discussion, let’s arrange a private meeting.
We can talk about:
Upgrades, migrations and patching in general
Your specific challenges
An upcoming project where you would value our input
The future of Oracle AI Database and related tools
We’d also love to hear your feedback::
What has your experience been with our tools?
What could we improve?
How can we make the tools more useful for you?
We can’t help you with:
Service requests
License issues
Sales and commercial discussions
How Can I Schedule a Meeting?
First, take a few minutes to prioritize the topics you’d like to discuss. Meeting availability will be limited, so let’s focus on what matters most to you.
Then send me an email at daniel.overby.hansen@oracle.com. Please introduce yourself and your company, and let me know what you’d like to discuss.
I can’t guarantee that we’ll have time to meet everyone, but I guarantee that I’ll do my best to find a spot in our calendar.
In little more than a month, Oracle AI World 2026 starts in Las Vegas.
Sunday is the first day of the conference – and it’s all about learning.
Together with Oracle University, we’re hosting a full-day training session on upgrades, patching, and migration.
Together with Oracle University we’re hosting a full-day training session on upgrades, patching and migration.
Join Mike Dietrich, Daniel Overby Hansen, Rodrigo Jorge, and Alex Zaballa for a workshop featuring real-world customer cases and practical examples of upgrade, migration, and consolidation techniques and strategies.
Explore the power and possibilities of Oracle AI Database 26ai. Learn how to prepare for Oracle AI Database 26ai and leverage the latest enhancements in AutoUpgrade.
Discover how to take patching to the next level, ease operations in the multitenant architecture, get Data Pump on steroids, simplify migration to Oracle ADB for beginners and experts, and explore the coolest and best new features for DBAs in Oracle AI Database 26ai.
In a recent project, a customer used Advanced Queueing (AQ), and I had to move a single queue from one database to another.
In Oracle AI Database, you can use Data Pump to move queues. According to the documentation, exporting and importing a queue is straightforward, but there are some caveats to be aware of.
How to Export a Queue
I want to export the ORDER_Q queue in the APPUSER schema.
Under the hood, a queue consists of a queue table. Often, the queue uses an object type for its payload. I start by finding the queue table name and payload type:
select q.queue_table, qt.object_type
from dba_queues q, dba_queue_tables qt
where q.owner='APPUSER' and q.name='ORDER_Q'
and q.owner=qt.owner and q.queue_table =qt.queue_table;
QUEUE_TABLE OBJECT_TYPE
______________ __________________
ORDER_QT APPUSER.ORDER_T
I prepare a Data Pump parfile named queue_table_export.par. It exports the queue table:
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.
