In previous releases, if you used Oracle Wallet with TDE, then you specified the location of the existing keystore directory location by using the deprecated sqlnet.ora parameter SQLNET.ENCRYPTION_WALLET_LOCATION. In Oracle Database 19c and later releases, you should specify the keystore location by using the WALLET_ROOT system parameter in the database initialization parameter file (PFILE). What you need to do depends on how your source Oracle Database release is configured:

• If your source Oracle Database release has WALLET_ROOT set already, then the parameter files that AutoUpgrade generates automatically pick up the WALLET_ROOT system parameter from the source database during the upgrade, and use that parameter in target database parameter files.

• If your source Oracle Database release does not have the initialization parameter WALLET_ROOT set, then you can use AutoUpgrade to complete that task during the upgrade.

This example is of an AutoUpgrade configuration file that specifies the upgrade of two databases. The configuration file specifies that AutoUpgrade performs the following actions:

Database 1

• An in-place database upgrade of the Oracle Database 12c Release 2 (12.2) CDB, where the source and target Oracle homes use the same Oracle Base directory (the database home directory for Oracle Database installation owner oracle (/u01/app/oracle/) on the same server hardware, with the same system identifier (sid=HR1).
• During the upgrade, all the PDBs of the CDB are upgraded (pdbs=*)
• The upgrade starts immediately (start_time=now)
• The database upgrade logs will be sent to the path /database/logs/hr (log_dir=/database/logs/hr)
• The Time Zone upgrade will run on all the containers (timezone_upg=yes)

Database 2

• An in-place database upgrade of the Oracle Database 18c CDB, where the source and target Oracle homes use the same Oracle Base directory (the database home directory for Oracle Database installation owner oracle (/u01/app/oracle/) on the same server hardware, with the same system identifier (sid=SALES1).
• The upgrade starts immediately (start_time=now)
• The database upgrade logs will be sent to the path /database/logs/sales (log_dir=/database/logs/sales).
• The Time Zone upgrade will not run on any containers (timezone_upg=no).

For both databases:

• The parameter upgrade_node specifies the actual system host name (nodename-1), and not to an alias assigned to the host name. (You can also use the keyword localhost to refer to the current system.)
• The global AutoUpgrade log files (also known as job manager logs) are placed under the path /database/jobmgr (autoupg_log_dir=/database/jobmgr).

On the Oracle Database Upgrades and Migration YouTube Channel, you can see a similar upgrade scenario, Oracle Database AutoUpgrade 19c - Upgrading 2 databases in parallel (11:57), demonstrated by Mike Dietrich.

In the following configuration file, you can see how you can use AutoUpgrade configuration file entries to standardize their database configurations. The global PFILE entries are applied to all databases within the configuration file. The local PFILE entries are applied only to a specific database in the configuration file. The syntax for these PFILE values follow the same Oracle rules for PFILE configurations.

In this scenario, you upgrade two specific PDBs, without upgrading the other PDBs in the source CDB, To perform the incremental upgrade, you direct AutoUpgrade in the configuration file to unplug the PDBs you specify from an earlier release CDB, plug them into a target release CDB, and then upgrade the earlier release PDBs on the target CDB. This selection of PDBs to unplug, plug in, and upgrade, enables you to perform an incremental upgrade of PDBs on the earlier release CDB to reduce downtime.

In this scenario, you upgrade specific PDBs that were excluded in a previous upgrade of the CDB and PDBs, or PDBs that were added to the CDB through manual Non-CDB to PDB or Unplug-Plug operations. The PDBs are in an earlier release version.

The configuration file has a Database 1 section that identifies the CDB database as CDB19X, which is the CDB that has the existing PDBs PDB1 and PDB2. In this scenario CDB19X has 10 PDBs, PDB1 through PDB10, but PDB1 and PDB2 were excluded from an earlier upgrade procedure. CDB19X and PDBs 3 through 10 are all upgraded to the later release, but PDB1 and PDB2 remain on an earlier release. We will now run AutoUpgrade to upgrade the remaining two PDBs on the earlier release, specifying that the target upgrade PDBs PDB1 and PDB2 are on CDB19X (upg1.sid=CDB19X), and the upgrade should start immediately with upg.start_time=now.

By default, AutoUpgrade runs in console mode, which enables you to run commands to monitor specific aspects of your AutoUpgrade jobs while they are running on your systems.

You can use the Unplug-Plug relocate upgrade as a method to create clones from other PDBs, or from non-CDB databases. If the source database is a non-CDB, then AutoUpgrade upgrades and converts the non-CDB as part of the upgrade process. This feature is compatible with Oracle Database 12c release 1 (12.1.0.2) and later releases as the source release. Starting with AutoUgrade version 22.5, AutoUpgrade supports unplug-relocate operations using a source of at least Oracle Database 12c Release 1 (12.1.0.2). When a 12.1.0.2 source is used, the deploy operation requires the source to be in read only mode, and the target CDB to not be in local undo mode. The CLONE_ONLY option is also required when specifying the source_dblink parameter.Oracle Database Release 11g (11.2) is not compatible as a source version for the AutoUpgrade Hot-Cloning feature.

1. Grant a user on the database that you want to clone the CREATE SESSION, CREATE PLUGGABLE DATABASE, and SELECT_CATALOG_ROLE privileges. Also, on SYS, give the user GRANT READ ON sys.enc$. In this example, the user clone is created with these privileges,

   • Non-CDB:

     alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=db-node1)(PORT=1521))';
     ALTER SYSTEM REGISTER;
     CREATE USER clone IDENTIFIED BY some-password;
     GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SELECT_CATALOG_ROLE TO clone;
     GRANT READ ON sys.enc$ TO user;

   • PDB:

     alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=db-node1)(PORT=1521))';
     ALTER SYSTEM REGISTER; 
     CREATE USER c##clone IDENTIFIED BY some-password CONTAINER=ALL; 
     GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SELECT_CATALOG_ROLE TO c##clone CONTAINER=ALL;
     GRANT READ ON sys.enc$ TO c##clone CONTAINER=ALL;

     On a PDB, you can also limit the scope of creating the user to a single PDB on the CDB by specifying a particular PDB name. For example:

     CREATE USER c##clone IDENTIFIED BY some-password CONTAINER=PDBX; 

2. Configure the CDB to which you want to clone the PDB by creating a database link pointing to the source database on the source system that you plan to clone.

   In the following example, the database link points to the source database db18x:

   • Non-CDB

     In the following example, the database link points to the source database db18x:

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

   • PDB

     In the following example, the database link points to the source PDB pdbx on the CDB cdb18x:

     CREATE DATABASE LINK pdbxcdb18x_link 
     CONNECT TO c##clone IDENTIFIED BY some-password 
     USING'(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = db-node1) (PORT =
     1521))(CONNECT_DATA = (SERVICE_NAME = pdbx)))';

3. Update the AutoUpgrade configuration file with the information needed to identify the databases that you want to clone.

   Each database that you plan to clone must have the AutoUpgrade local parameter target_pdb_copy_option set to convert file names.

   Note:

   On the target CDB, 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, then set the value of prefix.target_pdb_copy_option=file_name_convert=NONE. However, you must have a file name and path specified either in the configuration file, or on the target CDB, or the upgrade will fail.

   By using the prefix for local parameters for each database, you can combine non-CDB and PDB upgrades in the same configuration file to relocate both non-CDBs and PDBs to the same target CDB. The following is an example of the relevant portion of the configuration file where both the non-CDB database db18x is configured for upgrade, and the PDB pdbx is configured for upgrade. In this case, file names for db18x are set to change the prepended name from DB18x to db18x, and the file names for the :

   upg1.sid=db18x 
   upg1.source_home=/source/18x 
   upg1.target_home=/target/19x 
   upg1.target_cdb=cdb19x 
   upg2.sid=cdb18x 
   upg2.pdbs=pdbx 
   upg2.target_cdb=cdb19x 
   upg2.source_home=/source/18x 
   upg2.target_home=/target/19x

   Each database has a target_pdb_copy_option set. For example, here the non-CDB filenames are converted from the prepended string DB18X to db18x:

   upg1.target_pdb_copy_option.db18x=file_name_convert=('DB18X', 'db18x')

   Each database must have the local parameter source_dblink set to the database link that you created on the target CDB:

   upg1.source_dblink.db18x=db18x_link

   To improve consistency, you can also use the local parameter start_time in combination with source_dblink with the optional refresh rate (in seconds) to set a refresh rate for the data, and schedule the job start time. The following parameters combined start AutoUpgrade, but sets a delay for the deployment of the upgrade of one hour and 40 minutes from the time that AutoUpgrade was started, and sets a refresh rate from the source database files to the target database files every 20 seconds:

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

   If you do not set a refresh rate for source_dblink, then the database files of the cloned database are cloned only once, without a refresh. If start_time is not set (so there is no delay in the processing of the upgrade), then the source_dblink refresh rate value is ignored.

4. Start the Unplug-Plug relocate deployment, specifying the configuration file you created for this task:

   java -jar autoupgrade.jar -config config.cfg -mode deploy

To override the default list of fixups that AutoUpgrade performs automatically for upgrades, you can load an existing checklist of fixup steps in to AutoUpgrade by using the local configuration file parameter checklist. In the checklist that you specify with the local parameter, you can set a precheck fixup as follows:

• YES (the default): Run checks, and run fixups
• NO: Run checks, but do not run fixups.
• _SKIP: Do not run checks, and do not run fixups.

You can configure four parameters in the configuration file that enable you to run custom scripts:

• before_action

  Run a custom script on the source Oracle home before the database is upgraded, during the Preupgrade stage when the database is up.

• after_action

  Run a custom script on the target Oracle home after the database is upgraded, during the Postupgrade stage or PDB upgrade stage, depending on the options set in the configuration file.

• revert_before_action

  Run a custom script on the target Oracle home before the database is restored, typically when the database is still up. Due to the nature of the upgrade process, be aware that the database can be down when the script is started. You can use this script to undo actions performed by a before_action custom script.

• revert_after_action

  Run a custom script on the source Oracle home after the database restored, and the database is up. You can use this script to undo actions performed by an after_action custom script.

See parameter descriptions under "AutoUpgrade Utility Configuration Files" for more detailed information about these parameters.