Zero Downtime Migration software requires a Linux host running on Oracle Linux 7 or later with 100 GB of free storage space.

Zero Downtime Migration service host must be able to connect with the source and target database servers through either root user or SSH keys.

Zero Downtime Migration supports Oracle Database 11g Release 2 (11.2.0.4) or later.

Both the Source and Target database release versions should be the same.

1. The source database must be running in archive log mode.
2. 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.
3. 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;

4. 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.
5. Verify that port 22 on the source and target database server nodes allow incoming connections from Zero Downtime Migration service host.
6. Ensure that the scan listener ports (1521, for example) on the source database servers allow incoming connections from the target database servers and vice versa.

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

7. During the migration, disable all RMAN scripts, for example, cron jobs, to avoid multiple RMAN backups.

• If the source database is Oracle release 12.2 and later, TDE is not enabled, so see Setting Up the Transparent Data Encryption Wallet to enable TDE.

• In step 4, if the database is deployed on ASM storage, for example:

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

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

1. A placeholder target database must be created before database migration begins.

   Ensure that the shape chosen for creating the database from the console can accommodate the source database plus any future sizing requirements. A good guideline is to use a shape similar or larger in size than source database.

   The target database db_name should be same as the source database db_name, and 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.

2. The SYS password must match the source database SYS password.
3. 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.
4. Transparent Data Encryption (TDE) should be enabled and 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).

   SQL> SELECT * FROM v$encryption_wallet;

5. If the target is an Oracle RAC database, then you must set up SSH connectivity without a passphrase between the Oracle RAC servers for the oracle user.
6. 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.
7. Make sure adequate storage is provisioned and available on the object store to accommodate the source database backup.
8. Verify that ports 22 and 1521 on the target servers are open and not blocked by a firewall.

• The placeholder target database is overwritten during migration, but it retains the overall configuration.
• If the target database environment is at a higher patch level than the source database (for example, if the source database is at Oct 2018 PSU/BP and the target database is at Jan 2019 PSU/BP), then you must run datapatch after database migration.
• For Exadata Cloud Service, the target environment must be installed with latest DBaaS Tooling RPM.
• Provision the target database from the console without enabling automatic backups.

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

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

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

For the Oracle Data Guard setup and sync, open SQL*Net (DB Ports, Scan ports) between the source (on-premises databases or Oracle Cloud Infrastructure Classic instances) and the target instance on Oracle Cloud Infrastructure, Exadata Cloud at Customer, or Exadata Cloud Service. For example, 1521 is the database port on the Oracle Cloud Infrastructure target.

Zero Downtime Migration service host

Source and Target

TCP

22

SSH

Authentication-based operations to run Zero Downtime Migration operational phases. Source and Target nodes should accept incoming connections from the Zero Downtime Migration service host.

Source

Target

TCP

1521

SQL*Net

Should allow Oracle client connections to the database over Oracle's SQL*Net protocol to perform database queries, Data Guard sync and configuration.

Note: If you are using a non-default port number (that is, something other than port 1521) for the local listener address, then the non-default port should allow connections.

Target

Source

TCP

1521

SQL*Net

Should allow Oracle client connections to the database over Oracle's SQL*Net protocol.

Allows redo log shipping if on-premises database needs to be in sync with the new primary on Oracle Cloud after switchover. If there is no communication possible from Oracle Cloud to on-premises host then set SKIP_FALLBACK to TRUE in the response file to avoid this communication.

Note: If you are using a non-default port number (that is, something other than port 1521) for the local listener address, then the non-default port should allow connections.

Source

Oracle Cloud Object Store Service

SSL

443

Create a backup of the source database to the specified Oracle Cloud Object store bucket.

If the chosen backup method involves Oracle Cloud Object Store Service as the backup medium, then access ports as documented Oracle Cloud Object Store Service applies.

Target

Oracle Cloud Object Store Service

SSL

443

Restore backup of the source database from the specified Oracle Cloud Object store bucket to the target.

If the chosen backup method involves Oracle Cloud Object Store Service as the backup medium, then access ports as documented Oracle Cloud Object Store Service applies.