Oracle Database Patching with AutoUpgrade in Offline Environments

INTRO:

In my previous post, I showcased how to use AutoUpgrade for downloading Oracle patches. The key takeaway was that AutoUpgrade can be used solely for downloading patches , even from behind a proxy server and across platforms, such as downloading Linux patches from a Windows host.

In previous post, we’ve downloaded all the required setups, we can proceed to use Autoupgrade utility to patch our Oracle Database software for updating it to the desired Release Update level (19.27). The motto of this post is:

You don’t need internet access to use AutoUpgrade for database patching.

I’ll demonstrate how you can patch your Oracle Database in offline environments using previously downloaded files, making it ideal for air-gapped or isolated systems.

If your database server has internet access, you can combine these two steps into one. For a detailed guide, refer to Marcus Vinicius Miguel Pedro’s post, “AutoUpgrade-Composer: Downloading and Applying the N-2 RU with Deploy Mode” . It also demonstrates how to use AutoUpgrade Composer to prepare your configuration file easily.

I will provide all the steps I followed, including the checks I performed, some of which may be optional or unnecessary in your environment, as well as any actions I completed manually.

AutoUpgrade uses Out-of-place patching methodology behind the scenes.

Step 1: Create your new ORACLE_HOME directory

Follow a version-specific naming convention.

[oracle@oravt01 autoupgrade]$ mkdir -p /u01/app/oracle/product/19.27/dbhome_1

Step 2: Create autoupgrade directories

We will create a seperate log directory and a directory to store patches.

[oracle@oravt01 ~]$ mkdir -p  /u01/app/Setup/autoupgrade/log
[oracle@oravt01 ~]$ mkdir -p  /u01/app/Setup/autoupgrade/patches

Step 3: Copy the patch setup files to the offline patch directory on the database server.

We will copy the setup files and the latest version of AutoUpgrade.jar to the patch directory from the Windows host where we downloaded them in the previous blog post, or you may have manually downloaded them from MOS.

c:\Users\insanedba\> cd c:\Users\insanedba\Downloads\autoupgrade\patches
c:\Users\insanedba\Downloads\autoupgrade\patches> scp autoupgrade.jar oracle@oravt01:/u01/app/Setup/autoupgrade/patches
c:\Users\insanedba\Downloads\autoupgrade\patches> scp p*.zip oracle@oravt01:/u01/app/Setup/autoupgrade/patches

In addition to the setup files we downloaded, we will also need the autoupgrade.jar file and the Oracle Database 19.3 base version ZIP file: LINUX.X64_193000_db_home.zip.

Step 4: Create config file

In this example, since we will not be downloading anything, the keystore parameter is not required. If you are running Enterprise Edition in ARCHIVELOG mode, you may choose to create a Guaranteed Restore Point. AutoUpgrade can automatically drop it after patching using the option patch1.drop_grp_after_patching=YES, but I prefer to handle that manually under my control.

[oracle@oravt01 autoupgrade]$ cat update_db_1927.cfg

global.global_log_dir=/u01/app/Setup/autoupgrade/log
patch1.sid=bltdb
patch1.source_home=/u01/app/oracle/product/19.24/dbhome_1
patch1.target_home=/u01/app/oracle/product/19.27/dbhome_1
patch1.download=NO
patch1.patch=RU:19.27,OPATCH,OJVM,OPATCH,34672698
patch1.folder=/u01/app/Setup/autoupgrade/patches
patch1.restoration=YES

Step 5: Run the analyze command for a precheck.

You can run this command while the database is running. No additional Java installation is needed, you can use the Java binary located under the current Oracle Database home.

[oracle@oravt01 autoupgrade]$  /u01/app/oracle/product/19.24/dbhome_1/jdk/bin/java -jar autoupgrade.jar -config update_db_1927.cfg -patch -mode analyze
AutoUpgrade Patching 25.3.250509 launched with default internal options
Processing config file ...
+-----------------------------------------+
| Starting AutoUpgrade Patching execution |
+-----------------------------------------+
1 Non-CDB(s) will be analyzed
Type 'help' to list console commands
...

patch> Job 100 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]

Please check the summary report at:
/u01/app/Setup/autoupgrade/log/cfgtoollogs/patch/auto/status/status.html
/u01/app/Setup/autoupgrade/log/cfgtoollogs/patch/auto/status/status.log

Step 6: Apply the patches to the new ORACLE_HOME and switch to the new ORACLE_HOME using the deploy command.

You can run this command while the database is running. Use the tasks and status commands to track progress. The process will unzip the Database Base Release (19.3) ZIP file LINUX.X64_193000_db_home.zip into the new ORACLE_HOME, then apply the Release Update and the defined patches. After that, it will shut down the running database instance, start it from the new ORACLE_HOME, and apply the SQL patches using datapatch. The listener will continue running from the old ORACLE_HOME, this is normal since AutoUpgrade does not modify it , but your database will be serving from the new ORACLE_HOME with the updated release. Here is the command that does all the trick. What a big command !

[oracle@oravt01 autoupgrade]$  /u01/app/oracle/product/19.24/dbhome_1/jdk/bin/java -jar autoupgrade.jar -config update_db_1927.cfg -patch -mode deploy 

....
patch> status

Config

		User configuration file    [/u01/app/Setup/autoupgrade/update_db_1927.cfg]
		General logs location      [/u01/app/Setup/autoupgrade/log/cfgtoollogs/patch/auto]
		Mode                       [DEPLOY]
Jobs Summary

		Total databases in configuration file [1]
		Total Non-CDB being processed         [1]
		Total Containers being processed      [0]

		Jobs finished successfully            [0]
		Jobs finished/stopped                 [0]
		Jobs in progress                      [1]

Progress
		+---+---------------------------------------------------------+
		|Job|                                                 Progress|
		+---+---------------------------------------------------------+
		|101|[|||||||||||||||||||||||||||||||||||||             ] 73 %|
		+---+---------------------------------------------------------+

patch> Job 101 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

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

# Run the root.sh script as root for the following jobs:
For bltdb -> /u01/app/oracle/product/19.27/dbhome_1/root.sh

---- Drop GRP at your convenience once you consider it is no longer needed ----
Drop GRP from bltdb: drop restore point AU_PATCHING_9212_BLTDB1924000

Please check the summary report at:
/u01/app/Setup/autoupgrade/log/cfgtoollogs/patch/auto/status/status.html
/u01/app/Setup/autoupgrade/log/cfgtoollogs/patch/auto/status/status.log

Post Upgrade Operations

Step 7: Run root.sh as root user to apply all the required file permissions.

Unless the oracle user has sudo privileges or the sudo command is configured to run without a password, you will need to run the root.sh script manually, since a new ORACLE_HOME is created. Otherwise, AutoUpgrade will execute it automatically. In our case, I ran it manually.

[root@oravt01 ~]# /u01/app/oracle/product/19.27/dbhome_1/root.sh

Step 8: Start listener from new ORACLE_HOME

Since the listener is running from old ORACLE_HOME, we will start it from the new ORACLE_HOME.

[oracle@oravt01 ~]# export ORACLE_HOME = /u01/app/oracle/product/19.24/dbhome_1
[oracle@oravt01 ~]# lsnrctl stop
[oracle@oravt01 ~]# export ORACLE_HOME = /u01/app/oracle/product/19.27/dbhome_1
[oracle@oravt01 ~]# lsnrctl start

Step 9: (Optional) Drop Restore Point if everything is fine

At this point, We may drop restore point if everything runs smoothly since we have set drop_grp_after_patching=NO , for this reason we will do it manually.

SYS@bltdb>  select TIME,NAME from v$restore_point;
TIME                                NAME
--------------                      ------------------
30-MAY-25 10.08.04.000000000        AU_PATCHING_9212_BLTDB1924000

SYS@bltdb> drop restore point AU_PATCHING_9212_BLTDB1924000;

Restore point dropped.

Step 10: (Optional) Review Crontab Entries and Bash Profile Commands That Reference the Old ORACLE_HOME

In our environment, no scripts are directly dependent on the Oracle Database Home patch itself; they all rely on the ORACLE_HOME environment variable set in the .bashrc file. Therefore, I will simply update this variable to point to the new ORACLE_HOME, and everything will work as expected.

[oracle@oravt01 ~]$ sed -i 's@19.24/dbhome_1@19.27/dbhome_1@g' /home/oracle/.bashrc
[root@oravt01  ~]$ sed -i 's@19.24/dbhome_1@19.27/dbhome_1@g' /root/.bashrc

Step 11: (Optional) Relink Unified Auditing on new ORACLE_HOME

If you are using pure unified auditing, do not forget the relink new ORACLE_HOME with unified_auditing option is set to on. We will shutdown the database, relink the new home and start the database.

SYS@bltdb> shutdown immediate

[oracle@oravt01 ~]$ cd /u01/app/oracle/product/19.27/dbhome_1/rdbms/lib
[oracle@oravt01 ~]$ export ORACLE_HOME=/u01/app/oracle/product/19.27/dbhome_1/
[oracle@oravt01 ~]$ make -f ins_rdbms.mk uniaud_on ioracle

SYS@bltdb> startup

Step 12: (Optional) Copy the sqlplus site profile file (glogin.sql)

If you have any custom site profile configurations, make sure to copy them from the old ORACLE_HOME to the new ORACLE_HOME.

[oracle@oravt01 lib]$ cp /u01/app/oracle/product/19.24/dbhome_1/sqlplus/admin/glogin.sql /u01/app/oracle/product/19.27/dbhome_1/sqlplus/admin/glogin.sql

At this point, the patching operation is actually complete. However, I will share the checks I performed, which will shed light on the tasks AutoUpgrade executed automatically.

Step 13: (Optional) Manual checks

I verified whether the SQL patches (Datapatch) were applied. This step was automatically handled by the AutoUpgrade utility.

SYS@bltdb > select * from dba_registry_sqlpatch;

I checked the Network configuration files (tnsnames.ora, sqlnet.ora, and listener.ora) and confirmed that they were correctly copied to the new ORACLE_HOME. This task was also performed automatically by the AutoUpgrade utility.

I checked for any invalid objects after the patching process and found none. It appears that AutoUpgrade handled this step as well by automatically running utlrp.sql.

SYS@bltdb > SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);

I checked the parameter file and password file under the dbs directory, and confirmed they were already copied to the new ORACLE_HOME. This step was also handled automatically by the AutoUpgrade utility.

I checked the contents of the ORATAB configuration file (/etc/oratab) and confirmed that the ORACLE_HOME values for the database instances had also been updated.

Initially, I was looking for any operations that AutoUpgrade might have missed during the patching process, but it kept surprising me by handling every task automatically.

At this point, I expected something to be left undone and was almost certain that the utlfixdir.sql script, commonly forgotten by DBAs for modifying Oracle-managed directories, would still need to be run. But it had already been executed. All the directories were updated to the new ORACLE_HOME. You may check with the command provided below.

SYS@bltdb > SELECT * FROM DBA_DIRECTORIES;

Finally, I checked whether the RMAN packages and procedures were compiled with new version, and they were. You can verify this by checking the last_ddl_time of the SYS.DBMS_BACKUP_RESTORE and SYS.DBMS_RCVMAN packages. In the content of the SYS.DBMS_BACKUP_RESTORE package, you will find the line:

bannerVersion CONSTANT VARCHAR2(15) := '19.27.00.00' 

Actually, based on my prior patching experience, DBAs may forget some post-patching tasks, but it seems that AutoUpgrade does not.

Conclusion:

Patching Oracle Database in offline environments is no longer a complex task thanks to AutoUpgrade. By using previously downloaded files and following a structured approach, you can perform out-of-place patching with minimal manual intervention. AutoUpgrade takes care of most tasks automatically, from applying datapatch to copying network configuration files, making it a reliable and efficient solution even in air-gapped systems. Just remember to perform a few final checks, like updating environment variables.

Hope it helps.