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.

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 the WALLET_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.

  1. 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 the TDE_CONFIGURATION dynamic initialization parameter to create the type of keystores that you require. For example, if you configure TDE_CONFIGURATION to use FILE for Transparent Data Encryption software keystores, then Oracle Database creates the software keystore in WALLET_ROOT/tde (lower case).
  2. In the AutoUpgrade configuration file, use the AutoUpgrade configuration file parameters add_during_upgrade_pfile and add_after_upgrade_pfile to refer to that file on the operating system to set WALLET_ROOT and TDE_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

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 keyword localhost 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

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 from during_upgrade_pfile_dbname.ora
  • add_during_upgrade_pfile Add entries to during_upgrade_pfile_dbname.ora.
  • del_after_upgrade_pfile Removes entries from after_upgrade_pfile_dbname.ora
  • add_after_upgrade_pfile Add entries to after_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.

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 and PDB1 to the target Oracle Database 21c Oracle home /u01/app/oracle/product/21.0.0/dbhome_1
  • Change the name of PDB2 to DEPSALES, and copy the PDB2 files using the new filename DEPSALES.
  • Change the name of PDB1 to EMPLOYEES.

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.