Upgrade a PDB to Oracle Database 23ai Using Replay Upgrade

When you upgrade a PDB to Oracle Database 23ai, there is a new method for performing the upgrade. It’s called Replay Upgrade.

I would call it a convenience feature. You simply plug in to a higher release CDB and open the PDB. The CDB detects the lower-release PDB and performs the upgrade. You don’t have to invoke AutoUpgrade.

Here’s how to do it.

A Few Words on Replay Upgrade

In Oracle Database 23ai, you can upgrade the data dictionary in two ways:

  • Parallel Upgrade – Has been around for quite a few releases. It’s what you’ve used before and can still use.
  • Replay Upgrade – The new thing that enables you to upgrade the data dictionary by simplying plugging in a lower-release PDB and allowing the CDB to perform the upgrade – without using AutoUpgrade.

I suggest you watch this video about the fundamental differences between the two methods.

Replay Upgrade is not a substitute for the entire upgrade project. Even with Replay Upgrade, you must still run the pre-upgrade and post-upgrade tasks. The version of the PDB must be one that allows for a direct upgrade to Oracle Database 23ai: 19c or 21c.

AutoUpgrade uses Parallel Upgrade. You can force AutoUpgrade to use Replay Upgrade in your config file:

upg1.replay=yes

How To Upgrade Using Replay Upgrade

  1. You must perform the pre-upgrade tasks while the PDB is in the lower-release CDB.
  2. One of such tasks is to analyze the PDB for upgrade readiness:
    java -jar autoupgrade.jar ... -mode analyze
    
  3. If needed, run the pre-upgrade fixups:
    java -jar autoupgrade.jar ... -mode fixups
    
  4. Plug in a lower-release PDB into a higher-release CDB. It doesn’t matter whether you plugged in from a manifest file, using refreshable clone PDBs or any other method.
  5. Open the PDB:
    alter pluggable database PDB1 open;
    
    • When you open the PDB in normal mode, Replay Upgrade starts.
    • The open command doesn’t complete until the upgrade completes. The command is not hanging; it’s simply upgrading in the background.
    • If you open the PDB in upgrade mode, Replay Upgrade does not start.
  6. During the open command, you can see in the alert log that the CDB upgrades the PDB:
    2025-03-31T14:02:37.955470+00:00
    ORANGE(6):Starting Upgrade on PDB Open
    
  7. When the open command completes, the PDB will be upgraded. But it will open in restricted mode until you run Datapatch. From alert.log:
    ORANGE(6) Error Violation: SQL Patch, Cause: '23.5.0.24.07 Release_Update2407102158' is installed in the CDB but no release updates are installed in the PDB, Action: Call datapatch to install in the PDB or the CDB
    2025-03-31T14:11:03.803899+00:00
    ORANGE(6):Opening pdb with no Resource Manager plan active
    Violations: Type: 1, Count: 1
    Completed: Pluggable database ORANGE opened read write
    Completed:    alter pluggable database orange open
    
  8. Run Datapatch:
    $ORACLE_HOME/OPatch/datapatch -pdbs PDB1
    
  9. Restart the PDB to remove restricted mode:
    alter pluggable database PDB1 close immediate;
    alter pluggable database PDB1 open;
    
  10. Run post-upgrade tasks.

Want To Try It?

In our upgrade lab, Hitchhiker’s Guide for Upgrading to Oracle Database 23ai, there is no lab on Replay Upgrade.

You can still perform a Replay Upgrade if you want. I’ve created instructions in the appendix that you can use. The lab takes 15 minutes to complete.

My Database Is A Non-CDB

Replay Upgrade performs an upgrade-on-open. Interestingly, it can also perform a convert-on-open. The latter will run the same commands you’ll find in noncdb_to_pdb.sql, which you normally run to convert a non-CDB to a PDB.

So, you can simply plug a 19c non-CDB into a 23ai CDB. When you open the PDB, the CDB upgrades and converts to a PDB.

My Recommendation

I recommend using AutoUpgrade. It ensures that you run all the tasks and automates them completely, giving you the safest upgrade.

Replay Upgrade does look a lot easier at first glance, but you still need to remember all the pre-upgrade and post-upgrade tasks. When there’s something you must run manually, there’s always the risk that you forget one or two of the tasks.

For me, Replay Upgrade is a convenience feature you can use in a lab or demo environment or if you think it’s easier to incorporate in your automation. But even with automation, you can still use AutoUpgrade with the -noconsole command line option.

But the choice is yours.

Happy upgrading!

Appendix

Replay Upgrade Queries and Commands

  • Here’s how you can tell whether Replay Upgrade (Upgrade on Open and Convert On Open) is enabled:
    select property_name, property_value 
    from   database_properties
    where  property_name like '%OPEN%';
    
    You can set the property in the root container and in the PDB.
  • Here’s how to disable Replay Update:
    alter database upgrade sync off;
    

Hands-On Lab

Here are the instructions for trying a Replay Upgrade in our Hands-On Lab.

The below steps perform a Replay Upgrade of the ORANGE PDB from CDB19 to CDB23.

  1. Start by provisioning a new lab and connecting to it. The lab runs in Oracle LiveLabs and is completely free. No installation is required.
  2. Start the CDB19 database. It’s a container database on Oracle Database 19c:
    . cdb19
    env | grep ORA
    sqlplus / as sysdba<<EOF
       startup;
    EOF
    
  3. Create an AutoUpgrade config file:
    cd /home/oracle/scripts
    cat > orange-replay.cfg <<EOF 
    global.autoupg_log_dir=/home/oracle/logs/orange-replay
    upg1.source_home=/u01/app/oracle/product/19
    upg1.target_home=/u01/app/oracle/product/23
    upg1.sid=CDB19
    upg1.target_cdb=CDB23
    upg1.pdbs=ORANGE
    upg1.target_pdb_copy_option.ORANGE=file_name_convert=none
    upg1.timezone_upg=NO
    EOF
    
  4. Run AutoUpgrade in analyze mode:
    cd
    java -jar autoupgrade.jar -config scripts/orange-replay.cfg -mode analyze
    
    • AutoUpgrade analyzes the ORANGE PDB for upgrade readiness.
  5. Check the preupgrade summary report:
    cat /home/oracle/logs/orange-replay/cfgtoollogs/upgrade/auto/status/status.log
    
    • The report states Check passed and no manual intervention needed.
  6. Run the preupgrade fixups:
    java -jar autoupgrade.jar -config scripts/orange-replay.cfg -mode fixups
    
    • AutoUpgrade runs pre-upgrade fixups, if any.
  7. Unplug ORANGE from the 19c CDB:
    . cdb19
    sqlplus / as sysdba<<EOF
        alter pluggable database ORANGE close;
    	alter pluggable database ORANGE unplug into '/home/oracle/orange.xml';
    	drop pluggable database ORANGE keep datafiles;
    EOF
    
  8. Plug into the 23ai CDB and open ORANGE:
    . cdb23
    env | grep ORA
    sqlplus / as sysdba<<EOF
       set timing on
       create pluggable database ORANGE using '/home/oracle/orange.xml' nocopy;
       alter pluggable database orange open;
    EOF
    
    • The open command upgrades the PDB. The command runs for several minutes.
    • In the end, the command completes but prints Warning: PDB altered with errors.
  9. Run Datapatch on the ORANGE PDB:
    $ORACLE_HOME/OPatch/datapatch -pdbs ORANGE
    
  10. Restart ORANGE:
    sqlplus / as sysdba<<EOF
    	alter pluggable database orange close;
    	alter pluggable database orange open;
    	select open_mode, restricted from v\$pdbs where name='ORANGE';
    EOF
    
    • The PDB now opens normally (READ WRITE) and unrestricted.
  11. Run the post-upgrade fixups:
    java -jar autoupgrade.jar \
       -preupgrade "dir=/home/oracle/logs/orange-replay/fixups,inclusion_list=ORANGE" \
       -mode postfixups
    
    
  12. That’s it. ORANGE has now been upgraded:
    sqlplus / as sysdba<<EOF
    	select open_mode, restricted from v\$pdbs where name='ORANGE';
    	alter session set container=ORANGE;
    	select version_full from v\$instance;
    EOF
    

AutoUpgrade New Features: Better Automation To Patch Oracle Database on Windows

Running Oracle Database on Microsoft Windows is slightly different from running it on other platforms. So, of course, patching Oracle Database is also slightly different.

The Oracle Database runs as a Windows service. AutoUpgrade must re-create the service when you perform out-of-place patching so the service starts oracle.exe from the new Oracle home.

Oracle Database on Windows runs as a Windows service with a hardcoded Oracle home path

To recreate the service, you must specify the credentials of the user who runs the service. Windows allows you to store the credentials in a special file; AutoUpgrade can use that when it recreates the service.

AutoUpgrade brings up a prompt to store credentials for a Windows service

For security purposes, AutoUpgrades deletes the credential file when it is no longer needed. For automation, however, that’s impractical because you would need to recreate the credential file every time you patch or upgrade.

AutoUpgrade now allows you to keep the file and reuse it. To do so, use the config file parameter delete_credential_file.

How To Patch Oracle Database on Windows

  1. Get the latest version of AutoUpgrade:
    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    
  2. Create an AutoUpgrade config file:
    global.keystore=c:\oracle\autoupgrade\keystore
    patch1.source_home=c:\oracle\product\dbhome_19_26_0
    patch1.target_home=c:\oracle\product\dbhome_19_27_0
    patch1.sid=DB19
    patch1.folder=c:\oracle\patches
    patch1.patch=RECOMMENDED
    patch1.wincredential=c:\oracle\autoupgrade\credential
    patch1.delete_credential_file=false
    
  3. Load the credentials for the user running the service into a credential file:
    java -jar autoupgrade.jar 
         -config ...
         –patch 
         -load_win_credential "DB19"	
    
  4. Start AutoUpgrade in deploy mode:
    java -jar autoupgrade.jar 
         -config ...
         –patch 
         -mode deploy
    
    • AutoUpgrade finds and downloads the right patches for Windows.
    • Creates a new Oracle home with the new patches.
    • Completes the entire patching process.

That’s it! You’ve patched your Oracle Database on Windows.

Here’s a little demo from our YouTube channel. Be sure to subscribe so you don’t miss out.

Happy patching!

AutoUpgrade New Features: Include Monthly Recommended Patches When Patching

Staying even more up-to-date with Monthly Recommended Patches (MRP) is now easier when patching using AutoUpgrade.

MRP contains fixes from 555.1 conveniently bundled together in a single patch.

> To provide customers more frequent access to recommended and well-tested collections of patches, Oracle is pleased to introduce Monthly Recommended Patches (MRPs)

From My Oracle Support note ID 555.1

How To

  1. Get the latest version of AutoUpgrade:
    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    
  2. Add MRP to the patch entry in your AutoUpgrade config file:
    global.keystore=/home/oracle/autoupgrade-patching/keystore
    patch1.source_home=/u01/app/oracle/product/19/dbhome_19_25_0
    patch1.target_home=/u01/app/oracle/product/19/dbhome_19_26_0
    patch1.sid=DB19
    patch1.folder=/home/oracle/autoupgrade-patching/patch
    patch1.patch=RECOMMENDED,MRP
    
  3. Run AutoUpgrade in analyze, download or deploy mode, and AutoUpgrade gets: * RECOMMENDED – latest available Release Update, OPatch, Data Pump Bundle Patch and OJVM Bundle Patch * MRP – latest available MRP matching the Release Update
  4. Optionally, you can add one-off fixes that are not part of the Release Update or MRP:
    patch1.patch=RECOMMENDED,MRP,34672698
    
    • You can add more one-off fixes using a comma-separated list

Tell Me More About Monthly Recommended Patches

Here’s a little snippet from Virtual Classroom #16: Oracle Database Release and Patching Strategy for 19c and 23ai, where Mike explains the concept.

I recommend that you also install MRPs when possible. Using AutoUpgrade, it’s really easy to add them, so why miss out?

Happy patching

Appendix

Further Reading

Using Refreshable Clone PDBs from a Standby Database

The other day, I found myself praising refreshable clone PDBs to a customer (which I often do because it’s a killer feature). They liked the feature too but asked:

> We are concerned about the impact on the source database. When AutoUpgrade connects to the source database and clones the database, can we offload the work to a standby database?

Refreshable clone PDBs can eat up your resources if you don’t constrain the target CDB. So, let’s see what we can do.

Mounted Standby Database

This won’t work, because you must be able to connect to the database via a regular database link. Further, AutoUpgrade and the cloning process must be able to execute queries in the source database, which is not possible on a mounted database.

Open Standby Database / Active Data Guard

What if you stop redo apply and open the standby database? Or if you have Active Data Guard?

In this case, the database would be open in read-only mode, and those queries would work. However, the refreshable clone PDB feature was developed to work in and require a read-write database, so this won’t work either – Not even if you enable automatic redirection of DML operations (ADG_REDIRECT_DML).

Even if this case would work, we wouldn’t recommend it. Because, we recommend that you run analyze and fixups mode on the source database, which wouldn’t be possible on a read-only database. You could run analyze and fixups on the primary database. But is that really an option? If you’re worried about affecting your primary and want to offload to the standby, would running those commands on the primary be an option?

Snapshot Standby Database

What about a snapshot standby? That’s a read-write database. Let’s give it a try.

  1. Convert the source standby to a snapshot standby:
    DGMGRL&gt; convert database '...' to snapshot standby;
    
    • The standby must remain a snapshot standby for the entire duration of the job. If you need to switch over or fail over to the standby, you must restart the entire operation.
  2. Ensure the PDB is open on the source standby.
    alter pluggable database ... open;
    
    • Otherwise, you will run into ORA-03150 when querying the source database over the database link.
  3. In the source standby, create the user used by the database link and grant appropriate permissions:
    create user dblinkuser identified by ...;
    grant create session, create pluggable database, select_catalog_role to dblinkuser;
    grant read on sys.enc$ to dblinkuser;
    
  4. In the target CDB, create a database link that points to the PDB in source standby:
    create database link clonepdb
    connect to dblinkuser identified by ...
    using '';
    
  5. Create an AutoUpgrade config file:
    global.global_log_dir=/home/oracle/autoupgrade/log
    global.keystore=/home/oracle/autoupgrade/keystore
    upg1.source_home=/u01/app/oracle/product/19.0.0.0/dbhome_1
    upg1.target_home=/u01/app/oracle/product/23.0.0/dbhome_1
    upg1.sid=CDB19
    upg1.target_cdb=CDB23
    upg1.pdbs=PDB1
    upg1.source_dblink.PDB1=CLONEPDB 300
    upg1.target_pdb_copy_option.PDB1=file_name_convert=none
    upg1.start_time=+12h
    
  6. Start AutoUpgrade in deploy mode:
    java -jar autoupgrade.jar ... -mode deploy
    
  7. Convert the source standby back to a physical standby:
    DGMGRL&gt; convert database '...' to physical standby;
    

Is It Safe?

Using a standby database for anything else than your DR strategy, is sometimes perceived as risky. But it is not, as I explain in this blog post (section What Happens If I Need to Switch Over or Fail Over?).

Happy upgrading!

The Easiest Way to Download 19.27 Release Update

Oracle just released new Release Updates, so it’s time to patch your Oracle Database again. As much as I love patching, the part about finding and downloading patches is not that much fun.

Luckily, I can use AutoUpgrade to download the Release Update and other patches with just a few commands.

How to Download Release Updates

I can do the following on any computer. I just need Java 8 or 11 to run AutoUpgrade.

  1. I download the latest version of AutoUpgrade:

    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    
  2. I create an AutoUpgrade config file called get-patches:

    global.global_log_dir=/home/oracle/autoupgrade/logs
    global.keystore=/home/oracle/autoupgrade/keystore
    global.folder=/home/oracle/autoupgrade/patches
    
    patch1.platform=LINUX.X64
    patch1.patch=RU:19.27,OPATCH,OJVM
    
    • I want to download 19.27 Release Update and supporting patches for Linux and I specify that using the platform parameter.
  3. I’ve already used AutoUpgrade to download patches, so my My Oracle Support credentials are already stored in the AutoUpgrade keystore. If you’ve never used AutoUpgrade to download patches, follow the instructions below (see Creating an AutoUpgrade Keystore).

  4. I download the patches by starting AutoUpgrade in download mode:

    java -jar autoupgrade.jar -config get-patches -patch -mode download
    
  5. That’s it! I’ve download all the new Release Updates – plus OPatch and the matching OJVM bundle patch.

    • DATABASE RELEASE UPDATE 19.27.0.0.0 – p37642901_190000_Linux-x86-64.zip
    • OJVM RELEASE UPDATE 19.27.0.0.0 – p37499406_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…

Happy patching!

What About the Other Platforms

At the time of writing, Oracle has only released the Linux patches. Once the other platforms are available, you can easily download them as well. Check the Patch Availability Document for details. Add the following to your config file:

patch2.platform=ARM.x64
patch2.patch=RU:19.27,OPATCH,OJVM

patch3.platform=AIX.x64
patch3.patch=RU:19.27,OPATCH,OJVM

patch4.platform=SPARC.x64
patch4.patch=RU:19.27,OPATCH,OJVM

patch5.platform=SOLARIS.x64
patch5.patch=RU:19.27,OPATCH,OJVM

patch6.platform=WINDOWS.X64
patch6.patch=RU:19.27,OPATCH,OJVM

Creating an AutoUpgrade Keystore

The first time I use AutoUpgrade to download patches, I must store my MOS credentials in the AutoUpgrade keystore.

  1. I create my config file. It must include global.keystore to specify the location of the AutoUpgrade keystore.

  2. I start the password console:

    java -jar autoupgrade.jar -config get-patches -patch -load_password
    
  3. AutoUpgrade prompts for a password to protect its keystore. AutoUpgrade uses the password to encrypt the keystore, which stores my My Oracle Support credentials.

    • This is not the database keystore password that you use for TDE Tablespace Encryption.
    Processing config file ...
    
    Starting AutoUpgrade Patching Password Loader - Type help for available options
    Creating new AutoUpgrade Patching keystore - Password required
    Enter password:
    Enter password again:
    
  4. I specify my MOS username. AutoUpgrade then prompts me for the MOS password:

    MOS> add -user <mos-username-or-email>
    Enter your secret/Password:
    Re-enter your secret/Password:
    
  5. I save the changes, and I choose to create an auto-login keystore so I don’t have to enter the AutoUpgrade keystore password every time AutoUpgrade starts:

    MOS> save
    Convert the AutoUpgrade Patching keystore to auto-login [YES|NO] ? YES
    
  6. I exit, and that’s it:

    MOS> exit
    
    AutoUpgrade Patching Password Loader finished - Exiting AutoUpgrade Patching
    

Here’s a video explaining the use of the AutoUpgrade keystore:

Pro Tips

  • After downloading the patches, I still need to patch my databases. I can do that using AutoUpgrade as well.

  • Once MRPs (888.1) or critical fixes (555.1) become available for the Release Update, I can get those as well. Or, if I need specific one-off patches:

    patch1.patch=RU:19.27,OPATCH,OJVM,MRP,12345678,23456789,34567890
    
  • If the Data Pump bundle patch is also available, I can also get that:

    patch1.patch=RU:19.27,OPATCH,OJVM,DPBP,MRP,12345678,23456789,34567890
    
    • Notice the DPBP keyword, that toggles the download of the Data Pump bundle patch.

What About Grid Infrastructure

  • Although AutoUpgrade can’t patch Grid Infrastructure, it can still get the GI bundle patch:

    patch1.patch=RU:19.27,OCW
    

Be sure to patch Grid Infrastructure out-of-place and I’d recommend using the SwitchGridHome method.

Further Reading

AutoUpgrade New Features: Using Proxy to Download Patches

Once you try the download mode in AutoUpgrade to get patches from My Oracle Support, you will never download patches in any other way. It’s so simple and so easy.

Post from Bluesky from a user of AutoUpgrade satisified with the new download mode Post on Bluesky

Suppose you need to connect through a proxy server to reach My Oracle Support and get the patches. AutoUpgrade now supports several ways to use a proxy.

Download Patches Through a Proxy

  1. Get the latest version of AutoUpgrade:

    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    
  2. Set the proxy settings in an environment variable before calling AutoUpgrade:

    export https_proxy=https://proxy.weyland-yutani.net:8080
    java -jar autoupgrade.jar ... -mode download
    
    • Set https_proxy in lowercase. At least on Linux, environment variables are case-sensitive and although some programs can handle any case, it’s better to use the official case.

    • AutoUpgrade automatically picks up and uses the proxy.

Other Proxy Types

You can set https_proxy to a value matching this specification:

[https|http|socks5|socks]://(user_info@)site:port
  • Here’s an example of how to use SOCKS5 proxy:

    export https_proxy=socks5://proxy.weyland-yutani.net:8080
    
  • The user_info is optional. Here’s an example::

    export https_proxy=https://ellen:Olympia2092@proxy.weyland-yutani.net:8080
    

It Doesn’t Work

  • This error message indicates that you forgot to set the https_proxy environment variable or set it correctly:

    There were conditions found preventing AutoUpgrade Patching from successfully running
    
    *Downloading Oracle Patch files
    Patch query failed
    *login-ext.identity.oraclecloud.com*
    
  • This error message indicates that your proxy doesn’t allow connections to all the required servers:

    There were conditions found preventing AutoUpgrade Patching from successfully running
    
    *Downloading Oracle Patch files
    Patch query failed
    *Unable to tunnel through proxy. Proxy returns "HTTP/1.1 403 Forbidden"*
    

Required Connections

AutoUpgrade must connect to:

URLs are part of a CDN, so expect changing IP addresses. Use DNS names instead of IP addresses in your firewall/proxy configuration.

Happy patching!

Get the Slides and Recording Of “Migration to Oracle Autonomous Database – Part 1: Planning”

Last week, we aired our first webinar in our 4-part series on migration to Oracle Autonomous Database.

Migration to Oracle Autonomous Database – Part 1: Planning

The slides are available for download, and you can read the Q&A.

The Next Webinars

To complete your journey to Autonomous Database, be sure to sign up for the other webinars:

Often, you need to make changes to the database or application to fit into an Autonomous Database. In part 2, we show you how to deal with the findings from the Cloud Premigration Advisor Tool (CPAT).

Part 3 is all about demos—demos on how to migrate to Autonomous Database using a number of different techniques.

Finally, how is the life of a DBA after migrating to an Autonomous Database? Is there anything left to do? We think there is, and we’ll show you the cool life of a DBA on an Autonomous Database.

Happy Migrating

We’re looking for customers to collaborate with. If you’re already working on a migration project, contact us today. You might be our next reference customer.

As a last remark, subscribe to our YouTube channel so you never miss out on our tech videos.

Hey, Let Me Kill Your Network!

This short story is about the awesomeness of AutoUpgrade and refreshable clone PDBs.

Colleagues of mine were testing upgrades to Oracle Database 23ai using refreshable clone PDBs. They wanted to see how fast AutoUpgrade would clone the PDB and how that affected the source system.

The Systems

The source and target systems were identical:

  • Exadata X10M
  • 2-node RAC
  • 190 CPU/node
  • 25Gbps network/node

The database:

  • 1 TB in size
  • All data files on ASM

The Results

The source database is Oracle Database 19c. They configured AutoUpgrade to upgrade to Oracle Database 23ai using refreshable clone PDBs. However, this test measured only the initial copy of the data files – the CLONEDB stage in AutoUpgrade.

Parallel Time Throughput Source CPU %
Default 269s 3,6 GB/s 3%
Parallel 4 2060 0,47 GB/s 1%
Parallel 8 850 1,14 GB/s 1%
Parallel 16 591 1,65 GB/s 2%

A few observations:

  • Cloning a 1 TB database in just 5 minutes.
  • Very little effect on CPU + I/O on source, entirely network-bound.
  • The throughput could scale almost up to the limit of the network.
  • By the way, this corresponds with reports we’ve received from other customers.

Learnings

  • The initial cloning of the database is very fast and efficient.
  • You should be prepared for the load on the source system. Especially since the network is a shared resource, it might affect other databases on the source system, too.
  • The target CDB determines the default parallel degree based on its own CPU_COUNT. If the target system is way more powerful than the source, this situation may worsen.
  • Use the AutoUpgrade config file entry parallel_pdb_creation_clause to select a specific parallel degree. Since the initial copy happens before the downtime, you might want to set it low enough to prevent overloading the source system.
  • Be careful. Don’t kill your network!

Happy upgrading!

Full-day Workshop in The Netherlands and Belgium

A year and a half ago, Mike Dietrich and I ran the Real World Upgrade and Migrate to Oracle Database 19c and 23ai workshop in Belgium and The Netherlands. Now, we’re returning with…

Advanced Real World Oracle Database Upgrade and Migration to 19c and 23ai

Perhaps not the most creative title for a sequel. But what the title lacks in creativity, we will compensate tenfold in content.

Workshop banner

If you’re interested in database tech, Mike and I invite you to join our workshops.

… a day full of technical best practices, tips, tricks and advices based on real world customer experience

The Agenda

Here are the topics that we will cover:

  • Release Strategy with Oracle Database 19c and 23ai
  • Oracle Database Patching – We are going to change the game!
  • New Features in AutoUpgrade
  • How to size, build and operate a Multitenant environment efficiently
  • Data Pump – The best new performance features and optimizations
  • Migrations for hands-on DBAs
  • Cross-platform migrations – Pushing the limits
  • Oracle Database 23ai Feature Update for DBAs and Developers

It’s all tech, no marketing!

When and Where

The workshops take place at the Oracle offices in Utrecht and Vilvoorde. We start at 09:00 and finish at 16:30 or when we’ve answered the last question.

The workshops are an in-person event. It’s not possible to join remotely.

Sign Up

The workshops are free, but registration is required.

Sign up for Utrecht and Vilvoorde.

Seats are limited, so sign up to secure your seat. If you can’t make it, please cancel your registration so a fellow geek can join instead.

I hope to see you there for a full day of fun!

AutoUpgrade Never Fails, But When It does

Any piece of software has errors. It’s just a fact of life.

Should you encounter problems with AutoUpgrade, you can help us by compiling a zip package. This package contains valuable information that we need to troubleshoot.

Are You Using the Latest Version

  • Before generating a zip package, check that you’re using the latest version of AutoUpgrade… Perhaps the issue is already fixed:
    java -jar autoupgrade.jar -version
    
  • Check the latest version on oracle.com or AutoUpgrade Tool (Doc ID 2485457.1).
  • Or, simply get the latest version, and compare:
    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    java -jar autoupgrade.jar -version
    

How To Generate a Zip Package

  1. You add -zip to the AutoUpgrade command that failed.
  2. You remove all other parameters except -config.
  3. Execute the command:
    java -jar autoupgrade.jar -config db19.cfg -zip
    
  4. AutoUpgrade generates a zip package in the current directory and outputs the name of the file in the console.
    • You can specify the directory using -d <dir>.

What Does It Contain?

It contains:

  • All the files from the following locations:
    • global.global_log_dir
    • global.autoupg_log_dir
    • <prefix>.log_dir
  • Database alert log
  • Data Guard broker log
  • Attention log

When creating the zip package, AutoUpgrade doesn’t connect to the database but gathers the information from the file system.

If there are files that you don’t want to include in the package, you can exclude them using -zip_exclusion_list. Check the documentation for details.