Tag: autoupgrade

AutoUpgrade New Features: The Patch Overview

I trust you’ve already used AutoUpgrade to download patches. If not, you’re missing out big time.

Here’s a nifty new feature that makes AutoUpgrade fit better into your automation and gives you an overview of what you’ve downloaded already.

The Download JSON File

  • AutoUpgrade constructs and maintains a JSON file named patches_info.json.
  • AutoUpgrade stores the file in the download folder (config file entry folder).
  • It contains information about all the patches AutoUpgrade has downloaded.
  • The file is cumulative, so it contains information about not just the latest download but also previous ones.

Example

Here’s a sample output:

{
    "patchFolder": "/home/oracle/patches",
    "patches": [
        {
            "description": "DATABASE RELEASE UPDATE 23.26.3.0.0(GOLD IMAGE)",
            "platform": "Linux x86-64",
            "releaseUpdate": "23.26.3.0.0",
            "files": [
                {
                    "name": "p39581612_230000_Linux-x86-64.zip",
                    "checksum": "DDBEBAC94B5F0B7D3FF4910AB01DB8FCDD3390A7",
                    "checksum-256": "2CAFECB11DBDD7F81C55DEE9FC846AA7E8F8C265721C1B8AB4B23EF13F94643D"
                }
            ]
        },
        {
            "description": "OPatch 12.2.0.1.52 for DB 23.0.0.0.0 (Jul 2026)",
            "platform": "Linux x86-64",
            "files": [
                {
                    "name": "p6880880_230000_Linux-x86-64.zip",
                    "checksum": "21EF498D3ECA4E734467A02FD0A799C464008726",
                    "checksum-256": "8C0D19B7774CD2E0443D2FC2BD29D3A784383199BEA3867CD4D39E2D32BFA6CC"
                }
            ]
        }
    ]
}

Checksum

After downloading a file, AutoUpgrade automatically checks the integrity of the file by calculating and verifying the checksum.

If there is a discrepancy, AutoUpgrade deletes the file and informs you.

If you want to verify it manually, you can find the expected checksum in the JSON file.

Human Readable

JSON is good for machines, but bad for humans, so here’s a party trick to beautify the output:

jq -r '
["TYPE","DESCRIPTION","PLATFORM","FILE","SHA1","SHA256"],
(.patches[] |
 [
   (if .description|test("RELEASE UPDATE") then "RU"
    elif .description|test("OPatch") then "OPATCH"
    elif .description|test("OJVM") then "OJVM"
    elif .description|test("DATAPUMP") then "DPBP"
    else "PATCH" end),
   .description,
   (.platform // "Generic"),
   .files[0].name,
   .files[0].checksum,
   .files[0]["checksum-256"]
 ]) | @tsv
' patches_info.json | column -t -s $'\t'

This command turns the JSON file into a tabular format:

TYPE    DESCRIPTION                                      PLATFORM      FILE                               SHA1                                      SHA256
RU      DATABASE RELEASE UPDATE 23.26.3.0.0(GOLD IMAGE)  Linux x86-64  p39581612_230000_Linux-x86-64.zip  DDBEBAC94B5F0B7D3FF4910AB01DB8FCDD3390A7  2CAFECB11DBDD7F81C55DEE9FC846AA7E8F8C265721C1B8AB4B23EF13F94643D
OPATCH  OPatch 12.2.0.1.52 for DB 23.0.0.0.0 (Jul 2026)  Linux x86-64  p6880880_230000_Linux-x86-64.zip   21EF498D3ECA4E734467A02FD0A799C464008726  8C0D19B7774CD2E0443D2FC2BD29D3A784383199BEA3867CD4D39E2D32BFA6CC

Thanks to Abhilash Kumar for the tip.

Happy patching!

Upgrade Encrypted Oracle Database 19c Non-CDB to 26ai and Convert to PDB Using Refreshable Clone PDB

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.

1. Preparations

I’ve already prepared my database.

I’ve also installed a new Oracle home and created a new CDB, or decided to use an existing one. The CDB can be on the same or a different system than the source non-CDB.

  1. In the source non-CDB, I create a user:
    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.
  2. 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.

  1. I create an AutoUpgrade config file for the analysis. I call it upgrade26-analyze.cfg:
    global.global_log_dir=/home/oracle/autoupgrade/upgrade26-analyze
upg1.source_home=/u01/app/oracle/product/19
upg1.target_version=26
upg1.sid=FTEX
upg1.target_cdb=CDB26
upg1.target_is_remote=yes
    • Since the target Oracle home doesn’t exist on my source system, I omit target_home.
    • Without the target Oracle home, AutoUpgrade can’t deduce the version I’m upgrading to, so I must specify target_version=26.
    • I specify target_is_remote=yes because the CDB is on another system. This causes AutoUpgrade to skip a few checks that it would normally run.
  2. I start AutoUpgrade in analyze mode:
    java -jar autoupgrade.jar -config upgrade26-analyze.cfg -mode analyze
  3. I check the pre-upgrade summary report:
    cd /home/oracle/autoupgrade/kraken/cfgtoollogs/upgrade/auto/status
vi status.log

3. Initial Clone

  1. I create a config file on my target system. I call it upgrade26.cfg:
    global.global_log_dir=/home/oracle/autoupgrade/upgrade26
global.keystore=/home/oracle/autoupgrade/keystore
upg1.source_home=/tmp
upg1.source_base=/u01/app/oracle
upg1.target_home=/u01/app/oracle/product/26
upg1.sid=FTEX
upg1.target_cdb=CDB26
upg1.source_dblink.FTEX=CLONEPDB 1800
upg1.target_pdb_name.FTEX=PDB1
upg1.start_time=19/01/2038 03:14:07
upg1.parallel_pdb_creation_clause.FTEX=2
upg1.target_pdb_copy_option.FTEX=file_name_convert=NONE
upg1.drop_dblink=yes
    • 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.
  2. I start the AutoUpgrade password console to load the target CDB keystore password:
    java -jar autoupgrade.jar -config upgrade26.cfg -load_password
    • This is required because my database is encrypted.
    • AutoUpgrade prompts me for the AutoUpgrade keystore password. This is a password to protect the AutoUpgrade keystore; not the database keystore.
  3. I want to add the database keystore password of the target CDB:
    TDE> add CDB26
    • CDB26 is the SID of the database and matches the target_cdb parameter in the config file.
    • I must enter the database keystore password.
  4. I save the database keystore password in the AutoUpgrade keystore:
    TDE> save
    • I agree to create an auto-login keystore and enter yes when prompted.
  5. Exit from the password console:
    TDE> exit
  6. Next, I start AutoUpgrade in deploy mode:
    java -jar autoupgrade.jar -config upgrade26.cfg -mode deploy
    • AutoUpgrade copies the data files over the database link.
    • Rolls the copies of the data files forward with redo from the source non-CDB.
    • There’s no outage. The source database remains open.
  7. Leave the AutoUpgrade session running.
    • Since the session might run for a while, better start it with tmux, screen, or similar.
    • Don’t use nohup because you must be able to interact with AutoUpgrade.
    • If your session disconnects, just restart AutoUpgrade with the same command.

4. Upgrade And Convert

The maintenance window has started, and users have left the database.

  1. On the source system, I run the pre-upgrade fixups on the source database:

    java -jar autoupgrade.jar -config upgrade26-analyze.cfg -mode fixups
    • 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.

  2. 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.

  3. 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.

  4. 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.

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

    vi /home/oracle/autoupgrade/upgrade26/cfgtoollogs/upgrade/auto/status/status.log

  6. I take care of the post-upgrade tasks.

  7. I update any profiles or scripts that use the database.

  8. I ensure that the source non-CDB is shut down.

    • If source non-CDB and target CDB are on the same system, AutoUpgrade stops the source non-CDB. You can override this using the parameter close_source.
    • When I’m sure I won’t need the source non-CDB anymore, I can delete it.

  9. I can remove the database link user:

    drop user dblinkuser cascade;

  10. Recreate the connection services.

  11. 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.

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

Happy upgrading!

Appendix

What If I Have Data Guard

Refreshable clone PDB doesn’t propagate fully to the standbys. The plug-in operation happens with deferred recovery.

After plug-in on the primary database, the standbys don’t protect the PDB. You must first restore the PDB to each standby database.

Also, check pages 210-221 in Move to Oracle Database 23ai – Everything you need to know about Oracle Multitenant – part 1.

Draining the Source Non-CDB

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.

Automating AutoUpgrade: Populating the Keystore

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

  1. Here’s my AutoUpgrade config file called sales.cfg:

    global.autoupg_log_dir=/home/oracle/autoupgrade/logs
global.keystore=/home/oracle/autoupgrade/keystore
upg1.sid=CDB19
upg1.target_cdb=CDB26
upg1.pdbs=SALES
upg1.source_home=/u01/app/oracle/product/19.0.0.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/23.0.0.0/dbhome_1
upg1.target_pdb_copy_option.SALES=file_name_convert=NONE
upg1.source_dblink.SALES=CLONE_LINK_SALES 300
upg1.start_time=01/01/2030 08:03:00
    • I’ve configured the location of the AutoUpgrade keystore using the global.keystore parameter.

  2. I create an expect file called sales.exp. I set the executable flag and ensures no others can read the file:

    touch /dev/shm/sales.exp
chmod 700 /dev/shm/sales.exp
    • 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.

  3. I add the following to my expect file.

    #!/usr/bin/expect

spawn java -jar autoupgrade.jar -config sales.cfg -load_password
expect "Enter password:"
send -- "MyS3cr3tPassw0rd#\r"
expect "Enter password again:\r"
send -- "MyS3cr3tPassw0rd#\r"
expect "TDE>\r"
send -- "add CDB19\r"
expect "Enter your secret/Password:\r"
send -- "Databas3CDB19#\r"
expect "Re-enter your secret/Password:\r"
send -- "Databas3CDB19#\r"
expect "TDE>\r"
send -- "add CDB26\r"
expect "Enter your secret/Password:\r"
send -- "Databas3CDB26#\r"
expect "Re-enter your secret/Password:\r"
send -- "Databas3CDB26#\r"
expect "TDE>\r"
send -- "save\r"
expect "Select auto-login mode for the AutoUpgrade keystore"
send -- "YES\r"
expect "TDE>\r"
send -- "exit\r"
expect eof
    • Using the spawn command I start the AutoUpgrade load password console.
    • I can wait for AutoUpgrade to print certain information using the expect command.
    • Then I can send the appropriate response – a command or a password – using the send command.
    • Be sure to add the \r at the end of your commands or passwords. All the passwords end with a # so you can see how the control character is appended.
    • This file contains the passwords in clear-text. Make sure the file is protected with restrictive file permissions.

  4. I start the password loading using expect:

    expect /dev/shm/sales.exp
    • expect starts the AutoUpgrade load password console and inputs the passwords when needed.

  5. I remove the expect file:

    rm /dev/shm/sales.exp

  6. Now that the keystore is populated with the TDE keystore passwords, I can move on with the process.

MOS Credentials For Patch Downloading

Pardon me for sidetracking a bit.

  • You can use the same approach to populate the keystore with MOS credentials for patch downloading.
  • Here’s an example of an expect file:
    #!/usr/bin/expect

spawn java -jar autoupgrade.jar -patch -config download.cfg -load_password
expect "Enter password:"
send -- "MyS3cr3tPassw0rd#\r"
expect "Enter password again:\r"
send -- "MyS3cr3tPassw0rd#\r"
expect "MOS>\r"
send -- "add -user ash@weyland-yutani.com\r"
expect "Enter your secret/Password:\r"
send -- "MyS3cr3tMOSPassw0rd#\r"
expect "Re-enter your secret/Password:\r"
send -- "MyS3cr3tMOSPassw0rd#\r"
expect "MOS>\r"
send -- "save\r"
expect "Select auto-login mode for the AutoUpgrade keystore"
send -- "YES\r"
expect "MOS>\r"
send -- "exit\r"
expect eof
    • 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.

Happy upgrading!

When You Forget To Rekey Your Encrypted Database

[The other day I was helping a customer perform an unplug-plug upgrade of an encrypted PDB using AutoUpgrade and a refreshable clone PDB.

Cloning PDB2 to NEWPDB2 and upgrading it

But it kept failing during the initial copy of the PDB:

upg> Copying remote database 'PDB2' as 'NEWPDB2' for job 101

-------------------------------------------------
Errors in database [CDB19]
Stage     [CLONEPDB]
Operation [STOPPED]
Status    [ERROR]
Info    [
Error: UPG-4016
[Unexpected exception error]
Cause: There was an error during the database clone operation
For further details, see the log file located at /u01/app/oracle/cfgtoollogs/autoupgrade/CDB19/101/autoupgrade_20400101_user.log]

-------------------------------------------------
Logs: [/u01/app/oracle/cfgtoollogs/autoupgrade/CDB19/101/autoupgrade_20400101_user.log]
-------------------------------------------------

Luckily, there’s extensive logging in AutoUpgrade, so I went into the directory holding the logs from the CLONEPDB stage and found the following:

create pluggable database "NEWPDB2"  FROM PDB2@CLONEPDB   file_name_convert=none  tempfile reuse keystore identified by "*" REFRESH MODE MANUAL
*
ERROR at line 1:
ORA-17628: Oracle error 46659 returned by remote Oracle server
ORA-46659: master encryption keys for the given PDB not found
Help: https://docs.oracle.com/error-help/db/ora-17628/

Let’s dig into the error.

A Possible Solution

A search on MOS revealed a note with a possible solution:

  • Manually export/import the encryption keys, or
  • Use the undocumented INCLUDING SHARED KEYS clause on the CREATE PLUGGABLE DATABASE statement.

I didn’t like these solutions because:

  • The target CDB should be able to import the keys automatically over the database link.
  • It worked fine on other encrypted databases without the workaround.

So what was the problem?

The Root Cause

  • In the source CDB, I could see from V$ENCRYPTION_KEYS that the source PDB, PDB2, didn’t have any encryption keys.

  • There should be an encryption key activated by PDB2. But the query returned no rows.

    SELECT * FROM v$encryption_keys WHERE activating_pdbname='PDB2';

  • So which encryption key did PDB2 use?

  • It turns out that PDB2 was recently created by cloning another local PDB, PDB1. PDB2 was recently cloned from PDB1

  • After cloning an encrypted PDB, the new PDB keeps using the same encryption keys as the source PDB. This is called a shared key.

  • So, PDB2 was using the same encryption key as PDB1.

  • For security reasons, if you try to clone a PDB using a shared key, the database errors out.

The Solution

  • I advise you to rekey your database after cloning. This ensures that the clone gets its own encryption keys and, thus, strengthens security.

  • After connecting to PDB2, I performed a rekey using the set key command:

    alter session set container=PDB2;
administer key management set key
   force keystore identified by "<keystore_pwd>"
   with backup;

  • Then, I could clone PDB2 using refreshable clone PDB and upgrade it without problems.

Lesson Learned

  • Oracle recommends that you rotate your encryption keys by doing a rekey.
  • After cloning an encrypted database, you should perform a rekey, so the clone has its own encryption keys and does not share encryption keys with another database.
  • The database can operate with a shared key, but it might cause problems later.

Happy upgrading!

How to Make Oracle AI Database Patching Easier

Oracle recently announced that they strongly recommend customers to apply Release Updates frequently and also announced plans to release monthly security updates.

For most of you this means that they must patch more often. Here are some ideas that can help you ease the burden of patching.

Grab a coffee with your DBA buddies and go over the list. Perhaps you’re missing out.

Patches

Oracle Home

  • Use out-of-place patching. This allows you to install the new Oracle home in advance. It reduces downtime, is less risky and makes rollbacks easier.

    • Use a brand-new home each time.
    • If you insist on in-place patching or clone Oracle homes be sure to clean up.

  • Create and use gold images. Once you’ve created your own gold image, you can deploy it to other hosts faster than installing and patching a new Oracle home.

    • Standardize on as few gold images as possible. Ideally, you have only one gold image for a specific Release Update.

  • Move files out of the Oracle home. You can find many configuration files and such inside the Oracle home. You must copy them to the new Oracle home when you use out-of-place patching – unless you use AutoUpgrade that does it for you.

    • Many of these files can be placed outside the Oracle home.

Connectivity

Patching

Datapatch

  • You can run Datapatch while users are connected. Knowing this you can minimize the outage on single instance databases by allowing users to connect as soon as you’ve restarted the database in the new Oracle home.

  • Use Datapatch sanity checks to assess the patch readiness of your database.

    • Generate the report by running datapatch -sanity_checks.
    • It’s a lightweight, non-intrusive check of the database.

  • Regularly clean up old patching metadata.

    • Limit the space used by Datapatch in the SYSTEM tablespace.

  • If you wonder what Datapatch spends time on, check the Datapatch logs in $ORACLE_BASE/cfgtoollogs/sqlpatch.

  • Ensure Datapatch patches the most important PDBs first.

    • Datapatch patches many PDBs at the same time. This depends on the database CPU_COUNT.
    • By default, Datapatch takes the PDBs in order by CON_ID.
    • But you can change the order using ALTER PLUGGABLE DATABASE <pdb_name> PRIORITY 1. The lower the priority, the sooner the PDB is processed.

  • Patch multiple databases at the same time.

    • Datapatch works on one database only. But you can start multiple instances of Datapatch to patch multiple databases simultaneously provided you have the CPU resources.

  • Speed up patching by removing unused components. Check your database using SELECT * FROM cdb_registry.

    • Generally, the more components, the longer patching/upgrading takes.

Automation

  • Automate the patching process. Including:

    • Rollback
    • Removal of old Oracle home
    • Listener patching

  • Tim Hall (ORACLE-BASE) wrote a series of blog posts about automation.

  • Use AutoUpgrade to automate the patching process.

  • Use Fleet Patching and Provisioning to automate the patching process.

    • A huge benefit for Exadata systems as FPP can patch the entire stack.
    • Separately licensed.

Grid Infrastructure

Miscellaneous

  • Familiarize yourself with the new patch level.

  • Oracle tries to avoid plan changes after patching by adding optimizer fixes as installed, but disabled. This increases plan stability.

That’s It

Did you find anything useful? Do you have other ideas to make patching easier?

Drop a comment and let’s help each other.

Happy patching!

Further Reading

Recent Webinars on Database Patching

After a short delay, the latest Release Updates are out for Linux.

Are you wondering about the remaining platforms? Or do you want to refresh your knowledge of database patching? We recently aired two webinars that you’ll find interesting.

Webinar
Database Patching for DBAs – Patch smarter, not harder Slides Q&A Recording
Patch smarter, not harder – MS Windows Special Edition Slides Q&A Recording

If you’re still downloading patches from My Oracle Support, you must watch these webinars. Save yourself a lot of time and grab all the patches you need in one command.

If you have RAC databases and the applications are a little slow to drain or you just want more control, check out the DBA-controlled draining we recently introduced.

My Highlights

Here are a few of the topics that I find especially useful:

Next Webinar

It didn’t take long after the last one before we settled on the next webinar:

Statistics and Migrations – Well-Kept Secrets Revealed

Interested? Take a look at the abstract and sign up.

Happy patching!

The Easiest Way to Download the Latest OPatch

I just saw a post on LinkedIn about the OPatch page on My Oracle Support stating it was the worst experience ever!

I had a look and I agree there’s room for improvement (possibly an understatement). I’ll see if I can find someone to give it a polish.

In the meantime, let me show you a much better to download the latest OPatch. Using AutoUpgrade in download mode.

How to Download OPatch

I download from my Mac, but Windows or Linux would do fine as well.

  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=/Users/daniel/orcl/autoupgrade/logs
global.keystore=/Users/daniel/orcl/autoupgrade/keystore
global.folder=/Users/daniel/Downloads/patches

patch1.platform=LINUX.X64
patch1.target_version=19
patch1.patch=OPATCH
    • I use the platform parameter to instruct AutoUpgrade to find OPatch for Linux.
    • I want OPatch for an 19c database and I specify that with target_version.
    • I just want OPatch, so I set patch=OPATCH.

  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. AutoUpgrade finds and downloads the right version of OPatch:

    AutoUpgrade Patching 26.3.260401 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 /Users/daniel/Downloads/patches
------------------------------------------------------
OPatch 12.2.0.1.51 for DB 19.0.0.0.0 (Apr 2026)
   File: p6880880_190000_Linux-x86-64.zip - VALIDATED
------------------------------------------------------

  6. That’s it! Is it really that easy? Yes, it is…

Happy patching!

What About the Other Platforms and Releases?

  • You can download for more platforms by adding:
    patch2.platform=WINDOWS.X64
patch2.target_version=19
patch2.patch=OPATCH

patch3.platform=AIX.x64
patch3.target_version=19
patch3.patch=OPATCH
  • You can download for more releases by adding:
    patch4.platform=LINUX.X64
patch4.target_version=21
patch4.patch=OPATCH

patch5.platform=LINUX.X64
patch5.target_version=26
patch5.patch=OPATCH
    • AutoUpgrade supports downloading patches from Oracle Database 19c and onwards.

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:

Further Reading

AutoUpgrade New Features: Download the Newest AutoUpgrade.jar

I’ve told you a million times:

Always get the latest version of AutoUpgrade!

A while ago, AutoUpgrade even became available for direct download from Oracle.com. But it must be even easier.

Now, AutoUpgrade downloads the latest version of itself when you use the keywords RECOMMENDED or AU. Here’s an example:

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
global.folder=/home/oracle/autoupgrade/patches
patch1.target_version=19
patch1.patch=RECOMMENDED

I start AutoUpgrade:

java -jar autoupgrade.jar -config download.cfg -mode download -patch

Conveniently, AutoUpgrade grabs the latest version after downloading the patches:

Connected to MOS - Searching for specified patches

-----------------------------------------------------
Downloading files to /home/oracle/autoupgrade/patches
-----------------------------------------------------
DATABASE RELEASE UPDATE 19.30.0.0.0(REL-JAN260130)
    File: p38632161_190000_Linux-x86-64.zip - LOCATED

...

autoupgrade.jar 26.2 (February 2026)
    File: autoupgrade.jar - LOCATED
-----------------------------------------------------

Simple and easy!

Other Tools

Besides AutoUpgrade, there are other important tools for Oracle AI Database.

Here’s a little sneak peek at what the next version of AutoUpgrade brings. Using this config file:

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
global.folder=/home/oracle/autoupgrade/patches

patch1.target_version=19
patch1.patch=AHF,CVU,SQLCL

You’ll get the latest versions of:

  • Autonomous Health Framework
  • Cluster Verification Utility
  • SQLcl

Leave a comment if you think there are other tools that AutoUpgrade should get for you.

AutoUpgrade New Features: Download Bundle Patches for Spatial and Text

If you use the Spatial Data Option or Oracle Text in your Oracle AI Database, you should add the dedicated bundle patches to your Oracle home.

In AutoUpgrade, you can use the keywords SDOBP (Spatial) and TEXT (Oracle Text) to download and add the patches to your Oracle home. Here’s an example:

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
global.folder=/home/oracle/autoupgrade/patches

patch1.target_version=19
patch1.platform=LINUX.X64
patch1.patch=RECOMMENDED,SDOBP,TEXT

I start AutoUpgrade in download mode:

java -jar autoupgrade.jar -config download.cfg -mode download -patch

AutoUpgrade determines that 19.30 is the latest Release Update and finds the appropriate bundle patches:

Connected to MOS - Searching for specified patches

-----------------------------------------------------
Downloading files to /home/oracle/autoupgrade/patches
-----------------------------------------------------
DATABASE RELEASE UPDATE 19.30.0.0.0(REL-JAN260130)
    File: p38632161_190000_Linux-x86-64.zip - LOCATED

...

SPATIAL BUNDLE PATCH #1 ON DBRU 19.30.0.0.0
    File: p38794194_1930000DBRU_Linux-x86-64.zip - LOCATED

MERGE OF 19.30 ORACLE TEXT RAC + NON-RAC MLRS
    File: p38910143_1930000DBRU_Linux-x86-64.zip - LOCATED
-----------------------------------------------------

Simple and easy!

Missing Bundle Patches

At the time of writing, there are no Spatial or Oracle Text bundle patches for Oracle AI Database 26ai. AutoUpgrade reports:

Connected to MOS - Searching for specified patches

There were conditions found preventing AutoUpgrade Patching from successfully running

*Downloading files
Cannot find the Oracle Text patch
Cannot find the Oracle Spatial (SDO) patch

All necessary patches for Spatial and Oracle Text in Oracle AI Database 26ai are included in the latest Release Update.

This might change over time, and we may start to see bundle patches again.

Oracle Text

Fixes for Oracle Text are included in Release Updates whenever possible.

The Oracle Text bundle patch contains:

  1. Patches that haven’t made it into a Release Update yet.
  2. Patches that aren’t RAC Rolling installable.

Over time, you may see patches disappear from the bundle patch as they become part of the Release Update.

The Oracle Text bundle patch is also recommended for users of JSON and XML search indexes.

Additional Information

MOS Notes

Upgrade Oracle Database PDB 19c to 26ai with Data Guard and Re-using Data Files (Enabled Recovery)

Let me show you how to upgrade a single PDB to Oracle AI Database 26ai.

This is called an unplug-plug upgrade and is much faster than a full CDB upgrade.

But what about Data Guard? I want to reuse the data files and plug in using enabled recovery. This ensures that my standby protects the PDB immediately.

Let’s see how it works.

Environment

The demo environment:

  • Two servers:
    • COPENHAGEN (primary)
    • AARHUS (standby)
  • Source CDB:
    • SID: CDB19
    • Primary unique name: CDB19_COPENHAGEN
    • Standby unique name: CDB19_AARHUS
  • Target CDB:
    • SID: CDB26
    • Primary unique name: CDB26_COPENHAGEN
    • Standby unique name: CDB26_AARHUS
  • PDB to upgrade: SALES

Overview of the demo environment for upgrade to Oracle Database 26ai

1. Prepare Standby

I’ve already prepared my database (SALES) and installed a new Oracle home. I’ve also created a new container database (CDB26) and configured it for Data Guard.

The maintenance window has started, and users have left the database.

  1. If I use Active Data Guard, I close my PDB (SALES) on the source standby (CDB19_AARHUS):
    alter pluggable database SALES close instances=all;
  2. I stop redo apply in my target standby (CDB26_AARHUS):
    edit database cdb26_aarhus set state='apply-off';
    • I turn off redo apply, so I can control when the target standby should claim the PDB data files.
    • I must ensure the source standby (CDB19_AARHUS) has released the PDB data files before doing the plug-in on the target standby (CDB26_AARHUS).

2. Upgrade On Primary

  1. This is my AutoUpgrade config file:

    global.global_log_dir=/home/oracle/autoupgrade/logs/SALES-CDB26
upg1.source_home=/u01/app/oracle/product/19
upg1.target_home=/u01/app/oracle/product/26
upg1.sid=CDB19
upg1.pdbs=SALES
upg1.target_cdb=CDB26
upg1.manage_standbys_clause=standbys=all
    • I specify the source and target Oracle homes.
    • sid contains the SID of my current CDB.
    • target_cdb specifies the SID of the container where I plug into.
    • pdbs is the PDB that I want to upgrade. I can specify additional PDBs in a comma-separated list.
    • I want to reuse the existing data files, so I omit target_pdb_copy_option.
    • To plug in with enabled recovery, I set manage_standbys_clause=all.
    • Check the appendix for additional parameters.

  2. I start AutoUpgrade in deploy mode:

    java -jar autoupgrade.jar -config SALES-CDB26.cfg -mode deploy
    • AutoUpgrade starts by analyzing the database for upgrade readiness and executes the pre-upgrade fixups.
    • Next, it creates a manifest file and unplugs from source CDB (CDB19_COPENHAGEN).
    • Then, it plugs into the target CDB with enabled recovery (CDB26_COPENHAGEN).
    • The plug-in doesn’t happen on the target standby (CDB26_AARHUS), because I stopped redo apply.
    • Finally, it upgrades the PDB (SALES).

  3. I wait until AutoUpgrade reaches the DBUPGRADE phase. I monitor progress:

    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.

  4. When AutoUpgrade is on the DBUPGRADE phase, it means that the PDB has been unplugged from the source CDB (CDB19_COPENHAGEN) and plugged into the target CDB (CDB26_COPENHAGEN).

3. Check Standby

I must ensure the source standby (CDB19_AARHUS) has applied the redo, which unplugs the PDB.

  1. On the standby, I look in the source standby alert log:
    tail -100f $ORACLE_BASE/diag/rdbms/cdb19_aarhus/CDB1/trace/alert_CDB19.log
  2. I look for proof that SALES PDB has been unplugged:
    2026-03-23T07:50:44.450680+00:00
SALES(3):Recovery deleting file #16:'/u02/oradata/CDB19_AARHUS/4DAD2FA764C642E4E0638338A8C0A72D/datafile/o1_mf_users_nw1vs832_.dbf' from controlfile.
SALES(3):Recovery dropped tablespace 'USERS'
SALES(3):Recovery dropped temporary tablespace 'TEMP'
SALES(3):Recovery deleting file #15:'/u02/oradata/CDB19_AARHUS/4DAD2FA764C642E4E0638338A8C0A72D/datafile/o1_mf_undotbs1_nw1vrgby_.dbf' from controlfile.
SALES(3):Recovery dropped tablespace 'UNDOTBS1'
SALES(3):Recovery deleting file #14:'/u02/oradata/CDB19_AARHUS/4DAD2FA764C642E4E0638338A8C0A72D/datafile/o1_mf_sysaux_nw1vrgbx_.dbf' from controlfile.
SALES(3):Recovery dropped tablespace 'SYSAUX'
SALES(3):Recovery deleting file #13:'/u02/oradata/CDB19_AARHUS/4DAD2FA764C642E4E0638338A8C0A72D/datafile/o1_mf_system_nw1vrgbg_.dbf' from controlfile.
SALES(3):Recovery dropped tablespace 'SYSTEM'
SALES(3):Recovery dropped pluggable database 'SALES'
    • Notice the last line informing me that the SALES PDB has been unplugged from my source standby.
    • The redo from the ALTER PLUGGABLE DATABASE ... UNPLUG command on the primary has been applied on the standby.
    • All PDB data files are now consistent and available for the target standby.

4. Standby Data Files

I must ensure the target standby (CDB26_AARHUS) can find the PDB data files.

The plug-in operation happens on the primary. AutoUpgrade uses a manifest file for the plug-in. The manifest file contains a list of all the data files on the primary, but there’s no information about the standby database.

How does the standby find the data files to use for the plug-in?

1. Regular File System

  1. The standby (CDB26_AARHUS) expects to find the data files in the same location as on the primary (CDB26_COPENHAGEN).
  2. During plug-in, I reused the data files. So, the primary data files are in the location of the source CDB (CDB19_COPENHAGEN):
    /u02/oradata/CDB19_COPENHAGEN/SALES/system01.dbf
/u02/oradata/CDB19_COPENHAGEN/SALES/sysaux01.dbf
/u02/oradata/CDB19_COPENHAGEN/SALES/undo01.dbf
/u02/oradata/CDB19_COPENHAGEN/SALES/users01.dbf
  3. However, on the standby (CDB19_AARHUS), the data files are here:
    /u02/oradata/CDB19_AARHUS/SALES/system01.dbf
/u02/oradata/CDB19_AARHUS/SALES/sysaux01.dbf
/u02/oradata/CDB19_AARHUS/SALES/undo01.dbf
/u02/oradata/CDB19_AARHUS/SALES/users01.dbf
  4. On the standby, I move the data files to the correct location:
    mv /u02/oradata/CDB19_AARHUS/SALES /u02/oradata/CDB26_AARHUS/SALES
  5. And use DB_FILE_NAME_CONVERT on the standby to redirect the files to the new location:
    alter system set db_file_name_convert='/u02/oradata/CDB19_COPENHAGEN','/u02/oradata/CDB26_AARHUS' scope=both;
    • Notice how I translate the source primary location to the target standby location.
    • The plug-in operation only knows where the primary data files are, and expects the standby use the exact same location (which it doesn’t).

2. OMF In Regular File System

  1. The standby (CDB26_AARHUS) expects to find the data files in the OMF location (db_create_file_dest).

  2. On standby, I create the OMF location for the PDB in the target CDB (CDB26_AARHUS):

    mkdir -p /u02/oradata/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A
    • 4DB38AE91A244341E0638338A8C0934A is the GUID of the PDB.
    • It doesn’t change when you move the PDB.
    • You can find the GUID of the PDB in the primary: select name, guid from v$containers;.

  3. I move the PDB data files from the source OMF location to the target OMF location:

    mv /u02/oradata/CDB19_AARHUS/4DB38AE91A244341E0638338A8C0934A/datafile \
   /u02/oradata/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A/datafile

3. ASM

  1. The standby (CDB26_AARHUS) expects to find the data files in the OMF location (db_create_file_dest).

  2. On standby, I connect to the ASM instance:

    export ORACLE_SID=+ASM1
sqlplus / as sysasm

  3. I create the OMF location for the PDB in the target CDB (CDB26_AARHUS):

    alter diskgroup data add directory '+DATA/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A';
alter diskgroup data add directory '+DATA/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A/DATAFILE';
    • 4DB38AE91A244341E0638338A8C0934A is the GUID of the PDB.
    • It doesn’t change when you move the PDB.
    • You can find the GUID of the PDB in the primary: select name, guid from v$containers;.

  4. For each data file in my PDB (including undo, excluding temp files), I must create an ASM alias, for instance:

    alter diskgroup data add alias
'+DATA/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A/DATAFILE/users_273_1103046827'
for '+DATA/CDB19_AARHUS/4DB38AE91A244341E0638338A8C0934A/DATAFILE/users.273.1103046827';
    • I must create an alias for each data file. I create the alias in the OMF location of the PDB in the target standby.
    • The alias must not contain dots/punctuation (.). That would violate the OMF naming standard. Notice how I replaced those with an underscore.
    • The alias points to the location of the data file in the source standby location.
    • You can find a script to create the aliases in MOS note KB106558.

5. Standby Redo Apply

At this point:

  • The PDB data files are consistent and unplugged from the source standby (CDB19_AARHUS).
  • I’ve ensured that the target standby (CDB26_AARHUS) can find the data files.

I can now re-enable redo apply in my target standby (CDB26_AARHUS).

  1. On the standby, I re-enable redo apply:

    edit database cdb26_aarhus set state='apply-on';

  2. I monitor the alert log (CDB26_AARHUS):

    cd $ORACLE_BASE/diag/rdbms/cdb26_aarhus/CDB26/trace
tail -100f alert_CDB26.log

  3. I ensure that the target standby (CDB26_AARHUS) finds and plugs in the PDB data files:

    2026-03-23T07:52:26.550343+00:00
PR00 (PID:26567): Media Recovery Log /u01/app/oracle/CDB26_AARHUS/archivelog/2026_03_23/o1_mf_1_30_nw1w78oo_.arc [krd.c:10255]
Recovery created pluggable database SALES
SALES(3):Recovery scanning directory +DATA/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A/DATAFILE/ for any matching files
SALES(3):Successfully added datafile 12 to media recovery
SALES(3):Datafile #12: '+DATA/CDB26_AARHUS/4DB38AE91A244341E0638338A8C0934A/DATAFILE/o1_mf_system_nw1vrgbg_.dbf'
    • There should be one entry for each PDB data file.

6. Complete Upgrade

As the upgrade progresses, the redo is shipped to the target standby and applied.

  1. I wait until AutoUpgrade completes the upgrade:
    Job 100 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

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

Please check the summary report at:
/home/oracle/autoupgrade/logs/SALES-CDB26/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/autoupgrade/logs/SALES-CDB26/cfgtoollogs/upgrade/auto/status/status.log
    • This includes the post-upgrade checks and fixups.
  2. I review the Autoupgrade Summary Report. The path is printed to the console:
    vi /home/oracle/autoupgrade/logs/SALES-CDB26/cfgtoollogs/upgrade/auto/status/status.log
  3. I take care of the post-upgrade tasks.
  4. AutoUpgrade unplugs the PDB from the source CDB.
    • On the primary, the PDB data files are in the original location. In the directory structure of the source CDB.
    • Take care you don’t delete them by mistake; they are now used by the target CDB.
    • Optionally, move them into the correct location using online datafile move.
    • The same applies to the standby if I use ASM. For regular file system, I moved the PDB data files to the correct location.

7. Check Standby

  • At this point, the standby (CDB26_AARHUS) protects my PDB.

  • I check the Data Guard config:

    validate database verbose CDB26_AARHUS;
    • Ensure that no data files are reported as offline.

  • Once my standby is in sync, I can do a switchover as the ultimate test:

    switchover to CDB26_AARHUS;

  • Now, I connect to the new primary (CDB26_AARHUS) and ensure the PDB opens in read write mode and unrestricted:

    select open_mode, restricted
from v$pdbs
where name='SALES';

OPEN_MODE     RESTRICTED
_____________ _____________
READ WRITE    NO

  • You can find the full procedure in (KB106558) Reusing the Source Standby Database Files When Plugging a PDB into the Primary Database of a Data Guard Configuration.

That’s It!

With AutoUpgrade, you can easily upgrade a single PDB using an unplug-plug upgrade. For maximum protection and to minimize downtime, you can reuse the data files on both primary and standby.

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

Happy upgrading!

Appendix

Rollback Options

When you perform an unplug-plug upgrade, you can’t use Flashback Database as a rollback method. You need to rely on other methods, like:

  • RMAN backups.
  • Storage snapshots.
  • If you have multiple standbys, you can leave one behind.

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 to downgrade, be sure to set the compatible parameter in the target CDB to the same value as in the source CDB.

Pre-plugin Backups

After doing an unplug-plug upgrade, you can restore a PDB using a combination of backups from before and after the plug-in operation. Backups from before the plug-in is called pre-plugin backups.

A restore using pre-plugin backups is more complicated; however, AutoUpgrade eases that by exporting the RMAN backup metadata automatically.

I suggest that you:

  • Start a backup immediately after the upgrade, so you don’t have to use pre-plugin backups.
  • Practice restoring with pre-plugin backups.

What If My Database Is A RAC Database?

There are no changes to the procedure if you have an Oracle RAC database. AutoUpgrade handles it transparently. You must manually recreate services in the target CDB using srvctl.

What If I Use Oracle Restart?

No changes. You must manually recreate services in the target CDB using srvctl.

What If My Database Is Encrypted

AutoUpgrade fully supports upgrading an encrypted PDB.

You’ll need to input the source and target CDB keystore passwords into the AutoUpgrade keystore. You can find the details in a previous blog post.

In the container database, AutoUpgrade always adds the database encryption keys to the unified keystore. After the conversion, you can switch to an isolated keystore.

Before starting redo apply on the standby, you must copy the keystore from the primary to the standby. Check (KB106558) Reusing the Source Standby Database Files When Plugging a PDB into the Primary Database of a Data Guard Configuration for details.

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: (default: Yes) AutoUpgrade upgrades the PDB time zone file after the actual upgrade. This 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. In multitenant, a PDB can use a different time zone file than the CDB.

  • target_pdb_name: AutoUpgrade renames the PDB. I must specify the original PDB name (SALES) as a suffix to the parameter:

    upg1.target_pdb_name.SALES=NEWSALES

    If I have multiple PDBs, I can specify target_pdb_name multiple times:

    upg1.pdbs=SALES,OLDNAME1,OLDNAME2
upg1.target_pdb_name.SALES=NEWSALES
upg1.target_pdb_name.OLDNAME1=NEWNAME1
upg1.target_pdb_name.OLDNAME2=NEWNAME2

  • before_action / after_action: Extend AutoUpgrade with your own functionality by using scripts before or after the job.

  • Check the documentation for the full list.