add_after_upgrade_pfile

(Optional) Specifies a path and file name of a PFILE whose parameters you want to add after the PFILE is upgraded. This specification applies to all databases in the user configuration file.

Example:

global.add_after_upgrade_pfile=/path/to/my/add_after.ora

(Optional) Specifies a path and file name of a PFILE whose parameters you want to have added during the PFILE upgrade. This specification applies to all databases in the user configuration file.

global.add_during_upgrade_pfile=/path/to/my/add_during.ora

after_action

(Optional) Specifies a path and a file name for a custom user script that you want to have run after all the upgrade jobs finish successfully. The script that you use must be in the form of name.ext (for example, myscript.sh, so that AutoUpgrade can identify the type of script that you want to run. Permitted extension options:

• Unix shell (.sh)

• Microsoft Windows batch (.bat, .cmd)

• Microsoft Windows PowerShell (.ps1)

By default, if the script fails, then AutoUpgrade continues to run. Use the Y flag to specify that AutoUpgrade stops if the operating system detects that your script fails. If the script finishes with a status different than 0, then it is considered a failed completion.

Examples:

If the script fails, then stop AutoUpgrade:

global.after_action=/path/to/my/script.sh Y 

If the script fails, then continue AutoUpgrade:

global.after_action=/path/to/my/script.sh

autoupg_log_dir

(Optional) Sets the location of the log files, and temporary files that belong to global modules, which AutoUpgrade uses.

Example:

global.autoupg_log_dir=/path/to/my/global/log/dir

Starting with AutoUpgrade 19.7, you can configure different log directory path in the userconfig file in the logs directory for a specific prefix

global.autoupg_log_dir=/path/to/my/global/log/dir
myprefix.log_dir=global.auto_log_dir:different/path

The result of using this syntax is that log files and temporary files are placed in the following path for databases identified by the prefix myprefix:

/path/to/my/global/log/dir/different/path

If you do not set this parameter to a path, then by default the log files are placed in the location indicated by the orabase utility for the databases that you include in your configuration file. In that case, the default logs directory is in the path ORACLE_BASE/cfgtoollogs/autoupgrade.

If the orabase utility fails for all databases included in the configuration file, then the log file location is then based on the temp directory for the user running AutoUpgrade.

before_action

(Optional) Specifies a custom user script that you want to have run for all upgrades before starting the upgrade jobs. The script that you use must be in the form of name.ext (for example, myscript.sh), so that AutoUpgrade can identify the type of script that you want to run. If you want to have a script run before a specific upgrade job, then specify that script by using the local parameter (local.before_action)

Permitted extension options:

• Unix shell (.sh)

• Microsoft Windows batch (.bat, .cmd)

• Microsoft Windows PowerShell (.ps1)

By default, if the script fails, then AutoUpgrade continues to run. Use the Y flag to specify that AutoUpgrade stops if the operating system detects that your script fails. If the script finishes with a status different than 0, then it is considered a failed completion.

Examples:

If the script fails, then stop AutoUpgrade:

global.before_action=/path/to/my/script.sh Y 

If the script fails, then continue AutoUpgrade:

global.before_action=/path/to/my/script.sh

catctl_options

(Optional) Specifies one or more of a set of catctl.pl options that you can select for AutoUpgrade to submit for catctl.pl to override default behavior. For a complete description of the options, refer to "Parallel Upgrade Utility (catctl.pl) Parameters," which is linked to at the end of this table.

Available catctl.pl options:

• -n Number of processes to use for parallel operations.
• -N Number of SQL processors to use when upgrading PDBs.
• -t Run SQL in classic upgrade overwriting default replay upgrade method
• -T Takes offline user schema-based table spaces.
• -z Turns on production debugging information for catcon.pm.

Example:

global.catctl_options=-t -n 24 -N 4

(Optional) Specifies a path and file name of a PFILE whose parameters you want to have removed after the PFILE upgrade. This specification applies to all databases in the user configuration file.

Example:

global.del_after_upgrade_pfile=/path/to/my/del_after.ora

(Optional) Specifies a path and file name of a PFILE whose parameters you want to have removed during the PFILE upgrade. This specification applies to all databases in the user configuration file.

Example:

global.del_during_upgrade_pfile=/path/to/my/del_during.ora

drop_grp_after_upgrade

(Optional) Deletes the Guaranteed Restore Point (GRP) after database upgrade. If you select this option, then GRP is deleted after upgrade completes successfully. If you set raise_compatible to yes, then you must also set the parameter drop_grp_after_upgrade to yes.

Options:

[yes | no]

The default value is no.

Example:

global.drop_grp_after_upgrade=yes

target_base

(Optional) Specifies the target ORACLE_BASE path for the target Oracle home. Use of this parameter is only required in rare cases.

Example:

global.target_base=/u01/app/oracle
sales4.target_base=/u04/app/oracle4

raise_compatible

(Optional) Increases the compatible parameter to the default value of the target release after the upgrade is completed successfully.

Options:

[yes | no]

The default value is no.

CAUTION:

• After the COMPATIBLE parameter is increased, database downgrade is not possible.
• Oracle recommends that you only raise the COMPATIBLE parameter to the current release level after you have thoroughly tested the upgraded database.
• Regardless of what value you use for the autoupgrade command-line parameter restore, if you set the value of the configuration file parameter raise_compatible to yes, then before starting the upgrade, you must delete manually any guaranteed restore point you have created. After the upgrade is completed successfully, AutoUpgrade deletes the guaranteed restore point it creates before starting the upgrade. When AutoUpgrade starts the POSTUPGRADE stage, there is no way to restore the database.
• If you set raise_compatible to yes, then you must also set the parameter drop_grp_after_upgrade to yes.

Example:

global.raise_compatible=yes

target_home

(Optional for analyze and fixups modes. Required for upgrade and deploy modes.) Sets a global target home for all of the databases specified in the configuration file. Use this option to avoid specifying the same target_home multiple times. This parameter can be overwritten locally.

Example:

global.target_home=/target/Oracle/home

target_version

(Optional) Specifies the target release version on which you want AutoUpgrade to perform the upgrade. AutoUpgrade uses the release version information that you provide in this parameter to ensure that the correct checks and fixups are used for the target Oracle Database release to which you are upgrading. The format for this parameter are period-delimited values of valid Oracle versions.

Valid values

• 12.2
• 18
• 19

This option is only required if the target home is not present on the system, or if the target home is a 12.2 release. Otherwise, AutoUpgrade can derive the target release value.

Example:

global.target_version=18
employees.target_version=12.2

upgradexml

(Optional) Generates the upgrade.xml file. Options: [yes | no]

The upgrade.xml is equivalent to the file in earlier releases that the preupgrade package generated when you specified the XML parameter. This file is created during the analyze mode (mode -analyze). It is generated in the prechecks directory defined for the AutoUpgrade log files.

Example:

global.upgradexml=yes