1. Move to Oracle Cloud Using Zero Downtime Migration
  2. Preparing for a Physical Database Migration

4 Preparing for a Physical Database Migration

Before starting a Zero Downtime Migration physical database migration you must configure connectivity between the servers, prepare the source and target databases, set parameters in the response file, and configure any required migration job customization.

See the Zero Downtime Migration Release Notes for the latest information about new features, known issues, and My Oracle Support notes.

Preparing the Source and Target Databases

There are several tasks you must complete on the source and target databases before configuring a migration job.

Note:

Zero Downtime Migration online physical migrations leverage Oracle Data Guard, so you must have the same operating system and database version on both source and target.

However, note that, while Standard Edition databases can use Zero Downtime Migration, they must use the offline migration method which is based on a backup and restore methodology that does not use Data Guard.

The Zero Downtime Migration physical migration work flow does not support cross-edition migration; however, you can migrate Standard Edition to Enterprise Edition using the logical migration work flow.

Source Database Prerequisites

Meet the following prerequisites on the source database before the Zero Downtime Migration process starts.

  • The source database must be running in ARCHIVELOG mode. See Changing the Database Archiving Mode.

  • The character set on the source database must be the same as the target database.

  • Configure the TDE wallet on Oracle Database 12c Release 2 and later. Enabling TDE on Oracle Database 11g Release 2 (11.2.0.4) and Oracle Database 12c Release 1 is optional.

    For Oracle Database 12c Release 2 and later, if the source database does not have Transparent Data Encryption (TDE) enabled, then it is mandatory that you configure the TDE wallet before migration begins. The WALLET_TYPE can be AUTOLOGIN (preferred) or PASSWORD based.

    Ensure that the wallet STATUS is OPEN and WALLET_TYPE is AUTOLOGIN (For an AUTOLOGIN wallet type), or WALLET_TYPE is PASSWORD (For a PASSWORD based wallet type). For a multitenant database, ensure that the wallet is open on all PDBs as well as the CDB, and the master key is set for all PDBs and the CDB. 

    SQL> SELECT * FROM v$encryption_wallet;

  • If the source is an Oracle RAC database, and SNAPSHOT CONTROLFILE is not on a shared location, configure SNAPSHOT CONTROLFILE to point to a shared location on all Oracle RAC nodes to avoid the ORA-00245 error during backups to Oracle Object Store.

    For example, if the database is deployed on ASM storage,

    $ rman target /  
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/db_name/snapcf_db_name.f';

    If the database is deployed on an ACFS file system, specify the shared ACFS location in the above command.

  • Verify that port 22 on the source database server allows incoming connections from the Zero Downtime Migration service host.

  • Ensure that the scan listener ports (1521, for example) on the source database servers allow incoming connections from the target database servers and outgoing connections to the target database servers.

    Alternate SQL connectivity should be made available if a firewall blocks incoming remote connection using the SCAN listener port.

  • To preserve the source database Recovery Time Objective (RTO) and Recovery Point Objective (RPO) during the migration, the existing RMAN backup strategy should be maintained.

    During the migration a dual backup strategy will be in place; the existing backup strategy and the strategy used by Zero Downtime Migration. Avoid having two RMAN backup jobs running simultaneously (the existing one and the one initiated by Zero Downtime Migration). If archive logs were to be deleted on the source database, and these archive logs are needed by Zero Downtime Migration to synchronize the target cloud database, then these files should be restored so that Zero Downtime Migration can continue the migration process.

  • If the source database is deployed using Oracle Grid Infrastructure and the database is not registered using SRVCTL, then you must register the database before the migration.

  • The source database must use a server parameter file (SPFILE).

  • If RMAN is not already configured to automatically back up the control file and SPFILE, then set CONFIGURE CONTROLFILE AUTOBACKUP to ON and revert the setting back to OFF after migration is complete. 

    RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

  • For offline migrations, plan to make sure no incoming transactions take place on the source database before the ZDM_BACKUP_DIFFERENTIAL_SRC phase, so that there is no loss of data during the migration. Once Zero Downtime Migration starts generating backups and transfers them, any new transactions on the source won't be part of the backups and therefore the target in the cloud won't have those changes.

  • System time of the Zero Downtime Migration service host and source database server should be in sync with your Oracle Cloud Infrastructure target.

    If the time on any of these systems varies beyond 6 minutes from the time on OCI, it should be adjusted. You can use ntp time check to synchronize the time if NTP is configured. If NTP is not configured, then it is recommended that you configure it. If configuring NTP is not an option, then you need to correct the time manually to ensure it is in sync with OCI time.

  • Set the COMPATIBLE database initialization parameter to the same value on the source and target database. See Values for the COMPATIBLE Initialization Parameter in Oracle Database for valid values.

See Also:

Setting Up the Transparent Data Encryption Keystore

Zero Downtime Migration Port Requirements

Target Database Prerequisites

The following prerequisites must be met on the target database before you begin the Zero Downtime Migration process.

  • You must create a placeholder target database.

    For Exadata Cloud Service and Exadata Cloud at Customer targets, the placeholder database must be created using Control Plane, not Grid Infrastructure Database Services before database migration begins.

    Note:

    For this release, only Grid Infrastructure-based database services are supported as targets. For example, an LVM-based instance or an instance created in compute node without Grid Infrastructure are not supported targets.

    The placeholder target database is overwritten during migration, but it retains the overall configuration.

    Pay careful attention to the following requirements:

    • Size for the future - When you create the database from the console, ensure that your chosen shape can accommodate the source database, plus any future sizing requirements. A good guideline is to use a shape similar to or larger in size than source database.
    • Set name parameters
      • DB_NAME - If the target database is Exadata Cloud Service or Exadata Cloud at Customer, then the database DB_NAME should be the same as the source database DB_NAME. If the target database is Oracle Cloud Infrastructure, then the database DB_NAME can be the same as or different from the source database DB_NAME.
      • DB_UNIQUE_NAME: If the target database is Oracle Cloud Infrastructure, Exadata Cloud Service, or Exadata Cloud at Customer, the target database DB_UNIQUE_NAME parameter value must be unique to ensure that Oracle Data Guard can identify the target as a different database from the source database.
    • Match the source SYS password - Specify a SYS password that matches that of the source database.
    • Disable automatic backups - Provision the target database from the console without enabling automatic backups.

      For Oracle Cloud Infrastructure and Exadata Cloud Service, do not select the Enable automatic backups option under the section Configure database backups.

      For Exadata Cloud at Customer, set Backup destination Type to None under the section Configure Backups.

  • The target database version should be the same as the source database version. The target database patch level should also be the same as (or higher than) the source database.

    If the target database environment is at a higher patch level than the source database (for example, if the source database is at Jan 2020 PSU/BP and the target database is at April 2020 PSU/BP), then Zero Downtime Migration runs the datapatch utility as part of the migration.

  • The character set on the source database must be the same as the target database.

  • The target database time zone version must be the same as the source database time zone version. To check the current time zone version, query the V$TIMEZONE_FILE view as shown here, and upgrade the time zone file if necessary. 

    SQL> SELECT * FROM v$timezone_file;

  • Verify that the TDE wallet folder exists, and ensure that the wallet STATUS is OPEN and WALLET_TYPE is AUTOLOGIN (For an auto-login wallet type), or WALLET_TYPE is PASSWORD (For a password-based wallet). For a multitenant database, ensure that the wallet is open on all PDBs as well as the CDB, and the master key is set for all PDBs and the CDB. 

    SQL> SELECT * FROM v$encryption_wallet;

  • The target database must use a server parameter file (SPFILE).

  • If the target is an Oracle RAC database, then verify that SSH connectivity without a passphrase is set up between the Oracle RAC servers for the oracle user.

  • Check the size of the disk groups and usage on the target database (ASM disk groups or ACFS file systems) and make sure adequate storage is provisioned and available on the target database servers.

  • Make sure adequate storage is provisioned and available on the object store to accommodate the source database backup.

  • Verify that ports 22 and 1521 (or the configured database listener port) on the target servers in the Oracle Cloud Infrastructure, Exadata Cloud Service, or Exadata Cloud at Customer environment are open and not blocked by a firewall.

  • Verify that port 22 on the target database server allows incoming connections from the Zero Downtime Migration service host.

  • Capture the output of the RMAN SHOW ALL command, so that you can compare RMAN settings after the migration, then reset any changed RMAN configuration settings to ensure that the backup works without any issues. 

    RMAN> show all;

  • System time of the Zero Downtime Migration service host and source database server should be in sync with your Oracle Cloud Infrastructure target.

    If the time on any of these systems varies beyond 6 minutes from the time on OCI, it should be adjusted. You can use ntp time check to synchronize the time if NTP is configured. If NTP is not configured, then it is recommended that you configure it. If configuring NTP is not an option, then you need to correct the time manually to ensure it is in sync with OCI time.

  • Set the COMPATIBLE database initialization parameter to the same value on the source and target database. See Values for the COMPATIBLE Initialization Parameter in Oracle Database for valid values.

See Also:

Managing User Credentials for information about generating the auth token for Object Storage backups

Zero Downtime Migration Port Requirements

Setting Up the Transparent Data Encryption Keystore

For Oracle Database 12c Release 2 and later, if the source and target databases do not have Transparent Data Encryption (TDE) enabled, then it is mandatory that you configure the TDE keystore before migration begins.

TDE should be enabled and the TDE WALLET status on both source and target databases must be set to OPEN. The WALLET_TYPE can be AUTOLOGIN, for an auto-login keystore (preferred), or PASSWORD, for a password-based keystore. On a multitenant database, make sure that the keystore is open on all PDBs as well as the CDB, and that the master key is set for all PDBs and the CDB.

If TDE is not already configured as required on the source and target databases, use the following instructions to set up the TDE keystore.

For a password-based keystore, you only need to do steps 1, 2, and 4; for an auto-login keystore, complete all of the steps.

  1. Set ENCRYPTION_WALLET_LOCATION in the $ORACLE_HOME/network/admin/sqlnet.ora file. 

    /home/oracle>cat /u01/app/oracle/product/12.2.0.1/dbhome_4/network/admin/sqlnet.ora 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
  (METHOD_DATA=(DIRECTORY=/u01/app/oracle/product/12.2.0.1/dbhome_4/network/admin/)))

    For an Oracle RAC instance, also set ENCRYPTION_WALLET_LOCATION in the second Oracle RAC node.

  2. Create and configure the keystore.

    1. Connect to the database and create the keystore.

      $ sqlplus "/as sysdba"
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin'
 identified by password;

    2. Open the keystore.

      For a non-CDB environment, run the following command.

      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
keystore altered.

      For a CDB environment, run the following command.

      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password container = ALL;
keystore altered.

    3. Create and activate the master encryption key.

      For a non-CDB environment, run the following command.

      SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password with backup;
keystore altered.

      For a CDB environment, run the following command.

      SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password with backup container = ALL;
keystore altered.

    4. Query V$ENCRYPTION_KEYS to get the keystore status, keystore type, and keystore location. 

      SQL> SELECT * FROM v$encryption_keys;

WRL_TYPE    WRL_PARAMETER
--------------------            --------------------------------------------------------------------------------
STATUS                         WALLET_TYPE          WALLET_OR FULLY_BAC    CON_ID
------------------------------ -------------------- --------- ---------            ----------
FILE        /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN                           PASSWORD             SINGLE    NO         0

    The configuration of a password-based keystore is complete at this stage, and the keystore is enabled with status OPEN and WALLET_TYPE is shown as PASSWORD in the query output above.

    Continue to step 3 only if you need to configure an auto-login keystore, otherwise skip to step 4.

  3. For an auto-login keystore only, complete the keystore configuration.

    1. Create the auto-login keystore.

      SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
 '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/' IDENTIFIED BY password;
keystore altered.

    2. Close the password-based keystore.

      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY password;
keystore altered.

    3. Query V$ENCRYPTION_WALLET to get the keystore status, keystore type, and keystore location. 

      SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE WRL_PARAMETER
-------------------- --------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR FULLY_BAC CON_ID
------------------------------ -------------------- --------- --------- ---------
FILE /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN AUTOLOGIN SINGLE NO

      In the query output, verify that the TDE keystore STATUS is OPEN and WALLET_TYPE set to AUTOLOGIN, otherwise the auto-login keystore is not set up correctly.

      This completes the auto-login keystore configuration.

  4. Copy the keystore files to the second Oracle RAC node.

    If you configured the keystore in a shared file system for Oracle RAC, or if you are enabling TDE for a single instance database, then no action is required.

    If you are enabling TDE for Oracle RAC database without shared access to the keystore, copy the following files to the same location on second node.

    • /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/ew*

    • /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/cw*

Setting Physical Migration Parameters

Set the required physical migration response file parameters. Get the response file template, $ZDM_HOME/rhp/zdm/template/zdm_template.rsp, which is used to create your Zero Downtime Migration response file for the database migration procedure, and edit the file as described here.

The following response file settings show you how to configure a typical use case. To further customize your configuration you can find additional parameters described in Zero Downtime Migration Physical Migration Response File Parameters Reference.

TGT_DB_UNIQUE_NAME

Set TGT_DB_UNIQUE_NAME to the target database DB_UNIQUE_NAME value. To find DB_UNIQUE_NAME run 

SQL> show parameter db_unique_name

For Cloud type Exadata Cloud at Customer Gen 1, set TGT_DB_UNIQUE_NAME to a different DB_UNIQUE_NAME not currently in use.

PLATFORM_TYPE

Set PLATFORM_TYPE to one of the following:

  • VMDB - Oracle Cloud Infrastructure virtual machine or bare metal targets.

  • EXACS - Exadata Cloud Service

  • EXACC - Exadata Cloud at Customer

  • NON_CLOUD - On-premises Exadata Database Machine

MIGRATION_METHOD

Set MIGRATION_METHOD to one of the following:

  • ONLINE_PHYSICAL - Oracle Data Guard (online)

  • OFFLINE_PHYSICAL - RMAN backup and restore (offline). Note that this is the only migration method supported for Oracle Standard Edition databases.

DATA_TRANSFER_MEDIUM

DATA_TRANSFER_MEDIUM specifies the media used for the source database backup, or you can configure direct data transfer.

  • OSS - Oracle Data Guard using Object Storage Service (OSS) for standby initialization.

    Supported for PLATFORM_TYPE set to Oracle Cloud Infrastructure (VMDB), Exadata Cloud Service (EXACS), and Exadata Cloud at Customer (EXACC).

    Also set ZDM_LOG_OSS_PAR_URL to the Cloud Object Store pre-authenticated URL if you want to upload migration logs onto Cloud Object Storage. For information about getting a pre-authenticated URL see Oracle Cloud documentation at https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/usingpreauthenticatedrequests.htm#usingconsole.

    When you perform a migration using backup and restore (OFFLINE_PHYSICAL) through Object Storage Service, SQL*Net connectivity between the source and target are not needed.

  • EXTBACKUP - Oracle Data Guard with existing backup in external location.

    Supported for PLATFORM_TYPE set to Exadata Cloud at Customer (EXACC) or on-premises Exadata Database Machine (NON_CLOUD)

    Also, create a standby control file backup in the specified path and provide read permissions to the backup pieces for the target database user. For example,

    RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT 'BACKUP_PATH/lower_case_dbname/standby_ctl_%U';

    Where standby_ctl_%U is a system-generated unique file name.

  • ZDLRA - Oracle Data Guard using ZDLRA for standby initialization.

    Supported for PLATFORM_TYPE set to Exadata Cloud at Customer (EXACC) or on-premises Exadata Database Machine (NON_CLOUD), and set the following parameters.

    • Set SRC_ZDLRA_WALLET_LOC for the wallet location, for example, 

      SRC_ZDLRA_WALLET_LOC=/u02/app/oracle/product/12.1.0/dbhome_3/dbs/zdlra

    • Set TGT_ZDLRA_WALLET_LOC for the wallet location, for example, TGT_ZDLRA_WALLET_LOC=target_database_oracle_home/dbs/zdlra.

    • Set ZDLRA_CRED_ALIAS for the wallet credential alias, for example, 

      ZDLRA_CRED_ALIAS=zdlra_scan:listener_port/zdlra9:dedicated

  • NFS - Oracle Data Guard using backup location such as NFS.

    Supported for PLATFORM_TYPE set to Exadata Cloud at Customer (EXACC) or on-premises Exadata Database Machine (NON_CLOUD).

    Also set BACKUP_PATH to specify the actual NFS path which is made accessible from both the source and target database servers, for example, an NFS mount point. The NFS mount path should be same for both source and target database servers. This path does not need to be mounted on the Zero Downtime Migration service host.

    When you perform a migration using backup and restore (OFFLINE_PHYSICAL) through NFS, SQL*Net connectivity between the source and target are not needed.

    Note the following considerations:

    • The source database is backed up to the specified path and restored to Exadata Cloud at Customer using RMAN SQL*Net connectivity.

    • The path set in BACKUP_PATH should have ‘rwx’ permissions for the source database user, and at least read permissions for the target database user.

    • In the path specified by BACKUP_PATH, the Zero Downtime Migration backup procedure will create a directory, $BACKUP_PATH/dbname, and place the backup pieces in this directory.

  • DIRECT - Uses RMAN active database duplication or restore from service to transfer data directly from the source to the target.

    RMAN active database duplication is supported in Oracle Database 11g (11.2) and later releases, which makes it the only option available for 11gR2 databases. RMAN restore from service is supported in Oracle Database 12g (12.1) and later releases.

    Because the connection is initiated from the target database host, both active duplication and restore from service direct transfer methods require SQL*Net connectivity from the target to the source database.

    The transfer method (restore from service or active duplicate) is configured with ZDM_RMAN_DIRECT_METHOD, which is set to RESTORE_FROM_SERVICE by default.

    To use the restore from service method, also set ZDM_SRC_DB_RESTORE_SERVICE_NAME to the fully qualified name of the service on the source database to be used for the migration. If not specified, the default database service is used.

    See Direct Data Transfer Support for more information about the transfer methods.

    You must also set up non-interactive access between the source and target. See Provide Passwords Non-Interactively Using a Wallet.

Additional Oracle Cloud Object Storage Settings

When DATA_TRANSFER_MEDIUM=OSS, set the following parameters to access Oracle Cloud Object Storage. The source database is backed up to the specified container and restored to the target using RMAN SQL*Net connectivity.

  • Set HOST to the cloud storage REST endpoint URL.

    • For Oracle Cloud Infrastructure storage the typical value format is HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/ObjectStorageNamespace

      To find the Object Storage Namespace value, log in to the Cloud Console and select Menu, Administration, Tenancy Detail, and in the Object Storage Settings section find Value against entry Object Storage Namespace:

    • For Oracle Cloud Infrastructure Classic storage the typical value format is HOST=https://acme.storage.oraclecloud.com/v1/Storage-tenancy name

  • Set the Object Storage bucket OPC_CONTAINER parameter.

    The bucket is also referred to as a container for Oracle Cloud Infrastructure Classic storage. Make sure that the Object Storage bucket is created using the Oracle Cloud Service Console as appropriate. Make sure adequate storage is provisioned and available on the object store to accommodate the source database backup.

TGT_SSH_TUNNEL_PORT

If SSH tunneling is set up, set the TGT_SSH_TUNNEL_PORT parameter.

Data and Redo Locations

Zero Downtime Migration automatically discovers the location for data, reco, and redo (for non-Exadata systems) storage volumes from the specified target database. If you need to override the discovered values, specify the target database data files storage (ASM or ACFS) location using the appropriate set of parameters.

  • ASM: TGT_DATADG, TGT_REDODG, and TGT_RECODG
  • ACFS: TGT_DATAACFS, TGT_REDOACFS, and TGT_RECOACFS

SKIP_FALLBACK

Set SKIP_FALLBACK=TRUE if you do not want to ship redo logs from the target to the source standby, either voluntarily or because there is no connectivity between the target and the source.

TGT_SKIP_DATAPATCH

Zero Downtime Migration runs the datapatch utility by default as part of the migration process if the target database environment is at a higher patch level than the source database (for example, if the source database is at Jan 2020 PSU/BP and the target database is at April 2020 PSU/BP).

If you want to skip this task set the TGT_SKIP_DATAPATCH=FALSE response file parameter.

PHASE_NAME_MONITORING_INTERVAL

Set PHASE_NAME_MONITORING_INTERVAL=n mins if you want Zero Downtime Migration to monitor and report the status of backup and restore operations at the configured time interval during the migration. The default interval value is 10 minutes. To disable monitoring, set these values to 0 (zero). 

ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL= 
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL= 
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL= 
ZDM_CLONE_TGT_MONITORING_INTERVAL= 
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL= 
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=

ZDM_BACKUP_RETENTION_WINDOW

Set ZDM_BACKUP_RETENTION_WINDOW=number of days if you wish to retain source database backup after the migration.

ZDM_SRC_TNS_ADMIN

Set ZDM_SRC_TNS_ADMIN=TNS_ADMIN value in case of custom location.

Provide Passwords Non-Interactively Using a Wallet

You can avoid entering passwords in the command line and run the ZDMCLI migrate database command without user interaction, such as when you do automation using Rundeck.

Note:

This wallet-based password input option is only supported for physical online and offline migration jobs.

Currently, whenever you submit the $ZDM_HOME/bin/zdmcli migrate database command, it prompts for the source database SYS password, Object Store user swift authentication token, and the source database Transparent Data Encryption (TDE) keystore password (if the wallet was configured as a PASSWORD-based TDE wallet).

Additionally, if you are converting a non-multitenant source database to a multitenant architecture on the target, that is a pluggable database (PDB), then you can also create an auto-login wallet for the target container database (CDB) TDE keystore password.

Run the following commands on the Zero Downtime Migration service host as Zero Downtime Migration software owner (for example, zdmuser).

To create an auto-login wallet for the source database SYS user:

  1. Create a directory where you want to create and store the wallet.

    zdmuser> mkdir sys_wallet_path

    For example: 

    /u01/app/zdmhome> mkdir sysWallet

  2. Create a wallet.

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet sys_wallet_path 
-auto_login_only

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create -wallet sysWallet 
-auto_login_only
Oracle PKI Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Operation is successfully completed.

  3. Add a SYS user login credentials to wallet. 

    zdmuser> $ZDM_HOME/bin/mkstore -wrl sys_wallet_path 
-createCredential store sysuser

    At the prompt, enter the source database SYS password.

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./sysWallet 
-createCredential store sysuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

  4. Verify that the wallet files were created.

    zdmuser> ls -l sys_wallet_path

    For example

    /u01/app/zdmhome> ls -l sysWallet/
total 4
-rw-------. 1 opc opc 581 Jun  2 08:00 cwallet.sso
-rw-------. 1 opc opc   0 Jun  2 08:00 cwallet.sso.lck

To create an auto-login wallet for the Object Store user:

  1. Create a directory where you want to create and store the wallet.

    zdmuser> mkdir oss_wallet_path

    For example

    /u01/app/zdmhome> mkdir ossWallet

  2. Create a wallet

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet oss_wallet_path 
-auto_login_only

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create 
-wallet ./ossWallet -auto_login_only 
Oracle PKI Tool Release 19.0.0.0.0 -Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019,
Oracle and/or its affiliates. All rights reserved.

 Operation is successfully completed.

  3. Add the Object Store user login credentials to the wallet.

    zdmuser> $ZDM_HOME/bin/mkstore -wrl oss_wallet_path 
-createCredential store ossuser

    For the prompt,

    • If the backup destination is Object Store (Bucket), then enter the user swift authentication token.

    • If the backup destination is Storage Classic (Container), then enter your tenancy login password.

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./ossWallet 
-createCredential store ossuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

  4. Verify that the wallet files were created.

    zdmuser> ls -l oss_wallet_path

    For example

    /u01/app/zdmhome> ls -l ./ossWallet
total 4
-rw-------. 1 opc opc 597 Jun  2 08:02 cwallet.sso
-rw-------. 1 opc opc   0 Jun  2 08:01 cwallet.sso.lck

To create an auto-login wallet for the source database TDE keystore:

  1. Create a directory where you want to create and store the wallet.

    zdmuser> mkdir tde_wallet_path

    For example

    /u01/app/zdmhome> mkdir tdeWallet

  2. Create a wallet.

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet tde_wallet_path 
-auto_login_only

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create -wallet ./tdeWallet 
-auto_login_only
Oracle PKI Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Operation is successfully completed.

  3. Add the source database TDE keystore credentials to the wallet.

    zdmuser> $ZDM_HOME/bin/mkstore -wrl tde_wallet_path 
-createCredential store tdeuser

    At the prompt, enter the TDE keystore password.

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./tdeWallet 
-createCredential store tdeuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

  4. Verify that the wallet files were created.

    zdmuser> ls -l tde_wallet_path

    For example

    /u01/app/zdmhome> ls -l tdeWallet
total 4
-rw-------. 1 opc opc 581 Jun  2 08:06 cwallet.sso
-rw-------. 1 opc opc   0 Jun  2 08:04 cwallet.sso.lck

To create an auto-login wallet for the target CDB database TDE keystore password:

  1. Create a directory where you want to create and store the wallet.

    zdmuser> mkdir cdb_tde_wallet_path

    For example

    /u01/app/zdmhome> mkdir cdbtdeWallet

  2. Create a wallet.

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet cdb_tde_wallet_path 
-auto_login_only

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create -wallet ./cdbtdeWallet 
-auto_login_only
Oracle PKI Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Operation is successfully completed.

  3. Add the source database TDE keystore credentials to the wallet.

    zdmuser> $ZDM_HOME/bin/mkstore -wrl cdb_tde_wallet_path 
-createCredential store cdbtdeuser

    At the prompt, enter the TDE keystore password.

    For example

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./cdbtdeWallet 
-createCredential store cdbtdeuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

Setting Command Options to Access the Wallets

To specify wallet information in the ZDMCLI MIGRATE DATABASE command, set the -sourcesyswallet, -osswallet, -tdekeystorewallet, and -tgttdekeystorewallet options as shown here. 

zdmuser> $ZDM_HOME/bin/zdmcli migrate database 
-sourcedb source_db_unique_name_value
-sourcenode source_database_server_name 
-srcauth zdmauth
-srcarg1 user:source_database_server_login_user_name
-srcarg2 identity_file:zdm_installed_user_private_key_file_location
-srcarg3 sudo_location:/usr/bin/sudo 
-targetnode target_database_server_name
-backupuser object_store_login_user_name 
-rsp response_file_location
-tgtauth zdmauth 
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:zdm_installed_user_private_key_file_location 
-tgtarg3 sudo_location:/usr/bin/sudo 
-sourcesyswallet sys_wallet_path 
-osswallet oss_wallet_path  
-tdekeystorewallet tde_wallet_path 
-tgttdekeystorewallet cdb_tde_wallet_path 
-eval
  • -sourcesyswallet sys_wallet_path specifies the full path for the auto-login wallet file on the Zero Downtime Migration host containing the SYS password of the source database
  • -osswallet oss_wallet_path specifies the full path for the auto-login wallet file on the Zero Downtime Migration host containing credentials for the Object Storage Service backup user
  • -tdekeystorewallet tde_wallet_path specifies the full path for the auto-login wallet file on the Zero Downtime Migration host containing the TDE keystore password
  • -tgttdekeystorewallet cdb_tde_wallet_path specifies the full path for the auto-login wallet file on the Zero Downtime Migration host containing the target CDB TDE keystore password

Evaluation Mode Example 

zdmuser> $ZDM_HOME/bin/zdmcli migrate database 
-sourcedb zdmsdb 
-sourcenode ocicdb1 
-srcauth zdmauth 
-srcarg1 user:opc 
-srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-srcarg3 sudo_location:/usr/bin/sudo 
-targetnode ocidb1 
-backupuser backup_user@example.com 
-rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_zdmsdb.rsp 
-tgtauth zdmauth 
-tgtarg1 user:opc 
-tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-tgtarg3 sudo_location:/usr/bin/sudo 
-sourcesyswallet /u01/app/zdmhome/sysWallet 
-osswallet /u01/app/zdmhome/ossWallet 
-eval

Operation "zdmcli migrate database" scheduled with the job ID "1".

Migration Mode Example

zdmuser> $ZDM_HOME/bin/zdmcli migrate database 
-sourcedb zdmsdb 
-sourcenode ocicdb1 
-srcauth zdmauth 
-srcarg1 user:opc 
-srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-srcarg3 sudo_location:/usr/bin/sudo 
-targetnode ocidb1 
-backupuser backup_user@example.com 
-rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_zdmsdb.rsp 
-tgtauth zdmauth 
-tgtarg1 user:opc 
-tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-tgtarg3 sudo_location:/usr/bin/sudo 
-sourcesyswallet /u01/app/zdmhome/sysWallet 
-osswallet /u01/app/zdmhome/ossWallet

Operation "zdmcli migrate database" scheduled with the job ID "2".

Preparing for Automatic Application Switchover

To minimize or eliminate service interruptions on the application after you complete the database migration and switchover, prepare your application to automatically switch over connections from the source database to the target database.

Note:

In physical migrations, Autonomous Database targets are not supported for automatic application switchover.

In the following example connect string, the application connects to the source database, and when it is not available the connection is switched over to the target database.

(DESCRIPTION=
    (FAILOVER=on)(LOAD_BALANCE=on)(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
    (ADDRESS_LIST=
        (ADDRESS=(PROTOCOL=TCP)(HOST=source_database_scan)(PORT=1521))
        (ADDRESS=(PROTOCOL=TCP)(HOST=target_database_scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=zdm_prod_svc)))

On the source database, create the service, named zdm_prod_svc in the examples.

srvctl add service -db clever -service zdm_prod_svc -role PRIMARY
 -notification TRUE -session_state dynamic -failovertype transaction
 -failovermethod basic -commit_outcome TRUE -failoverretry 30 -failoverdelay 10
 -replay_init_time 900 -clbgoal SHORT -rlbgoal SERVICE_TIME -preferred clever1,clever2
 -retention 3600 -verbose

If the db_domain changes between the source and target then the connect string specified in the application should cater to both for failover to be effective. 

(DESCRIPTION_LIST=
            (FAILOVER=ON)
            (LOAD_BALANCE=ON)
            (DESCRIPTION=
            (ADDRESS= (PROTOCOL=TCP) (HOST=SRC_SCAN) (PORT=1521))
            (CONNECT_DATA=
            (SERVICE_NAME=SVC.SRC_DOMAIN)))            
            (DESCRIPTION=
            (ADDRESS= (PROTOCOL=TCP) (HOST=TGT_SCAN) (PORT=1521))
            (CONNECT_DATA=
            (SERVICE_NAME= SVC.TGT_DOMAIN))

See Also:

Oracle MAA white papers about client failover best practices on the Oracle Active Data Guard Best Practices page at https://www.oracle.com/goto/maa

High Availability in Oracle Database Development Guide

Configuring Resiliency to Intermittent Network Failures

Zero Downtime Migration physical migrations are resilient to intermittent network failures that can cause backups or SSH connectivity to fail.

Zero Downtime Migration can auto-detect intermittent network failures. Zero Downtime Migration automatically retries the RMAN retry-able errors, and some retry customization is available.

SSH connection retries are customized using the following parameters:

SRC_SSH_RETRY_TIMEOUT

TGT_SSH_RETRY_TIMEOUT

You can customize RMAN backup retries with following parameters:

ZDM_OPC_RETRY_WAIT_TIME

ZDM_OPC_RETRY_COUNT

ZDM_OPC_RETRY_WAIT_TIME

Converting a Non-CDB Database to a CDB During Migration

As part of the physical migration process, Zero Downtime Migration can handle conversion of a non-CDB source database to a PDB of the same version in the cloud. The conversion process transforms the source non-CDB into a target PDB that is then plugged into an existing CDB in the target.

Downtime will increase due to the non-CDB to CDB conversion. This process is offline (no redo transport and apply), and no rollback is possible.

Source non-CDB Database Prerequisites

  • Oracle Database 12c or later versions, because this is when multitenant architecture became available

  • Same character set as the target CDB

Target Database CDB and PDB Prerequisites

  • The target CDB must not contain a PDB with same name as the resulting converted PDB, because Zero Downtime Migration will create the PDB.

  • The target database must be at least the same major version as the source database.

    • If the minor version is different on the target, it must be a higher minor version than the source database.
    • If the patch level is different, you must set the response file parameter TGT_SKIP_DATAPATCH=FALSE.

Transparent Data Encryption Requirements

  • Transparent Data Encryption (TDE) is optional on the source database. If TDE is not set there is no further information required; however if TDE is set up on source, the credentials for export and import TDE keys are required.

  • For source credentials, the migrate database command must include either -tdekeystorepasswd or the -tdekeystorewallet auto-login option.

  • If any of these options is used then the target credentials must be also provided by using either -tgttdekeystorepasswd or the -tgttdekeystorewallet auto-login option.

Application Express Requirements

  • If Application Express (APEX) is not installed on the source there are no further requirements.

  • If APEX exists on the source, and the source database is a non-CDB, you must choose one of the following options:

    • Remove APEX from the source non-CDB.
    • Verify that the APEX version on the target CDB is the same as that on the source.

      If APEX is not at the same version conversion is not possible; APEX schemas vary between versions and the target PDB will not be able to open.

The target CDB is not dropped in the process, and the presence or absence of other PDBs does not affect the outcome of the conversion and plug-in.

Parameters in the response file are set as follows:

  • (Required) NONCDBTOPDB_CONVERSION: Set to TRUE to indicate that you want to convert a source database from non-CDB to PDB.
  • (Optional) NONCDBTOPDB_SWITCHOVER: Set to TRUE for a physical migration using Data Guard switchover, to execute switchover operations during a migration job with non-CDB to PDB conversion enabled.

The following are examples of the ZDMCLI migrate database command usage for converting a non-CDB to a PDB during migration using the TDE credentials.

Example interactively supplying passwords:

zdmuser> $ZDM_HOME/bin/zdmcli migrate database
  -sourcedb source_db_unique_name_value 
  -sourcenode source_database_server_name 
  -srcroot
  -targetnode target_database_server_name 
  -backupuser Object_store_login_user_name
  -rsp response_file_location 
  -tgtauth zdmauth 
  -tgtarg1 user:target_database_server_login_user_name
  -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location 
  -tgtarg3 sudo_location:/user/bin/sudo
  -tdekeystorepasswd 
  -tgttdekeystorepasswd

Example using auto-login wallet for CDB TDE keystore:

zdmuser> $ZDM_HOME/bin/zdmcli migrate database
  -sourcedb source_db_unique_name_value 
  -sourcenode source_database_server_name 
  -srcroot
  -targetnode target_database_server_name 
  -backupuser Object_store_login_user_name
  -rsp response_file_location 
  -tgtauth zdmauth 
  -tgtarg1 user:target_database_server_login_user_name
  -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location 
  -tgtarg3 sudo_location:/user/bin/sudo
  -tdekeystorepasswd 
  -tgttdekeystorewallet /scratch/credentials/cdbtde.sso

Run a Migration Job Using an Existing RMAN Backup

Zero Downtime Migration lets you use an existing level 0 backup to skip the full backup phase of a migration job.

Zero Downtime Migration takes level 0 and level 1 backups on the fly for both online and offline physical migration jobs. During a migration job, Zero Downtime Migration lets you re-use existing source database backup in place of performing a full back up.

All types of backup devices, such as DISK, SBT_TAPE, and ZDLRA, are supported as data transfer media for this migration method.

Only level 0 backups with incremental_level=0 are valid for this use case.

To use an existing RMAN backup, set the following response file parameters.

ZDM_USE_EXISTING_BACKUP=TRUE
ZDM_BACKUP_TAG=RMAN backup tag

When you run the ZDMCLI database migration command in evaluation mode (ZDMCLI database migration -eval), Zero Downtime Migration verifies the existence of the backup, checks that it is valid, and displays whether the backup is available and validated in the job output.

In migrate mode (ZDMCLI database migration), Zero Downtime Migration performs the same steps done in evaluation mode, then skips full backup and performs other backup operations like incremental and differential backup.

Creating a Backup

To take a valid RMAN backup to use as a migration source, you can run the following commands.

For DISK:

RUN {
ALLOCATE CHANNEL channel_name DEVICE TYPE DISK FORMAT 'directory_path/%d_backup_%U';
ALTER SYSTEM ARCHIVE LOG CURRENT;
BACKUP AS COMPRESSED BACKUPSET FORCE INCREMENTAL LEVEL 1 FOR RECOVER OF TAG 'backup_tag'
 DATABASE FORMAT 'directory_path/%d_backup_%U_DBF' SECTION SIZE 4G ;
}

For SBT_TAPE:

RUN {
ALLOCATE CHANNEL channel_name DEVICE TYPE SBT FORMAT '%d_%I_%T-%s_%p'
 PARMS 'SBT_LIBRARY=path/libopc.so, SBT_PARMS=(OPC_PFILE=path/OPC/mzdm.conf)';
ALTER SYSTEM ARCHIVE LOG CURRENT;
BACKUP AS COMPRESSED BACKUPSET FORCE INCREMENTAL LEVEL 1 FOR RECOVER OF TAG 'backup_tag'
 DATABASE FORMAT '%d_%I_%T-%s_%p_DBF' SECTION SIZE 4G ;
}

Alternate Use Case

If the ZDM_BACKUP_TAG value is provided and ZDM_USE_EXISTING_BACKUP=FALSE the Zero Downtime Migration will create a full backup with the provided tag.

Using Backups with Password Authentication

To use an existing backup with backup password authentication, you can specify the password using the -backuppasswd password option in the command migrate database.

You can also specify a backup wallet path by using -backupwallet in the command migrate database.

Migrating an On-Premises Database to an On-Premises Exadata Database Machine

An on-premises migration to an on-premises Exadata Database Machine target using Zero Downtime Migration works the same way as a migration to a cloud target. In the response file, you indicate that the migration target is on-premises by setting PLATFORM_TYPE=NON_CLOUD.

Just like in cloud migration scenarios, you must provision the target database with the shape and size desired, including configuring any initialization parameters, before starting the migration. The target database is expected to be the same major version as the source database, Oracle Grid Infrastructure is mandatory at the target database, and target datafiles can be stored on ASM or ACFS.

One aspect where an on-premises to on-premises migration is different from migrating to the cloud is in the handling of Transparent Data Encryption (TDE). On the cloud, TDE is mandatory for Oracle Database 12.2 and later releases; however, for an on-premises to on-premises migration, TDE must be configured at the target only if TDE is used at the source. You must configure TDE at the target before the migration starts; Zero Downtime Migration does not configure it for you.

You can specify that TDE is not configured at the source or target by setting the response file parameter ZDM_TDE_MANDATORY=FALSE. This parameter can only be used when you set PLATFORM_TYPE=NON_CLOUD. With ZDM_TDE_MANDATORY=FALSE set, Zero Downtime Migration does not require TDE at the target when the source is not using TDE, and does not encrypt the target on restore.

For an on-premises Exadata target database migration, MIGRATION_METHOD can be set to ONLINE_PHYSICAL or OFFLINE_PHYSICAL, and DATA_TRANSFER_MEDIUM can be set to any of the values supported by Zero Downtime Migration. Set the remaining parameters as you would for a cloud migration.