Some customers prefer to install Oracle homes in a path that indicates the patch level, like:

/u01/app/oracle/dbhome_1928

1928 indicates this is Oracle Database 19c with Release Update 28. If you use AutoUpgrade to create your Oracle home, you can specify that path in your config file:

patch1.target_home=/u01/app/oracle/dbhome_1928

To ease automation, AutoUpgrade can dynamically determine the target Oracle home using placeholders. After downloading the patches, it checks which Release Update it will apply.

patch1.target_home=/u01/app/oracle/dbhome_%RELEASE%%UPDATE%

Easier Patching

Take a look at this config file

global.global_log_dir=/home/oracle/autoupgrade-patching/log
global.keystore=/home/oracle/autoupgrade-patching/keystore
global.folder=/home/oracle/patch-repo
patch1.source_home=/u01/app/oracle/product/dbhome_1927
patch1.target_home=/u01/app/oracle/product/dbhome_%RELEASE%%UPDATE%
patch1.sid=FTEX
patch1.patch=RECOMMENDED

patch=RECOMMENDED or even patch=RU would always get the latest Release Update. At time of writing, that would be 19.28.
target_home contains the placeholders. After AutoUpgrade determined that 19.28 is the latest Release Update, it would dynamically determine the Oracle home path.
You would still need to update source_home in the config file. It will change after each run because you use out-of-place patching.

Now, you can just start AutoUpgrade every quarter:

java -jar autoupgrade.jar \
     -config FTEX.cfg \
     -patch \
     -mode deploy

AutoUpgrade downloads the latest Release Update and builds a new Oracle home for your – with a dynamically created path reflecting the Release Update.

Ain’t that easy?

Other Release Updates

What if you want to install an older Release Update. That works too:

patch1.target_home=/u01/app/oracle/product/dbhome_%RELEASE%_%UPDATE%
patch1.patch=RU:19.27,OPATCH

This will install the Oracle home in:

/u01/app/oracle/product/dbhome_19_27

Even Easier

Here’s another way. It requires that the environment is set correctly and works entirely without a config file.

export ORACLE_SID=FTEX
export ORACLE_HOME=/u01/app/oracle/product/19
export AU_LOG_DIR="/home/oracle/autoupgrade-patching/log_"`date +%Y%m%d_%H%M%S`
java -jar autoupgrade.jar \
     -config_values "global.global_log_dir=$AU_LOG_DIR,global.folder=/home/oracle/patch-repo,download=no,target_home=/u01/app/oracle/product/dbhome_%RELEASE%%UPDATE%,patch=RECOMMENDED" \
     -patch \
	 -mode deploy

AutoUpgrade takes sid and source_home from the environment variables ORACLE_SID and ORACLE_HOME.
Then you specify other parameters as a comma-separated list using -config_values.
Notice the target_home with placeholders in the long list of parameters.
The AutoUpgrade logging directory uses a timestamp to ensure a new one is used on each invocation.

Final Words

It’s now easier to automate creation of Oracle homes using AutoUpgrade.

Do you think this feature is useful? Do you need other replacement variables?

3 thoughts on “AutoUpgrade New Features: Create Oracle Home Path Dynamically”

Pingback: AutoUpgrade-Composer: Updated to v.25.4-3 – Added capability for Dynamic Path on Target Home | Vinicius DBA
Michał says:

September 11, 2025 at 13:29

Dear Daniel,

Good update – thank You.
Is it possible to use a configuration file (for static variables that do not change or are provided by variables like: %RELEASE%, %UPDATE%) and for other variables parameter (like source_home) use: -config_values and than use environment variables? Or can we use environment variables (like ORACLE_HOME, ORACLE_sid) in config file?

Regards,
Michał

LikeLike

1. Daniel Overby Hansen says:
  
  September 12, 2025 at 08:38
  
  Hi Michał,
  You can’t use environment variables inside the config file. The only substitution variables are those defined in the blog post (RELEASE and UPDATE).
  If you wan’t to use -config_values you can have environment variables and all other must be specified in the -config_values parameter.
  Regards,
  Daniel
  
  LikeLike