Hi everyone, hope you’re doing good.
A few days ago, I released the BETA version of my new tool: AutoUpgrade-Composer. You can read about the release here: Introducing: The AutoUpgrade-Composer Tool [BETA]
This will be the first post in a series of blog posts exploring the potential of AutoUpgrade-Composer, as we may have dozens of scenarios.
In this blog post, we’ll perform a straightforward operation, no big customization at all.
Current environment:
- SID: TST1
- Source Home (current RU): /u01/app/oracle/product/19.22/dbhome_1
- Edition: Enterprise
We will be targeting the latest RU as of now (19.27).
So, first we’ll access AutoUpgrade-Composer: https://viniciusdba.com.br/autoupgrade-composer
In the section Global Options, we have only the option to Patch Database available (remember, AutoUpgrade-Composer is in BETA version and I’m expecting to release the full capabilities by mid-June). We will not change the Global Log Directory, but feel free to change it in your environment:

After Patch Database is selected, let’s go to the section below: Database Configurations.
In the Basic Information tab, we will choose the Deploy mode. Ideally, you should choose Analyze. But as we are running in a lab environment, we are good to go with Deploy mode directly.
We will change some parameters. The Target Home will be the new Home to be installed for DB being patched.
- SID: TST1
- Source Home: /u01/app/oracle/product/19.22/dbhome_1
- Target Home: /u01/app/oracle/product/19.27/TST1

Now, go to the Patch Content tab. Here, we will keep RU and OPATCH selected. This means that we are targeting an OPatch utility update and to applying the RU. In my environment, I changed the Patch Folder, where is the directory on the server where I have the patch files:
- Patch Folder: /u01/software

Perfect! Now, go to the Download Settings tab:
For now, we will not choose to download. I will explain later how to configure the AutoUpgrade keystore properly for that.

Now, go to the Additional Options tab:
I will not change anything. Note that Restoration is selected. This means that if you are running on Enterprise Edition and on ARCHIVELOG mode, a Guaranteed Restore Point will be created as part of patching operation. By default, the GRP created will not be dropped. You can see that the next option is to drop the GRP once patching completes. I will not enable it, so, I will need to drop the GRP manually later.

Perfect! Now, in the section below, we have the Generated Config.
You have two options: download the config file, or copy the config to clipboard. You will need the info you are seeing below to use in your AutoUpgrade execution.

Perfect! In the section below, there is the instruction on how to run the AutoUpgrade.
Note that it’s always recommended to run the Analyze mode first.

Let’s now check our environment. We’ll start by checking the processes:
[oracle@upgrade-lab ~]$ ps -ef |grep -v 'grep' | grep 'pmon' oracle 3303187 1 0 15:58 ? 00:00:00 ora_pmon_TST1
Now, from inside the DB, let’s check some more information:
set lines 120 col banner_full for a80 select banner_full from v$version; BANNER_FULL -------------------------------------------------------------------------------- Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.22.0.0.0
Now we will use Mike Dietrich’s script check_patches_19.sql, but only run the first query:
SET LINESIZE 500 SET PAGESIZE 1000 SET SERVEROUT ON SET LONG 2000000 COLUMN action_time FORMAT A20 COLUMN action FORMAT A10 COLUMN status FORMAT A10 COLUMN description FORMAT A60 COLUMN source_version FORMAT A13 COLUMN target_version FORMAT A13 COLUMN version_full FORMAT A13 COLUMN comp_id FORMAT A8 alter session set "_exclude_seed_cdb_view"=FALSE; select CON_ID, TO_CHAR(action_time, 'YYYY-MM-DD') AS action_time, PATCH_ID, PATCH_TYPE, ACTION, DESCRIPTION, SOURCE_VERSION, TARGET_VERSION from CDB_REGISTRY_SQLPATCH order by CON_ID, action_time, patch_id; CON_ID ACTION_TIME PATCH_ID PATCH_TYPE ACTION DESCRIPTION SOURCE_VERSIO TARGET_VERSIO ---------- -------------------- ---------- ---------- ---------- ------------------------------------------------------------ ------------- ------------- 0 2025-04-30 35943157 RU APPLY Database Release Update : 19.22.0.0.240116 (35943157) 19.1.0.0.0 19.22.0.0.0
We can confirm that the DB is running on version 19.22.
We need to make sure we have the latest version of AutoUpgrade. You can always check the AutoUpgrade Tool Reference Note (Doc ID 2485457.1). You can also download it directly from Oracle.com as mentioned on Mike’s blog post: Download AutoUpgrade directly from oracle.com. But I noticed some delay in releasing the AutoUpgrade versions on Oracle.com compared with the versions available in the mentioned My Oracle Support Note, for example, as of today, May 16th, the version available on MOS is the version 25.3. However, on Oracle.com, the latest version available is 25.2, but the label on the website shows it as 25.1.
After uploading the latest version of AutoUpgrade to my server, let’s confirm the version:
java -jar autoupgrade.jar -version build.version 25.3.250509 build.date 2025/05/09 02:53:51 +0000 build.hash 3110a3d32 build.hash_date 2025/05/05 19:43:04 +0000 build.supported_target_versions 12.2,18,19,21,23 build.type production build.label (HEAD, tag: v25.3, origin/stable_devel, stable_devel) build.MOS_NOTE 2485457.1 build.MOS_LINK https://support.oracle.com/epmos/faces/DocumentDisplay?id=2485457.1
Great!
We need to create a Config File for AutoUpgrade on our server. I created the file TST1.cfg, here is the content:
# Created by AutoUpgrade Composer # Patch, ExecMode: Deploy global.global_log_dir=/home/oracle/autoupgrade-patching/log patch1.sid=TST1 patch1.log_dir=/home/oracle/autoupgrade-patching/TST1/log patch1.source_home=/u01/app/oracle/product/19.22/dbhome_1 patch1.target_home=/u01/app/oracle/product/19.27/TST1 patch1.restoration=YES patch1.folder=/u01/software patch1.patch=RU,OPATCH patch1.download=NO
We are almost ready to start the patching activity. Some important info to consider before triggering the patching:
Our Target Home will be /u01/app/oracle/product/19.27/TST1, note that the path /u01/app/oracle/product/19.27 must exist on the server. If not, AutoUpgrade process will fail. So, if you don’t have this path created, now is the time to create it:
mkdir -p /u01/app/oracle/product/19.27
We chose to not download patches for now (this will be in another blog post) and we set our Patch Folder to /u01/patch. If you remember, this is our Patch parameter for AutoUpgrade:
patch1.patch=RU,OPATCH
The question is, what will be the RU to be applied if we are not downloading the patches?
AutoUpgrade will check the content of the directory, and will pick the latest RU available in the directory (thank you, Rodrigo Jorge!). If no RU is available, AutoUpgrade will fail. As I’d like to apply RU 19.27, we need to make sure we have the following files in this directory:
- Database Gold Image for 19c: LINUX.X64_193000_db_home.zip
- RU 19.27: p37642901_190000_Linux-x86-64.zip
- OPatch: p6880880_190000_Linux-x86-64.zip
Let’s check the content of the directory:
[oracle@upgrade-lab ~]$ ls -l /u01/software total 5289624 -rw-r--r--. 1 oracle oinstall 3059705302 Apr 30 21:01 LINUX.X64_193000_db_home.zip -rw-r--r--. 1 oracle oinstall 2284324411 Apr 30 16:09 p37642901_190000_Linux-x86-64.zip -rw-r--r--. 1 oracle oinstall 72539776 Apr 30 16:17 p6880880_190000_Linux-x86-64.zip
Perfect! We are ready to start! As we mentioned in the AutoUpgrade-Composer instructions on how to run AutoUpgrade, let’s go:
$ java -jar autoupgrade.jar -config TST1.cfg -patch -mode deploy AutoUpgrade Patching 25.3.250509 launched with default internal options Processing config file ... +-----------------------------------------+ | Starting AutoUpgrade Patching execution | +-----------------------------------------+ 1 Non-CDB(s) will be processed Type 'help' to list console commands patch>
Great! We can keep checking the jobs running using the command lsj, we can keep this command running automatically every 10 seconds:
patch> lsj -a 10 patch> +----+-------+---------+---------+-------+----------+-------+----------------+ |Job#|DB_NAME| STAGE|OPERATION| STATUS|START_TIME|UPDATED| MESSAGE| +----+-------+---------+---------+-------+----------+-------+----------------+ | 100| TST1|PRECHECKS|EXECUTING|RUNNING| 16:18:53| 4s ago|Executing Checks| +----+-------+---------+---------+-------+----------+-------+----------------+ Total jobs 1 The command lsj is running every 10 seconds. PRESS ENTER TO EXIT
Our job ID is 100. If we would like to cancel the automatic execution, just press [ENTER].
You can also check the status of your job:
patch> status -job 100 Details Job No 100 Oracle SID TST1 Start Time 25/05/16 16:18:53 Elapsed (min): 1 End time: N/A Logfiles Logs Base: /home/oracle/autoupgrade-patching/TST1/log/TST1 Job logs: /home/oracle/autoupgrade-patching/TST1/log/TST1/100 Stage logs: /home/oracle/autoupgrade-patching/TST1/log/TST1/100/prechecks TimeZone: /home/oracle/autoupgrade-patching/TST1/log/TST1/temp Remote Dirs: Stages PENDING <1 min GRP <1 min PREACTIONS <1 min PRECHECKS ~1 min (RUNNING) PREFIXUPS EXTRACT DBTOOLS INSTALL OH_PATCHING OPTIONS ROOTSH DB_PATCHING POSTCHECKS POSTFIXUPS POSTACTIONS Stage-Progress Per Container +--------+---------+ |Database|PRECHECKS| +--------+---------+ | TST1| 97 % | +--------+---------+
As mentioned in the output above, the Log Directory (where you defined it in your Config File) is /home/oracle/autoupgrade-patching/TST1/log/TST1/100. You can check the log there, the name of file is autoupgrade_patching_YYYYMMDD_user.log, where YYYYMMDD is the current date. Below, a little piece from the log:
tail -6f autoupgrade_patching_20250516_user.log 2025-05-16 16:18:53.165 INFO The following patches will be used for this job: /u01/software/LINUX.X64_193000_db_home.zip - Base Image - 19 /u01/software/p37642901_190000_Linux-x86-64.zip - Database Release Update : 19.27.0.0.250415 (37642901) /u01/software/p6880880_190000_Linux-x86-64.zip - OPatch - 12.2.0.1.46 2025-05-16 16:18:53.577 INFO Guarantee Restore Point (GRP) successfully removed [TST1][AU_PATCHING_9212_TST11922000] 2025-05-16 16:18:55.157 INFO Guarantee Restore Point (GRP) successfully created [TST1][AU_PATCHING_9212_TST11922000]
Great!
Now, you just need to wait!
This is the output of AutoUpgrade console:
Job 100 completed ------------------- Final Summary -------------------- Number of databases [ 1 ] Jobs finished [1] Jobs failed [0] Jobs restored [0] Jobs pending [0] ---- Drop GRP at your convenience once you consider it is no longer needed ---- Drop GRP from TST1: drop restore point AU_PATCHING_9212_TST11922000 Please check the summary report at: /home/oracle/autoupgrade-patching/log/cfgtoollogs/patch/auto/status/status.html /home/oracle/autoupgrade-patching/log/cfgtoollogs/patch/auto/status/status.log
So, it’s finished! We can drop the GRP later.
Below, we have all the content of the log:
2025-05-16 16:18:53.165 INFO The following patches will be used for this job: /u01/software/LINUX.X64_193000_db_home.zip - Base Image - 19 /u01/software/p37642901_190000_Linux-x86-64.zip - Database Release Update : 19.27.0.0.250415 (37642901) /u01/software/p6880880_190000_Linux-x86-64.zip - OPatch - 12.2.0.1.46 2025-05-16 16:18:53.577 INFO Guarantee Restore Point (GRP) successfully removed [TST1][AU_PATCHING_9212_TST11922000] 2025-05-16 16:18:55.157 INFO Guarantee Restore Point (GRP) successfully created [TST1][AU_PATCHING_9212_TST11922000] 2025-05-16 16:18:55.205 INFO No user defined actions were specified 2025-05-16 16:18:59.968 INFO Analyzing TST1, 60 checks will run using 8 threads 2025-05-16 16:22:24.674 INFO Total FixUps 4 for conName TST1 2025-05-16 16:22:24.675 INFO Adding fixup PURGE_RECYCLEBIN to execution queue of TST1 2025-05-16 16:22:24.675 INFO Total FixUps 5 for conName TST1 after adjustment 2025-05-16 16:23:11.685 INFO Analyzing TST1, 60 checks will run using 8 threads 2025-05-16 16:26:33.969 INFO The file /u01/software/LINUX.X64_193000_db_home.zip is being extracted to /u01/app/oracle/product/19.27/TST1 2025-05-16 16:28:31.242 INFO Successfully extracted the gold image to /u01/app/oracle/product/19.27/TST1 2025-05-16 16:28:31.312 INFO The file /u01/software/p6880880_190000_Linux-x86-64.zip is being extracted to /u01/app/oracle/product/19.27/TST1 2025-05-16 16:28:33.614 INFO The existing autoupgrade.jar is not going to be updated within the new ORACLE_HOME 2025-05-16 16:28:33.676 INFO Waiting to acquire lock 2025-05-16 16:28:33.686 INFO Installing ORACLE_HOME 2025-05-16 16:28:33.686 INFO The new ORACLE_HOME will be created in /u01/app/oracle/product/19.27/TST1 and will have the following edition: Enterprise Edition 2025-05-16 16:28:33.687 INFO Running runInstaller in the target ORACLE_HOME /u01/app/oracle/product/19.27/TST1 2025-05-16 16:29:46.955 INFO Successfully installed the target ORACLE_HOME /u01/app/oracle/product/19.27/TST1 2025-05-16 16:29:47.001 INFO Waiting to acquire lock 2025-05-16 16:29:47.008 INFO Patching Binaries 2025-05-16 16:29:47.015 INFO Installing Database Release Update : 19.27.0.0.250415 (37642901) - /u01/software/p37642901_190000_Linux-x86-64.zip 2025-05-16 16:45:58.241 INFO The source and target ORACLE_HOME have the same set of binary options. No changes are necessary. 2025-05-16 16:45:58.712 INFO Root Script Path : /u01/app/oracle/product/19.27/TST1/root.sh 2025-05-16 16:45:58.828 INFO Executing Root Script 2025-05-16 16:45:58.955 INFO Root script execution was successful. 2025-05-16 16:45:59.043 INFO Patching database using the following config file - /home/oracle/autoupgrade-patching/TST1/log/TST1/100/db_patching/autoupgrade.cfg 2025-05-16 16:50:20.567 INFO Analyzing TST1, 8 checks will run using 8 threads 2025-05-16 16:50:20.575 WARNING The fixup for OLD_TIME_ZONES_EXIST will not be executed on database TST1 as requested. Failure to upgrade your timezone file can lead to erroneous query results. 2025-05-16 16:50:20.812 INFO Total FixUps 3 for conName TST1 2025-05-16 16:50:20.812 INFO Total FixUps 3 for conName TST1 after adjustment 2025-05-16 16:50:20.880 INFO Parallel factor recompile for non-CDBs: factor 1. Job 100 2025-05-16 16:50:24.310 INFO Analyzing TST1, 8 checks will run using 8 threads 2025-05-16 16:50:24.312 WARNING The fixup for OLD_TIME_ZONES_EXIST will not be executed on database TST1 as requested. Failure to upgrade your timezone file can lead to erroneous query results. 2025-05-16 16:50:24.473 INFO No user defined actions were specified
The entire operation took 32 minutes. The online operation (checks, DB Home installation, RU installation) took 28 minutes. The offline (downtime) operation, which is the switch of the DB to the new home took 1 minute. DataPatch (with DB online), took 3 minutes. Cool, isn’t it?
Let’s check the patches installed:
$ORACLE_HOME/OPatch/opatch lspatches 37642901;Database Release Update : 19.27.0.0.250415 (37642901) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
The patches are there! Great!
Let’s check the Patches inside the DB:
SET LINESIZE 500 SET PAGESIZE 1000 SET SERVEROUT ON SET LONG 2000000 COLUMN action_time FORMAT A20 COLUMN action FORMAT A10 COLUMN status FORMAT A10 COLUMN description FORMAT A60 COLUMN source_version FORMAT A13 COLUMN target_version FORMAT A13 COLUMN version_full FORMAT A13 COLUMN comp_id FORMAT A8 alter session set "_exclude_seed_cdb_view"=FALSE; select CON_ID, TO_CHAR(action_time, 'YYYY-MM-DD') AS action_time, PATCH_ID, PATCH_TYPE, ACTION, DESCRIPTION, SOURCE_VERSION, TARGET_VERSION from CDB_REGISTRY_SQLPATCH order by CON_ID, action_time, patch_id; CON_ID ACTION_TIME PATCH_ID PATCH_TYPE ACTION DESCRIPTION SOURCE_VERSIO TARGET_VERSIO ---------- -------------------- ---------- ---------- ---------- ------------------------------------------------------------ ------------- ------------- 0 2025-04-30 35943157 RU APPLY Database Release Update : 19.22.0.0.240116 (35943157) 19.1.0.0.0 19.22.0.0.0 0 2025-05-16 37642901 RU APPLY Database Release Update : 19.27.0.0.250415 (37642901) 19.22.0.0.0 19.27.0.0.0
Perfect! We can see the DataPatch there for RU 19.27.
That’s it!
As mentioned, this will be the first blog post in a series about AutoUpgrade-Composer.
Hope it helps!
Peace!
Vinicius