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 thenoconsoleparameter.
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_ROOTset already, then the parameter files that AutoUpgrade generates automatically pick up theWALLET_ROOTsystem 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_ROOTset, then you can use AutoUpgrade to complete that task during the upgrade.
- Create a text file on your operating system with the
WALLET_ROOTinitialization parameter value for the directory that you want to use, and that provides the configuration option you want for theTDE_CONFIGURATIONdynamic initialization parameter to create the type of keystores that you require. For example, if you configureTDE_CONFIGURATIONto useFILEfor 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_pfileandadd_after_upgrade_pfileto refer to that file on the operating system to setWALLET_ROOTandTDE_CONFIGURATIONduring 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_nodespecifies the actual system host name (nodename-1), and not to an alias assigned to the host name. (You can also use the keywordlocalhostto 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_pfileRemoves entries fromduring_upgrade_pfile_dbname.oraadd_during_upgrade_pfileAdd entries toduring_upgrade_pfile_dbname.ora.del_after_upgrade_pfileRemoves entries fromafter_upgrade_pfile_dbname.oraadd_after_upgrade_pfileAdd 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
CDB122in the home/u03/app/oracle/product/12.2.0/dbhome_1 - Upgrade PDBs
PDB2andPDB1to the target Oracle Database 21c Oracle home/u01/app/oracle/product/21.0.0/dbhome_1 - Change the name of
PDB2toDEPSALES, and copy thePDB2files using the new filenameDEPSALES. - Change the name of
PDB1toEMPLOYEES.
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 4-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