Zero Downtime Migration permissions and ownership of files and directories, and handling of configurations for security features, are equivalent to those of Oracle Database. Zero Downtime Migration installs in a location, named ZDM_HOME, that is structured similarly to the Oracle home directory, ORACLE_HOME, for Oracle Database. The permissions and ownership of files and directories in the ZDM_HOME follow the same conventions as that of a database ORACLE_HOME. Zero Downtime Migration also creates a base directory structure for storing Zero Downtime Migration configuration files, logs, and other artifacts, named ZDM_BASE, that is similar to an Oracle base directory, ORACLE_BASE, that is associated with an Oracle home. The structure, owners, and permissions of directories and files in ZDM_BASE are similar to that of an ORACLE_BASE. ZDM_BASE and ORACLE_BASE do not allow access by group or others. You do not need to do any additional steps to ensure security the of the Zero Downtime Migration configuration because the Zero Downtime Migration configuration is designed to be secure out of the box. Zero Downtime Migration is configured to accept JMX connections only from the local host, and to listen on the loopback address for HTTP connections. Zero Downtime Migration operations can only be performed by the operating system user that installed the product. For physical migrations, SSH connectivity from the Zero Downtime Migration service host to the source database server and the target database server is required. You must provide the SSH key file location as an input for a migration job, and the existence of this file is expected for the duration of the migration job. You must manage the security of the directories and files where these key files are located. You can modify the communication ports when there is a port conflict with another application. Note that access to these ports are configured only from within the Zero Downtime Migration host. You can change the RMI and HTTP port properties in the file $ZDM_BASE/crsdata/zdm_service_host/rhp/conf/standalone_config.properties. The properties are:
Restart the Zero Downtime Migration service after changing the properties. When Zero Downtime Migration operations require passwords, prompts are given for password entry by default. Zero Downtime Migration can also operate non-interactively by entering wallet information in the migration response file settings. Passwords are encrypted and stored in the Zero Downtime Migration database. Provided passwords are not expected to change for the duration of a migration job. From an operation perspective, Zero Downtime Migration follows the guidelines in Oracle Database Security Guide for handling source and target database configurations for migration, such as Oracle Wallets, Transparent Data Encryption, and so on. Page 2If a host has not had Zero Downtime Migration software installed on it previously, verify that it complies with the requirements and perform any pre-installation tasks, then download and install the software. Once the software is installed, the host is referred to as the Zero Downtime Migration service host. Provision a host with the following prerequisites and complete the following pre-installation tasks before installing Zero Downtime Migration software on it.
Page 3Host * ServerAliveInterval 10 ServerAliveCountMax 2 Host OCI_server_name HostName OCI_server_IP_address IdentityFile Private_key_file_location User OCI_user_login ProxyCommand /usr/bin/nc -X connect -x proxy_name:proxy_port %h %p Where
Note that the proxy setup might not be required when you are not using a proxy server for connectivity. For example, when the source database server is on Oracle Cloud Infrastructure Classic, you can remove or comment the line starting with ProxyCommand. For example, after specifying the relevant values, the /root/.ssh/config file should be similar to the following. Host * ServerAliveInterval 10 ServerAliveCountMax 2 Host ocidb1 HostName 192.0.2.1 IdentityFile /root/.ssh/ocidb1.ppk User opc ProxyCommand /usr/bin/nc -X connect -x www-proxy.example.com:80 %h %pThe file permissions should be similar to the following. /root/.ssh>ls -l config -rw------- 1 root root 1679 Oct 16 10:05 configIn the above example, the Oracle Cloud Infrastructure server name is ocidb1, and the Oracle Cloud Infrastructure server public IP address is 192.0.2.1. If the source is an Oracle Cloud Infrastructure Classic server, the proxy_name is not required, so you can remove or comment the line starting with ProxyCommand. If the source is an Oracle RAC database, then copy the same /root/.ssh/config file onto all of the source Oracle RAC database servers. This file will have the Oracle Cloud Infrastructure server name, Oracle Cloud Infrastructure server public IP address, and private key file location of first Oracle Cloud Infrastructure Oracle RAC server information configured. Page 4The Zero Downtime Migration physical migration process involves creating a backup of the source database and restoring it to the target database, or using and existing backup.
Oracle Cloud Infrastructure Object Storage OCI Object Storage is supported as a backup medium when migrating a database to Oracle Cloud Infrastructure, Exadata Cloud Service, or any on-premises Exadata Cloud at Customer target. Zero Downtime Migration service either initiates the source database backup as part of the migration work flow, or you can specify an existing backup already in the Object Storage bucket, and Zero Downtime Migration restores it to the target environment, so Object Storage must be accessible from both the source and target environments. The source database is backed up to the specified container and restored to the target using RMAN SQL*Net connectivity. The Zero Downtime Migration service host uses an SSH connection to the source and target database servers to install and configure the backup module software necessary to back up to and restore from Object Storage. The backup from the source database to Object Storage takes place over an RMAN channel. Make sure that the Object Storage bucket is created using the Oracle Cloud Service Console as appropriate. Also, make sure adequate storage is provisioned and available on the object store to accommodate the source database backup. Zero Data Loss Recovery Appliance Zero Data Loss Recovery Appliance is supported as a backup medium for migrating a database to an Exadata Cloud at Customer target or an Oracle Exadata Database Machine. If Zero Data Loss Recovery Appliance is chosen as backup medium, then you must ensure that the Zero Data Loss Recovery Appliance has a valid backup of the source database, because Zero Downtime Migration does not initiate a backup to Zero Data Loss Recovery Appliance as part of the work flow. You must also ensure that all instances of the database are up before initiating a backup to Zero Data Loss Recovery Appliance. The duplicate database operation might fail if the backup is initiated when an instance is down. The Zero Downtime Migration service accesses the backup in Zero Data Loss Recovery Appliance and restores it to Exadata Cloud at Customer. The Zero Data Loss Recovery Appliance access credentials and wallet location are mandatory input parameters, so that Zero Downtime Migration can handle the Zero Data Loss Recovery Appliance wallet setup at the target database. Any transfer of redo stream between the source and the target database server, in either direction, takes place over a SQL*Net link. Refer to the Zero Data Loss Recovery Appliance documentation for information about creating backups. Network File System (NFS) NFS is supported as a backup medium when migrating a database to an Exadata Cloud at Customer target, or any on-premises Oracle Exadata Database Machine target. If you choose to back up the database to an NFS mount, then the Zero Downtime Migration service initiates the source database backup (or you can specify a pre-existing backup) and restores it to the Exadata target environment. The NFS should be accessible from both the source and target environments. The source database is backed up to the specified path and restored to Exadata Cloud at Customer using RMAN SQL*Net connectivity. When you perform a migration using offline migration through NFS, SQL*Net connectivity between the source and target are not needed. Page 5
In Zero Downtime Migration, you can specify objects to include or exclude from a logical migration job using parameters in the response file.
Specify rules for objects to include or exclude in a migration job using the EXLCUDEOBJECTS-n and INCLUDEOBJECTS-n response file parameters. You can either include or exclude objects in a migration, but you cannot do both. If no rule is defined, all schemas and objects of the source database will be migrated, with exceptions listed in What Is Migrated During Initial Load. If you specify Include rules, the migration will only move the specified objects and their dependent objects; all other objects are automatically excluded. USER and TABLESPACE_QUOTA objectType associated with included schema are included by default. When specifying Exclude rules, the migration will exclude the specified objects and their dependent objects; all other objects are included in the migration. You can define multiple include or exclude rules by incrementing the integer appended to the parameter name, as shown in these examples. Example of a single include rule: INCLUDEOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1 Example of two exclude rules: EXCLUDEOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1 EXCLUDEOBJECTS-2=owner:ownerValue2, objectName:objectNameValue2, objectType:objectTypeValue2
Required Parameter Fields To specify INCLUDEOBJECTS-n and EXLCUDEOBJECTS-n response file parameters, enter values for each of the following fields:
You can filter owner and objectName fields using any valid pattern in Java class Pattern. For example, you can enter .* in the objectName field to select objects of any name.
Supported objectTypes for object-level filtering objectName can be chosen or can be .* DIRECTORY FUNCTION JOB MATERIALIZED_VIEW PACKAGE PROCEDURE TRIGGER SEQUENCE TABLE
Supported objectTypes for generic objectType-level exclude or include (objectName must be .*)CLUSTER DB_LINK GRANT OBJECT_GRANT SYSTEM_GRANT ROLE_GRANT PROCOBJ_GRANT PROCDEPOBJ_GRANT INDEX INDEXTYPE MATERIALIZED_VIEW_LOG MATERIALIZED_ZONEMAP POST_TABLE_ACTION PROCOBJ PROFILE REF_CONSTRAINT RLS_POLICY SYNONYM TABLESPACE TABLESPACE_QUOTA USER XMLSCHEMA VIEW
Example 5-1 Include all objects of schema MySchema INCLUDEOBJECTS-1=owner:MySchema, objectName:.*, objectType:ALL
Example 5-2 Include all tables starting with PROD and procedure MYPROC of schema MySchema, including all dependent objects INCLUDEOBJECTS-1=owner:MySchema, objectName:PROD.*, objectType:TABLE INCLUDEOBJECTS-2=owner:MySchema, objectName:MYPROC, objectType:PROCEDURE
Example 5-3 Exclude schemas starting with Experimental, the table MySchema.OldTable (also excluding all dependent objects) and all objects of type DB_LINK Note that MySchema.OldTable will not be excluded if a table called OldTable is present in a different schema that is also migrated. EXCLUDEOBJECTS-1=owner:Experimental.*, objectName:.*, objectType:ALL EXCLUDEOBJECTS-2=owner:MySchema, objectName:OldTable, objectType:TABLE EXCLUDEOBJECTS-3=owner:.*, objectName:.*, objectType:DB_LINK
Specify Included and Excluded Objects with Special Characters The following examples show you how to specify objects names that use special characters in the EXCLUDEOBJECTS and INCLUDEOBJECTS parameters.
Migrating Tables with support_mode = INTERNAL Zero Downtime Migration detects and notifies you about tables with support_mode = INTERNAL. DML replication: Oracle GoldenGate automaticallys ignore DML for support_mode = INTERNAL tables. Zero Downtime Migration does not set GoldenGate Extract parameter TABLEEXCLUDE for tables with support_mode = INTERNAL. Global Temporary Tables are always excluded. DDL replication: If you set parameter GOLDENGATESETTINGS_REPLICATEDDL = TRUE, then Zero Downtime Migration sets Oracle GodenGate Extract parameter DDLOPTIONS CAPTUREGLOBALTEMPTABLE.
Migrating Tables with support_mode = ID KEY Under normal operation Zero Downtime Migration reports an error listing all user tables with Oracle GoldenGate support_mode = ID KEY. If you set parameter GOLDENGATESETTINGS_USEFLASHBACKQUERY = TRUE, Zero Downtime Migration sets the following Oracle GoldenGate Extract parameters that allow ID KEY support mode objects to be replicated.
Ensure that the source database has sufficient UNDO size to allow Oracle GoldenGate to use Flashback Query. For best fetch results, configure the source database as documented at Setting Flashback Query in Using Oracle GoldenGate with Oracle Database. Page 6
Ensure that the subnet Amazon RDS security policy allows connections from Zero Downtime Migration to the DB instance on the specified secure port. See the AWS documentation for details: Scenarios for accessing a DB instance in a VPC Scenarios for accessing a DB instance not in a VPC
Setting Endpoint Information
Allowing Zero Downtime Migration to connect to Amazon RDS Oracle DB instance using SSL/TLS
Page 7You can get data from one or more user actions and use that data to run another user action. For example, you can perform an action on the source database and use that data to perform an action on the target database.
When adding a user action, you can use the -outputfrom option to provide the list of user actions whose output will be supplied to the user action being added. In the following example there are two user actions already registered in Zero Downtime Migration, USERAC1 and USERAC2, both of which generate some output. This output can be used by a third user action, USERAC3, by listing them with the -outputfrom option, as shown here. $ZDM_HOME/bin/zdmcli add useraction -useraction USERAC3 -actionscript useractionscript.sh -outputfrom USERAC1,USERAC2Accessing the Data The output file is copied to the same location where the useraction file runs from, so the content of the output file can be accessed from the same location.
Example User Actions in an Autonomous Database Migration The following example shows how to get DDL output from the source database, and runs it on the target database. User action get_ddl1 runs on the source database and generates DDL output. $ZDM_HOME/bin/zdmcli add useraction -useraction get_ddl1 -phase ZDM_VALIDATE_SRC -pre -optype MIGRATE_DATABASE -runscope ONENODE -onerror ABORT -actionscript /home/useraction1.shUser action table_fromddl runs on the target database, and uses the output from user action get_ddl1. $ZDM_HOME/bin/zdmcli add useraction -useraction table_fromddl -phase ZDM_VALIDATE_TGT -pre -optype MIGRATE_DATABASE -runscope ONENODE -onerror ABORT -actionscript /home/useraction2.sh -outputfrom get_ddl1Adding both user actions to an imagetype: $ZDM_HOME/bin/zdmcli add imagetype -imagetype OUTPUTIMG1 -basetype CUSTOM_PLUGIN -useractions get_ddl1,table_fromddlContent of useraction1.sh: #!/bin/sh for var in $@ do if [[ $var == *"ZDM_SRCDBHOME="* ]] then IFS='=' read -ra PATHARR <<< "$var" SRCDBHOME=${PATHARR[1]} fi if [[ $var == *"LOG_PATH"* ]] then IFS='=' read -ra PATHARR <<< "$var" LOGPATH=${PATHARR[1]} fi done echo $SRCDBHOME; ORACLE_HOME=$SRCDBHOME; export ORACLE_HOME; ORACLE_SID=zdm1121; export ORACLE_SID; export TMPLOG=/tmp/tmptmp.log; true>$TMPLOG; export PATH=$ORACLE_HOME/bin:$PATH #echo "home is $ORACLE_HOME"; $ORACLE_HOME/bin/sqlplus -s / as sysdba 2>> $TMPLOG << EOF > /tmp/testlog whenever sqlerror exit 1 SET PAGESIZE 60 SET LINESIZE 1300 SET VERIFY OFF TRIMSPOOL ON HEADING OFF TERMOUT OFF FEEDBACK OFF spool ${TMPLOG} append; select dbms_metadata.get_ddl('TABLE', 'TEST1') from DUAL; spool off EOF SQLRETURN=$? if [ "$SQLRETURN" -ne "0" ]; then echo "Failed to run $SQLRETURN"; fi sed -i 's/PCTFREE 10 PCTU//g' $TMPLOG; echo "$(cat $TMPLOG)";Content of useraction2.sh: select name from v$database; @:ACTION_OUTPUT_DIR/ZDM_VALIDATE_SRC_PRE_get_ddl1.out; select name from v$database;Example User Actions in a Co-Managed Database Migration For this example, the add useraction and add imagetype commands are same as above in the Autonomous Database use case, but the script contents are different. Content of useraction1.sh #!/bin/sh for var in $@ do if [[ $var == *"ZDM_SRCDBHOME="* ]] then IFS='=' read -ra PATHARR <<< "$var" SRCDBHOME=${PATHARR[1]} fi done ORACLE_HOME=$SRCDBHOME; export ORACLE_HOME; ORACLE_SID=zdmsrc1; export ORACLE_SID; export TMPLOG=/tmp/tmptmp.log; true>$TMPLOG; export PATH=$ORACLE_HOME/bin:$PATH #echo "home is $ORACLE_HOME"; $ORACLE_HOME/bin/sqlplus -s / as sysdba 2>> $TMPLOG << EOF > /tmp/testlog whenever sqlerror exit 1 SET PAGESIZE 60 SET LINESIZE 1300 SET VERIFY OFF TRIMSPOOL ON HEADING OFF TERMOUT OFF FEEDBACK OFF spool ${TMPLOG} append; select dbms_metadata.get_ddl('TABLE', 'TEST1') from DUAL; spool off EOF SQLRETURN=$? if [ "$SQLRETURN" -ne "0" ]; then echo "Failed to run $SQLRETURN"; fi echo "$(cat $TMPLOG)";Content of useraction2.sh: #!/bin/sh for var in $@ do if [[ $var == *"ZDM_TARGETDBHOME="* ]] then IFS='=' read -ra PATHARR <<< "$var" TARGETDBHOME=${PATHARR[1]} fi done CURR_DIR=$(dirname "$(readlink -f "$0")") export OUTPUTFILE=$CURR_DIR/get_ddl1.out; # export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1; ORACLE_HOME=$TARGETDBHOME; export ORACLE_HOME; ORACLE_SID=zdmnov19; export ORACLE_SID; export TMPLOG=/tmp/tmptmp.log; sed -i 's/PCTFREE 10 PCTUS//g' $OUTPUTFILE; export OUTPUT=$(cat $OUTPUTFILE); echo $OUTPUT; echo "">$TMPLOG; $ORACLE_HOME/bin/sqlplus -s / as sysdba 2>> $TMPLOG << EOF > /tmp/testlog whenever sqlerror exit 1 SET PAGESIZE 60 SET LINESIZE 1300 SET VERIFY OFF TRIMSPOOL ON HEADING OFF TERMOUT OFF FEEDBACK OFF spool ${TMPLOG} append; $OUTPUT; spool off EOF echo "$(cat $TMPLOG)"; #SELECT 'NAME: '|| NAME FROM V\$DATABASE;Page 8Before submitting the database migration job for the production database, perform a test migration to determine how the process might fare with your configuration and settings.
It is highly recommended that for each migration job, you first run migrate database in evaluation mode. Evaluation mode allows you to correct any potential problems in the setup and configuration before performing the actual migration on a production database.
In evaluation mode, the migration process runs without effecting the changes. It is safe to run a migration job in evaluation mode as many times as needed before running the actual migration job. The migrate database output indicates the migration job ID, which you can use to query the status of the job. To run an evaluation of the migration job, run the ZDMCLI command migrate database with the -eval option, as shown in the following example. Log in to the Zero Downtime Migration service host and switch to the zdmuser installed user. su - zdmuserIf connectivity to the source database server is done through root credentials then the command would be the following: 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:/usr/bin/sudo -evalFor the prompts, specify the source database SYS password and the source database server root user password. If the backup destination is Object Store (Bucket), then specify user swift authentication token. If the backup destination is Storage Classic (Container) then specify your tenancy login password. For example, zdmuser> $ZDM_HOME/bin/zdmcli migrate database -sourcedb zdmsdb -sourcenode ocicdb1 -srcroot -targetnode ocidb1 -backupuser -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 -eval Enter source database zdmsdb SYS password: Enter source user "root" password: Enter user "" password:If connectivity to the source database server is through SSH key, then the command would be: 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 -evalFor the prompts, specify the source database SYS password. If the backup destination is Object Store (Bucket), then specify user swift authentication token. If the backup destination is Storage Classic (Container), then specify your tenancy login password. 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 -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 -eval Enter source database zdmsdb SYS password: Enter user "" password:Note that if a source single instance database is deployed without a Grid Infrastructure home, then in the above command use -sourcesid in place of -sourcedb. Also, if a source database is configured for a PASSWORD based wallet, then add the -tdekeystorepasswd option to the command above, and for the prompt, specify the source database TDE keystore password value. Note that the –backupuser argument takes the Object Storage access user or Zero Data Loss Recovery Appliance VPC user, and is skipped if NFS is the backup medium. For NFS, the source database user should have ‘rwx’ access to the NFS path provided. The migration command checks for patch compatibility between the source and target home patch level, and expects the target home patch level to be equal to or higher than the source. If the target home patch level is not as expected, then the migration job is stopped and missing patches are reported. You can either patch the target home with the necessary patches or you can force continue the migration by appending the –ignore PATCH_CHECK or -ignore ALL option to the migration command. When you run migrate database with -eval, Zero Downtime Migration only runs a subset of the migration job phases. For example, a logical migration job run with -eval would only run the following phases: ZDM_VALIDATE_SRC ZDM_VALIDATE_TGT ZDM_SETUP_SRC ZDM_PRE_MIGRATION_ADVISOR ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT ZDM_PREPARE_DATAPUMP_SRC ZDM_DATAPUMP_ESTIMATE_SRC ZDM_CLEANUP_SRC The migrate database output indicates the job ID for the migration job, which you can use to query the status of the job. If you want to run the command without providing passwords at the command line, see Providing Passwords Non-Interactively Using a Wallet. Page 9You can discover and set the port number that Zero Downtime Services uses for MySQL.
MySQL Default Port Number Zero Downtime Migration uses MySQL internally, configuring it by default on port 3306. If a port number is not specified and the default is not available, Zero Downtime Migration increases the port value by one and retries up to five times. Finding the Current Port Number Run zdmservice status to see the current MySQL port number in the connection string, as shown here. zdmuser> $ZDM_HOME/bin/zdmservice status Conn String: jdbc:mysql://localhost:8897/Changing the Port Number You can change this default to another value using the zdmservice modify mysqlPort=port option. zdmuser> $ZDM_HOME/bin/zdmservice modify mysqlPort=portPage 10
If your migration job fails, the following logs can help you discover the issue. Migration Job Output Logs If your migration job encounters an error, refer to the migration job output logs, Zero Downtime Migration service logs, and server-specific operational phase logs present at the respective source or target database servers. If the migration job encounters an exception (that is, fails) then the logs can provide some indication of the nature of the fault. The logs for the migration procedures executed in the source and target environments are stored on the servers in the respective source and target environments. The Zero Downtime Migration command output location is provided to you when the migration job is run with the ZDMCLI command migrate database. You can also find the log file location (Result file path) in the output of the ZDMCLI command query job -jobid job-id. Zero Downtime Migration Service Host Log Determine which operational phase the migration job was in at the time of failure, and whether the phase belongs to the source (phase name contains SRC) or target (phase name contains TGT) . Check the Zero Downtime Migration service host log at $ZDM_BASE/crsdata/zdm_service_host/rhp/zdmserver.log.0, and access the respective source or target server to check the log associated with the operational phase in $ORACLE_BASE/zdm/zdm_db_unique_name_job-id/zdm/log. If the Zero Downtime Migration service does not start, then check the Zero Downtime Migration service logs for process start-up errors to determine the cause of the error reported. The Zero Downtime Migration service log can be found at $ZDM_BASE/crsdata/zdm_service_host/rhp/zdmserver.log.0. Data Pump Log For logical migration jobs on co-managed target databases, refer to the Data Pump log in the specified DATA_PUMP_DIR. For Autonomous Database targets, the Data Pump logs are uploaded to a data bucket specified with DATAPUMPSETTINGS_DATABUCKET_* in the response file. If the data bucket is not specified, then you will need to upload the dump from Autonomous Database to Object Storage to access it. See How To View Import Log Generated For ADW/ATP (Doc ID 2448060.1) If a migration job fails, you can fix the cause of the failure and then re-run the job while monitoring the logs for progress. Page 11
Zero Downtime Migration lets you configure connectivity to the source and target database servers through a bastion host for both physical and logical migration work flows. Note that a bastion host cannot be used to connect to an Autonomous Database, except for JDBC connections. Use the following sections to configure the appropriate parameters for physical and logical migrations that must connect to the source or target database server through a bastion host.
SSH Connection to Database Servers Connecting database servers through a bastion host requires the following information:
Physical Migration Response File Parameters Configure the following response file parameters for a physical migration. Source Database Server SRC_BASTION_HOST_IP= SRC_BASTION_PORT= SRC_BASTION_USER= SRC_BASTION_IDENTITY_FILE= SRC_HOST_IP= Target Database Server TGT_BASTION_HOST_IP= TGT_BASTION_PORT= TGT_BASTION_USER= TGT_BASTION_IDENTITY_FILE= TGT_HOST_IP=
Logical Migration Response File Parameters Configure the following response file parameters for a logical migration. Source Database Server SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IP= SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_PORT= SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IDENTITYFILE= SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_USERNAME= SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_REMOTEHOSTIP= Target Database Server (including Autonomous Database) TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IP= TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_PORT=22 TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IDENTITYFILE= TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_USERNAME= TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_REMOTEHOSTIP= Page 12
Zero Downtime Migration does not always require encryption at the source (although, all Cloud databases are encrypted by default). The following tables list specific cases when encryption is not required.
Table B-1 On-Premises Unencrypted Primary and Cloud Encrypted Standby
Table B-2 Cloud Encrypted Primary and On-Premises Unencrypted Standby
Page 13You 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.
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). Wallet Creation Examples The following examples show how to create auto-login wallets for the source database SYS user, the Object Store user, the source database TDE keystore, and the target CDB database 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:
To create an auto-login wallet for the Object Store user:
To create an auto-login wallet for the source database TDE keystore:
To create an auto-login wallet for the target CDB database TDE keystore password:
Accessing the Wallets in a Logical Migration Job In a logical migration you configure the wallet parameters using the RSP WALLET_* parameters appropriate for your migration use case. See the following links for details about the individual parameters. Accessing the Wallets in a Physical Migration Job In a physical migration you configure the wallet parameters as options in the ZDMCLI database migration command. See migrate database for information about the database migration options.
Note that 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. 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
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 -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 -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".Page 14
ZDM_VALIDATE_TGT Both Verifies that the target database exists, discovers the database type, and validates access credentials, security, and connectivity. For an Autonomous Database target, sets up the access to the target database from the Zero Downtime Migration node by downloading the target database access wallet with OCI REST services and discovers the target OCPU. Online only: verifies ggadmin user privileges. Page 15
The following topics describe the Zero Downtime Migration response file parameters used in physical migrations.
BACKUP_PATH specifies a valid path accessible at the source and target for migration backup type.
DATA_TRANSFER_MEDIUM specifies the media used for the source database backup, or you can specify a direct data transfer method.
DATAPATCH_WITH_ONE_INSTANCE_RUNNING specifies whether or not to stop all instances except one running on the target database server when the datapatch utility is run. When datapatch completes all of the stopped instances are started.
HOST specifies the cloud storage REST endpoint URL to access Oracle Cloud Object Storage.
Usage Notes To access Oracle Cloud Object Storage, you must set both the HOST and OPC_CONTAINER parameters.
MAX_DATAPATCH_DURATION_MINS specifies a timeout value, in minutes, after which if the datapatch utility has failed to complete then the operation is stopped.
MIGRATION_METHOD specifies whether the migration uses Oracle Data Guard (online) or backup and restore (offline).
NONCDBTOPDB_CONVERSION indicates whether to convert a source database from non-CDB to PDB or skip the conversion.
NONCDBTOPDB_SWITCHOVER, for a physical migration using Data Guard switchover, indicates whether the switchover operations will be executed during a migration job with non-CDB to PDB conversion enabled.
OPC_CONTAINER specifies the Object Storage bucket (called the container on Oracle Cloud Infrastructure Classic), and is set to access Oracle Cloud Object Storage.
Usage Notes To access Oracle Cloud Object Storage, you must set both the HOST and OPC_CONTAINER parameters. The bucket is also referred to as a container for Oracle Cloud Infrastructure Classic storage.
PLATFORM_TYPE specifies the target database platform.
SHUTDOWN_SRC specifies whether or not to shut down the source database after migration completes.
SKIP_FALLBACK specifies whether or not to ship redo logs from the primary (target) database to the standby (source) database, either voluntarily or because there is no connectivity between the target and source database servers.
SKIP_SRC_SERVICE_RETENTION specifies whether or not to retain the source database services and run them on the target database. This parameter is only effective for the BACKUP_RESTORE_OSS and BACKUP_RESTORE_NFS migration methods.
SRC_BASTION_HOST_IP specifies the bastion host IP address, if you want to connect to the source database server using a bastion host.
Usage Notes If you want to connect to the source database server using a bastion host, values for the bastion host IP address parameter, SRC_BASTION_HOST_IP, and the source database host IP address parameter, SRC_HOST_IP, are required in the Zero Downtime Migration response file. If you do not want to use the default value, set the following parameters for bastion host connection. SRC_BASTION_PORT - The port number defaults to 22 if not specified. SRC_BASTION_USER - The bastion host source user is only required if the user specified for the source zdmauth plug-in is different from the user of the source bastion host. The bastion user defaults to the user specified for the source zdmauth plug-in if the parameter is not specified. SRC_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the source zdmauth plug-in.
SRC_BASTION_IDENTITY_FILE specifies the bastion user, if you want to connect to the source database server using a bastion host.
Usage Notes If you want to connect to the source database server using a bastion host, values for the bastion host IP address parameter, SRC_BASTION_HOST_IP, and the source database server IP address parameter, SRC_HOST_IP, are required in the Zero Downtime Migration response file. If you do not want to use the default value, set the following parameters for bastion host connection. SRC_BASTION_PORT - The port number defaults to 22 if not specified. SRC_BASTION_USER - The bastion host source user is only required if the user specified for the source zdmauth plug-in is different from the user of the source bastion host. The bastion user defaults to the user specified for the source zdmauth plug-in if the parameter is not specified. SRC_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the source zdmauth plug-in.
SRC_BASTION_PORT specifies the bastion host port number, if you want to connect to the source database server using a bastion host.
Usage Notes If you want to connect to the source database server using a bastion host, values for the bastion host IP address parameter, SRC_BASTION_HOST_IP, and the source database server IP address parameter, SRC_HOST_IP, are required in the Zero Downtime Migration response file. If you do not want to use the default value, set the following parameters for bastion host connection. SRC_BASTION_PORT - The port number defaults to 22 if not specified. SRC_BASTION_USER - The bastion host source user is only required if the user specified for the source zdmauth plug-in is different from the user of the source bastion host. The bastion user defaults to the user specified for the source zdmauth plug-in if the parameter is not specified. SRC_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the source zdmauth plug-in.
SRC_BASTION_USER specifies the bastion user, if you want to connect to the source database server using a bastion host.
Usage Notes If you want to connect to the source database server using a bastion host, values for the bastion host IP address parameter, SRC_BASTION_HOST_IP, and the source database server IP address parameter, SRC_HOST_IP, are required in the Zero Downtime Migration response file. If you do not want to use the default value, set the following parameters for bastion host connection. SRC_BASTION_PORT - The port number defaults to 22 if not specified. SRC_BASTION_USER - The bastion host source user is only required if the user specified for the source zdmauth plug-in is different from the user of the source bastion host. The bastion user defaults to the user specified for the source zdmauth plug-in if the parameter is not specified. SRC_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the source zdmauth plug-in.
SRC_CONFIG_LOCATION specifies the SSH configuration file location on the Zero Downtime Migration service host (host where Zero Downtime Migration service is running).
Usage Notes Set SRC_CONFIG_LOCATION to the full path of the SSH configuration file location on the Zero Downtime Migration service host, for example, /home/crsuser/.ssh/config.
SRC_DB_LISTENER_PORT indicates the source database listener port. Set this property when there is Standalone Database (no Grid Infrastructure) configured with non-default SCAN listener port other than 1521.
SRC_HOST_IP specifies the bastion user, if you want to connect to the source database server using a bastion host.
Usage Notes If you want to connect to the source database server using a bastion host, values for the bastion host IP address parameter, SRC_BASTION_HOST_IP, and the source database server IP address parameter, SRC_HOST_IP, are required in the Zero Downtime Migration response file. If you do not want to use the default value, set the following parameters for bastion host connection. SRC_BASTION_PORT - The port number defaults to 22 if not specified. SRC_BASTION_USER - The bastion host source user is only required if the user specified for the source zdmauth plug-in is different from the user of the source bastion host. The bastion user defaults to the user specified for the source zdmauth plug-in if the parameter is not specified. SRC_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the source zdmauth plug-in.
SRC_HTTP_PROXY_PORT specifies the HTTPS proxy port number on the source database server if an SSH connection needs to connect using a proxy.
SRC_HTTP_PROXY_URL specifies the HTTPS proxy URL on the source database server if an SSH connection needs to connect using a proxy.
SRC_OSS_PROXY_HOST specifies the Object Storage Service proxy host on the source database server if a proxy is needed for connecting to the Object Store.
Usage Notes Set both the SRC_OSS_PROXY_HOST and SRC_OSS_PROXY_PORT parameters if a proxy is needed for connecting to the Object Store.
SRC_OSS_PROXY_PORT specifies the Object Storage Service proxy port number on the source database server if a proxy is needed for connecting to the Object Store.
Usage Notes Set both the SRC_OSS_PROXY_HOST and SRC_OSS_PROXY_PORT parameters if a proxy is needed for connecting to the Object Store.
SRC_PDB_NAME indicates the source database PDB name.
SRC_RMAN_CHANNELS specifies the number of RMAN channels to be allocated at the source database server for performing RMAN backups.
SRC_SSH_RETRY_TIMEOUT specifies a timeout value, in minutes, after which Zero Downtime Migration stops attempting SSH connections after an initial failure to connect.
SRC_TIMEZONE specifies the source database server time zone, which is needed for SIDB case when there is no Grid Infrastructure configured.
SRC_ZDLRA_WALLET_LOC specifies the path of the Zero Data Loss Recovery Appliance wallet on the source database server.
Usage Notes When using Zero Data Loss Recovery Appliance as the migration backup medium, you must set the following parameters. SRC_ZDLRA_WALLET_LOC TGT_ZDLRA_WALLET_LOC ZDLRA_CRED_ALIAS
TGT_BASTION_HOST_IP specifies the bastion host IP address, if you want to connect to the target database server using a bastion host.
Usage Notes If you want to connect to the target database server using a bastion host, you are required to configure values for the bastion host IP address parameter, TGT_BASTION_HOST_IP, and the target database server IP address parameter, TGT_HOST_IP, in the Zero Downtime Migration response file. If you do not want to use the default values for the remaining bastion connection parameters, set the following parameters to configure the bastion host connection. TGT_BASTION_PORT - The port number defaults to 22 if not specified. TGT_BASTION_USER - The bastion host target user is only required if the user specified for the target zdmauth plug-in is different from the user of the target bastion host. The bastion user defaults to the user specified for the target zdmauth plug-in if the parameter is not specified. TGT_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the target zdmauth plug-in.
TGT_BASTION_IDENTITY_FILE specifies the bastion user, if you want to connect to the target database server using a bastion host.
Usage Notes If you want to connect to the target database server using a bastion host, you are required to configure values for the bastion host IP address parameter, TGT_BASTION_HOST_IP, and the target database server IP address parameter, TGT_HOST_IP, in the Zero Downtime Migration response file. If you do not want to use the default values for the remaining bastion connection parameters, set the following parameters to configure the bastion host connection. TGT_BASTION_PORT - The port number defaults to 22 if not specified. TGT_BASTION_USER - The bastion host target user is only required if the user specified for the target zdmauth plug-in is different from the user of the target bastion host. The bastion user defaults to the user specified for the target zdmauth plug-in if the parameter is not specified. TGT_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the target zdmauth plug-in.
TGT_BASTION_PORT specifies the bastion host port number, if you want to connect to the target database server using a bastion host.
Usage Notes If you want to connect to the target database server using a bastion host, you are required to configure values for the bastion host IP address parameter, TGT_BASTION_HOST_IP, and the target database server IP address parameter, TGT_HOST_IP, in the Zero Downtime Migration response file. If you do not want to use the default values for the remaining bastion connection parameters, set the following parameters to configure the bastion host connection. TGT_BASTION_PORT - The port number defaults to 22 if not specified. TGT_BASTION_USER - The bastion host target user is only required if the user specified for the target zdmauth plug-in is different from the user of the target bastion host. The bastion user defaults to the user specified for the target zdmauth plug-in if the parameter is not specified. TGT_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the target zdmauth plug-in.
TGT_BASTION_USER specifies the bastion user, if you want to connect to the target database server using a bastion host.
Usage Notes If you want to connect to the target database server using a bastion host, you are required to configure values for the bastion host IP address parameter, TGT_BASTION_HOST_IP, and the target database server IP address parameter, TGT_HOST_IP, in the Zero Downtime Migration response file. If you do not want to use the default values for the remaining bastion connection parameters, set the following parameters to configure the bastion host connection. TGT_BASTION_PORT - The port number defaults to 22 if not specified. TGT_BASTION_USER - The bastion host target user is only required if the user specified for the target zdmauth plug-in is different from the user of the target bastion host. The bastion user defaults to the user specified for the target zdmauth plug-in if the parameter is not specified. TGT_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the target zdmauth plug-in.
TGT_CONFIG_LOCATION specifies the SSH configuration file location on the Zero Downtime Migration service host (host where Zero Downtime Migration service is running).
Usage Notes Set TGT_CONFIG_LOCATION to the full path of the SSH configuration file location on the Zero Downtime Migration service host, for example, /home/crsuser/.ssh/config.
TGT_DATAACFS specifies the location for the data files ACFS volume (data) on the target database. Use only if required to override the values discovered automatically by Zero Downtime Migration.
Usage Notes Zero Downtime Migration discovers the location for ASM and ACFS data, redo, and reco storage volumes from the specified target database, making these target database storage properties optional. If you need to override the values automatically discovered by Zero Downtime Migration, then you can set the following parameters. For example, TGT_DATADG=+DATAC3 For ASM use these parameters TGT_DATADG TGT_REDODG TGT_RECODG For ACFS use these parameters TGT_DATAACFS TGT_REDOACFS TGT_RECOACFS
TGT_DATADG specifies the location for the data files ASM disk group (data) on the target database. Use only if required to override the values discovered automatically by Zero Downtime Migration.
Usage Notes Zero Downtime Migration discovers the location for ASM and ACFS data, redo, and reco storage volumes from the specified target database, making these target database storage properties optional. If you need to override the values automatically discovered by Zero Downtime Migration, then you can set the following parameters. For example, TGT_DATADG=+DATAC3 For ASM use these parameters TGT_DATADG TGT_REDODG TGT_RECODG For ACFS use these parameters TGT_DATAACFS TGT_REDOACFS TGT_RECOACFS
TGT_DB_UNIQUE_NAME is used by Zero Downtime Migration to identify the target database.
Usage Notes Set TGT_DB_UNIQUE_NAME to the target database DB_UNIQUE_NAME value. 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.
TGT_HOST_IP specifies the bastion user, if you want to connect to the target database server using a bastion host.
Usage Notes If you want to connect to the target database server using a bastion host, you are required to configure values for the bastion host IP address parameter, TGT_BASTION_HOST_IP, and the target database server IP address parameter, TGT_HOST_IP, in the Zero Downtime Migration response file. If you do not want to use the default values for the remaining bastion connection parameters, set the following parameters to configure the bastion host connection. TGT_BASTION_PORT - The port number defaults to 22 if not specified. TGT_BASTION_USER - The bastion host target user is only required if the user specified for the target zdmauth plug-in is different from the user of the target bastion host. The bastion user defaults to the user specified for the target zdmauth plug-in if the parameter is not specified. TGT_BASTION_IDENTITY_FILE - If not specified, the value defaults to the value specified for the identity_file argument of the target zdmauth plug-in.
TGT_HTTP_PROXY_PORT specifies the HTTPS proxy port if an SSH connection needs to use a proxy to connect to the target database server.
Usage Notes Set both the TGT_HTTP_PROXY_URL and TGT_HTTP_PROXY_PORT parameters if the SSH connection needs to use an HTTPS proxy to connect to the target database server.
TGT_HTTP_PROXY_URL specifies the HTTPS proxy URL if an SSH connection needs to use a proxy to connect to the target database server.
Usage Notes Set both the TGT_HTTP_PROXY_URL and TGT_HTTP_PROXY_PORT parameters if the SSH connection needs to use an HTTPS proxy to connect to the target database server.
TGT_OSS_PROXY_HOST specifies the Object Storage Service proxy host on the target database server if a proxy is needed for connecting to the Object Store.
Usage Notes Set both the TGT_OSS_PROXY_HOST and TGT_OSS_PROXY_PORT parameters if a proxy is needed for connecting to the Object Store.
TGT_OSS_PROXY_PORT specifies the Object Storage Service proxy port number on the target database server if a proxy is needed for connecting to the Object Store.
Usage Notes Set both the TGT_OSS_PROXY_HOST and TGT_OSS_PROXY_PORT parameters if a proxy is needed for connecting to the Object Store.
TGT_RECOACFS specifies the location for the fast recovery area ACFS volume (reco) on the target database. Use only if required to override the values discovered automatically by Zero Downtime Migration.
Usage Notes Zero Downtime Migration discovers the location for ASM and ACFS data, redo, and reco storage volumes from the specified target database, making these target database storage properties optional. If you need to override the values automatically discovered by Zero Downtime Migration, then you can set the following parameters. For example, TGT_DATADG=+DATAC3 For ASM use these parameters TGT_DATADG TGT_REDODG TGT_RECODG For ACFS use these parameters TGT_DATAACFS TGT_REDOACFS TGT_RECOACFS
TGT_RECODG specifies the location for the fast recovery area ASM disk group (reco) on the target database. Use only if required to override the values discovered automatically by Zero Downtime Migration.
Usage Notes Zero Downtime Migration discovers the location for ASM and ACFS data, redo, and reco storage volumes from the specified target database, making these target database storage properties optional. If you need to override the values automatically discovered by Zero Downtime Migration, then you can set the following parameters. For example, TGT_DATADG=+DATAC3 For ASM use these parameters TGT_DATADG TGT_REDODG TGT_RECODG For ACFS use these parameters TGT_DATAACFS TGT_REDOACFS TGT_RECOACFS
TGT_REDOACFS specifies the location for redo log files ACFS volume (redo) on the target database. Use only if required to override the values discovered automatically by Zero Downtime Migration.
Usage Notes Zero Downtime Migration discovers the location for ASM and ACFS data, redo, and reco storage volumes from the specified target database, making these target database storage properties optional. If you need to override the values automatically discovered by Zero Downtime Migration, then you can set the following parameters. For example, TGT_DATADG=+DATAC3 For ASM use these parameters TGT_DATADG TGT_REDODG TGT_RECODG For ACFS use these parameters TGT_DATAACFS TGT_REDOACFS TGT_RECOACFS
TGT_REDODG specifies the location for redo log files ASM disk group (redo) on the target database. Use only if required to override the values discovered automatically by Zero Downtime Migration.
Usage Notes Zero Downtime Migration discovers the location for ASM and ACFS data, redo, and reco storage volumes from the specified target database, making these target database storage properties optional. If you need to override the values automatically discovered by Zero Downtime Migration, then you can set the following parameters. For example, TGT_DATADG=+DATAC3 For ASM use these parameters TGT_DATADG TGT_REDODG TGT_RECODG For ACFS use these parameters TGT_DATAACFS TGT_REDOACFS TGT_RECOACFS
TGT_RETAIN_DB_UNIQUE_NAME specifies whether to ship redo logs from Oracle Cloud to the on-premises standby, observe the environment for some time, and remove the fallback later.
When TGT_RETAIN_DB_UNIQUE_NAME=TRUE then the workflow phase ZDM_RETAIN_DBUNIQUENAME_TGT is present as the final phase. You must pause the migration job at a prior phase and resume the job when the fallback has to be removed.
TGT_RMAN_CHANNELS specifies the number of RMAN channels to be allocated at the target database server for performing RMAN restore.
TGT_SKIP_DATAPATCH specifies whether or not Zero Downtime Migration runs the datapatch utility on the target database as part of the post-migration tasks.
Usage Notes 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 set the TGT_SKIP_DATAPATCH parameter to FALSE to allow Zero Downtime Migration to run the datapatch utility on the target database as part of the post-migration tasks. Otherwise, set the parameter to TRUE, and if the target database environment is at a higher patch level than the source database, you will need to run the datapatch utility manually after the migration.
TGT_SSH_RETRY_TIMEOUT specifies the number of minutes during which retries are attempted after SSH connection failures. Retries stop when the timeout value has elapsed.
TGT_SSH_TUNNEL_PORT specifies the forwarding port on the source database server where the SSH tunnel to the target database server for SQL*Net connection is set up.
TGT_ZDLRA_WALLET_LOC specifies the path of the Zero Data Loss Recovery Appliance wallet on the target database server.
Usage Notes When using Zero Data Loss Recovery Appliance as the migration backup medium, you must set the following parameters. SRC_ZDLRA_WALLET_LOC TGT_ZDLRA_WALLET_LOC ZDLRA_CRED_ALIAS
ZDLRA_CRED_ALIAS specifies the Zero Data Loss Recovery Appliance wallet credential alias.
Usage Notes When using Zero Data Loss Recovery Appliance as the migration backup medium, you must set the following parameters. SRC_ZDLRA_WALLET_LOC TGT_ZDLRA_WALLET_LOC ZDLRA_CRED_ALIAS
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL specifies the time interval, in minutes, at which to monitor and report the progress of the ZDM_BACKUP_DIFFERENTIAL_SRC migration job phase.
Usage Notes The migration job phase monitoring interval parameters, listed below, monitor and report the backup and restore operations progress at the set time interval, specified in minutes. Note that the migration job phase for which the monitoring interval applies is prefixed to _MONITORING_INTERVAL in each parameter listed above.
To disable a monitoring interval parameter, set it to 0 (zero). Note that for parameters that are interval based, if the results are not in the job logs, check the specific phase logs for the monitoring information.
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL specifies the time interval, in minutes, at which to monitor and report the progress of the ZDM_BACKUP_FULL_SRC migration job phase.
Usage Notes The migration job phase monitoring interval parameters, listed below, monitor and report the backup and restore operations progress at the set time interval, specified in minutes. Note that the migration job phase for which the monitoring interval applies is prefixed to _MONITORING_INTERVAL in each parameter listed above.
To disable a monitoring interval parameter, set it to 0 (zero). Note that for parameters that are interval based, if the results are not in the job logs, check the specific phase logs for the monitoring information.
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL specifies the time interval, in minutes, at which to monitor and report the progress of the ZDM_BACKUP_INCREMENTAL_SRC migration job phase.
Usage Notes The migration job phase monitoring interval parameters, listed below, monitor and report the backup and restore operations progress at the set time interval, specified in minutes. Note that the migration job phase for which the monitoring interval applies is prefixed to _MONITORING_INTERVAL in each parameter listed above.
To disable a monitoring interval parameter, set it to 0 (zero). Note that for parameters that are interval based, if the results are not in the job logs, check the specific phase logs for the monitoring information.
ZDM_BACKUP_RETENTION_WINDOW specifies the number of days after which backups created by Zero Downtime Migration become obsolete.
ZDM_BACKUP_TAG specifies an RMAN backup tag that can be used to perform a database migration or create a backup.
Use cases: Set ZDM_USE_EXISTING_BACKUP=TRUE to use the specified RMAN backup in ZDM_BACKUP_TAG as the full backup, to skip the full backup phase in a migration job. An error is thrown if the backup associated with the specified tag is not valid. Set ZDM_USE_EXISTING_BACKUP=FALSE if you wish to create a backup with the specified tag in ZDM_BACKUP_TAG
ZDM_CLONE_TGT_MONITORING_INTERVAL specifies the time interval, in minutes, at which to monitor and report the progress of the ZDM_CLONE_TGT migration job phase.
Usage Notes The migration job phase monitoring interval parameters, listed below, monitor and report the backup and restore operations progress at the set time interval, specified in minutes. Note that the migration job phase for which the monitoring interval applies is prefixed to _MONITORING_INTERVAL in each parameter listed above.
To disable a monitoring interval parameter, set it to 0 (zero). Note that for parameters that are interval based, if the results are not in the job logs, check the specific phase logs for the monitoring information.
ZDM_CURL_LOCATION specifies a custom location for the CURL binary on the source.
ZDM_LOG_OSS_PAR_URL specifies the pre-authenticated URL to use when uploading logs to Object Storage Service. The logs capture the current migration job phase and the execution status of the phase.
ZDM_OPC_RETRY_COUNT specifies the number of retry attempts tat will be made after an initial Object Store connection failure.
ZDM_OPC_RETRY_WAIT_TIME specifies the number of seconds to wait after an Object Store connection failure before attempting to retry the connection.
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL specifies the time interval, in minutes, at which to monitor and report the progress of the ZDM_OSS_RECOVER_TGT migration job phase.
Usage Notes The migration job phase monitoring interval parameters, listed below, monitor and report the backup and restore operations progress at the set time interval, specified in minutes. Note that the migration job phase for which the monitoring interval applies is prefixed to _MONITORING_INTERVAL in each parameter listed above.
To disable a monitoring interval parameter, set it to 0 (zero). Note that for parameters that are interval based, if the results are not in the job logs, check the specific phase logs for the monitoring information.
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL specifies the time interval, in minutes, at which to monitor and report the progress of the ZDM_OSS_RESTORE_TGT migration job phase.
Usage Notes The migration job phase monitoring interval parameters, listed below, monitor and report the backup and restore operations progress at the set time interval, specified in minutes. Note that the migration job phase for which the monitoring interval applies is prefixed to _MONITORING_INTERVAL in each parameter listed above.
To disable a monitoring interval parameter, set it to 0 (zero). Note that for parameters that are interval based, if the results are not in the job logs, check the specific phase logs for the monitoring information.
ZDM_RMAN_COMPRESSION_ALGORITHM specifies which RMAN compression algorithm to use for backups.
ZDM_RMAN_DIRECT_METHOD specifies the RMAN method (restore from service or active duplicate) to use when DATA_TRANSFER_MEDIUM=DIRECT data transfer method is specified.
You must also set the ZDM_SRC_DB_RESTORE_SERVICE_NAME parameter if you configure a physical migration using direct data transfer (DATA_TRANSFER_MEDIUM=DIRECT). See Direct Data Transfer Support for more information about using direct data transfer in a physical migration
ZDM_SHARD_ID is used to ensure that a migration job is running or is being resumed in the correct intended pod.
In a scenario where Zero Downtime Migration is scaled out to service multiple simultaneous migrations, each ZDM server has its own metadata store, which means that the same migration job ID values could be repeated across multiple ZDM servers. To avoid job ID conflicts which could cause the incorrect job to be resumed on the incorrect ZDM server, the ZDM_SHARD_ID for each job will be configured contain the ZDM host name to which the migration job is being sent. This value will be seeded by E2E during RSP creation. The value of ZDM_SHARD_ID and the other RSP tokens will be used by ZDM to confirm that the job metadata matches the RSP file values for the source and target database properties to ensure the correct job ID and ZDM server are resumed. If the value from ZDM_SHARD_ID in the response file is set, and it does not match the current host name, the following exception is thrown: PRGZ-#### : Specified shard ID zdm_host_name_a does not match with current ZDM host zdm_host_name_b. in which den01gl is the value read from the response file, and den01glt is the current pod's host name
ZDM_SKIP_DG_CONFIG_CLEANUP indicates whether Zero Downtime Migration should clean up the Oracle Data Guard configuration from the source and target databases at the end of the migration when using online physical migration.
ZDM_SRC_DB_RESTORE_SERVICE_NAME specifies the fully qualified name of the service on the source database to be used for an online physical migration (MIGRATION_METHOD=ONLINE_PHYSICAL) using direct data transfer (DATA_TRANSFER_MEDIUM=DIRECT).
You must also set the ZDM_RMAN_DIRECT_METHOD parameter if you configure a physical migration using direct data transfer (DATA_TRANSFER_MEDIUM=DIRECT). See Direct Data Transfer Support for more information about using direct data transfer in a physical migration
ZDM_SRC_TNS_ADMIN specifies the custom location for TNS_ADMIN on the source database server when there is no Oracle Grid Infrastructure. If a Grid Infrastructure exists, then the TNS_ADMIN property must be set in the CRS resource attribute environment of the database resource.
Specifies the connect string of the standby database when ZDM_USE_EXISTING_STANDBY is enabled.
Indicates whether Zero Downtime Migration can use an Oracle Data Guard broker configuration to manage database role switchover.
ZDM_USE_EXISTING_BACKUP indicates whether Zero Downtime Migration can use an existing RMAN backup to perform a database migration.
If this parameter is set to TRUE, you must also set parameter ZDM_BACKUP_TAG. If no value is provided for ZDM_BACKUP_TAG, and ZDM_USE_EXISTING_BACKUP=TRUE an error is thrown.
Indicates whether Zero Downtime Migration can use an existing standby database to instantiate the standby in the target environment in a physical migration.
Optional parameters to set when ZDM_USE_EXISTING_STANDBY is enabled: ZDM_STANDBY_DB_NAME ZDM_STANDBY_DB_CONNECT_STRING See Using an Existing Standby to Instantiate the Target Database.
ZDM_USE_EXISTING_UNDO_SIZE specifies whether Zero Downtime Migration should use the existing undo tablespace size when creating a new undo tablespace, if required.
Page 16
Zero Downtime Migration response file parameters supported for logical migrations.
Specifies how data will be transferred from the source database system to the target database system.
See also Configuring the Transfer Medium and Specifying Transfer Nodes
Indicates whether to create a new OCI Auth Token.
If you are not using a network database link for Data Pump Import, an OCI Auth Token is created for the specified OCI user to import Data Pump dump files from the Object Storage into an Autonomous Database. To reuse an existing Auth Token, set this property to FALSE.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the name of the database link from the OCI database to the on-premise database.
Zero Downtime Migration creates the database link if the link does not already exist.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. The DATAPUMPSETTINGS_DATABASELINKDETAILS_* parameters are optional details for creating a network database link from OCI database to the on-premise database.
Specifies the OCI Object Storage bucket.
The DATAPUMPSETTINGS_DATABASELINKDETAILS_WALLETBUCKET_* parameters are used with Autonomous Database migration targets. These parameters settings specify the OCI Object Storage details used to store the wallet containing the certificate for on-premise database to create a database link from the Autonomous Database to the on-premise database using TLS. Not required for a TCP connection from Autonomous Database to the on-premise database.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the Object Storage namespace.
The DATAPUMPSETTINGS_DATABASELINKDETAILS_WALLETBUCKET_* parameters are used with Autonomous Database migration targets. These parameters settings specify the OCI Object Storage details used to store the wallet containing the certificate for on-premise database to create a database link from the Autonomous Database to the on-premise database using TLS. Not required for a TCP connection from Autonomous Database to the on-premise database.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
In lieu of a network database link, the OCI Object Storage bucket specified in DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME is used to store Data Pump dump files for migrating to an Autonomous Database.
DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME is one of the optional settings for logical migrations using Data Pump. Use with DATAPUMPSETTINGS_DATABUCKET_NAMESPACENAME
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
In lieu of a network database link, the OCI Object Storage bucket specified with DATAPUMPSETTINGS_DATABUCKET_NAMESPACENAME is used to store Data Pump dump files for migrating to an Autonomous Database.
DATAPUMPSETTINGS_DATABUCKET_NAMESPACENAME is one of the optional settings for logical migrations using Data Pump. Use with DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the STATISTICS method for Data Pump dump size estimation.
Zero Downtime Migration estimates the Data Pump dump size using the BLOCKS or STATISTICS methods. You are expected to apply discretion in arriving at the FILESYSTEM space required for the dump path, considering other factors that affect the actual dump size expected. The estimated dump size and actual size varies based on the data compression applied on the data in the database.
Note that by default, Zero Downtime Migration performs estimation using the BLOCKS method as part of the precheck and as part of the actual migration part of phase ZDM_DATAPUMP_ESTIMATE_SRC.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Specifies the action to be performed when data is loaded into a preexisting table.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
For EXPORT and Network IMPORT, if set to a nonzero value for schema-mode operations, specifies that the metadata to re-create the user's schemas should also be part of the operation.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETER_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Specifies the maximum number of worker processes that can be used for a Data Pump Import job.
For migration to an Autonomous Database target, Zero Downtime Migration automatically queries its CPU core count and sets this parameter.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Specifies the maximum number of worker processes that can be used for a Data Pump Import job.
For migration to an Autonomous Database target, Zero Downtime Migration automatically queries its CPU core count and sets this parameter.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Specifies a comma separated list of object types to exclude.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Example DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXCLUDETYPELIST=cluster,dblink,comment
Specifies whether actions that were "in progress" on a previous execution of the job are skipped when the job restarts.
This mechanism allows you to skip actions that trigger fatal bugs and cause the premature termination of a job. Multiple actions can be skipped on a restart. The log file identifies which actions are skipped. The skip is only honored for Import jobs. If a domain index was being processed, all pieces of the domain index are skipped, even if the error only occurred in a sub-component of the domain index.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Specifies whether all Data Pump workers are started on the current instance or on instances usable by the job.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Specifies whether to retain the index.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs. DATAPUMPSETTINGS_DATAPUMPPARAMETERS_* are optional parameters for Data Pump Export and Import. See SET_PARAMETER Procedures for more information.
Indicates whether to retain dump files which are uploaded to Object Storage as part of the migration.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the object name of a directory on server file system of an on-premises database.
In lieu of a network database link, a directory on the server file system of an on-premises database, specified with the DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_* properties is used to store Data Pump Export dump files. Zero Downtime Migration creates this object if it does not already exist
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the object path of a directory on server file system of an on-premises database.
In lieu of a network database link, a directory on the server file system of an on-premises database, specified with the DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_* properties is used to store Data Pump Export dump files. Zero Downtime Migration creates this object if it does not already exist
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies whether invalid objects are recompiled in the database as part of the migration job.
Migration can result in invalid schema objects. Typically, invalid objects fix themselves as they are accessed or run. However, Oracle recommends that invalid objects are recompiled in the database as part of the Zero Downtime Migration migration job so that issues with invalid objects, and any required dependencies, are resolved before users encounter these invalid objects.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the path of an import directory object.
In lieu of a network database link, a directory on the server file system of OCI database is used to store Data Pump dump files. Zero Downtime Migration creates this object if it does not already exist. For Autonomous Database migration targets, the DATA_PUMP_DIR object will already exist.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the name of an import directory object.
In lieu of a network database link, a directory on the server file system of OCI database is used to store Data Pump dump files. Zero Downtime Migration creates this object if it does not already exist. For Autonomous Database migration targets, the DATA_PUMP_DIR object will already exist.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the Data Pump export mode.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Defines the name, the object type, and the value of the filter for the Data Pump METADATA_FILTER property.
To add multiple filters, increment the integer appended to the parameter name, as shown in the examples below. DATAPUMPSETTINGS_METADATAFILTERS-1=name:nameValue1st, objectType:objectTypeValue1st, value:valueValue1st DATAPUMPSETTINGS_METADATAFILTERS-2=name:nameValue2nd, objectType:objectTypeValue2nd, value:valueValue2ndTo exclude select SCHEMA Objects for FULL mode: DATAPUMPSETTINGS_METADATAFILTERS-1=name:NAME_EXPR,value:'NOT IN(' 'SYSMAN' ')',objectType:SCHEMA DATAPUMPSETTINGS_METADATAFILTERS-2=name:NAME_EXPR,value:'NOT IN(' 'SH' ')',objectType:SCHEMANote that the SCHEMA name SYSMAN is surrounded by two single quotes and not a double quote.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Defines remapping to be applied to objects as they are processed.
To add multiple remappings, increment the integer appended to the parameter name, as shown in the examples below. DATAPUMPSETTINGS_METADATAREMAPS-1=type:typeValue1st, oldValue:oldValueValue1st, newValue:newValueValue1st DATAPUMPSETTINGS_METADATAREMAPS-2=type:typeValue2nd, oldValue:oldValueValue2nd, newValue:newValueValue2ndSee METADATA_REMAP Procedure for more information.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Defines the name, the object type, and the value for the Data Pump METADATA_TRANSFORM property.
To add multiple filters, increment the integer appended to the parameter name, as shown in the examples below. DATAPUMPSETTINGS_METADATATRANSFORMS-1=name:nameValue1st, objectType:objectTypeValue1st, value:valueValue1st DATAPUMPSETTINGS_METADATATRANSFORMS-2=name:nameValue2nd, objectType:objectTypeValue2nd, value:valueValue2nd
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the Data Pump monitor interval in minutes. This setting is optional.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Sets TRANSFORM=OMIT_ENCRYPTION_CLAUSE, which directs Data Pump to suppress any encryption clauses associated with objects using encrypted columns.
This parameter is valid for targets on Oracle Database 19c and later releases. OMIT_ENCRYPTION_CLAUSE applies to materialized view, table, and tablespace objects, and enables objects which were using encrypted columns in the source to get created in a target database environment where encryption attributes are not supported.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Sets TRANSFORM=LOB_STORAGE:SECUREFILE, which directs Data Pump to transform basic LOBs into securefile LOBs during the Data Pump import.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the number of schemas to be processed in parallel as batches.
When DATAPUMPSETTINGS_JOBMODE=SCHEMA you can specify the number of schemas to be migrated in parallel. If this count is specified, then Zero Downtime Migration determines the set of schemas included in each batch from the list of user schemas identified from the database. DATAPUMPSETTINGS_SCHEMABATCHCOUNT is mutually exclusive with the DATAPUMPSETTINGS_SCHEMABATCH parameter.
Specifies which schemas are batched together to be migrated in parallel.
When DATAPUMPSETTINGS_JOBMODE=SCHEMA you can specify which schemas are migrated together in parallel as a batch. Increment the -LIST_ELEMENT_NUMBER value to differentiate the batches. In this example there are two batches, each containing two schemas that are migrated in parallel. DATAPUMPSETTINGS_SCHEMABATCH-1=n1,n2 DATAPUMPSETTINGS_SCHEMABATCH-2=n3,n4 DATAPUMPSETTINGS_SCHEMABATCH is mutually exclusive with the DATAPUMPSETTINGS_SCHEMABATCHCOUNT parameter.
Skips default transform parameters.
Set this property to TRUE to avoid all internal Zero Downtime Migration transform defaults.
Parameter Relationships The optional DATAPUMPSETTINGS_* parameters let you customize Oracle Data Pump Export and Import jobs.
Specifies the maximum number of Export dump files to transfer to Object Storage or remote node in parallel.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl.
Specifies the number of times to retry upload or transfer of dump failure.
Intermittent network failures observed during the transfer of Data Pump dumps can mitigated by setting the DUMPTRANSFERDETAILS_RETRYCOUNT parameter.
Parameter Relationships The DUMPTRANSFERDETAILS parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl.
Specifies that the transfer dump files are using the Linux rsync utility.
Ensure rsync is installed in both source and target servers. Oracle Exadata does not ship with rsync, refer to MOS Doc ID 1556257.1 for details. ZDM defaults to scp command for transfer.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl.
Specifies the access key of the Amazon Simple Storage Service (Amazon S3) bucket.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node.
Specifies the name of the Amazon Simple Storage Service (Amazon S3) bucket.
When you set DATA_TRANSFER_MEDIUM=AMAZON3 to migrate an Amazon Web Services RDS Oracle database to Oracle Autonomous Database using an S3 bucket, you must also set the DUMPTRANSFERDETAILS_S3BUCKET_* parameters.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node.
Specifies the region of the Amazon Simple Storage Service (Amazon S3) bucket.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node.
Specifies the Oracle Cloud OCI-CLI Binary path.
Parameter Relationships The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage. The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl.
Specifies the part size in MB for chunked transfer.
Parameter Relationships The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage. The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl.
Specifies the absolute path of the directory to copy or upload dump files.
The DUMPTRANSFERDETAILS_SOURCE_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using Oracle Cloud OCI-CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage.
Specifies the dump transfer node host name.
The DUMPTRANSFERDETAILS_SOURCE_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using Oracle Cloud OCI-CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage.
Specifies the Sudo path on the dump transfer node.
The DUMPTRANSFERDETAILS_SOURCE_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using Oracle Cloud OCI-CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage.
Specifies the user allowed to execute OCI CLI in the dump transfer node.
The DUMPTRANSFERDETAILS_SOURCE_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using Oracle Cloud OCI-CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage.
Specifies the user's authentication key.
The DUMPTRANSFERDETAILS_SOURCE_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using Oracle Cloud OCI-CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage.
Indicates that transfer dump files use Oracle Cloud Infrastructure command line interface (CLI).
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_SOURCE_* parameters specify details to upload the Dump files from source node Data Pump dump location to Oracle Cloud Object Storage.
Specifies the Oracle Cloud Infrastructure command line interface (CLI) Binary path.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the part size in MB for chunked transfer.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the absolute path of the directory to copy or upload dump files.
The DUMPTRANSFERDETAILS_TARGET_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using the OCI CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through Oracle Cloud Infrastructure command line interface (CLI) or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the dump transfer node host name.
The DUMPTRANSFERDETAILS_TARGET_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using OCI CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through Oracle Cloud Infrastructure command line interface (CLI) or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the Sudo path on the dump transfer node.
The DUMPTRANSFERDETAILS_TARGET_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using OCI CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through Oracle Cloud Infrastructure command line interface (CLI) or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the user allowed to execute OCI CLI in the dump transfer node.
The DUMPTRANSFERDETAILS_TARGET_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using OCI CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through Oracle Cloud Infrastructure command line interface (CLI) or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the user's authentication key.
The DUMPTRANSFERDETAILS_TARGET_TRANSFERNODE_* parameters are configured when you use a standalone server as transfer server. Transfer dump files using OCI CLI or curl, or copy to or from a node other than the database server. This option can be leveraged for cases where OCI CLI is installed and configured in a specific node per data center and the node has the Data Pump export or import directory path shared with it. This avoids the requirement of installing OCI CLI on the database node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through Oracle Cloud Infrastructure command line interface (CLI) or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Indicates that transfer dump files use Oracle Cloud Infrastructure command line interface (CLI).
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TARGET_* parameters specify details to download the Dump files to the target node Data Pump dump location from Oracle Cloud Object Storage.
Specifies the absolute path of the directory to copy or upload dump files.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TRANSFERTARGET_* parameters specify details for the target node to copy the Dump files from source node Data Pump dump location or transfer node directory path specified. Default target database host.
DUMPTRANSFERDETAILS_TRANSFERTARGET_HOST specifies the dump transfer node host name.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TRANSFERTARGET_* parameters specify details for the target node to copy the Dump files from source node Data Pump dump location or transfer node directory path specified. Default target database host.
Specifies the Sudo path on the dump transfer node.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TRANSFERTARGET_* parameters specify details for the target node to copy the Dump files from source node Data Pump dump location or transfer node directory path specified. Default target database host.
Specifies the host user name that has write permission to the indicated dump storage path.
The user specified in DUMPTRANSFERDETAILS_TRANSFERTARGET_USER should be allowed to
See Configuring the Transfer Medium and Specifying Transfer Nodes for more information about configuring the dump transfer details parameters.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TRANSFERTARGET_* parameters specify details for the target node to copy the Dump files from source node Data Pump dump location or transfer node directory path specified. Default target database host.
Specifies the user's authentication key.
Parameter Relationships The DUMPTRANSFERDETAILS_* parameters specify details to transfer dumps from the source node to the target node. Supported modes of transfer are OSS and secure copy. Upload of dumps to OSS can be either through OCI CLI or Curl. The DUMPTRANSFERDETAILS_TRANSFERTARGET_* parameters specify details for the target node to copy the Dump files from source node Data Pump dump location or transfer node directory path specified. Default target database host.
Specifies database objects to exclude from migration.
To exclude multiple objects, increment the integer appended to the parameter name, as shown in the examples below. EXCLUDEOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1 EXCLUDEOBJECTS-2=owner:ownerValue2, objectName:objectNameValue2, objectType:objectTypeValue2 See Selecting Objects for Migration for more information about using EXCLUDEOBJECTS.
Specifies the GoldenGate hub administrator user name.
Parameter Relationships For online logical migration, you must set the GOLDENGATEHUB_* parameters to provide Zero Downtime Migration with details about Oracle GoldenGate Microservices configuration.
Specifies the Oracle Cloud identifier of the VM.
Parameter Relationships For online logical migration, you must set the GOLDENGATEHUB_* parameters to provide Zero Downtime Migration with details about Oracle GoldenGate Microservices configuration.
Specifies the name of the GoldenGate Microservices deployment to operate on the source database.
Parameter Relationships For online logical migrations, you must set the GOLDENGATEHUB parameters to provide Zero Downtime Migration with details about Oracle GoldenGate Microservices configuration.
Specifies the name of the GoldenGate Microservices deployment to operate on the target database.
Parameter Relationships For online logical migrations, you must set the GOLDENGATEHUB parameters to provide Zero Downtime Migration with details about Oracle GoldenGate Microservices configuration.
Specifies the Oracle GoldenGate hub's REST endpoint.
Parameter Relationships For online logical migrations, you must set the GOLDENGATEHUB parameters to provide Zero Downtime Migration with details about Oracle GoldenGate Microservices configuration.
Specifies GoldenGate end-to-end latency lag time Zero Downtime Migration monitors GoldenGate end-to-end latency until the lag time is lower than the value (in seconds) specified in GOLDENGATESETTINGS_ACCEPTABLELAG.
Parameter Relationships For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Tunes Oracle GoldenGate Integrated Capture.
Use this setting to automatically configure relevant parameters to achieve the desired throughput and latency.
Parameter Relationships The GOLDENGATESETTINGS_EXTRACT_* parameters define settings for the Integrated Extract process. Only one Extract can be configured. For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Specifies the frequency in seconds with which Oracle GoldenGate checks for long-running transactions.
Parameter Relationships GOLDENGATESETTINGS_EXTRACT_WARNLONGTRANS_* parameters specify a length of time in seconds that a transaction can be open before Extract generates a warning message that the transaction is long-running. The GOLDENGATESETTINGS_EXTRACT_* parameters define settings for the Integrated Extract process. Only one Extract can be configured. For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Specifies a length of time in seconds that a transaction can be open before the GoldenGate Extract process generates a warning message that the transaction is long-running.
Parameter Relationships GOLDENGATESETTINGS_EXTRACT_WARNLONGTRANS_* parameters specify a length of time in seconds that a transaction can be open before Extract generates a warning message that the transaction is long-running. The GOLDENGATESETTINGS_EXTRACT_* parameters define settings for the Integrated Extract process. Only one Extract can be configured. For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Specifies the number of threads used to read GoldenGate trail files.
Valid for Parallel Replicat.
Parameter Relationships The GOLDENGATESETTINGS_REPLICAT_* parameters define settings for the Parallel Replicat process. For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Defines the range in which the GoldenGate Replicat automatically adjusts its apply parallelism.
Valid for Parallel Replicat.
Parameter Relationships The GOLDENGATESETTINGS_REPLICAT_* parameters define settings for the Parallel Replicat process. For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Defines the range in which the GoldenGate Replicat automatically adjusts its apply parallelism.
Valid for Parallel Replicat.
Parameter Relationships The GOLDENGATESETTINGS_REPLICAT_* parameters define settings for the Parallel Replicat process. For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Specifies whether to set Oracle GoldenGate Extract parameter DDLOPTIONS CAPTUREGLOBALTEMPTABLE.
DDL replication: If you set parameter GOLDENGATESETTINGS_REPLICATEDDL = TRUE, then Zero Downtime Migration sets Oracle GodenGate Extract parameter DDLOPTIONS CAPTUREGLOBALTEMPTABLE.
Parameter Relationships For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Specifies whether to set Oracle GoldenGate Extract parameters that allow ID KEY support mode objects to be replicated.
If you set parameter GOLDENGATESETTINGS_USEFLASHBACKQUERY = TRUE, Zero Downtime Migration sets the following Oracle GoldenGate Extract parameters that allow ID KEY support mode objects to be replicated.
Parameter Relationships For online logical migrations, you can set the optional GOLDENGATESETTINGS_* parameters to provide Zero Downtime Migration with details about the Oracle GoldenGate Microservices configuration.
Specifies database objects to include for migration.
To include multiple objects, increment the integer appended to the parameter name, as shown in the examples below. INCLUDEOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1 INCLUDEOBJECTS-2=owner:ownerValue2, objectName:objectNameValue2, objectType:objectTypeValue2 See Selecting Objects for Migration for more information about using INCLUDEOBJECTS.
In a logical migration, specifies whether the migration is online logical or offline logical
The required MIGRATION_METHOD parameter specifies whether the migration is online (Data Pump with Oracle GoldenGate replication) or offline (Data Pump only).
Specifies the OCI region identifier.
Parameter Relationships To call REST APIs, you must configure the OCIAUTHENTICATIONDETAILS_* parameters.
Specifies the fingerprint of the public API key.
See Required Keys and OCIDs for more information.
Parameter Relationships To call REST APIs, you must configure the OCIAUTHENTICATIONDETAILS_* parameters.
Specifies the absolute path of API private key file.
See Required Keys and OCIDs for more information.
Parameter Relationships To call REST APIs, you must configure the OCIAUTHENTICATIONDETAILS_* parameters.
Specifies the OCID of the OCI tenancy.
You can find the tenant OCID on OCI at Governance and Administration, Administration, Tenancy Details. The tenancy OCID is shown under Tenancy Information. Example: ocid1.tenancy.oc1..aaaaaaaaba3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfdsq See Managing the Tenancy and Required Keys and OCIDs for more information.
Parameter Relationships To call OCI REST APIs, you must configure the OCIAUTHENTICATIONDETAILS_* parameters.
Specifies the OCID of the IAM user.
Parameter Relationships To call OCI REST APIs, you must configure the OCIAUTHENTICATIONDETAILS_* parameters.
Specifies the HTTP proxy host name.
Parameter Relationships The OCIPROXY_* parameters specify details about the proxy for connecting to OCI REST endpoints.
Specifies the HTTP proxy port number.
Parameter Relationships The OCIPROXY_* parameters specify details about the proxy for connecting to OCI REST endpoints.
Specifies whether Cloud Premigration Advisor Tool (CPAT) should run on the Zero Downtime Migration service host with a remote connection to the source database. See Running CPAT with a Remote Connection for details.
Specifies the source CDB administrator user name.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_* parameters specify connection details for the source database CDB root.
Specifies the identity file to access the bastion, as part of the database connection details for bastion-based access to the database.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_* parameters specify details for bastion based access to the database.
Specifies the IP address of the source CDB bastion host, as part of the database connection details for bastion-based access to the database.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_* parameters specify details for bastion based access to the database.
Specifies the bastion host port, as part of the database connection details for bastion-based access to the container database (CDB).
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_* parameters specify details for bastion based access to the database.
Specifies the remote host IP address to access from the bastion, as part of the database connection details for bastion-based access to the container database (CDB).
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_* parameters specify details for bastion based access to the database.
Specifies the user name to access the bastion, as part of the database connection details for bastion-based access to the container database (CDB).
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_* parameters specify details for bastion based access to the database.
Specifies the listener host name or IP address for the source container database (CDB).
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root.
Specifies the listener port number for the source container database (CDB).
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root.
Specifies the HTTPS proxy host name for the CDB.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PROXYDETAILS_* parameters specify connection details for the source CDB root through an HTTP proxy.
Specifies the HTTPS proxy host port number for the CDB.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PROXYDETAILS_* parameters specify connection details for the source CDB root through an HTTP proxy.
Specifies the fully qualified source CDB service name.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_* parameters specify connection details for the source database CDB root.
Specifies the directory containing client credentials (wallet, keystore, trustfile, etc.) for the CDB.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_TLSDETAILS_* parameters specify details for TLS connection to the database CDB. These settings are not required if you are using TCP.
Specifies the distinguished name (DN) of the database server (SSL_SERVER_CERT_DN).
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source CDB root. The SOURCECONTAINERDATABASE_CONNECTIONDETAILS_TLSDETAILS_* parameters specify details for TLS connection to the CDB. These settings are not required if you are using TCP.
Specifies the source CDB GoldenGate administrator user name.
Parameter Relationships For online logical migrations, the SOURCECONTAINERDATABASE_* parameters specify connection details for the source database CDB root.
Specifies the source database administrator user name.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies the identity file to access the bastion for bastion-based access to the database.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the IP address of the bastion host for bastion-based access to the database.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the port number of the bastion host for bastion-based access to the database.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the remote host IP address to access from the bastion for bastion-based access to the database.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the user name to access the bastion for bastion-based access to the database.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the source database listener host name or IP address.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies the source database listener port number.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies the proxy host name to connect to the source database through an HTTPS proxy.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the HTTP proxy port number to connect to the source database through an HTTPS proxy.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS parameters specify connection details for the source database.
Specifies the source database fully qualified service name.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies the directory containing client credentials (wallet, keystore, trustfile, etc.) for a TLS connection to the database.
Parameter Relationships The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Specifies the distinguished name (DN) of the database server (SSL_SERVER_CERT_DN) for a TLS connection to the database.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database. The SOURCEDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the source database.
Indicates the type of database to migrate from the specified environment.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies the environment of the source database.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies the GoldenGate administrator user name for online logical migrations.
Parameter Relationships The SOURCEDATABASE_* parameters specify connection details for the source database.
Specifies whether Zero Downtime Migration automatically creates tablespaces at the target database necessary to allocate space in the database to contain schema objects.
Parameter Relationships In a logical migration, the TABLESPACEDETAILS_* parameters specify details that allow Zero Downtime Migration to automatically create the required tablespaces at target database..
Specifies whether Zero Downtime Migration automatically remaps a tablespace at the target database.
See Automatic Tablespace Remap for more information.
Parameter Relationships In a logical migration, the TABLESPACEDETAILS_* parameters specify details that allow Zero Downtime Migration to automatically create the required tablespaces at target database..
Specifies tablespaces to be excluded from automatic creation at the target database.
See Automatic Tablespace Creation for more information.
Parameter Relationships In a logical migration, the TABLESPACEDETAILS_* parameters specify details that allow Zero Downtime Migration to automatically create the required tablespaces at target database..
Specifies an extend size for AUTOEXTEND in support of automatic tablespace creation.
Properly setting TABLESPACEDETAILS_EXTENDSIZEMB enables AUTOEXTEND to avoid extend errors when automatic tablespace creation is enabled. See Automatic Tablespace Creation for more information.
Parameter Relationships In a logical migration, the TABLESPACEDETAILS_* parameters specify details that allow Zero Downtime Migration to automatically create the required tablespaces at target database..
Specifies tablespaces to be remapped.
For a tablespace to be used as REMAP target, the user performing the import operation, for example SYSTEM, should have some quota on the chosen tablespace. See Automatic Tablespace Remap for more information.
Parameter Relationships In a logical migration, the TABLESPACEDETAILS_* parameters specify details that allow Zero Downtime Migration to automatically create the required tablespaces at target database..
Specifies whether to use bigfile tablespaces, if Zero Downtime Migration is configured to create tablespaces automatically.
Using bigfile tablespaces, which can be up to 128 TB, significantly reduces the number of data files for your database. Combined with Oracle Managed Files (OMF), bigfile tablespaces simplify data file management. See Automatic Tablespace Creation for more information.
Parameter Relationships In a logical migration, the TABLESPACEDETAILS_* parameters specify details that allow Zero Downtime Migration to automatically create the required tablespaces at target database..
Specifies the target database administrator user name.
Parameter Relationships The TARGETDATABASE_* parameters specify connection details for the target OCI database.
Specifies the identity file to access the bastion for bastion-based access to the target database.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the IP address of the bastion host for bastion-based access to database.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the port number of the bastion host for bastion-based access to database.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the remote host IP address to access from the bastion for bastion-based access to database.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the user name to access the bastion for bastion-based access to database.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the listener host name or IP address.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS parameters specify connection details for the target OCI database. These properties are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the listener port number.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the proxy host name for connecting to the target database through an HTTPS proxy.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database.
Specifies the HTTP proxy port number for connecting to the source database through an HTTPS proxy.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database.
Specifies the fully qualified service name.
This parameter is optional for Autonomous Database targets; however if an HTTP proxy is required to connect, specify it. In addition, for Oracle Autonomous Database Dedicated Infrastructure and Autonomous Database on Cloud@Customer with fractional OCPU service you must specify the appropriate service alias in the parameter. You can specify any predefined fractional service alias available; however, for Autonomous Transaction Processing workloads TP* services are preferred over LOW* services because LOW* is meant for low priority batch jobs.
See also Connecting to a DB System and About Connecting to a Dedicated Autonomous Database
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database.
Specifies the directory containing client credentials (wallet, keystore, trustfile, etc.) for a TLS connection.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the distinguished name (DN) of the database server (SSL_SERVER_CERT_DN) for a TLS connection.
Parameter Relationships The TARGETDATABASE_CONNECTIONDETAILS_* parameters specify connection details for the target OCI database. These are optional for Autonomous Database; however if an HTTP proxy is required to connect, specify them.
Specifies the GoldenGate administrator user name for online logical migrations.
Parameter Relationships The TARGETDATABASE_* parameters specify connection details for the target OCI database.
Specifies the Oracle Cloud resource identifier.
Parameter Relationships The TARGETDATABASE_* parameters specify connection details for the target OCI database.
Specifies the Amazon S3 Secret Key wallet path.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the OCI Auth Token password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the Data Pump encryption password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the Oracle GoldenGate hub administrative password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the source database administrative user password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the source database administrative c##ggadmin user password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the source database administrative user ggadmin password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the target database administrative admin password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Specifies the absolute path to the directory that contains the auto login wallet file cwallet.sso, which is used to get the target database administrative user ggadmin password.
The path should be resolvable from the Zero Downtime Migration service host.
About the WALLET_* Parameters The WALLET_* parameters specify the full path for the auto login wallet file on the Zero Downtime Migration service host.
Page 17
ZDMCLI is the command line interface for Zero Downtime Migration migration operations. To run ZDMCLI commands, go to the /bin directory in the Zero Downtime Migration software home and enter one of the commands listed in the topics below. For example: zdmuser> $ZDM_HOME/bin/zdmcli migrate databaseTo list help pages for any ZDMCLI command use the -help option. The following command lists the help for all of the ZDMCLI commands. zdmuser> $ZDM_HOME/bin/zdmcli -helpTo get the current release information for your Zero Downtime Migration software, run ZDMCLI with the -build option. zdmuser> $ZDM_HOME/bin/zdmcli -buildThe following topics describe the Zero Downtime Migration ZDMCLI command usage and options.
You can run options on ZDMCLI without specifying a command.
Syntax $ZDM_HOME/bin/zdmcli -option
Options
Table G-1 ZDMCLI Options
Terminates the specified job, if running.
Syntax $ZDM_HOME/bin/zdmcli abort job -jobid job_id
Options
Table G-2 ZDMCLI abort job Options
Configures a new image type of the specified name and its associated user actions.
Syntax $ZDM_HOME/bin/zdmcli add imagetype -imagetype image_type -basetype CUSTOM_PLUGIN [-useractions user_action_list]
Options
Table G-3 ZDMCLI add imagetype Options
Configures a new user action of the specified name with its associated script and action file.
Syntax $ZDM_HOME/bin/zdmcli add useraction -useraction user_action_name -actionscript script_name [-actionfile file_name] {-pre | -post} -optype MIGRATE_DATABASE [-phase operation_phase] [-onerror {ABORT | CONTINUE}] [-runscope {ONENODE | ALLNODES | AUTO}] [-outputfrom useraction_names]
Options
Table G-4 ZDMCLI add useraction Options
Examples For more examples, see Registering User Actions.
Performs a migration of a database to the Oracle Cloud.
Syntax $ZDM_HOME/bin/zdmcli migrate database [-sourcedb source_db_unique_name_value | -sourcesid source_oracle_sid} -rsp zdm_template_path -sourcenode source_host_name -targetnode target_host_name [-targethome target_home] [-eval] [-tdekeystorepasswd [-tgttdekeystorepasswd]] [-tdemasterkey] [-useractiondata user_action_data] [-imagetype] [-backupuser user_name [-restoreuser user_name]] [-backuppasswd] [-dvowner database_vault_owner] [-tdewallet wallet_path [-tgttdewallet wallet_path]] [-tdekeystorewallet tde_wallet_path [-tgttdekeystorewallet tde_wallet_path]] [-sourcesyswallet sys_wallet_path] [-osswallet oss_wallet_path [-ossrestorewallet oss_restore_wallet_path]] [-dvwallet dv_wallet_path] [-backupwallet backup_wallet_path] [{-srcroot | -srccred cred_name | -srcuser user_name | {-srcsudouser sudo_user_name -srcsudopath sudo_binary_path} | {-srcauth plugin_name [-srcarg1 user:source_database_server_login_user_name -srcarg2 identity_file:ZDM_installed_user_private_key_file_location -srcarg3 sudo_location:sudo_location]}}] {-tgtroot | -tgtcred cred_name | -tgtuser user_name | {-tgtsudouser sudo_user_name -tgtsudopath sudo_binary_path} | {-tgtauth plugin_name [-tgtarg1 user:target_database_server_login_user_name -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location -tgtarg3 sudo_location:sudo_location]}} [-schedule {timer_value | NOW}] [-pauseafter phase] [-stopafter phase] [-listphases] [-ignoremissingpatches patch_name [,patch_name...]] [-ignore {ALL | WARNING | PATCH_CHECK | NLS_CHECK | NLS_NCHAR_CHECK | ENDIAN_CHECK}] [-incrementalinterval timer_minutes] [-advisor | -ignoreadvisor | -skipadvisor] [-genfixup {YES | NO}]
Options
Table G-5 ZDMCLI migrate database Options
Examples ZDMCLI migrate database options for an Autonomous Database migration: zdmuser> $ZDM_HOME/bin/zdmcli migrate database -rsp file_path -sourcenode host -srcauth zdmauth -srcarg1 user:username -srcarg2 identity_file:ssh_key_path -srcarg3 sudo_location:sudo_path -eval [-advisor [-ignoreadvisor] | -skipadvisor]]ZDMCLI migrate database options for a co-managed database migration: zdmuser> $ZDM_HOME/bin/zdmcli migrate database -rsp file_path -sourcenode host -srcauth zdmauth -srcarg1 user:username -srcarg2 identity_file:ssh_key_path -srcarg3 sudo_location:sudo_path -targetnode host -tgtauth zdmauth -tgtarg1 user:username -tgtarg2 identity_file:ssh_key_path -tgtarg3 sudo_location:sudo_path -eval [-advisor [-ignoreadvisor] | -skipadvisor]]
Modifies the list of user actions associated with the specified image type.
Syntax $ZDM_HOME/bin/zdmcli modify imagetype -imagetype image_type_name -useractions user_action_list
Options
Table G-6 ZDMCLI modify imagetype Options
Allows you to modify the Oracle GoldenGate Extract and Replicat parameters of a running migration job.
Syntax zdmuser> $ZDM_HOME/bin/zdmcli modify job -jobid job_id -rsp response_file_path
Options
Table G-7 ZDMCLI modify job Options
Modifies the configuration of the user action with the specified name.
Syntax $ZDM_HOME/bin/zdmcli modify useraction -useraction user_action_name [-actionscript script_name] [-actionfile file_name] [-pre | -post] [-optype MIGRATE_DATABASE] [-phase phase] [-onerror {ABORT | CONTINUE}] [-runscope {ONENODE | ALLNODES | AUTO}] [-outputfrom useraction_names]
Options
Table G-8 ZDMCLI modify useraction Options
Displays the migration job audit records.
Syntax $ZDM_HOME/bin/zdmcli query audit [[ [-operation { add | abort | modify | migrate | grant | revoke | query | resume | suspend }] [ -entity { client | role | database | user | audit | imagetype | useraction}] | [-user user_name] [-client client_name] | [-from timestamp -to timestamp] | -before timestamp | -since timestamp | -first number | -last number] | -record record_id | -config]
Options
Table G-9 ZDMCLI query audit Options
Gets the current status of scheduled migration jobs.
Syntax $ZDM_HOME/bin/zdmcli query job [-jobid job_id [-jobtype]] [-sourcenode source_host_name [-sourcedb db_name | -sourcesid sid]] [-targetnode target_host_name] [-latest] [-eval | -migrate] [-status {SCHEDULED | EXECUTING | UNKNOWN | TERMINATED | FAILED | SUCCEEDED | PAUSED | ABORTED}] [-phase] [-dbname database_name] [-since timer_value] [-upto timer_value] [-brief] [-statusonly]
Options
Table G-10 ZDMCLI query job Options
Usage Notes To identify if the current run is a resumption of a PAUSED migration job, a restart of a FAILED migration job, or a fresh start for a migration job, use the following options:
Displays the configuration of a user action.
Syntax $ZDM_HOME/bin/zdmcli query useraction [-useraction user_action_name | -imagetype image_type [-optype MIGRATE_DATABASE]]
Options
Table G-11 ZDMCLI query useraction Options
Resumes a specified job that was paused.
Syntax $ZDM_HOME/bin/zdmcli resume job -jobid job_id [-pauseafter pause_phase | -rsp zdm_logical_template_path] [-rerun {BACKUP|RESTORE}]
Options
Table G-12 ZDMCLI resume job Options
Usage Notes See Resume a Migration Job
The -rerun {BACKUP|RESTORE} option which enables the phase rerun provides you an option to retry backup or restore procedures on failure. You might use this option if
Suspends the specified job if running. Executing suspend job stops the ongoing job at the current work flow phase and allows jobs to be resumed later.
Syntax $ZDM_HOME/bin/zdmcli suspend job -jobid job_id
Options
Table G-13 ZDMCLI suspend job Options
Page 18Previous Next JavaScript must be enabled to correctly display this content
A B D E H K L M O R S T U Z
|
Which two migration methodologies can you use for migrating on-premises databases to autonomous database with Oracle zero downtime migration?
zusammenhängende Posts
Urheberrechte © © 2024 wiewird Inc.
