Example 3-1 AutoUpgrade Configuration File With Two Database Entries

#
# Global logging directory pertains to all jobs
#
global.autoupg_log_dir=/database/jobmgr        # Top level logging directory (Required)

#
# Database 1
#
upg1.dbname=hr                                 # Database Name (Required)
upg1.source_home=/database/apps/11204/dbhome_1 # Source Home (Required)
upg1.target_home=/database/apps/18100/dbhome_1 # Target home (Required)
upg1.sid=hr1                                   # Oracle Sid (Required)
upg1.start_time=now                            # Start time of the operation (Required)
upg1.pdbs=*                                    # All or a comma separated pdb list (Optional)
upg1.log_dir=/database/logs/hr                 # Local logging directory (Required)
upg1.upgrade_node=nodename1                    # Upgrade node that operation will run on (Required)
upg1.run_utlrp=yes  # yes(default) to run utlrp as part of upgrade, no to skip it (Optional)
upg1.timezone_upg=yes # yes(default) to upgrade timezone if needed, no to skip it (Optional)
upg1.target_version=18.1                       # Oracle Home Target version number (Required)

#
# Database 2
#
upg2.dbname=sales 
upg2.source_home=/database/apps/12202/dbhome_1
upg2.target_home=/database/apps/18100/dbhome_1
upg2.sid=sales1
upg2.start_time=now
upg2.log_dir=/database/logs/sales
upg2.upgrade_node=nodename2
upg2.timezone_upg=no
upg1.target_version=12.2

The parameter upgrade_node refers to the actual system name (hostname) and not to an alias assigned to the host name. You can also use the keyword localhost to refer to the current system.

Example 3-2 Standardizing Upgrades With AutoUpgrade Configuration File Entries

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. The value field can be left empty, if desired. 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
instancename.locallistener=

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
locallistener=

The parameter after_upgrade_pfile_dbname is used to create the database SPFILE during the postupgrade process.