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:

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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.