Are There Any New Patches?

The other day, a customer showed me their more-or-less fully automated patching process. Part of the process involved:

  • A nightly job that starts AutoUpgrade to download the latest Release Update and MRP.
  • If AutoUpgrade downloads a new patch, the job builds a new gold image.
  • Next, it deploys the new gold image to test servers.
  • Then, notifies the DBAs, so they can start testing when they arrive at the office in the morning.

That’s such a cool process. I’m a huge fan.

But one question came up:

We run AutoUpgrade through an Ansible runbook. How can we know which patches are new?

Parsing Console Output

When downloading patches, AutoUpgrade prints the patch description and file name to the console along with a status.

------------------------------------------------------
Downloading files to /Users/doverbyh/Downloads/patches
------------------------------------------------------
DATABASE RELEASE UPDATE 19.32.0.0.0
    File: p39472050_190000_Linux-x86-64.zip - LOCATED

OPatch 12.2.0.1.53 for DB 19.0.0.0.0 (Sep 2026)
    File: p6880880_190000_Linux-x86-64.zip - LOCATED

DATAPUMP BUNDLE PATCH 19.32.0.0.0
    File: p39657094_1932000DBRU_Generic.zip - LOCATED

OJVM RELEASE UPDATE 19.32.0.0.0
    File: p39222882_190000_Linux-x86-64.zip - LOCATED

DATABASE MRP 19.32.0.0.260915
    File: p39971265_1932000DBRU_Linux-x86-64.zip - VALIDATED

You can use the status to determine whether the file is new:

  • VALIDATED: This file was not on disk and has been downloaded.
  • REPLACED: This file was already on disk, but was re-downloaded.
  • LOCATED: The file was already on disk.

To use this information with a script, you must parse stdout and put the pieces together. Doable, but not very elegant.

Checking the Patch Info File

In the download_folder, you find patches_info.json, which is an overview of all the files downloaded by AutoUpgrade.

Here’s an example:

{
    "patchFolder": "/home/oracle/patch-repo",
    "generatedAt": "2026-10-06T07:54:27.930456Z",
    "patches": [
        {
            "description": "DATABASE MRP 19.32.0.0.260915",
            "platform": "Linux x86-64",
            "patchId": 39971265,
            "releasedDate": "+58659-01-03T15:56:40",
            "files": [
                {
                    "name": "p39971265_1932000DBRU_Linux-x86-64.zip",
                    "checksum": "029A3847AC9A38571E052440AA187D5AE147A24D",
                    "checksum-256": "090348A58923A031212628BE9A69F2E800C16933C7CF53678CB070A3DA1630B1",
                    "size": 29432590,
                    "lastUpdated": "2026-09-21T05:23:05.158447Z"
                }
            ]
        },
...
  • The lastUpdated timestamp indicates when the file was downloaded. The Z at the end indicates UTC, also known as Zulu time.
  • The customer only wants to create a gold image when a new Release Update or MRP arrives. They can use description to filter the patches.
  • A single patch may consist of multiple files, so your code needs to take that into consideration.

The JSON file is much better suited for automation.

Checking the Log File

You can also use the AutoUpgrade log files. For download mode, you find them here:

<global.global_log_dir>/cfgtoollogs/patch/auto/aru

To find a list of downloaded files, you can look in aru_user.log:

grep "Finished the downloading" aru_user.log

...
2026-10-06 09:54:21.434 INFO Finished the downloading of DATABASE RELEASE UPDATE 23.26.3.0.0(GOLD IMAGE) - p39581612_230000_Linux-x86-64.zip
2026-10-07 06:41:44.070 INFO Finished the downloading of DATAPUMP BUNDLE PATCH 19.32.0.0.0 - p39657094_1932000DBRU_Generic.zip
2026-10-07 10:38:18.046 INFO Finished the downloading of autoupgrade.jar 26.6 (September 2026) - autoupgrade.jar
2026-10-07 10:39:06.251 INFO Finished the downloading of DATABASE MRP 19.32.0.0.260915 - p39971265_1932000DBRU_Linux-x86-64.zip

  • Each line matches the download of one file.
  • The line contains the download timestamp, patch description and file name.
  • A patch consists of one or multiple files, so don’t assume that each line represents a different patch.

Grepping a text file works, but it’s not the best option for automation.

That’s It

AutoUpgrade fits perfectly into your automation. The information is available through the console, log files, and patches_info.json. For automation, I’d go with JSON.

If there’s anything we can change to make AutoUpgrade even more suitable for automation, leave a comment and I’ll see what we can do.

Happy patching!

The Easiest Way to Download Exadata Patches

Using AutoUpgrade, you can download patches for Oracle Exadata. It’s fast and convenient.

Get Those Patches

  1. I use the latest version of AutoUpgrade.

    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    
  2. I’ve already stored my MOS credentials in the AutoUpgrade keystore.

  3. I create an AutoUpgrade config file:

    global.global_log_dir=/home/oracle/autoupgrade/logs
    global.keystore=/home/oracle/autoupgrade/keystore
    global.download_folder=/home/oracle/patch-repo
    
    patch1.patch=EXAQFSDP:19,EXAPATCHMGR
    patch1.target_version=19
    patch1.platform=LINUX.X64
    
    • I use the EXAQFSDP keyword to download the Quarterly Full Stack Download Patch (QFSDP) for Exadata systems.
    • I want to download patches for 19c.
    • I also want to get the latest version of the patchmgr utility.
  4. I start AutoUpgrade in download mode:

    java -jar autoupgrade.jar -patch \
       -config get-patches.cfg \
       -mode download
    
  5. AutoUpgrade now downloads the patches:

    AutoUpgrade Patching 26.6.260925 launched with default internal options
    Processing config file ...
    Loading AutoUpgrade Patching keystore
    AutoUpgrade Patching keystore is loaded
    
    ------------------------------------------------------
    Downloading files to /Users/doverbyh/Downloads/patches
    ------------------------------------------------------
    QUARTERLY FULL STACK DOWNLOAD PATCH FOR EXADATA (JUL2026 - 19.32)
        File: p39619107_190000_Linux-x86-64_10of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_1of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_2of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_3of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_4of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_5of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_6of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_7of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_8of10.zip - LOCATED
        File: p39619107_190000_Linux-x86-64_9of10.zip - LOCATED
    
    DBSERVER.PATCH.ZIP ORCHESTRATOR PLUS DBNU - ARU PLACEHOLDER
        File: p21634633_261300_Linux-x86-64.zip - LOCATED
    ------------------------------------------------------
    
  6. That’s it. Now I have everything I need to patch the Exadata system.

Notes

  • The QFSDP contains patches for:
    • Infrastructure
      • ExadataStorageServer
      • DBServerPatch
      • ExadataDBNodeUpdate
      • SunRackIIPDUMeteringUnitFirmware
    • Database
      • Database Oracle home
      • Grid Infrastructure Oracle home
      • OPatch
      • OPlan
    • Systems management
      • Enterprise Manager OMS Release Update
      • Enterprise Manager Agent Release Update
  • Each QFSDP is quite large. Have at least 60 GB of free space for the download, plus additional space to extract it.
  • You can also download the QFSDP for releases 21c and 26ai.
  • You must also specify target_version in the config file, although AutoUpgrade doesn’t use it for Exadata patches. That requirement will be removed in a later version of AutoUpgrade.

How to Extract the QFSDP

Here’s how to extract the QFSDP. I’m using QUARTERLY FULL STACK DOWNLOAD PATCH FOR EXADATA (JUL2026 – 19.32) as an example.

  • The QFSDP comes in 10 zip files. Extract all of them:
    mkdir -p p39619107
    for i in {1..10}; do
        unzip -q "p39619107_190000_Linux-x86-64_${i}of10.zip" -d p39619107 || break
    done
    
  • Now you have 10 parts of a split tar archive. Combine and extract them:
    cd p39619107
    cat *.tar.* | tar -xvf -
    
  • You now have all the patches extracted and ready for patching.

That’s It

AutoUpgrade now belongs in your Exadata patching runbook. Regardless of how you patch your system, AutoUpgrade can take care of getting the patches.

This enhancement came directly from customer feedback. What should we add next?

Happy patching!

AutoUpgrade Keystore Security Changes in 26.6

In the latest version of AutoUpgrade (26.6), you will notice some changes to the AutoUpgrade keystore.

AutoUpgrade uses a keystore to store sensitive information like your MOS credentials, TDE keystore passwords and authorization tokens.

We’ve implemented these changes to better protect your data.

Password Length

Your AutoUpgrade keystore password should contain:

  • At least 16 characters
  • Alphabetic characters
  • At least one number or special character

If your password is 7 characters or fewer, AutoUpgrade throws an error:

Starting AutoUpgrade Patching Password Loader - Type help for available options
Creating new AutoUpgrade Patching keystore - Password required
Enter password:
PKI-01002: Invalid password. Passwords must have a minimum length of sixteen characters and contain alphabetic characters combined with numbers or special characters.

If your password is 8-15 characters long, AutoUpgrade prints a warning but allows you to use the weak password:

Starting AutoUpgrade Patching Password Loader - Type help for available options
Creating new AutoUpgrade Patching keystore - Password required
Enter password:
Warning: For security reasons, passwords must have at least 16 characters.
Enter password again:

The warning message is misleading. It states that you must use a stronger password. The correct word would be should.

Keep your secrets safe; use a strong password!

Keystore Permissions

Only the current user can have write access to the keystore folder and the files inside it.

If your file permissions are too permissive, you’ll see an error message:

Unable to connect to the Oracle Update Advisor service using the provided credentials
*No messages received from the Oracle Update Advisor service*

Or:

Oracle Update Advisor service - Connection Failure
*Tag mismatch!*

AutoUpgrade requires that you use strict file permissions:

find <keystore-folder> -type d -exec chmod 700 {} +
find <keystore-folder> -type f -exec chmod 600 {} +

That’s It

To keep your credentials and other sensitive information safe, AutoUpgrade now enforces stronger security practices.

At first glance, this might be an annoyance, but with AI changing how we work, protecting credentials and other secrets is more important than ever.

Happy safekeeping!

The Easiest Way to Download Enterprise Manager Patches

Using AutoUpgrade, you can download patches for Oracle Enterprise Manager (OEM). It’s fast and convenient.

Get Those Patches

  1. I use the latest version of AutoUpgrade.

    wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar
    
  2. I’ve already stored my MOS credentials in the AutoUpgrade keystore.

  3. I create an AutoUpgrade config file:

    global.global_log_dir=/home/oracle/autoupgrade/logs
    global.keystore=/home/oracle/autoupgrade/keystore
    global.download_folder=/home/oracle/patch-repo
    
    patch1.patch=OEM:24.1
    patch1.target_version=19
    
    patch2.patch=OEM:13.5
    patch2.target_version=19
    
    • I use the OEM keyword to download patches for Oracle Enterprise Manager.
    • I want to get patches for versions 24.1 and 13.5.
  4. I start AutoUpgrade in download mode:

    java -jar autoupgrade.jar -patch \
       -config get-patches.cfg \
       -mode download
    
  5. AutoUpgrade now downloads the patches:

    AutoUpgrade Patching 26.6.260925 launched with default internal options
    Processing config file ...
    Loading AutoUpgrade Patching keystore
    AutoUpgrade Patching keystore is loaded
    
    ------------------------------------------------------
    Downloading files to /Users/doverbyh/Downloads/patches
    ------------------------------------------------------
    Oracle Enterprise Manager 24ai Release 1 Update 13 (24.1.0.13) for Oracle Management Service
        File: p39815035_241000_Generic.zip - LOCATED
    
    Oracle Enterprise Manager 24ai Release 1 Holistic Patch for Oracle Management Service - September 2026
        File: p39984254_241000_Generic.zip - LOCATED
    
    Oracle Enterprise Manager 24ai Release 1 Update 13 (24.1.0.13) for Oracle Management Agent
        File: p39815042_241000_Generic.zip - LOCATED
    
    OMSPatcher patch of version 13.9.24.17.0 for Enterprise Manager 24.1.0.0.0
        File: p19999993_241000_Generic.zip - LOCATED
    
    AgentPatcher patch of version 13.9.25.3.0 for Enterprise Manager 24.1.0.0.0
        File: p33355570_241000_Generic.zip - LOCATED
    ------------------------------------------------------
    
    
    ------------------------------------------------------
    Downloading files to /Users/doverbyh/Downloads/patches
    ------------------------------------------------------
    Oracle Enterprise Manager 13c Release 5 Update 34 (13.5.0.34) for Oracle Management Service
        File: p39820104_135000_Generic.zip - LOCATED
    
    Oracle Enterprise Manager 13c Release 5 Holistic Patch for Oracle Management Service - September 2026
        File: p39984261_135000_Generic.zip - LOCATED
    
    Oracle Enterprise Manager 13c Release 5 Update 34 (13.5.0.34) for Oracle Management Agent
        File: p39820108_135000_Generic.zip - LOCATED
    
    OMSPatcher patch of version 13.9.5.27.0 for Enterprise Manager Cloud Control 13.5.0.0.0
        File: p19999993_135000_Generic.zip - LOCATED
    
    AgentPatcher release of version 13.9.5.10.0 for Enterprise Manager Cloud Control Agent 13.5.0.0.0
        File: p33355570_135000_Generic.zip - LOCATED
    ------------------------------------------------------	
    
  6. That’s it. Now I can take those patches and patch OEM. AutoUpgrade can’t help me with that part.

Notes

  • AutoUpgrade downloads the following patches:
    • Oracle Management Service Release Update
    • Oracle Management Service Holistic Patch
    • Oracle Management Agent Release Update
    • OMSPatcher
    • AgentPatcher
  • OEM patches are generic, so there’s no need to specify a platform in the config file.
  • You must also specify target_version in the config file, although AutoUpgrade doesn’t use it for OEM patches.That requirement will be removed in a later version of AutoUpgrade.
  • AutoUpgrade supports OEM versions 13.5 and 24.1. There will be no support for older releases.
  • The patches are quite large. Have at least 15 GB per set of patches.

That’s It

Once again AutoUpgrade proves itself as the trusted aid of the DBA.

This enhancement came directly from customer feedback. What should we add next?

Happy patching!

AutoUpgrade New Features: Create and Use Your Own Gold Images

There are several advantages to using gold images to install new Oracle homes:

  • You know all servers get the exact same Oracle home.
  • You can install faster because you don’t need to apply all the patches.
  • They fit very well with automation.
  • They’re easier to test and work well with configuration management.

When you install an Oracle home using AutoUpgrade, you can also create your own gold images. Later, you can deploy the gold image to new servers.

Create Gold Image

I will use AutoUpgrade to install a new Oracle home with the desired patches and create a gold image.

  1. I’ve already downloaded the patches.
  2. Here’s my config file:
    global.global_log_dir=/home/oracle/autoupgrade/log
    install1.download_folder=/home/oracle/patch-repo
    install1.source_home=/u01/app/oracle/product/19
    install1.target_home=/u01/app/oracle/product/19_32
    install1.create_gold_image=db_home_%RELEASE%_%UPDATE%_%TIMESTAMP%.zip
    install1.patch=recommended
    
    • 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.
  3. I start AutoUpgrade to install the new Oracle home:
    java -jar autoupgrade.jar -config install-home.cfg -patch -mode create_home
    
    • In 19c, the installation takes longer because AutoUpgrade must apply the Release Update.
    • In 26ai, this process is much faster because Oracle delivers gold images with the latest Release Update already applied.
  4. When AutoUpgrade completes, I can find the gold image in my download_folder.
  5. It took 15 minutes to install the Oracle home and apply all the patches, plus five minutes to generate the gold image.

Install From Gold Image

Now I move to a different server. I need a new Oracle home and I’ll use the gold image.

  1. Here’s my AutoUpgrade config file:
    global.global_log_dir=/home/oracle/autoupgrade/log
    install1.download_folder=/home/oracle/patch-repo
    install1.source_home=/u01/app/oracle/product/19
    install1.target_home=/u01/app/oracle/product/19_32
    install1.patch=GOLDIMAGE:db_home_19_32_20260819113026.zip
    
    • Notice the patch parameter. I specify the gold image instead of individual patches.
  2. I start AutoUpgrade to install the new Oracle home:
    java -jar autoupgrade.jar -config install-home.cfg -patch -mode create_home
    
    • AutoUpgrade extracts the gold image and performs the installation.
    • There are no patches to apply. The gold image is already up to date.
  3. That’s it! I now have an Oracle home with exactly the same patches.
  4. It took just two minutes to install the gold image. That’s much faster than the 15 minutes it took for a regular installation.

That’s It

If you’re not already using gold images, you should get started. AutoUpgrade makes them easy to create and deploy.

Happy patching!

AutoUpgrade New Features: Download 26ai Release Update Rather Than Gold Image

Starting with Oracle AI Database 26ai, Oracle delivers fully updated gold images in addition to just the Release Update.

This is very convenient because:

  • It significantly shortens the installation time of a new Oracle home because the Release Update has already been applied.
  • It includes an updated OPatch.
  • It includes an updated OCW component.
  • It includes an updated JDK and Perl installation.

AutoUpgrade downloads the gold image automatically and you get to enjoy the much shorter installation time.

But sometimes you want just the Release Update.

Download Release Update Patch File

  • Here’s my AutoUpgrade config file:

    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.target_version=26
    patch1.patch=RU
    patch1.gold_image=no
    
    • I set gold_image=no to tell AutoUpgrade to download the Release Update patch instead of the gold image.
  • I start AutoUpgrade in download mode:

    java -jar autoupgrade.jar -patch -config download.cfg -mode download
    
  • AutoUpgrade locates the latest Release Update and starts the download.

    AutoUpgrade Patching 26.4.260701 launched with default internal options
    Processing config file ...
    Loading AutoUpgrade Patching keystore
    AutoUpgrade Patching keystore is loaded
    
    ------------------------------------------------------
    Downloading files to /home/oracle/autoupgrade/patches
    ------------------------------------------------------
    DATABASE RELEASE UPDATE 23.26.3.0.0
        File: p39578879_230000_Linux-x86-64.zip - VALIDATED
    ------------------------------------------------------
    
  • You can distinguish between the Release Update patch and the gold image by their descriptions:

    • Gold image: DATABASE RELEASE UPDATE 23.26.3.0.0(GOLD IMAGE)
    • Patch file: DATABASE RELEASE UPDATE 23.26.3.0.0

That’s It

Gold images are the fastest way to provision a new Oracle home. But when you need the Release Update patch instead, AutoUpgrade lets you choose.

Happy patching!

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!