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!

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!

AutoUpgrade New Features: Download Tools (AHF, CVU, SQLcl)

Once you try downloading patches using AutoUpgrade, you’ll never do it from My Oracle Support again.

But what if you want to download:

Do you really have to do that from My Oracle Support? Of course – AutoUpgrade has you covered!

Download Tools

  1. I’ve already configured AutoUpgrade to download patches.

  2. I create a 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=19
    patch1.patch=SQLCL,AHF,CVU
    
    • Notice the patch specification. It contains the three new keywords that instruct AutoUpgrade to download the tools.
  3. I start AutoUpgrade in download mode:

    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 /home/oracle/autoupgrade/patches
    -----------------------------------------------------
    PLACEHOLDER - DOWNLOAD LATEST AHF (TFA and ORACHK/EXACHK)
        File: AHF-LINUX_v26.3.1.zip - LOCATED
    
    Standalone CVU (OL8+, RHEL8+) January 2026
        File: cvupack_linux_ol8_x86_64.zip - LOCATED
    
    sqlcl-latest.zip 26.1.2.132.1334 (May 2026)
        File: sqlcl-latest.zip - LOCATED
    ------------------------------------------------------	
    
  • AutoUpgrade places the latest version of the tools in the download folder.

  • Nice and simple.

Multiple Platforms

  • If I have multiple platforms, I can download for all of them:

    patch1.platform=LINUX.X64
    patch1.target_version=19
    patch1.patch=SQLCL,AHF,CVU
    
    patch2.platform=WINDOWS.X64
    patch2.target_version=19
    patch2.patch=SQLCL,AHF,CVU
    
    patch3.platform=AIX.X64
    patch3.target_version=19
    patch3.patch=SQLCL,AHF,CVU
    
    • Notice how each platform has its own prefix (patch1, patch2, and patch3).
  • When I start AutoUpgrade in download mode, it downloads the tools for the three platforms.

That’s It

There are several tools that help you work with Oracle AI Database. Don’t miss out, update the tools and benefit from the latest enhancements.

Do you have a favorite tool that AutoUpgrade should download for you? Drop a comment and I’ll see what we can do.

Happy patching!

Is Your Oracle AI Database Ready For Patching?

My colleagues enhanced Datapatch so it can check your Oracle AI Database and see if it’s prone to errors we’ve seen at other customers.

This check is called a Datapatch Sanity Check.

It is a lightweight and non-intrusive check that scans an Oracle AI Database and produces a report with findings.

How to Run a Sanity Check

  • Before patching, assess the patching readiness of your Oracle AI Database:
    export ORACLE_SID=ORCL
    cd $ORACLE_HOME/OPatch
    ./datapatch -sanity_checks
    
    • You can run the check on an active database.
    • The check scans the operating system, database and all open PDBs.
  • Datapatch prints the report on the screen. Examine it:
    SQL Patching sanity checks version 19.27.0.0.0 on Fri 12 Jun 2026 03:25:42 PM GMT
    Copyright (c) 2021, 2026, Oracle.  All rights reserved.
    
    Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sanity_checks_20260612_152542_17281/sanity_checks_20260612_152542_17281.log
    
    Running checks
    JSON report generated in /u01/app/oracle/cfgtoollogs/sqlpatch/sanity_checks_20260612_152542_17281/sqlpatch_sanity_checks_summary.json file
    Checks completed. Printing report:
    
    Check: Database component status - OK
    Check: PDB Violations - OK
    Check: Invalid System Objects - OK
    Check: Tablespace Status - OK
    Check: Backup jobs - OK
    Check: Temp file exists - OK
    Check: Temp file online - OK
    Check: Data Pump running - OK
    Check: Container status - OK
    Check: Oracle Database Keystore - OK
    Check: Dictionary statistics gathering - OK
    Check: Scheduled Jobs - OK
    Check: GoldenGate triggers - OK
    Check: Logminer DDL triggers - OK
    Check: Check sys public grants - OK
    Check: Statistics gathering running - OK
    Check: Optim dictionary upgrade parameter - OK
    Check: Symlinks on oracle home path - OK
    Check: Central Inventory - OK
    Check: Queryable Inventory dba directories - OK
    Check: Queryable Inventory locks - OK
    Check: Queryable Inventory package - OK
    Check: Queryable Inventory external table - OK
    Check: Imperva processes - OK
    Check: Guardium processes - OK
    Check: Locale - OK
    
    Refer to MOS Note 2975965.1 and debug log
    /u01/app/oracle/cfgtoollogs/sqlpatch/sanity_checks_20260612_152542_17281/sanity_checks_debug_20260612_152542_17281.log
    
    SQL Patching sanity checks completed on Fri 12 Jun 2026 03:26:18 PM GMT	
    
    • All checks passed.

Usage Notes

  • The checks may give the following result:

    • OK
    • WARNING
    • ERROR
  • Datapatch exit codes:

    • 0 – All checks passed
    • 1 – Errors found
    • 2 – Warnings found
  • If the database is an Oracle RAC Database, Datapatch also connects to the other nodes to conduct scanning. This requires passwordless SSH between the nodes.

  • The Sanity Check doesn’t check whether patches need to be applied or not. To determine whether patches need to be installed in the database, use:

    ./datapatch -prereq
    

That’s It

Checking your database upfront will help you avoid some of the common pitfalls when installing patches.

Happy patching!

Further Reading

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!

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.