Patch Parameters for the AutoUpgrade Configuration File

The patch parameters for the AutoUpgrade configuration file (config) are only used with software maintenance -patch operations.

Locally Modifiable Global Patch Parameters for the AutoUpgrade Configuration File

The Patch locally modifiable global parameters for the AutoUpgrade configuration file enable you to set modifiable global parameters in the configuration (config) file that can be overwritten by a database-specific local parameter.

Note:

At this time there are no locally modifiable global parameters for patching.

Local Patch Parameters for the AutoUpgrade Config File

The patch parameters enable you to configure AutoUpgrade processing in the configuration file (config) for specific Oracle Databases for software maintenance (-patch).

after_action.create_home

(Optional for AutoUpgrade patching) In create_home mode, specifies a custom action that you want to have performed after completing the patch create_home mode for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

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. This script is only run during the deploy stage of the patching operation.

Permitted extension options:

  • Unix shell (.sh)
  • Microsoft Windows batch (.bat, .cmd)
  • Microsoft Windows PowerShell (.ps1)
  • Oracle SQL file (.sql), with a local operation only designated by the prefix.

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.

For patching operations, the local after_action.create_home parameter can specify a SQL script, which then runs on the database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. If you want to run additional container-specific actions, then they must be set within the code. For more complex scenarios, you can run container-specific actions in a shell.

The output of the script is captured and stored in files. Both stdout and stderr are captured. The files are stored in the postupgrade subdirectory in the directory matching the specific database or job.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Examples

Run the specified script after AutoUpgrade completes processing create_home mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.after_action.create_home=/user/path/script.sh Y 

Run the specified script after AutoUpgrade completes processing create_home, with AutoUpgrade set to continue to run if the script fails:

sales4.after_action.create_home=/user/path/script.sh 

after_action.deploy

(Optional for AutoUpgrade patching) Specifies a custom action that you want to have performed after completing the deploy part of the patching job for the database identified by the prefix address.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

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. This script is only run during the deploy stage of the patching operation.

Note:

The after_action.deploy parameter for AutoUpgrade patching and the local parameter after_action cannot be specified in the same configuration file.

Permitted extension options:

  • Unix shell (.sh)
  • Microsoft Windows batch (.bat, .cmd)
  • Microsoft Windows PowerShell (.ps1)
  • Oracle SQL file (.sql), with a local operation only designated by the prefix.

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.

For patching operations, the local after_action.deploy parameter can specify a SQL script, which then runs on the database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. If you want to run additional container-specific actions, then they must be set within the code. For more complex scenarios, you can run container-specific actions in a shell.

The output of the script is captured and stored in files. Both stdout and stderr are captured. The files are stored in the postupgrade subdirectory in the directory matching the specific database or job.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Examples

Run the specified script after AutoUpgrade starts processing the patch operation, with the Y flag set to stop AutoUpgrade if the script fails:

sales2.after_action.deploy=/user/path/script.sh Y 

Run the specified script after AutoUpgrade starts processing the deploy option for patching, with AutoUpgrade set to continue to run the patch operation if the script fails:

sales3.after_action.deploy=/user/path/script.sh 

before_action.create_home

(Optional for AutoUpgrade patching) In create_home mode, specifies a custom action that you want to have performed before starting the patch create_home mode for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

For patching operations, the local before_action.create_home can specify an actoin that you want performed before creating a new Oracle home for the patched database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. You must specify the new Oracle home path.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Syntax

prefix.before_action.create_home=/my/new/oracle/home/

Examples

Run the specified script before AutoUpgrade starts processing create_home mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.before_action.create_home=/user/path/script.sh Y 

Run the specified script before AutoUpgrade starts processing create_home mode, with AutoUpgrade set to continue to run if the script fails:

sales4.before_action.create_home=/user/path/script.sh 

before_action.deploy

(Optional for AutoUpgrade patching). In deploy mode, specifies a custom action that you want to have performed before starting the upgrade job for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

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)
  • Oracle SQL file (.sql), with a local operation only designated by the prefix.

Note:

The before_action.deploy parameter for AutoUpgrade patching and the local parameter before_action parameter cannot be specified in the same configuration file.

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.

For patching operations, the local before_action.deploy parameter can specify a SQL script, which then runs on the database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. If you want to run additional container-specific actions, then they must be set within the code. For more complex scenarios, you can run container-specific actions in a shell.

The output of the script is captured and stored in files. Both stdout and stderr are captured. The files are stored in the preupgrade subdirectory in the directory matching the specific database or job.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Examples

Run the specified script before AutoUpgrade starts processing deploy mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.before_action.deploy=/user/path/script.sh Y 

Run the specified script before AutoUpgrade starts processing deploy mode, with AutoUpgrade set to continue to run if the script fails:

sales4.before_action.deploy=/user/path/script.sh 

download

(Optional for AutoUpgrade patching) Specifies whether to automatically download patches from My Oracle Support. .

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Specifies whether to automatically download patches from My Oracle Support. The default is YES.

When set to YES, you must either load My Oracle Support (MOS) credentials or an OAUTH token into AutoUpgrade Patching at the command line using the -load_password command-line option.

The patches that are downloaded are placed into the directory folder specified by the folder parameter.

If proxy information is required to connect to My Oracle Support, then set proxy values using the Linux operating system environment variables https_proxy, http_proxy, and no_proxy.

The supported format of the proxy definition is as follows, where user_info is a user account, site is a URL, and port is a designated port for the proxy listener:

[https|http|socks5|socks]://(user_info@)site:port

Adding user_info to the proxy definition is optional, and has a format of username:password for the credentials of the proxy.

Options

[yes | no]

The default value is yes.

Examples

Override the default (yes) so that you use patches that you have downloaded manually instead of having AutoUpgrade download the patches automatically:

upg1.download=no 

drop_grp_after_patching

(Optional for AutoUpgrade patching) Deletes the Guaranteed Restore Point (GRP) after database patch maintenance.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

If you select this parameter option, then GRP is deleted after the AutoUpgrade patch maintenance completes successfully.

Options

[yes | no]

The default value is no.

Example

sales4.drop_grp_after_patching=yes

folder

(Required for AutoUpgrade patching) Specifies the directory that contains the patch zip files as well as any Oracle Database base images that are required.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

For AutoUpgrade to perform patching, you must identify the directory that contains the patch zip files. This directory must also contain the Oracle Database base image. There is no default value. You must provide the directory path. This parameter also is used in conjunction with the download parameter as follows:

When download=YES, the directory specified by the folder parameter is the directory to which the patches will be downloaded

When download=NO, the directory specified by the folder parameter is the directory that must contain the patches that have been manually downloaded.

The directory that you specify with the folder parameter must contain the base image of the source database's release (for example, Oracle Database Release 19.3).

Examples

upg1.folder=/storage/patches

home_settings.account_type

(Optional) for AutoUpgrade patching) On Microsoft Windows, this option specifies the type of account to use when creating the target ORACLE_HOME.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

On Microsoft Windows, the Oracle Home User can be either a Windows Virtual Account (VIRTUAL), a Windows Built-in Account (BUILT_IN), or a standard Windows User Account (not an Administrator account) (USER).

If a Windows Virtual Account is used, then it enables you to install an Oracle Database and create and manage Database services without passwords. If a Built-in Account is used, then no user name or password is required during installation and administration. If a Windows User Account is used as Oracle Home User, then you must provide the user name and password during installation and some of the administration tasks. A Virtual Account can be used as the Oracle Home User for Oracle Database Single Instance installations. Virtual accounts do not require a user name or password during installation and administration.

Note:

To use this option, the Windows user account (nonadministrative user) must exist before you run AutoUpgrade. AutoUpgrade cannot create these users.

Options

[VIRTUAL|BUILT_IN|USER]

Examples

In this example, you specify the Oracle Home User account to be a Built-in account:

upg1.home_settings.account_type=built_in

home_settings.binopt.asm

(Optiona for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle ASM (asm) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Note:

This option is not available on Microsoft Windows platforms.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the Oracle Automatic Storage Management (asm) binary turned off. This parameter instructs AutoUpgrade to turn the asm binary to ON in the target Oracle home.

upg1.home_settings.binopt.asm=yes

home_settings.binopt.dm

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle Data Mining (dm) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration file source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Note:

This option is not available on Microsoft Windows platforms.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the Oracle Data Mining (dm) binary turned off. This parameter instructs AutoUpgrade to turn the dm binary to ON in the target Oracle home.

upg1.home_settings.binopt.dm=yes

home_settings.binopt.jox

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for the JavaVM JIT Compiler (jox) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Note:

This option is not available on Microsoft Windows platforms.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the JavaVM JIT Compiler (jox) binary turned off. This parameter instructs AutoUpgrade to turn the DM binary to ON in the target Oracle home.

upg1.home_settings.binopt.jox=yes

home_settings.binopt.olap

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for the On Line Application Processing (OLAP) options (olap) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the On Line Application Processing options (olap) binary turned off. This parameter instructs AutoUpgrade to turn the olap binary to ON in the target Oracle home.

upg1.home_settings.binopt.olap=yes

home_settings.binopt.part

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle Partitioning (part) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has Oracle Partitioning (part) binary turned off. This parameter instructs AutoUpgrade to turn the part binary to ON in the target Oracle home.

upg1.home_settings.binopt.part=yes

home_settings.binopt.rac

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle RAC (rac) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Note:

This option is not available on Microsoft Windows platforms.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the Oracle Real Application Clusters (Oracle RAC) binary (rac) turned off. This parameter instructs AutoUpgrade to turn the rac binary to ON in the target Oracle home.

upg1.home_settings.binopt.rac=yes

home_settings.binopt.rat

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle Real Application Testing (rat) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the Oracle Real Application Testing binary (rat) turned off. This parameter instructs AutoUpgrade to turn the rat binary to ON in the target Oracle home.

upg1.home_settings.binopt.rat=yes

home_settings.binopt.sdo

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle Spatial Data Option Messages (sdo) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Note:

This option is not available on Microsoft Windows platforms.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has the Oracle Spatial Data Option Messages (SDO) binary (sdo) turned off. This parameter instructs AutoUpgrade to turn the sdo binary to ON in the target Oracle home.

upg1.home_settings.binopt.sdo=yes

home_settings.binopt.uniaud

(Optional for AutoUpgrade patching) Specifies whether the target ORACLE_HOME being created by AutoUpgrade Patching has the binary option for Oracle's unified auditing feature (uniaud) turned ON or OFF.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Oracle products and components are enabled or disabled at the binary level in the source Oracle home. When a source Oracle home is defined in the configuration file by using the local configuration parameter source_home, the value used for the target Oracle home matches the status of the binary option for the source Oracle home; the default is to leave the binary value unchanged. However you can choose to override the target Oracle home setting by choosing either yes or no.

Options

[yes | no]

There is no default.

Examples

In this example, the source Oracle home has Oracle's unified auditing feature binary (uniaud) turned off. This parameter instructs AutoUpgrade to turn the uniaud binary to ON in the target Oracle home.

upg1.home_settings.binopt.uniaud=yes

home_settings.cluster_nodes

(Optional for AutoUpgrade patching) Specifies the list of nodes in an Oracle Real Applications (Oracle RAC) cluster on which you want to run AutoUpgrade patching.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

The value of this parameter should be a comma-delimited list of node names, where each node name is the hostname of a node in the cluster. This option is only available on certified POSIX-compliant platforms.

Note:

Autoupgrade Patching on an Oracle RAC Database automatically applies the Oracle Clusterware patch that matches the RU version for the Oracle Clusterware software, even if the Oracle Clusterware value (OCW) is not defined in the patch parameter.

Syntax

home_settings.cluster_nodes=node1[,node2,node3...]

In the syntax, node1, node2 and node3 are names of cluster member nodes in the Oracle RAC cluster.

Note:

Regardless of the specific nodes listed in the comma-delimited list, this parameter always runs on the local node where AutoUpgrade is run. For example, suppose you run AutoUpgrade patching from cluster member node1 in an Oracle RAC cluster with cluster members node1 and node2:

home_settings.cluster_nodes=node2

Because you are running AutoUpgrade patching from node1, AutoUpgrade patching will run on both node1 (the local node) and node2.

Examples

In this example, when Autoupgrade Patching is run in deploy mode, the configuration file instructs AutoUpgrade to create a new Oracle home in the target home location on both node1 and node2, and move the source Oracle home on each node (/databases/ee/product/19x/dbhome_1) to the target Oracle home (/home/oracle/newOH) on each node.

global.global_log_dir=/home/oracle/autopatch
upg1.patch=RU,OPATCH
upg1.sid=raccdb191
upg1.source_home=/databases/ee/product/19x/dbhome_1
upg1.target_home=/home/oracle/newOH
upg1.folder=/home/oracle/patches
upg1.home_settings.cluster_nodes=node1,node2

home_settings.edition

(Optional for AutoUpgrade patching) Specifies the Oracle Database edition that you want to use for creating the target ORACLE_HOME.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

When a source ORACLE_HOME is defined in the configuration file, the default value for edition matches the edition used for that ORACLE_HOME. Otherwise, there is no default value.

Options

Standard (SE2) or Enterprise Edition (EE):

[se2|ee]

Examples

In this example, you specify the Oracle Database edition to be Oracle Database Standard Edition.

upg1.home_settings.edition=se2

home_settings.home_name

(Optional for AutoUpgrade patching) Specifies the Oracle home name that will be used for the database in the inventory.xml file in the Oracle Inventory (oraInventory) directory when creating the target ORACLE_HOME.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

In a read/write ORACLE_HOME, the ORACLE_BASE_HOME path is the same as the ORACLE_HOME directory. However, in a read-only ORACLE_HOME, the ORACLE_BASE_HOME directory is not co-located with ORACLE_HOME, but instead is located at ORACLE_BASE/homes/HOME_NAME. The value for HOME_NAME is the internal name for the ORACLE_HOME. These home names are tracked in the oraInventory directory, which contains a file called inventory.xml that lists the names of all the Oracle homes installed on the system. Oracle software owners are members of this group. The default value is to use a generic name for the database homes, but you can specify a particular name by using this option.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the Oracle home name change the database home from a generic name, such as dbhome_2, to be inv_west:

upg1.home_settings.home_name=inv_west

home_settings.ignore_opatch_conflict

(Optional for AutoUpgrade patching) Specifies the conflict resolution strategy for resolving conflicts between patches caused by one-off patches.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This optional parameter enables you to configure a patching conflict policy that AutoUpgrade can apply when AutoUpgrade patching performs OPatch prerequisite checks. When you set a conflict policy using this parameter and AutoUpgrade detects conflicts among the patches specified by the patch parameter, AutoUpgrade applies the patch conflict policy to resolve the conflict.

 If the conflict is only between the one-off patches specified by the patch parameter, then, based on the home_settings.ignore_opatch_conflict parameter value, AutoUpgrade patching can automatically resolve conflicts between those patches and proceed to complete the patching, without stopping with a patch conflict error.

Note:

If patch conflicts are between any other types of patches other than the one-off patches that you specify with the patch parameter, then AutoUpgrade will always stop and issue an error, regardless of the ignore_patch_conflict policy that you set.

Options

[error|keep_first|skip_all]

The default is error. The values for home_settings.ignore_opatch_conflict are as follows:

  • error (default) : When AutoUpgrade encounters patch conflicts, patching then stops. AutoUpgrade displays an error, indicating that there are conflicts among the specified patches.

  • keep_first: When AutoUpgrade encounters patch conflicts, it prioritizes installing the one-off patches based on the order in which they are entered in the configuration file prefix.patch=RU,OPATCH,patch-number1,patch-number2,patch-number3... parameter entry. When a conflict is found, the one-off patches that come first in the patch parameter value sequence continue to be installed, even if these patches conflict with patches that are specified later in the parameter patch priority list. At the end of the patching operation, AutoUpgrade reports the patches that could not be applied.
  • skip_all : AutoUpgrade patching automatically skips installing all conflicted one-offs patches and proceeds to install patches that do not have conflicts.

Examples

ignore_opatch_conflict=error

In this example, the ignore_opatch_conflict option either is not specified (in which case the default is set to ERROR), or this option is set in the configuration file to ERROR. As a result, if AutoUpgrade encounters any conflicts between any of the one-off patches (101,102,103), then AutoUpgrade stops and displays an error.

upg1.patch=RECOMMENDED,101,102,103

upg1.home_settings.ignore_opatch_conflict = ERROR



ignore_opatch_conflict=keep_first

In this example, the ignore_opatch_conflict option is set in the configuration file to KEEP_FIRST.

upg1.patch=RU,OPATCH,OJVM,101,102,103,104,105,106,107,108
upg1.home_settings.ignore_opatch_conflict = KEEP_FIRST

Suppose conflict arise among the following one-off patches:

  • 101,102
  • 101,103
  • 102,103
  • 103,104
  • 104,105
  • 105,108

In this case, AutoUpgrade patching does not stop with an error message, but continues to install patches :(RU,OPATCH,OJVM,101,104,106,107,108), based on the order of their appearance in the patch parameter value sequence. AutoUpgrade automatically ignores installing patches 102,103, and 105. At the end of the patching operation, AutoUpgrade reports the patches that had conflicts (102,103,105), and were ignored, with the following message: "Conflicts are detected and ignored among the provided one-off patches for the following jobs."

ignore_opatch_conflict=skip_all

In this example, the ignore_opatch_conflict option is set in the configuration file to SKIP_ALL.

upg1.patch=RU,OPATCH,OJVM,101,102,103,104,105
upg1.home_settings.ignore_opatch_conflict = SKIP_ALL

Suppose that there are conflicts, but they only exist between patches 103 and 104. In that event, AutoUpgrade ignores patch numbers 103 and 104, and completes installing patches RU,OPATCH,OJVM, 101, 102, and 105, without stopping to display an error. At the end of the process, AutoUpgrade reports that patches 103 and 104 had conflicts that were detected, so these patches were ignored.

home_settings.ignore_prereq_failure

(Optional for AutoUpgrade patching) Specifies whether AutoUpgrade patching ignores any prerequisite check errors that occur during installation on an Oracle Real Application Clusters (Oracle RAC) target home.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.
This optional parameter enables you to choose to ignore specific prerequisite checks and continue with the installation. It is not avaible for Microsoft Windows Oracle RAC home patching. Use this parameter when you have investigated a check error and find that it will not affect the installation.

Note:

Oracle highly recommends that you first address any prerequisite check conflict errors before you proceed.

Options

[yes|no]

The default is no.

Example

In the following example, the value is set to yes. AutoUpgrade patching will ignore any prerequisite check failure and continue new target oracle home creation in node1 and node2 .

global.global_log_dir=/home/oracle/autopatch
upg1.patch=RU,OPATCH
upg1.sid=raccdb191
upg1.source_home=/databases/ee/product/19x/dbhome_1
upg1.target_home=/home/oracle/newOH
upg1.folder=/home/oracle/patches
upg1.home_settings.cluster_nodes=node1,node2
upg1.home_settings.ignore_prereq_failure=yes

home_settings.inventory_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the Oracle Inventory group (OINSTALL).

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Members of the Oracle Inventory group group are granted OINSTALL privileges to read and write to the Oracle Inventory group directory (oraInventory). Oracle software owners are members of this group. When oraInst.loc already exists on the system, the default value matches the specified operating system group that is already defined on the system. Otherwise, the default value is oinstall.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the OINSTALL group to be oracle-owners:

upg1.home_settings.inventory_group=oracle-owners

home_settings.inventory_location

(Optional for AutoUpgrade patching) Specifies the directory that should be used for the Oracle Database inventory (oraInventory) directory.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

The Oracle Inventory directory (oraInventory) maintains an inventory of all installed Oracle software on the system. When oraInst.loc already exists on the system, the default value for oraInventory matches the specified inventory_location directory already defined. Otherwise, there is no default value.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the Oracle Inventory to be in the path location /u02/app/oraInventory:

upg1.home_settings.inventory_location=/u02/app/oraInventory

home_settings.oracle_base

(Optional for AutoUpgrade patching) Specifies the directory that should be used for the Oracle base directory.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

For both a read-only ORACLE_HOME and a read/write ORACLE_HOME, the user-specific files, instance-specific files, and log files reside in a location known as the ORACLE_BASE_HOME. An Oracle base home directory by default has an Optimal Flexible Architecture (OFA) path, such as /u01/app/oracle/. If you prefer, you can change from the default Oracle base into some other path, such as an /opt path,

Examples

In this example, you specify the Oracle base home to be in the path location /opt/oracle/databases/:

upg1.home_settings.inventory_location=/opt/oracle/databases/

home_settings.osbackupdba_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the operating system OSBACKUPDBA backup and recovery system privileges group for an Oracle Database.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This option is used with AutoUpgrade patching when installing the target ORACLE_HOME to specify the OSBACKUPDBA system privileges group. The user running AutoUpgrade Patching must be a member of the specified group. By default, when a source ORACLE_HOME is defined in the configuration file, the default value matches the OSBACKUPDBA group used for that ORACLE_HOME. Otherwise, the default group uses the group that is specified for home_settings.osdba_group. You can override those defaults by specifying a named OSBACKUPDBA group.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the OSBACKUPDBA group to be oracle_backup:

upg1.home_settings.osbackupdba_group=oracle_backup

home_settings.dba_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the operating system DBA system privileges group (OSDBA) management for the database.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This option is used with AutoUpgrade patching when installing the target ORACLE_HOME to specify the OSDBA system privileges group. Members of this group are granted the SYSDBA system privileges to administer the database. The user running AutoUpgrade Patching must be a member of the specified group. By default, when a source ORACLE_HOME is defined in the configuration file, the default value matches the OSDBA system privileges group used for that ORACLE_HOME. If the source_home is not defined, then the default for this parameter then becomes dba.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the OSDBA group to be inv_dba:

upg1.home_settings.osdba_group=inv_dba

home_settings.osdgdba_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the operating system OSDGDBA system privileges to administer and monitor Oracle Data Guard.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This option is used with AutoUpgrade patching when installing the target ORACLE_HOME to specify the OSDGDBA system privileges group. The user running AutoUpgrade Patching must be a member of the specified group. By default, when a source ORACLE_HOME is defined in the configuration file, the default value matches the OSDGDBA system privileges group used for that ORACLE_HOME. Otherwise, the default group uses the group that is specified for home_settings.osdba_group. You can override those defaults by specifying a named OSDGDBA group.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the OSDGDBA group to be oracle_dg:

upg1.home_settings.osdgdba_group=oracle_dg

home_settings.oskmdba_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the operating system SYSKM system privileges for encryption key management for applications such as Oracle Wallet Manager.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This option is used with AutoUpgrade patching when installing the target ORACLE_HOME to specify the SYSKM system privileges group. The user running AutoUpgrade Patching must be a member of the specified group. By default, when a source ORACLE_HOME is defined in the configuration file, the default value matches the SYSKM system privileges used for that ORACLE_HOME. Otherwise, the default group uses the group that is specified for home_settings.osdba_group. You can override those defaults by specifying a named SYSKM group.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the SYSKM group to be oracle_keystore:

upg1.home_settings.osdgdba_group=oracle_keystore

home_settings.oper_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the operating system operator (OSOPER) system privileges group.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This option is used with AutoUpgrade patching when installing the target ORACLE_HOME to specify the OSOPER system privileges group. Members of this group are granted the OPERATOR system privileges to start up and shut down the database. The user running AutoUpgrade Patching must be a member of the specified group. By default, when a source ORACLE_HOME is defined in the configuration file, the default value matches the OSOPER system privileges group used for that ORACLE_HOME. Otherwise, the default group uses the group that is specified for home_settings.osdba_group. You can override those defaults by specifying a named OSOPER group.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the OSOPER group to be inv_oper:

upg1.home_settings.osdba_group=inv_oper

home_settings.osracdba_group

(Optional for AutoUpgrade patching) Specifies the group that is designated as the operating system SYSRAC privileges to perform day to day administration of Oracle Database on an Oracle RAC cluster.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

This option is used with AutoUpgrade patching when installing the target ORACLE_HOME to specify the operating system RACDBA system privileges group. The user running AutoUpgrade Patching must be a member of the specified group. By default, when a source ORACLE_HOME is defined in the configuration file, the default value matches the RACDBA system privileges used for that ORACLE_HOME. Otherwise, the default group uses the group that is specified for home_settings.osdba_group. You can override those defaults by specifying a named RACDBA group.

Note:

This option is not available on Microsoft Windows platforms.

Examples

In this example, you specify the RACDBAgroup to be oracle_rac:

upg1.home_settings.osdgdba_group=oracle_rac

home_settings.read_only

(Optional for AutoUpgrade patching) Specifies whether a Read-Only Oracle home should be enabled when creating the target ORACLE_HOME.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

A read-only Oracle home can simplify provisioning. In a read-only Oracle home, all the configuration data and log files reside outside of the read-only Oracle home. See your platform installation guide for more information about read-only Oracle homes.

When a source ORACLE_HOME is defined in the configuration file, the default value matches the setting used for that ORACLE_HOME. Otherwise, the default for a read-only Oracle home is no. To provision a read-only Oracle home for the target Oracle home, you can use this option to select a read-only Oracle home by specifying this option with yes.

Options

[yes|no]

The default is no.

Examples

In this example, you specify that the target Oracle home should be a read-only Oracle home:

upg1.home_settings.read_only=yes

home_settings.ru_apply

(Optional for AutoUpgrade patching) Specifies whether a release update (RU) is installed at the same time as the ORACLE_HOME, or installed as a separate step by OPatch.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

When the parameter is specified to YES on a platform other than Microsoft Windows, the RU being installed during a deploy operation is installed when runInstaller is run using the -applyRU command line option. When the parameter is specified to NO, the RU is then installed separately by running OPatch after the ORACLE_HOME has already been installed.

Note:

This option is not available on Microsoft Windows platforms.

Options

[yes|no}

The default value is no, unless the current operating system is Oracle Linux 9 or higher.

Examples

In this example, the parameter is specified to no, indicating that you plan to run OPatch after the Oracle home is installed.

upg1.home_settings.ru_apply=no

method

(Optional for AutoUpgrade patching) Specifies whether to create a new target Oracle home, and if so, how it will be created.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

The default value is outofplace. At the time of this release, outofplace is the only permitted value. When the AutoUpgrade command-line parameter -patch is used, AutoUpgrade creates a new target Oracle home using the base image contained in the directory specified by the folder parameter. Oracle recommends that all patching is performed as out-of-place patching, where a new Oracle home is created.

Examples

upg1.method=outofplace

patch

(Required for AutoUpgrade patching) Specifies a comma-delimited list of the patches that you want to install.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

Options

[recommended|ru|ru:x.y|ocw|opatch|ojvm|ojvm:x.y|dpbp|patch-number]

The default value is RECOMMENDED.

Options:

  • RECOMMENDED: Alias for all of the following options: RU, OPATCH, OJVM, DPBP.

  • RU: Latest release update

  • RU:x.y: A release update (RU) of the specified release version, where x is the major release number, and y is the RU. For example: RU:19.24

  • OCW: Apply the Oracle Clusterware patch that applies to the specified RU.
  • OPATCH: Use latest version of OPatch

  • OJVM: Apply the Oracle Java VM patch that applies to the specified RU.

  • OJVM:x.y: Apply the Oracle Java VM patch of the specified release version, where x is the major release number, and y is the RU. For example: OJVM:19.24

  • DPBP: Apply the Oracle Data Pump patch for the specified RU

  • patch-number[,patch-number,patch-number...] specifies one or more specific one-off patches that you want AutoUpgrade to apply, in order of priority.

Examples

patch-number: Provide a specific one-off patch number.

upg1.patch=ru:19.24,12345678,opatch

Apply recommended patches, which includes the set of recommended patch options: RU (the latest release update for the base image), as well as OPATCH, OJVM, and DPBP:

upg1.patch=recommended

patch_node

(Optional) For AutoUpgrade patching, specifies the node on which the current user configuration is valid. The default value is localhost.

Usage Notes

Note:

For use with AutoUpgrade patching only.

The purpose of this parameter is to prevent AutoUpgrade patching from processing databases that are listed in the configuration file that you use with AutoUpgrade, where the value for the patch_node parameter does not correspond to the current host name. It does not enable running AutoUpgrade patching remotely. You can use the keyword localhost as a wild card to indicate that databases on the local host should be processed.

Use case:

The configuration file config.cfg contains 10 databases. Five of the databases have the value of patch_node set to denver01. The remaining five have the value of patch_node set to denver02. If AutoUpgrade is run on the server denver01 using the configuration file config.cfg, then AutoUpgrade only processes the databases for patching where patch_node is set to denver01. It ignores the databases where patch_node is set to denver02. The utility hostname identifies the value used to resolve the upgrade node.

Example

hostname
denver02
sales1.patch_node=denver01

platform

(Optional for AutoUpgrade patching) Specifies the platform used by AutoUpgrade Patching when downloading patches from My Oracle Support.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

The parameter platform specifies which platform patches AutoUpgrade uses for patching. AutoUpgrade Patching supports the following platforrms:

  • AIX.x64 IBM AIX on POWER Systems (64-Bit)
  • ARM.x64 LINUX ARM (aarch64)
  • LINUX.X64 Linux x86-64
  • SPARC.x64 Oracle Solaris on SPARC (64-Bit)
  • SOLARIS.x64 Oracle Solaris on x86-64 (64-Bit)
  • WINDOWS.X64 Microsoft Windows x64 (64-bit).

If the current operating system is one of the supported platforms, then the default value matches that platform. Otherwise, the default value is LINUX.X64

Options

[AIX.x64|ARM.x64|LINUX.X64|SPARC.x64|SOLARIS.x64|WINDOWS.X64]

The default value is LINUX.X64.

Example

upg1.platform=LINUX.X64

revert_after_action.create_home

(Optional for AutoUpgrade patching) In create_home mode, specifies a custom action that you want to have run on the operating system after a system restoration is completed for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

For patching operations, the local revert_after_action.create_home reverts a before_action.create_home option for a new Oracle home for the patched database after the restoration process is completed, and the database is up. This option uses the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. You must specify the new Oracle home path.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Syntax

prefix.revert_after_action.create_home=/my/new/oracle/home/

Examples

Run the specified script after AutoUpgrade starts processing create_home mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.revert_after_action.create_home=/user/path/script.sh Y 

Run the specified script before AutoUpgrade starts processing create_home mode, with AutoUpgrade set to continue to run if the script fails:

sales4.revert_after_action.create_home=/user/path/script.sh 

revert_after_action.deploy

(Optional for AutoUpgrade patching) In deploy mode, specifies a custom action that you want to have run on the operating system after a system restoration is completed for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

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)
  • Oracle SQL file (.sql), with a local operation only designated by the prefix.

Note:

The revert_after_action.deploy parameter for AutoUpgrade patching and the local parameter revert_action parameter cannot be specified in the same configuration file.

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.

For patching operations, the local revert_after_action.deploy parameter can specify a SQL script, which then runs on the database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. If you want to run additional container-specific actions, then they must be set within the code. For more complex scenarios, you can run container-specific actions in a shell.

The output of the script is captured and stored in files. Both stdout and stderr are captured. The files are stored in the preupgrade subdirectory in the directory matching the specific database or job.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Examples

Run the specified script after AutoUpgrade completes processing deploy mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.revert_after_action.deploy=/user/path/script.sh Y 

Run the specified script after AutoUpgrade completes processing deploy mode, with AutoUpgrade set to continue to run if the script fails:

sales4.revert_after_action.deploy=/user/path/script.sh 

revert_before_action.create_home

(Optional for AutoUpgrade patching) In create_home mode, specifies a custom action that you want to have run on the operating system after a system restoration is completed for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

For patching operations, the local revert_before_action.create_home can start a script to revert an action before creating an Oracle home for the patched database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. You must specify the new Oracle home path.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Syntax

prefix.revert_before_action.create_home=/my/new/oracle/home/

Examples

Run the specified script to revert an action before AutoUpgrade starts processing create_home mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.revert_before_action.create_home=/user/path/script.sh Y 

Run the specified script to revert an action before AutoUpgrade starts processing create_home mode, with AutoUpgrade set to continue to run if the script fails:

sales4.revert_before_action.create_home=/user/path/script.sh 

revert_before_action.deploy

(Optional for AutoUpgrade patching). In deploy mode, specifies a custom script to revert an action before starting the upgrade job for the specific database job addressed by the prefix.

Usage Notes

Note:

For use with AutoUpgrade patching only. Patching and upgrade operations are mutually incompatible. You can either perform a patching operation, or an upgrade operation, but not both in the same entry in the configuration file.

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)
  • Oracle SQL file (.sql), with a local operation only designated by the prefix.

Note:

The revert_before_action.deploy parameter for AutoUpgrade patching and the local parameter before_action parameter cannot be specified in the same configuration file.

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.

For patching operations, the local revert_before_action.deploy parameter can specify a SQL script, which then runs on the database using the target Oracle Database binaries on a non-CDB Oracle home, or on CDB$ROOT. If you want to run additional container-specific actions, then they must be set within the code. For more complex scenarios, you can run container-specific actions in a shell.

The output of the script is captured and stored in files. Both stdout and stderr are captured. The files are stored in the preupgrade subdirectory in the directory matching the specific database or job.

The following environment variables are set in the shell that runs the script:

  • ORACLE_SID
  • ORACLE_UNQNAME
  • ORACLE_BASE
  • ORACLE_HOME
  • TNS_ADMIN

Examples

Run the specified script to revert an action before AutoUpgrade starts processing deploy mode, with the Y flag set to stop AutoUpgrade if the script fails:

sales.revert_before_action.deploy=/user/path/script.sh Y 

Run the specified script to revert an action before AutoUpgrade starts processing deploy mode, with AutoUpgrade set to continue to run if the script fails:

sales4.revert_before_action.deploy=/user/path/script.sh 

target_version

(Optional for AutoUpgrade patching) Specifies the target release version on which you want AutoUpgrade to perform the patch maintenance operation.

Usage Notes

The purpose of this parameter is to ensure that the proper set of patches are downloaded or installed into the target Oracle home that is being created. For AutoUpgrade patching, the local parameter target_version is only required if both of the following conditions are true:

  1. The source_home parameter is not specified in the configuration file
  2. The patch parameter does not use RU:x.y notation

If these conditions do not apply, then AutoUpgrade can derive the target release value. The allowed value is a single major release number. At the time of this release, the only valid value is for Oracle Database 19c (19).

Valid value:

19

Example

sales1.target_version=19

Global Patch Parameters for the AutoUpgrade Config File

The patch global parameters for the AutoUpgrade configuration file (config) enable you to set a global parameter for software maintenance (-patch).

patch_json

(Optional for AutoUpgrade patching) Generates the patch.json file.

Usage Notes

The patch.json generated 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.

Options

[yes | no]

The default value is no.

Example

global.patch_json=yes