Upgrade Parameters for the AutoUpgrade Configuration File

The upgrade parameters for the AutoUpgrade configuration file (config) are used only with upgrade operations.

Locally Modifiable Global Upgrade Parameters for the AutoUpgrade Configuration File

The Upgrade 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.

catctl_options

(Optional for AutoUpgrade upgrades) 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.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Available catctl.pl options:

  • -n Number of processes to use for parallel operations. For Replay upgrades, the number of parallel processes used for the upgrade defaults to the value of (CPU_COUNT divided by 4) . For Classic upgrades, the default for CDB$ROOT and NON-CDB databases is 8.
  • -N Number of processors to use when upgrading PDBs. For Replay upgrades, the number of parallel processes used for the upgrade defaults to the value of (CPU_COUNT divided by 4) For Classic upgrades, the default is 2
  • -T Takes offline user schema-based table spaces.
  • -z Turns on production debugging information for catcon.pl.

Examples

sales4.catctl_options=-n 24 -N 4

defer_standby_log_shipping

(Optional for AutoUpgrade upgrades) Defers shipping logs from the primary database to any standby database. All log archive destionations (log_archive_dest_n) are set to deferred.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

By default, log shipping occurs as part of the upgrade. When Autoupgrade defers log shipping, you receive a notice that log shipping is deferred, and that after the upgrade completes successfully, you need to reenable shipping logs from the primary database to the secondary database.

Note:

This configuration file parameter affects not only standby databases, but all products or services that receive redo from the primary database, such as Oracle Zero Data Loss Recovery Appliance (ZDLRA) real-time log transport, and Oracle GoldenGate downstream capture.

Options

[yes | no]

The default value is no

The default is no (log-shipping is not deferred). If you change the default to Yes, then log shipping is deferred, and you must choose to re-enable it manually after upgrade.

Example

defer_standby_log_shipping=yes

drop_grp_after_upgrade

(Optional for AutoUpgrade upgrades) Deletes the Guaranteed Restore Point (GRP) after database upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 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
sales.drop_grp_after_upgrade=yes

enable_local_undo

(Optional for AutoUpgrade upgrades) For a CDB upgrade, specifies whether or not LOCAL undo should be enabled before the upgrade of CDB$ROOT.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 option, then AutoUpgrade runs the following statement before upgrade: ALTER DATABASE LOCAL UNDO ON;.

When local undo is first enabled, the size of the undo tablespace in PDB$SEED is determined as a factor of the size of the undo tablespace in CDB$ROOT. The default is 30 percent of the undo tablespace size. Every other PDB in the CDB inherits this property from PDB$SEED. Ensure that there is enough space to allocate new UNDO tablespaces.

Options

[yes | no]

The default value is no.

Example

enable_local_undo=yes

export_rman_backup_for_noncdb_to_pdb

(Optional for AutoUpgrade upgrades) Specifies that AutoUpgrade transports metadata from the source non-CDB database to the target PDB database as part of the conversion process.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 converting a non-CDB to a PDB, you can extract the RMAN metadata from the source database, and put it into the target database, so that the metadata it will be available after the PDB conversion. Using this parameter enables the backups to be used as "pre-plugin" backups. If you want to restore the PDB right after plug-in, then the pre-plugin backups option can help to save time and effort.

This parameter applies to non-CDB to PDB conversions only (not with refreshable clone PDBs). In all other cases, the parameter should be ignored.

Options

[yes | no]

The default value is no.

Example

sales.export_rman_backup_for_noncdb_to_pdb=yes

manage_network_files

(Optional for AutoUpgrade upgrades) Specifies whether network files are processed during the upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 option, then AutoUpgrade processes network files, depending on the option that you specify.

The following network files are processed: oranfstab, ldap.ora, tnsnames.ora, sqlnet.ora, and listener.ora

Options

[FULL|SKIP|IGNORE_READ_ONLY]

  • FULL: (default) Raise all exceptions encountered during the copy and merge of network files into the target Oracle home.
  • SKIP: Do not process network files during postupgrade.
  • IGNORE_READ_ONLY: Attempt to copy and merge network files, but do not raise an exception during the upgrade if the target file is read only

Example

manage_network_files=ignore_read_only

patch_in_upgrade_mode

(Optional for AutoUpgrade upgrades only) Specifies that the database that you want to patch is patched in upgrade mode, instead of normal mode.

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 AutoUpgrade 23.4 and earlier versions, the default for patching has been to perform patching in upgrade mode. Starting with AutoUpgrade 24.1, the default is to perform patching in normal mode. If you prefer to perform patching only in upgrade mode, then you can use this parameter to override that default behavior, and patch in upgrade mode.

Options

[yes | no]

The default value is no.

Example

sales.patch_in_upgrade_mode=yes

raise_compatible

(Optional for AutoUpgrade upgrades) Increases the Oracle Database COMPATIBLE initialization parameter to the default value of the target release after the upgrade is completed successfully.

Usage Notes

Options:

  • Y : Increase the COMPATIBLE parameter setting to the target release
  • N : Do not increase the COMPATIBLE parameter setting to the target release
  • Increase the COMPATIBLE level to a specific release update (RU) level (for example, 23.0, 23.4, 23.7)

The default is N.

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 specify to raise COMPATIBLE to a target RU level, then the the RU level you specify cannot be greater than the target Oracle home release. For example, if the target Oracle home release is Oracle Database 23ai updated to RU 23.4, then 23.7 is not a valid value for raise_compatible.

Examples

Raise COMPATIBLE to the level of the target Oracle Database home:

sales1.raise_compatible=yes

Raise COMPATIBLE to RU 23.4:

sales1.raise_compatible=23.4

Raise COMPATIBLE to RU 23.7:

sales1.raise_compatible=23.7

remove_underscore_parameters

(Optional for AutoUpgrade upgrades) Removes underscore (hidden) parameters from PFILE files during upgrade, and after upgrade, for all Oracle Databases in the configuration file.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Underscore parameters should only be used by advice of Oracle Support.

Options

[yes | no]

The default value is no.

Example

sales1.remove_underscore_parameters=yes

replay

(Optional for AutoUpgrade upgrades) Specifies whether to use Replay or to use a Classic upgrade to upgrade the database.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

By default, AutoUpgrade performs a Classic upgrade to upgrade the database.

Options

[yes | no]

The default value is no.

Note:

In addition to setting the replay parameter value to yes, both the PDBs that you want to upgrade with Replay Upgrade and CDB$ROOT must have sys.database_properties.pdb_upgrade_sync set to 1 (the default value).

If a container's sys.database_properties.pdb_upgrade_sync is not already set to the default value of 1, then log on to that container and run the following SQL command:

ALTER PLUGGABLE DATABASE UPGRADE SYNC ON

Example

upg1.replay=yes

target_base

(Optional for AutoUpgrade upgrades) Specifies the target ORACLE_BASE path for the target Oracle home.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Example

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

target_version

(Required for AutoUpgrade upgrades if target Oracle home is not on the system, or is release 12.2) Specifies the target release version on which you want AutoUpgrade to perform the upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

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.

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.

Options

Valid values

  • 12.2
  • 18
  • 19
  • 21
  • 23

Example

global.target_version=23
employees.target_version=19

Local Upgrade Parameters for the AutoUpgrade Config File

The upgrade local parameters enable you to configure AutoUpgrade processing in the configuration file (config) for specific Oracle Databases for upgrades (upgrade).

add_after_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to add after the upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

You can use the prefix to specify for which upgrade group you want to apply the PFILE parameters.

In addition, within the PFILE that you specify with add_after_upgrade_pfile, you can specify particular parameters for a specific named PDB. To specify parameters for a specific PDB, you must enter the PDB-specific parameters using a comment line (#) in the PFILE. This requirement is necessary so that AutoUpgrade can identify the parameters from the PFILE, but the line otherwise ignored; for the database, PFILEs cannot contain PDB-specific parameter values. For plug-in operations, use the original PDB or non-CDB name.

For specifying loading PFILE parameters for a named PDF, the following requirements apply to the PFILE parameters:

  • The ispdb_modifiable column in V$SYSTEM_PARAMETER must be set to TRUE. If this value is not set to TRUE, then the AutoUpgrade operation will fail.
  • If the issys_modifiable column in V$SYSTEM_PARAMETER is set to FALSE, then you must restart the system so that the changes will be reflected in the PFILE. . Otherwise, changes can be seen after the upgrade is complete.

Syntax

upgrade-batch].add_after_upgrade_pfile=value

In a pfile, add a comment line specifying the PDB name and parameter, where the PDB name is enclosed within brackets, and add the parameter name using the normal syntax for a parameter in a PFILE:

[pdb-name].parameter-name=parameter-value

Examples

Use add_after_upgrade_pfile to specify the path to a PFILE whose parameters you want to add after the upgrade:
sales3.add_after_upgrade_pfile=/path/to/my/pfile

To specify a particular parameter for a PDB, you first create your PFILE, and then edit the PFILE to specify the PDB-specific parameters using comment lines. For example, suppose you have a PDB named pdb10, and you want to specify the log archive destination LOG_ARCHIVE_DEST_4='LOCATION=/u02/oracle/oradata/payroll/' for pdb10, using the PFILE sales3_params.ora as the basis for the parameters you want to apply. The procedure then is as follows:

  1. Create a PFILE called pfile_add.ora with the initialization parameters you want to add after upgrades with AutoUpgrade:

    CREATE PFILE = 'pfile_add.ora' FROM SPFILE = 'sales3_params.ora';
  2. Open pfile_add_ora with a text editor such as vi, and add the line to specify the log location as a comment line specified with the prefix # [pdb10], so that AutoUpgrade identifies this as a parameter to add to the PFILE for pdb10:

    *.local_listener='LISTENER_sales3'
    *.nls_language='AMERICAN'
    *.nls_territory='AMERICA'
    *.sga_target=10641m
    *.undo_tablespace='UNDOTBS1'
    # [pdb10].LOG_ARCHIVE_DEST_4='LOCATION=/u02/oracle/oradata/payroll/'
  3. Save pfile_add_ora in the location /u02/app/oracle/dbs.

  4. Open your configuration file and add the line ad_after_upgrade_pfile to specify the location of pfile_add_ora:

    sales3.add_after_upgrade_pfile=/u02/app/oracle/dbs/pfile_add.ora
  5. Run AutoUpgrade.

  6. After the upgrade is complete, the PFILE parameters from pfile_add.ora are applied to the PDBs that are upgraded. In addition, for pdb10, this parameter is added to its PFILE: LOG_ARCHIVE_DEST_4=LOCATION=/u02/oracle/oradata/payroll/

  7. Shut down pdb10 and start it up again with the new PFILE parameter additions:

    startup PFILE=$ORACLE_HOME/dbs/pdb10.ora

add_during_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to add during the upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Examples

sales3.add_during_upgrade_pfile=/path/to/my/newpfile.ora

close_source

(Optional for AutoUpgrade upgrades) Closes the source non-CDB or source PDB just before AutoUpgrade starts a non-CDB to PDB conversion, starts an unplug-relocate upgrade, or uses a refreshable clone PDB.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

During the operations described above, if close_source is set to yes (the default), then AutoUpgrade closes source non-CDB or source PDB just before starting the upgrade. Additionally, if Oracle Real Application Clusters or Oracle Grid Infrastructure (CRS) services are configured for a non-CDB source, then they are disabled before starting the upgrade.

This parameter can only be used when the source and target databases are both on the same system. When they are on different systems, the source non-CDB or PDB cannot be closed, because AutoUpgrade has no access to it.

Options

[yes | no]

The default value is yes.

Examples

sales3.close_source=yes

del_after_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to have removed after upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Examples

sales3.del_after_upgrade_pfile=/path/to/my/pfile_del.ora

del_during_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to have removed during upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Examples

sales3.del_during_upgrade_pfile=/path/to/my/oldpfile.ora

drop_db_link

(Optional for AutoUpgrade upgrades) Specifies that the database link set up for an unplug-plug relocate (hot clone) upgrade is dropped after successful job completion.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

After an unplug-plug relocate (hot clone) job using a database link specified by the parameter source_dblink, the drop_db_link parameter specifies to drop the link after the successful completion of that job. This parameter applies only to jobs that are using the source_dblink parameter. Any error encountered during drop of the database link does not result in overall job error, but is noted in the AutoUpgrade log files only.

Note:

This option is available for source database releases Oracle Database 12.1.0.2 and later.

Example

In the following example, after using a link set up with source_dblink, the drop_db_link specifies that the database link is dropped after successful completion.
upg1.drop_db_link

drop_win_src_service

(Optional for upgrades only) For upgrades on Microsoft Windows, specifies whether to drop the Windows operating system service for the source Oracle Database after upgrade.

Usage Notes

By default, for Oracle Database upgrades on Microsoft Windows operating systems, after AutoUpgrade shuts down the Windows Oracle Database service and completes the upgrade, it leaves the service in place. Leaving the service down but in place gives you the option to restore the database to the source Oracle home without having to recreate the Microsoft Windows service for the database. However, you can choose to have the Microsoft Windows service for the source database removed automatically after upgrade is completed successfully. If either no is specified, or no value is is specified, then the service is shut down on the source, but left in place after the upgrade.

Options

[yes | no]

The default value is no.

Examples

upg1.drop_win_src_service=yes 

exclusion_list

(Optional for AutoUpgrade upgrades) Sets a list of PDBs that you want to be excluded from the AutoUpgrade run. This parameter only applies to the multitenant architecture (CDB) databases. If you are plugging in and upgrading a non-CDB database, then this parameter is ignored.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Use this parameter to provide a list of PDBs to exclude from the AutoUpgrade run. The PDB list is comma-delimited. It can contain either a list of PDB names, or an asterisk character (*), which indicates that you want ot exclude all PDBs that are open on the CDB at the time that you run AutoUpgrade.

Syntax:

prefix.exclusion_list=[pdb-name|*][,pdb-name,...]

Examples

Assume that you want to exclude PDBs pdb1 and pdb2 from the upgrade of cdb sales1. The following entry in the configuration file excludes pdb1 and pdb2 from being processed during the AutoUpgrade run:

sales1.exclusion_list=pdb1,pdb2

This entry in the configuration file excludes all open PDBs from the CDB sales2:

sales2.exclusion_list=*

ignore_errors

(Optional for AutoUpgrade upgrades) Enables you to specify a comma-delimited list of specific Oracle errors that you want AutoUpgrade to ignore during the upgrade or patching process.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 add this parameter to your configuration file, then the error numbers that you specify are ignored during the upgrade for the upgrade prefix that you specify.

Examples

sales3.ignore_errors=ORA-48181,ORA-00001

keep_pdb_save_state

(Optional for AutoUpgrade upgrades) Specifies that if the PDB has a saved state in the source CDB, then you can either save or not save the PDB state on the target CDB.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 parameter applies to the Unplug-Plug flow (including restorations). If the PDB state is saved in the source CDB, then by default that same saved state continues to be saved after the upgrade process (default is yes). When keep_pdb_save_state is set to no, the source PDB state is not saved after the upgrade. You can choose to set keep_pdb_save_state to no when you are advised to do so in AutoUpgrade preupgrade checks. For example, with Oracle Real Application Clusters (Oracle RAC) upgrades, Oracle recommends that you do not keep the source PDB saved state.

Options

[yes | no]

The default value is yes.

Example

sales1.keep_pdb_save_state.pdbA=no

keep_source_pdb

(Optional for AutoUpgrade upgrades) Specifies if the source PDB in an unplug-plug upgrade operation is kept in a closed state instead of being removed from the source CDB.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

By default, the source PDB is removed from the source CDB during the upgrade process. When keep_source_pdb is set to YES, the source PDB is not removed from the earlier release system. You are only able to set the parameter to YES when the copy option is specified in the parameter target_pdb_copy_option. When the copy option is not used, this parameter is ignored, because the PDB must be dropped. Without a copy, the existing datafiles can only be used by a single CDB.

Options

[yes | no]

The default value is no.

Example

sales1.keep_source_pdb=yes

manage_standbys_clause

(Optional for AutoUpgrade upgrades) Specifies whether standby Oracle Data Guard standby databases you identify by DB_UNIQUE_NAME are excluded from AutoUpgrade plug-in upgrades, so that standby database files can be reused.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Before upgrades of database configurations with standby databases, to reduce potential issues, Oracle recommends that you run AutoUpgrade in analyze mode on your standby databases.

Options

In the following syntax, pdb-name is a DB_UNIQUE_NAME of a source PDB that you are upgrading to the target CDB in an unplug/plug upgrade.

manage_standbys_clause=STANDBYS=[NONE|ALL|ALL EXCEPT ('pdb-name', 'pdb-name', ...)|STANDBYS=('pdb-name', 'pdb-name', ...)]

The default value is NONE.

Examples

In the following example, any non-CDB or pluggable database that is a member of an Oracle Data Guard standby is not excluded from AutoUpgrade plug-in upgrades:

upg2.sid=cdb1 
upg2.pdbs=* 
upg2.target_cdb=cdb21x 
upg2.source_home=/source/18x 
upg2.target_home=/target/21x
upg2.manage_standbys_clause=standbys=none

In the following example, applying the redo on data files on all standby databases is deferred on all AutoUpgrade plug-in upgrades:


upg3.sid=cdb2 
upg3.pdbs=* 
upg3.target_cdb=cdb21x 
upg3.source_home=/source/18x 
upg3.target_home=/target/21x
upg3.manage_standbys_clause=standbys=all

In the following example, during the AutoUpgrade plug-in upgrades, applying the redo on data files is deferred on all standby PDBs except PDBs cdb3_stby_1 and cdb3_stby_2.


upg4.sid=cdb3 
upg4.pdbs=* 
upg4.target_cdb=cdb21x 
upg4.source_home=/source/12.2x 
upg4.target_home=/target/21x
upg4.manage_standbys_clause=standbys=all except ('cdb3_stby_1','cdb3_stby_2')

In the following example, during the AutoUpgrade plug-in upgrades, applying the redo on data files is deferred only on standby PDB cdb4_stby1.


upg4.sid=cdb4 
upg4.pdbs=* 
upg4.target_cdb=cdb21x 
upg4.source_home=/source/12.2x 
upg4.target_home=/target/21x
upg4.manage_standbys_clause=standbys=('cdb4_stby_1')

parallel_pdb_creation_clause

(Optional for AutoUpgrade upgrades) Specifies the number of parallel execution servers to use when creating a pluggable database. This can be used for scenarios like PDB relocate, clone PDB, etc. It doesn't apply for cases when creating a PDB using an XML file.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 parameter is optional. You can use this parameter to specify the number of parallel execution servers to copy the new PDB's data files to a new location when creating a PDB. This may result in faster creation of the PDB. Scenarios where you can take advantage of this option is when you want to upgrade and convert a non-CDB Oracle Database to a PDB, or you want to unplug a PDB from a source release CDB and relocate it in for an upgrade to a target release CDB.

The parameter is specific for every source database or pluggable database on the AutoUpgrade configuration file. The CDB can ignore this setting, depending on the current database load and the number of available parallel execution servers. Using this parameter enables you to provide better control of the load placed on the target database.

Note:

Note: This feature does not work during unplug/plug processes.

Options

Use an integer value to specify the number of servers to run in parallel, where source-db-name-or-pdb is the non-CDB database name or the PDB name, and integer-value is a numeric value specifying the number of servers to run in parallel::

prefix.parallel_pdb_creation_clause.source-db-name-or-pdb='integer-value'

Example

In the following example, 16 servers are specified as the limit for the number of servers to run in parallel.

upg1.parallel_pdb_creation_clause.pdb1=16

pdbs

(Optional for AutoUpgrade upgrades) Sets a list of PDBs on which you want the upgrade to run. This parameter only applies to upgrades of multitenant architecture (CDB) databases. If you are plugging in and upgrading a non-CDB database, then this parameter is ignored.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 PDB list is comma-deliminated. The list can contain either PDB names, or a star character (*), which indicates that you want to upgrade all PDBs that are open on the CDB at the time that you run AutoUpgrade. If the parameter is not specified, then the default value is *.

If running in ANALYZE mode, AutoUpgrade ignores the PDBs in a mounted state.

If running in FIXUPS, DEPLOY or UPGRADE mode, AutoUpgrade opens the PDBs in mount state in read-write mode, upgrade mode, or both, depending on the execution mode.

Example

sales1.pdbs=pdb1, pdb2, pdbn
   upgr1.pdbs=*

remove_rac_config

(Optional for AutoUpgrade upgrades) Specifies whether to remove a non-CDB Oracle RAC database from clusterware on the source Oracle home after a successful conversion to the target CDB home, or to leave the source database unchanged.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

By default, the source Oracle RAC database configuration on a non-CDB is removed from the source Oracle Grid Infrastructure when it is migrated to a CDB during the upgrade process. When remove_rac_config is set to no, the source Oracle RAC database is not removed from the earlier release non-CDB system.

Options

[yes | no]

The default value is yes.

Example

upg1.remove_rac_config=no

run_dictionary_health

(Optional for AutoUpgrade upgrades) Specifies whether you run Oracle Dictionary Health Checks as part of preupgrade checks to identify database dictionary inconsistencies.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

To help to identify database dictionary inconsistencies, you can specify that AutoUpgrade runs the DBMS_DICTIONARY_CHECK PL/SQL package on the source database as part of preupgrade checks. If set, the AutoUpgrade run_dictionary_health parameter enables you to specify for each upgrade source database that AutoUpgrade runs either the full array of Oracle Dictionary Health Checks on the database dictionary, or that it runs only the most critical set of checks. If the check detects potential or critical problems with the database dictionary, then it prevents the upgrade from starting.

Oracle Dictionary Health Check results are stored under the AutoUpgrade precheck directory in the format dbname_healthcheck_result.log, where dbname is the name of the database on which the check was run. For more information about Oracle Dictionary Health Check, refer to the DBMS_HCHECK package documentation in Oracle Database PL/SQL Packages and Types Reference.

Options

[full| critical]

If the parameter is not set, then the default is to not run DBMS_DICTIONARY_CHECK.

Example

sales1.run_dictionary_health=full
sales2.run_dictionary_health=critical

skip_tde_key_import

(Optional for AutoUpgrade upgrades) When set to yes, the upgrade is run, but import of the source database KeyStore into the target database is skipped, without raising an error.

Deprecated

Note:

This parameter is deprecated, because it is no longer needed. It can be removed in a future AutoUpgrade release. Instead of using this parameter, Oracle recommends that you either use the -load_password command line option to add the TDE password to AutoUpgrade's keystore, or add the TDE password to a Secure External Password Store (SEPS).

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

You can use this option for nonCDB-to-PDB and unplug/plug operations. When import of the source database KeyStore into the target database is skipped, AutoUpgrade will leave the PDB open in upgrade mode, so that you can import the keys manually yourself. After you import the keys, you must then restart the database in normal mode.

Options

[yes | no]

The default value is no.

Example

sales1.skip_tde_key_import=yes

source_dblink

(Optional for AutoUpgrade upgrades) Specifies the database link set up for an unplug-plug relocate (hot clone) upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

To set up an unplug-plug relocate upgrade for a non-CDB or a PDB, you must first set up a database link between the source database and the target database location. You then pass that database link to AutoUpgrade using the source_dblink parameter. You identify source database name associated with the database link as a suffix to source_dblink. parameter. You also have the option to specify a time value, in seconds, that the database is refreshed from the database link.

Note:

This option is available for source database releases Oracle Database 12.1.0.2 and later.

The source_dblink parameter becomes active when you use the target_pdb_copy_option parameter. When you use source_dblink, you must also must specify a value for the file_name_convert parameter, either to convert file names, or to specify not to convert file names. If file_name_convert is set to none, then you must also set db_create_file_dest to specify where you want to place the database files.

You can also choose to set a refresh interval, in seconds, specifying how frequently the target database is updated over the database link from the source database. You can use the refresh interval with the start_time parameter to keep the source database refreshed for the target location. If no refresh rate is specified, then the source database is cloned only one time, and no refresh occurs. If the refresh rate is specified, but you do not specify a future start time using the start_time parameter, then the refresh interval value is ignored, and the database is cloned only one time.

Options

  • (Required) The source database name, specified as a suffix.
  • (Required) The name of the database link that you created.
  • (Optional) The refresh rate for the target database from the source database, in seconds. If you specify a refresh rate, then typically you also specify a future start time using the start_time parameter.
  • (Optional) CLONE_ONLY. Adding this option specifies that the PDB that is created is a clone that is never refreshed, and that the upgrade is started immediately after the clone operation is completed. This option is required when the source is Oracle Database 12.1 (Release 12.1.0.2).

Examples

In the following example, two database links are created:
  • pdbxcdb18x_link, created on the PDB source database named pdbx:

    CREATE DATABASE LINK pdbxcdb18x_link CONNECT TO remote-user IDENTIFIED BY password  
    USING'(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST
    GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SELECT_CATALOG_ROLE TO remote-user;
    GRANT READ ON sys.enc$ TO remote-user;
  • db18x_link, created on the non-CDB source database named db18x:

    CREATE DATABASE LINK db18x_link CONNECT TO remote-user IDENTIFIED BY password 
    USING'(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = db-node1)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = db18x)))';

In the AutoUpgrade configuration file, the database name associated with the database link is specified by using that name as a suffix to source_dblink: The suffix: pdbx for the PDB source database, and the suffix db18x for the non-CDB source database.

In the following example, source_dblink is used to specify the dblink for the source database pdbx. The PDB upgrade deployment starts immediately after you start AutoUpgrade, because no time interval is specified:
upg1.source_dblink.pdbx=pdbxcdb18x

Using the same configuration file, AutoUpgrade starts the upgrade of the database named db18x in 1 hour and 40 minutes after AutoUpgrade is started from the command line. Between the time that AutoUpgrade is started, and the deployment time specified by start_time, the cloned target database is refreshed every 20 seconds from the source.

upg1.source_dblink.db18x=db18x_link 20 
upg1.start_time=+1h40m

In the following example, the source database db18x is cloned to the target PDB db18x_link, and the upgrade is started immediately after that source database is cloned successfully:

upg1.source_dblink.db18x=db18x_link CLONE_ONLY

target_cdb

(Required for non-CDB AutoUpgrade upgrades) Specifies the SID of the target CDB into which a non-CDB Oracle Database is plugged in.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 parameter is mandatory when you want to upgrade and convert a non-CDB Oracle Database. It is case-sensitive.

Example


emp.target_cdb=salescdb

target_is_remote

(Optional for AutoUpgrade upgrades) Specifies whether the target CDB is located on the same system as the cloned PDB.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 parameter applies to the Unplug-Plug flow when the target CDB is on a remote host. To avoid the time spent on unnecessary checks, Oracle recommends that you set target_is_remote to yes when the target CDB is on a remote system.

By default, when you do not set this parameter, or it is set to no, AutoUpgrade performs checks with the assumption that the target CDB is on the same system as the cloned PDB.

When target_is_remote is set to yes, AutoUpgrade skips the TDE_PASSWORDS_REQUIRED and TARGET_CDB_AVAILABILITY checks during the analyze phase. These two checks are not applicable when the target CDB is on a remote system.

Options

[yes | no]

The default value is no.

Example

In the following example, the target CDB upgrade identified with the prefix upg1 is on a remote host. To prevent running the the TDE_PASSWORDS_REQUIRED and TARGET_CDB_AVAILABILITY checks, you set the parameter to yes:
upg1.target_is_remote=yes

target_ldap_admin_dir

(Optional for AutoUpgrade upgrades) Specifies the path to the LDAP_ADMIN directory in the target database home.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Example

sales1.target_ldap_admin_dir=/u01/app/oracle/19/dbhome01/ldap/admin

target_pdb_copy_option

(Optional for AutoUpgrade upgrades) Specifies the file_name_convert option used by the create pluggable database statement that AutoUpgrade runs when converting a non-CDB database to a PDB or an existing PDB from a different source CDB into a PDB in the specified target CDB.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 only used when creating a pluggable database within the target CDB. If you do not specify this parameter, then the default value of the parameter is NOCOPY, and existing data files on the source database are reused. When you do specify this parameter, then you must append a suffix to the parameter that specifies either the source database name or PDB name (target_pdb_copy_option.suffix, and specify file_name_convert= with one of the following options:

  • Specify source file names (f) and target replacement file names (r) ('f', 'r'), or specify NONE
  • If you are creating a refreshable clone database, then append a suffix to the parameter that specifies either the source database name or PDB name (target_pdb_copy_option.suffix

Caution:

Specifying target_pdb_copy_option enables AutoUpgrade to manage the recovery as needed. When target_pdb_copy_option is not set, and the default nocopy option is used, there is no recovery of the default PDB. Ensure that you have a backup of your source PDB.

On the target CDB, if you are using ASM, or if you have the parameters DB_CREATE_FILE_DEST or PDB_FILE_NAME_CONVERT set, and you want these parameters on the target CDB to take effect for replacement file names, then set the value of prefix.target_pdb_copy_option.source-db-name-or-pdb=file_name_convert=NONE.

If you want one or more data file names changed during conversion on the target CDB, then enter values for the parameter to indicate the source database name or PDB, specified as a suffix, the source filename you want to change, and the target filename to which you want the existing files copied, using the syntax prefix.target_pdb_copy_option.source-db-name-or-pdb=('f1', 'r1', 'f2', 'r2', . . .), where f1 is the first filename pattern on your source, r1 is the first replacement filename pattern on your target CDB, f2 is the second filename pattern on your source, r2 is the second replacement file pattern on your target CDB, and so on.

Syntax

prefix.target_pdb_copy_option.source-db-name-or-pdb=file_name_convert=('f1', 'r1', 'f2', 'r2', 'f3', 'r3'...)

Example

In this example, AutoUpgrade will copy existing datafiles during conversion of a database specified with the prefix string upg1, and with the suffix sales to replace the file path string and filename /old/path/pdb_2 with the file path string and filename /new/path/depsales:

upg1.target_pdb_copy_option.sales=file_name_convert=('/old/path/pdb_2', '/new/path/depsales') 

To convert OMF files with target_pdb_copy_optionsource-db-name-or-pdb=file_name_convert, the target Oracle home must be Oracle Database 19c Release Update 6 or later (19.6.0), or Oracle Database 18c Release Update 10 or later (18.10.0).

In this example, the parameter is configured so that data files that are stored on Oracle ASM, but not stored as Oracle-managed files, are copied from +DATA/dbname/sales to +DATA/dbname/depsales:

upg1.target_pdb_copy_option.sales=file_name_convert=('+DATA/dbname/sales', '+DATA/dbname/depsales')

target_pdb_name

(Optional for AutoUpgrade upgrades) Specifies the name that you want to assign to a non-CDB source Oracle Database after it is plugged in to the target CDB.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 parameter is optional. It is used when you want to upgrade and convert a non-CDB Oracle Database to a PDB, or you want to unplug a PDB from a source release CDB and plug it in for an upgrade to a target release CDB.

When you upgrade and convert an existing non-CDB database to a PDB on a target CDB, the target_cdb parameter is mandatory, because it specifies the target CDB. If you want to determine how the PDB is created on the target CDB, you can use the optional parameters target_pdb_name and target_pdb_copy_option to specify how the PDB is created on the target CDB. However, if neither optional parameters are used, then a full upgrade of the source CDB is performed.

The default name for the target PDB when you convert a non-CDB to a PDB is to use the database unique name of the non-CDB Oracle Database. To specify a name that is different from the existing name of the non-CDB when you plug it in to the CDB, set the new name by using target_pdb_name. In addition, if you are creating a refreshable clone database, then append a suffix to the parameter that specifies either the source database name or PDB name (target_name.suffix)

Examples

In the following example, the source non-CDB database is emp19. The target_pdb_name parameter is used to change the name to emp23pdb on the target CDB database.
upg.target_pdb_name=emp23pdb

For a refreshable clone, add a prefix to indicate the source database for the clone. In this example, the source container database is db122b and we are cloning pdb1 from db122b into the target container database db19. The suffix pdb1 is used as the identifier for both target_pdb_name and source_dblink. The pdb1 suffix identifier associates both the target PDB name and the dblink used to move the data from the source, pdb1, into the target PDB PLUG122.

global.autoupg_log_dir=/tmp/logs
upg1.source_home=/u01/app/oracle/122
upg1.target_home=/u01/app/oracle/19
upg1.sid=db122b
upg1.target_cdb=db19
upg1.pdbs=pdb1
upg1.target_pdb_name.pdb1=PLUG122
upg1.target_pdb_copy_option.pdb1=file_name_convert=('/u01/app/oracle/oradata/db122b/pdb1', '/u01/app/oracle/plug/pdb122b')
upg1.source_dblink.pdb1=pdbxcdb122x_link

target_tns_admin_dir

(Optional for AutoUpgrade upgrades) Specifies the path to the TNS_ADMIN directory in the target database home.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Example

sales1.target_tns_admin_dir=/u01/app/oracle/19/dbhome01/network/admin

timezone_upg

(Optional for AutoUpgrade upgrades) Enables or disables running the time zone upgrade as part of the AutoUpgrade process.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

To preserve data integrity, Oracle recommends that you upgrade the time zone file (DST) settings at the time of your database upgrade. In particular, upgrade the timezone when you have data that depend on the time zone, such as timestamp with time zone table columns. Note that this setting can be disabled by overwriting the fixup on the checklist file.

If you explicitly disable the time zone file upgrade in your AutoUpgrade configuration file, then Oracle recommends that you perform this task either as part of your upgrade plan, or at a later point in time.

Options

[yes | no]

The default value is yes for upgrade, and no for patching.

Example

sales1.timezone_upg=no

Note:

If you patch a database with RU 19.18 or later, then updated time zone files are installed in the Oracle home by default. A new database created with Database Configuration Assistant (DBCA) in a patched Oracle home will be created with the latest time zone files.

tune_setting

(Optional for AutoUpgrade upgrades) Enables special workflows that alter the behavior of AutoUpgrade during runtime, depending on the workflow option that you specify.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 tune_setting parameter enables you to fine-tune upgrade steps or the resources allocated to the processing of the upgrades specified by the container databases or pluggable databases (CDBs or PDBs) specified by the parameter prefix in your AutoUpgrade configuration file. This capability can be useful for some upgrades if you find the default AutoUpgrade values are insufficient for your system requirements, or when you want to enable nondefault AutoUpgrade options.

Syntax

prefix.tune_setting=option[, option, option, ...]
Select the tune_setting options that provide the AutoUpgrade runtime tuning that you require from the list that follows. To combine multiple tuning options with the tune_setting parameter, use comma delimiters. Example:
sales3.tune_setting=proactive_fixups=true,query_hint_parallel=8,utlrp_threads_per_pdb=8

Note:

You can concatenate multiple parameters together in a single tune_setting entry
Option Description
active_nodes_limit

Sets a new total of active cluster member nodes that you want to use during a distributed upgrade of Oracle Real Application Clusters databases. The default is 2. If the number you specify is equal to or greater than the maximum number of cluster member nodes, then all nodes are taken.

sales3.tune_setting=active_nodes_limit=4

distributed_upgrade

Specifies that AutoUpgrade performs a distributed upgrade. A distributed upgrade leverages the resources of the Oracle Clusterware cluster member nodes to perform the upgrades of PDBs more rapidly on the cluster. Use this option when a CDB in an Oracle RAC cluster of at least two nodes is being upgraded. When you choose this option, the proactive_fixups option is also enabled by default. Example:

sales3.tune_setting=proactive_fixups=true,distributed_upgrade=true

Note: Distributed upgrades are not supported on Microsoft Windows.

make_pdbs_available

Opens the PDBs designated by the prefix in read/write and non-restricted mode after postfixups are complete when proactive fixups mode is used. This option enables PDBs designated by the prefix to become available for service immediately after the upgrade is completed, while other PDBs continue to be upgraded, which can be useful for large fleet upgrade deployments.

Precautions:

Choosing this option enables the PDBs you designate to accept service requests from users, while other PDBs are being upgraded. The response time of the PDBs for service requests, and the time required for ongoing PDB upgrades can each be affected.

Example:

sales3.tune_setting=make_pdbs_available=true

proactive_fixups

Enables proactive fixups mode, where the PDBs are upgraded as the last stage of the upgrade. When the number of PDBs is higher than the CPU count defined in the database, divided by 2, choosing this tuning option can result in a faster upgrade. Example:

sales3.tune_setting=proactive_fixups=true

Precautions:

If the number of CPUs is higher than the number of PDBs, then changing this setting may not improve performance.

Note:

Although the proactive_fixups configuration option by default is set to TRUE, proactive fixups is currently not supported on Windows.

Note: the proactive_fixups option is not currently supported for Application Containers or on Microsoft Windows systems

query_hint_parallel

Specifies a parallel thread specification to the code that gathers data from the tablespaces during the query of the PDBs specified by the prefix, so that you can allocate a greater number or lesser number of parallel threads to the PDBs specified by the prefix. Example:

sales3.tune_setting=query_hint_parallel=8

Choosing this option can cause AutoUpgrade to consume more system resources.

Option NO_HINT avoids the use of optimizer hints on the query that gathers information about database tablespaces. This option can be useful in environments where existing hints (materialize and parallel) affect the performance of the query. For example:

sales3.tune_setting=query_hint_parallel=NO_HINT

utlrp_pdb_in_parallel

Overwrites default maximum number of concurrent recompilation threads to the number that you specify. Use this option to overwrite the default maximum number of concurrent processes of recompilation of invalid objects. Example:

sales3.tune_setting=utlrp_pdb_in_parallel=2

Precautions:

Each PDB process requires from the system as many threads as specified by utlrp_threads_per_pdb.

utlrp_threads_per_pdb

Overwrites default maximum number of threads generated by the recompilation of invalid objects in the CDB, and uses the number of threads that you specify. Example:

sales3.tune_setting=utlrp_threads_per_pdb=8

Precautions:

If the number of threads specified exceeds available threads on the system, then performance can be compromised.

Examples

In the following example, the database upgrades specified with the prefix sales3 are Oracle Real Application Clusters Oracle Database instances. The tune_setting parameter is used to set these database instances to use the setting distributed_upgrade, which distributes the upgrade load across multiple CDBs in the Oracle Grid Infrastructure cluster:
sales3.tune_setting=distributed_upgrade=true
In the following example, the database upgrades specified with the prefix sales3 are tuned with multiple tune_setting parameter options:
sales3.tune_setting=proactive_fixups=true,query_hint_parallel=8,utlrp_threads_per_pdb=8

upgrade_node

(Optional for AutoUpgrade upgrades) Specifies the node on which the current user configuration is valid. The default value is localhost.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 purpose of this parameter is to prevent AutoUpgrade from processing databases that are listed in the configuration file that you use with AutoUpgrade, where the value for the upgrade_node parameter does not correspond to the current host name. It does not enable running AutoUpgrade 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 upgrade_node set to denver01. The remaining five have the value of upgrade_node set to denver02. If AutoUpgrade is run on the server denver01 using the configuration file config.cfg, then AutoUpgrade only processes the databases where upgrade_node is set to denver01. It ignores the databases where upgrade_node is set to denver02. The utility hostname identifies the value used to resolve the upgrade node.

Example

hostname
denver02
sales1.upgrade_node=denver01

Global Upgrade Parameters for the AutoUpgrade Config File

The upgrade global parameters for the AutoUpgrade configuration file (config) enable you to set a global parameter for upgrades (upgrade).

add_after_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to add after the PFILE is upgraded.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

You can use the prefix to specify for which upgrade group you want to apply the PFILE parameters.

In addition, within the PFILE that you specify with add_after_upgrade_pfile, you can specify particular parameters for a specific named PDB. To specify parameters for a specific PDB, you must enter the PDB-specific parameters using a comment line (#) in the PFILE. This requirement is necessary so that AutoUpgrade can identify the parameters from the PFILE, but the line otherwise ignored; for the database, PFILEs cannot contain PDB-specific parameter values. For plug-in operations, use the original PDB or non-CDB name.

For specifying loading PFILE parameters for a named PDF, the following requirements apply to the PFILE parameters:

  • The ispdb_modifiable column in V$SYSTEM_PARAMETER must be set to TRUE. If this value is not set to TRUE, then the AutoUpgrade operation will fail.
  • If the issys_modifiable column in V$SYSTEM_PARAMETER is set to FALSE, then you must restart the system so that the changes will be reflected in the PFILE. . Otherwise, changes can be seen after the upgrade is complete.

This specification applies to all databases in the user configuration file.

Syntax

add_after_upgrade_pfile=value

In a pfile, add a comment line specifying the PDB name and parameter, where the PDB name is enclosed within brackets, and add the parameter name using the normal syntax for a parameter in a PFILE:

global.add_after_upgrade_pfile=parameter-name=parameter-value

Example

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

add_during_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to add during the upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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.

Examples

sales3.add_during_upgrade_pfile=/path/to/my/newpfile.ora

del_after_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to have removed after the PFILE upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 specification applies to all databases in the user configuration file.

Example

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

del_during_upgrade_pfile

(Optional for AutoUpgrade upgrades) Specifies a path and file name of a PFILE whose parameters you want to have removed during the PFILE upgrade.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 specification applies to all databases in the user configuration file.

Example

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

upgradexml

(Optional for AutoUpgrade upgrades) Generates the upgrade.xml file.

Usage Notes

Note:

For use with AutoUpgrade upgrades 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 upgrade.xml 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.upgradexml=yes