AutoUpgrade Configuration File Examples
Use these examples to understand how you can modify your own AutoUpgrade configuration files to perform a variety of configuration actions during the upgrade.
- Updating the TDE Wallet Store Location During Upgrade Using AutoUpgrade
See how you can use AutoUpgrade configuration file parameters to update your Transparent Data Encryption (TDE) wallet store during upgrade. - AutoUpgrade Configuration File with Two Database Entries
See how you can specify upgrade options for multiple databases in a configuration file. - Standardizing Upgrades With AutoUpgrade Configuration File Entries
See how to enforce standardization of your database configurations during upgrades using AutoUpgrade. - AutoUpgrade Configuration File for Incremental Upgrade of a Set of PDBs
See how you can selectively upgrade a subset of PDBs using AutoUpgrade, without affecting the other PDBs on the source CDB. - How to Run AutoUpgrade in a Script or Batch job
Learn how to run AutoUpgrade in your own scripts in noninteractive mode by calling AutoUpgrade using thenoconsole
parameter.
Parent topic: Using AutoUpgrade for Oracle Database Upgrades
Updating the TDE Wallet Store Location During Upgrade Using AutoUpgrade
See how you can use AutoUpgrade configuration file parameters to update your Transparent Data Encryption (TDE) wallet store during upgrade.
In previous releases, if you used Oracle Wallet with TDE, then you
specified the location of the existing keystore directory location by using the
deprecated sqlnet.ora
parameter
SQLNET.ENCRYPTION_WALLET_LOCATION
. In Oracle Database 19c and
later releases, you should specify the keystore location by using the
WALLET_ROOT
system parameter in the database initialization
parameter file (PFILE
). What you need to do depends on how your
source Oracle Database release is configured:
-
If your source Oracle Database release has
WALLET_ROOT
set already, then the parameter files that AutoUpgrade generates automatically pick up theWALLET_ROOT
system parameter from the source database during the upgrade, and use that parameter in target database parameter files. -
If your source Oracle Database release does not have the initialization parameter
WALLET_ROOT
set, then you can use AutoUpgrade to complete that task during the upgrade.
- Create a text file on your operating system with the
WALLET_ROOT
initialization parameter value for the directory that you want to use, and that provides the configuration option you want for theTDE_CONFIGURATION
dynamic initialization parameter to create the type of keystores that you require. For example, if you configureTDE_CONFIGURATION
to useFILE
for Transparent Data Encryption software keystores, then Oracle Database creates the software keystore inWALLET_ROOT/tde
(lower case). - In the AutoUpgrade configuration file, use the AutoUpgrade
configuration file parameters
add_during_upgrade_pfile
andadd_after_upgrade_pfile
to refer to that file on the operating system to setWALLET_ROOT
andTDE_CONFIGURATION
during the upgrade.
For example, if you want WALLET_ROOT
to use the path
/u01/app/oracle/admin/hr/wallet
, and Transparent Data
Encryption to store software keystores in the location
WALLET_ROOT/tde
, then you can create a text file called
tde-upgrade
, which contains the following lines:
WALLET_ROOT=/u01/app/oracle/admin/hr/wallet
tde_configuration="KEYSTORE_CONFIGURATION=FILE"
You can then specify for AutoUpgrade to set these parameters in the AutoUpgrade configuration file. For example, to set the Transparent Data Encryption keystore during and after the upgrade, as part of the AutoUpgrade operation, add the following line to your local configuration file to call that text file:
#
# Example local pfile configuration entries
upg1.add_after_upgrade_pfile=/usr/home/oracle/tde-upgrade
upg1.add_during_upgrade_pfile=/usr/home/oracle/tde-upgrade
Related Topics
Parent topic: AutoUpgrade Configuration File Examples
AutoUpgrade Configuration File with Two Database Entries
See how you can specify upgrade options for multiple databases in a configuration file.
This example is of an AutoUpgrade configuration file that specifies the upgrade of two databases. The configuration file specifies that AutoUpgrade performs the following actions:
Database 1
- An in-place database upgrade of the Oracle Database 12c Release 2
(12.2) CDB, where the source and target Oracle homes use the same Oracle Base
directory (the database home directory for Oracle Database installation owner
oracle
(/u01/app/oracle/
) on the same server hardware, with the same system identifier (sid=HR1). - During the upgrade, all the PDBs of the CDB are upgraded
(
pdbs=*
) - The upgrade starts immediately
(
start_time=now
) - The database upgrade logs will be sent to the path
/database/logs/hr
(log_dir=/database/logs/hr
) - The Time Zone upgrade will run on all the containers
(
timezone_upg=yes
)
Database 2
- An in-place database upgrade of the Oracle Database 18c CDB, where
the source and target Oracle homes use the same Oracle Base directory (the
database home directory for Oracle Database installation owner
oracle
(/u01/app/oracle/
) on the same server hardware, with the same system identifier (sid=SALES1
). - The upgrade starts immediately
(
start_time=now
) - The database upgrade logs will be sent to the path
/database/logs/sales
(log_dir=/database/logs/sales
). - The Time Zone upgrade will not run on any containers
(
timezone_upg=no
).
For both databases:
- The parameter
upgrade_node
specifies the actual system host name (nodename-1
), and not to an alias assigned to the host name. (You can also use the keywordlocalhost
to refer to the current system.) - The global AutoUpgrade log files (also known as job manager logs)
are placed under the path
/database/jobmgr
(autoupg_log_dir=/database/jobmgr
).
#
# Global logging directory pertains to all jobs
#
global.autoupg_log_dir=/database/jobmgr
#
# Database 1
#
upg1.source_home=/u01/app/oracle/product/12.2.0.2/dbhome_1
upg1.target_home=/u01/app/oracle/product/21.0.0/dbhome_1
upg1.sid=HR1
upg1.start_time=now
upg1.pdbs=*
upg1.log_dir=/database/logs/hr
upg1.upgrade_node=nodename1
upg1.run_utlrp=yes
upg1.timezone_upg=yes
upg1.target_version=21
#
# Database 2
#
upg2.source_home=/u01/app/oracle/product/18.0.0/dbhome_1
upg2.target_home=/u01/app/oracle/product/21.0.0/dbhome_1
upg2.sid=SALES1
upg2.start_time=now
upg2.log_dir=/database/logs/sales
upg2.upgrade_node=nodename1
upg2.timezone_upg=no
upg2.target_version=21
Parent topic: AutoUpgrade Configuration File Examples
Standardizing Upgrades With AutoUpgrade Configuration File Entries
See how to enforce standardization of your database configurations during upgrades using AutoUpgrade.
In the following configuration file, you can see how you can use
AutoUpgrade configuration file entries to standardize their database configurations.
The global PFILE
entries are applied to all databases within the
configuration file. The local PFILE
entries are applied only to a
specific database in the configuration file. The syntax for these
PFILE
values follow the same Oracle rules for
PFILE
configurations.
#
# Example global pfile configuration entries
#
global.del_during_upgrade_pfile=/database/pfiles/global_during_delinit.ora
global.add_during_upgrade_pfile=/database/pfiles/global_during_addinit.ora
global.del_after_upgrade_pfile=/database/pfiles/global_after_delinit.ora
global.add_after_upgrade_pfile=/database/pfiles/global_after_addinit.ora
#
# Example local pfile configuration entries
#
upg1.del_during_upgrade_pfile=/database/pfiles/hr_during_delinit.ora
upg1.add_during_upgrade_pfile=/database/pfiles/hr_during_addinit.ora
upg1.del_after_upgrade_pfile=/database/pfiles/hr_after_delinit.ora
upg1.add_after_upgrade_pfile=/database/pfiles/hr_after_addinit.ora
During the AutoUpgrade process, the files
during_upgrade_pfile_dbname.ora
and
after_upgrade_pfile_dbname.ora
are both created. These files
are used to start the database during the upgrade, and after the upgrade. If you
want to change a system parameter during the upgrade, or after the upgrade, then you
can modify both files.
The global PFILE
entries are applied first, and then
the local PFILE
entries designated by the job prefix
upgl
are applied. Within those two configuration files, entries
in the parameter del_upgrade_pfile
are applied first, followed by
entries in the parameter add_upgrade_pfile
. The parameters in these
PFILE
configuration entries are applied directly either to the
PFILE
during_upgrade_pfile_dbname.ora
or to the PFILE
after_upgrade_pfile_dbname.ora
, depending on which
PFILE
is targeted.
Actions:
del_during_upgrade_pfile
Removes entries fromduring_upgrade_pfile_dbname.ora
add_during_upgrade_pfile
Add entries toduring_upgrade_pfile_dbname.ora
.del_after_upgrade_pfile
Removes entries fromafter_upgrade_pfile_dbname.ora
add_after_upgrade_pfile
Add entries toafter_upgrade_pfile_dbname.ora.
The files referenced by the parameters
del_during_upgrade_pfile
and
del_after_upgrade_pfile
have a single database parameter listed
on each line. You cannot add any prefix to the parameter, because the entire line is
part of the parameter name. Consider the following example:
#
# global.del_during_upgrade_pfile
#
processes
*.open_cursors
The result of this configuration setting is to remove from the
PFILE
for each database listed in the configuration file all
references to the processes
parameter, but not references to the
open_cursors
parameter: Only instances of
open_cursors
that have a prefix are removed. However, the
parameters removed from the PFILE
includes all parameters that are
prefixed. For example, *.processes
and
instance_name.processes
are both removed with this syntax.
The files referenced by the parameters
add_during_upgrade_pfile
and
add_after_upgrade_pfile
have a single parameter listed on each
line with the format parameter=value
. If you delete the entry from the
PFILE
, then the value field can be left empty. If the parameter
is prefixed with *.
or instancename.
, then those
references are not added to the modified PFILE
. To update the value
of an existing parameter, you must first delete it. You can then add the parameter
with the desired value. Consider the following example:
#
# global.add_during_upgrade_pfile
#
processes=400
*.open_cursors=250
This global configuration file entry results in adding the following
entries to the PFILE
for each database that is listed in the
configuration file:
processes=400
open_cursors=250
The parameter after_upgrade_pfile_dbname
is used to
create the database SPFILE
during the postupgrade process.
Parent topic: AutoUpgrade Configuration File Examples
AutoUpgrade Configuration File for Incremental Upgrade of a Set of PDBs
See how you can selectively upgrade a subset of PDBs using AutoUpgrade, without affecting the other PDBs on the source CDB.
In this scenario, you upgrade two specific PDBs, without upgrading the other PDBs in the source CDB, To perform the incremental upgrade, you direct AutoUpgrade in the configuration file to unplug the PDBs you specify from an earlier release CDB, plug them into a target release CDB, and then upgrade the earlier release PDBs on the target CDB. This selection of PDBs to unplug, plug in, and upgrade, enables you to perform an incremental upgrade of PDBs on the earlier release CDB to reduce downtime.
The following configuration file identifies the CDB
CDB122
as the source CDB. The source CDB has 10 PDBs,
PDB1
through PDB10
, but only
PDB1
and PDB2
are upgraded. During the
upgrade, the PDB named PDB2
has its name changed to
DEPSALES
, and the database file names for PDB2
are changed to DEPSALES
:
global.autoupg_log_dir=/home/oracle/autoupg
upg1.sid=CDB122
upg1.source_home=/u03/app/oracle/product/12.2.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/21.0.0/dbhome_1
upg1.target_cdb=CDB21C
upg1.pdbs=PDB2, PDB1
upg1.target_pdb_name.PDB2=DEPSALES
upg1.target_pdb_name.PDB1=EMPLOYEES
upg1.target_pdb_copy_option.PDB2=file_name_convert=('PDB2','DEPSALES')
This configuration file directs AutoUpgrade to do the following:
- Select PDBs from the source Oracle Database
CDB122
in the home/u03/app/oracle/product/12.2.0/dbhome_1
- Upgrade PDBs
PDB2
andPDB1
to the target Oracle Database 21c Oracle home/u01/app/oracle/product/21.0.0/dbhome_1
- Change the name of
PDB2
toDEPSALES
, and copy thePDB2
files using the new filenameDEPSALES
. - Change the name of
PDB1
toEMPLOYEES
.
Parent topic: AutoUpgrade Configuration File Examples
How to Run AutoUpgrade in a Script or Batch job
Learn how to run AutoUpgrade in your own scripts in noninteractive mode by
calling AutoUpgrade using the noconsole
parameter.
By default, AutoUpgrade runs in console mode, which enables you to run commands to monitor specific aspects of your AutoUpgrade jobs while they are running on your systems.
Note:
You can run only one AutoUpgrade instance at a time that is associated with a given configuration file.
Example 3-7
In this example, AutoUpgrade is run in Deploy mode, using the settings specified in
the configuration file autoupgrade.cfg
, and turning
off console using the noconsole
parameter.
java -jar autoupgrade.jar -config autoupgrade.cfg -mode deploy -noconsole
Using the noconsole
mode turns off requirements for user input, so
you can enter this command in a script to run the upgrades you
specify in the configuration file.
Parent topic: AutoUpgrade Configuration File Examples