runbook: move on-premise databases and oracle cloud ... · 4.5 pause and resume a migration job...

Oracle® Zero Downtime MigrationRunbook: Move On-Premise Databases andOracle Cloud Infrastructure Classic Instancesto Exadata Cloud Service

Release 19cF25675-02December 2019

Oracle Zero Downtime Migration Runbook: Move On-Premise Databases and Oracle Cloud InfrastructureClassic Instances to Exadata Cloud Service, Release 19c

F25675-02

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.

Primary Authors: Virginia Beecher, Giridhar Reddy Sangala

This software and related documentation are provided under a license agreement containing restrictions onuse and disclosure and are protected by intellectual property laws. Except as expressly permitted in yourlicense agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify,license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means.Reverse engineering, disassembly, or decompilation of this software, unless required by law forinteroperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. Ifyou find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it onbehalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of theprograms, including any operating system, integrated software, any programs installed on the hardware,and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications.It is not developed or intended for use in any inherently dangerous applications, including applications thatmay create a risk of personal injury. If you use this software or hardware in dangerous applications, then youshall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure itssafe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of thissoftware or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks oftheir respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks areused under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced MicroDevices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,and services from third parties. Oracle Corporation and its affiliates are not responsible for and expresslydisclaim all warranties of any kind with respect to third-party content, products, and services unless otherwiseset forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not beresponsible for any loss, costs, or damages incurred due to your access to or use of third-party content,products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

Documentation Accessibility v

1 About Zero Downtime Migration

2 Prerequisites

2.1 Zero Downtime Migration Service Host Requirements 2-1

2.2 Source and Target Database Requirements 2-1

2.3 Object Storage Requirements 2-4

2.4 SQL*Net Connectivity Between Source and Target Database Servers 2-4

2.5 Port Requirements 2-4

3 Preparing for Database Migration

3.1 Setting Up Zero Downtime Migration Software 3-1

3.2 Configuring Connectivity From the Zero Downtime Migration Service Host tothe Source and Target Database Servers 3-4

3.3 Configuring Connectivity Between the Source and Target Database Servers 3-6

3.4 Prepare the Response File Template 3-12

3.4.1 Preparing a Response File for Online Migration 3-12

3.4.2 Preparing a Response File for Offline Migration (Backup and Recovery) 3-14

3.5 Preparing for Automatic Application Switchover 3-16

3.6 Customizing a Migration Job 3-16

4 Migrate the Database

4.1 Evaluate the Database Migration Process 4-1

4.2 Query the Migration Job Status 4-4

4.3 Migrate the Database 4-5

4.4 List Migration Job Phases 4-7

4.5 Pause and Resume a Migration Job 4-8

iii

4.6 Rerun a Migration Job 4-10

4.7 Post-Migration Tasks 4-10

5 Troubleshooting and Known Issues

6 Additional Information

7 Appendices

7.1 Setting Up the Transparent Data Encryption Wallet 7-1

7.2 Generating a Private SSH Key Without a Passphrase 7-4

7.3 Prechecks Verification 7-5

7.4 List Migration Job Phases 7-6

7.5 Migration Job Output 7-7

iv

Preface

This document describes Zero Downtime Migration prerequisites, the steps to set upthe Zero Downtime Migration service and connectivity, and migrate on-premisesdatabases and Oracle Cloud Infrastructure Classic instances to Exadata CloudService without incurring any significant downtime, by leveraging technologies such asOracle Active Data Guard. Zero Downtime Migration also supports offline migrationusing Backup and Recovery.

• Documentation Accessibility

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the OracleAccessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic supportthrough My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are hearing impaired.

v

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs

1About Zero Downtime Migration

Zero Downtime Migration gives you a way to simplify moving your on-premisedatabases and Oracle Cloud Infrastructure Classic instances to Oracle CloudInfrastructure, Exadata Cloud at Customer, and Exadata Cloud Service, withoutincurring any significant downtime, by leveraging technologies such as Oracle ActiveData Guard.

Zero Downtime Migration uses mechanisms such as backing up the source databaseto Oracle Cloud Infrastructure Object Storage, creating a standby database (withOracle Data Guard Maximum Performance protection mode and asynchronous(ASYNC) redo transport mode) in the target environment from the backup,synchronizing the source and target databases, and switching over to the targetdatabase as the primary database.

1-1

2Prerequisites

Satisfy the following requirements for Zero Downtime Migration.

• Zero Downtime Migration Service Host Requirements

• Source and Target Database Requirements

• Object Storage Requirements

• SQL*Net Connectivity Between Source and Target Database Servers

• Port Requirements

2.1 Zero Downtime Migration Service Host Requirements

Requirement

Description Comments

ZeroDowntimeMigrationservice host

Zero Downtime Migration softwarerequires a Linux host running on OracleLinux 7 or later with 100 GB of freestorage space.

Zero Downtime Migration service hostmust be able to connect with the sourceand target database servers througheither root user or SSH keys.

You cannot perform databasemigration without having establishedconnectivity from the Zero DowntimeMigration service host to the sourcedatabase servers, and from the ZeroDowntime Migration service host to thetarget database servers, so make surethat you meet the requirements in Configuring Connectivity From theZero Downtime Migration Service Hostto the Source and Target DatabaseServers.

2.2 Source and Target Database Requirements

Requirement


Supporteddatabasereleases

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

Both the Source and Target databaserelease versions should be the same.

2-1

Requirement


Sourcedatabaseprerequisites

1. The source database must berunning in archive log mode.

2. For Oracle Database 12c Release2 and later, if the source databasedoes not have Transparent DataEncryption (TDE) enabled, then it ismandatory that you configure theTDE wallet before migrationbegins. The WALLET_TYPE can beAUTOLOGIN (preferred) orPASSWORD based.

3. Ensure that the wallet STATUS isOPEN and WALLET_TYPE isAUTOLOGIN (for an AUTOLOGINwallet type), or WALLET_TYPE isPASSWORD (for a PASSWORD basedwallet type). For a multitenantdatabase, ensure that the wallet isopen on all PDBs as well as theCDB, and the master key is set forall PDBs and the CDB.SQL> SELECT * FROMv$encryption_wallet;

4. If the source is an Oracle RACdatabase, and SNAPSHOTCONTROLFILE is not on a sharedlocation, configure SNAPSHOTCONTROLFILE to point to a sharedlocation on all Oracle RAC nodesto avoid the ORA-00245 errorduring backups to Oracle ObjectStore.

5. Verify that port 22 on the sourceand target database server nodesallow incoming connections fromZero Downtime Migration servicehost.

6. Ensure that the scan listener ports(1521, for example) on the sourcedatabase servers allow incomingconnections from the targetdatabase servers and vice versa.Alternate SQL connectivity shouldbe made available if a firewallblocks incoming remote connectionusing the SCAN listener port.

7. During the migration, disable allRMAN scripts, for example, cronjobs, to avoid multiple RMANbackups.

• If the source database is Oraclerelease 12.2 and later, TDE is notenabled, so see Setting Up theTransparent Data EncryptionWallet to enable TDE.

• In step 4, if the database isdeployed on ASM storage, forexample:$ rman target / RMAN>CONFIGURE SNAPSHOTCONTROLFILE NAME TO'+DATA/snapcf_matrix.f';

If the database is deployed on anACFS file system, specify theshared ACFS location in theabove command.

Chapter 2Source and Target Database Requirements

2-2

Requirement


Targetdatabaseprerequisites

1. A placeholder target database mustbe created before databasemigration begins.

Ensure that the shape chosen forcreating the database from theconsole can accommodate thesource database plus any futuresizing requirements. A goodguideline is to use a shape similaror larger in size than sourcedatabase.

The target database db_nameshould be same as the sourcedatabase db_name, and the targetdatabase db_unique_nameparameter value must be unique, toensure that Oracle Data Guard canidentify the target as a differentdatabase from the sourcedatabase.

2. The SYS password must match thesource database SYS password.

3. The target database version shouldbe the same as the sourcedatabase version. The targetdatabase patch level should alsobe the same as (or higher than) thesource database.

4. Transparent Data Encryption (TDE)should be enabled and ensure thatthe wallet STATUS is OPEN andWALLET_TYPE is AUTOLOGIN (foran AUTOLOGIN wallet type), orWALLET_TYPE is PASSWORD (for aPASSWORD based wallet type).SQL> SELECT * FROMv$encryption_wallet;

5. If the target is an Oracle RACdatabase, then you must set upSSH connectivity without apassphrase between the OracleRAC servers for the oracle user.

6. Check the size of the disk groupsand usage on the target database(ASM disk groups or ACFS filesystems) and make sure adequatestorage is provisioned andavailable on the target databaseservers.

7. Make sure adequate storage isprovisioned and available on the

• The placeholder target databaseis overwritten during migration, butit retains the overall configuration.

• If the target database environmentis at a higher patch level than thesource database (for example, ifthe source database is at Oct2018 PSU/BP and the targetdatabase is at Jan 2019 PSU/BP),then you must run datapatch afterdatabase migration.

• For Exadata Cloud Service, thetarget environment must beinstalled with latest DBaaSTooling RPM.

• For Exadata Cloud Service,provision the target database fromthe console without enablingautomatic backups (in theConfigure database backupssection do not select the Enableautomatic backups option.

Chapter 2Source and Target Database Requirements

2-3

Requirement


object store to accommodate thesource database backup.

8. Verify that ports 22 and 1521 onthe target servers are open and notblocked by a firewall.

2.3 Object Storage Requirements

Requirement


ObjectStoragerequirements

Access to Oracle Cloud Object Storageand permission to create the bucket tohold database backup are required.During the migration job submission,you must have the object store Swifttoken password.

Make sure adequate storage isprovisioned and available on the objectstore to accommodate the sourcedatabase backup.

2.4 SQL*Net Connectivity Between Source and TargetDatabase Servers

Requirement


SQL*Netconnectivitybetweensource andtargetdatabaseservers

For the Oracle Data Guard setup andsync, open SQL*Net (DB Ports, Scanports) between the source (on-premisesdatabases or Oracle CloudInfrastructure Classic instances) andthe target Exadata Cloud Service. Forexample, 1521 is the database port onthe Exadata Cloud Service target.

none

2.5 Port Requirements

Initiator Target Protocol Port Purpose Comments

ZeroDowntimeMigrationservice host

SourceandTarget

TCP 22 SSH Authentication-basedoperations to run ZeroDowntime Migrationoperational phases.Source and Targetnodes should acceptincoming connectionsfrom the Zero DowntimeMigration service host.

Chapter 2Object Storage Requirements

2-4


Source Target TCP 1521 SQL*Net Should allow Oracleclient connections to thedatabase over Oracle'sSQL*Net protocol toperform databasequeries, Data Guardsync and configuration.

Note: If you are using anon-default port number(that is, something otherthan port 1521) for thelocal listener address,then the non-default portshould allowconnections.

Target Source TCP 1521 SQL*Net Should allow Oracleclient connections to thedatabase over Oracle'sSQL*Net protocol.

Allows redo log shippingif on-premises databaseneeds to be in sync withthe new primary onOracle Cloud afterswitchover. If there is nocommunication possiblefrom Oracle Cloud to on-premises host then setSKIP_FALLBACK toTRUE in the responsefile to avoid thiscommunication.

Note: If you are using anon-default port number(that is, something otherthan port 1521) for thelocal listener address,then the non-default portshould allowconnections.

Source OracleCloudObjectStoreService

SSL 443 Create a backup of thesource database to thespecified Oracle CloudObject store bucket.

If the chosen backupmethod involves OracleCloud Object StoreService as the backupmedium, then accessports as documentedOracle Cloud ObjectStore Service applies.

Chapter 2Port Requirements

2-5


Target OracleCloudObjectStoreService

SSL 443 Restore backup of thesource database fromthe specified OracleCloud Object storebucket to the target.

If the chosen backupmethod involves OracleCloud Object StoreService as the backupmedium, then accessports as documentedOracle Cloud ObjectStore Service applies.

Chapter 2Port Requirements

2-6

3Preparing for Database Migration

The following topics describe how to prepare for database migration.

• Setting Up Zero Downtime Migration Software

• Configuring Connectivity From the Zero Downtime Migration Service Host to theSource and Target Database Servers

• Configuring Connectivity Between the Source and Target Database Servers

• Prepare the Response File Template

• Preparing for Automatic Application Switchover

• Customizing a Migration Job

3.1 Setting Up Zero Downtime Migration Software

3-1

Requirement


Set up theZeroDowntimeMigrationsoftware

1. You may use an existing user, or,on the Zero Downtime Migrationservice host, as root user, create azdm group and add zdmuser userto the group.For example

root> groupadd zdm

root> useradd –g zdmzdmuser

Note that you can use any non rootuser to set up Zero DowntimeMigration. For the examples in thisdocument all of the commands areshown run as zdmuser.

2. Download the Zero DowntimeMigration software kit from https://www.oracle.com/database/technologies/rac/zdm-downloads.html to the ZeroDowntime Migration service host.

3. Refer to the README in thedownload for the mandatorypackages and install them.

4. Change to the directory to whereZero Downtime Migration softwareis downloaded.zdmuser> cdzdm_download_directory

Run the Zero Downtime Migrationinstallation script.

zdmuser>./zdminstall.shsetuporaclehome=zdm_oracle_homeoraclebase=zdm_base_directoryziploc=zdm_software_location –zdm

Where zmdinstall.sh is theinstallation script.

oraclehome is the Oracle Homewhere the Zero DowntimeMigration kit is installed.

oraclebase is the base directorywhere all of the Zero DowntimeMigration configuration files, logs,and other artifacts are stored.

ziploc is the location of thecompressed software file (ZIP)included in the Zero DowntimeMigration kit.

Ignore the following messages whichare displayed on the terminal at theend of installation. There is no need torun these scripts."As a root user, execute the followingscript(s):

1. /u01/app/zdmhome/inventory/orainstRoot.sh

2. /u01/app/zdmhome/root.sh"

Chapter 3Setting Up Zero Downtime Migration Software

3-2

https://www.oracle.com/database/technologies/rac/zdm-downloads.html




Requirement


For example,

zdmuser>./zdminstall.shsetup oraclehome=/u01/app/zdmhome

oraclebase=/u01/app/zdmbaseziploc=/u01/app/oracle/zdm/shiphome/zdm_home.zip -zdm

Hereafter, the oraclehome valueis referred to as ZDM_HOME, and theoraclebase value is referred to asZDM_BASE.

5. Start the Zero Downtime Migrationservice as user zdmuser.zdmuser> /u01/app/zdmhome/bin/zdmservicestart

You must start zdmservice beforeyou can migrate your databasesusing Zero Downtime Migration.

6. To stop the Zero DowntimeMigration service, run the followingcommand.zdmuser> /u01/app/zdmhome/bin/zdmservice stop

7. Verify that the Zero DowntimeMigration service installation issuccessful.When you run the followingcommand, the output should besimilar to that shown here.

zdmuser> /u01/app/zdmhome/bin/zdmservicestatus

---------------------------------------

Service Status

---------------------------------------

Running: true

Tranferport: 5000-7000

Conn String:jdbc:derby:/u01/app/zdmbase/derbyRepo;create=true

Repo Path: /u01/app/zdmbase/derbyRepo

RMI port: 8895

Chapter 3Setting Up Zero Downtime Migration Software

3-3

Requirement


HTTP port: 8896

Wallet path: /u01/app/zdmbase/crsdata/fopds/security

3.2 Configuring Connectivity From the Zero DowntimeMigration Service Host to the Source and Target DatabaseServers

Chapter 3Configuring Connectivity From the Zero Downtime Migration Service Host to the Source and Target Database Servers

3-4

Requirement


Configureconnectivityfrom theZeroDowntimeMigrationservice hostto the sourceand targetdatabaseservers

1. On the Zero Downtime Migrationservice host, verify that theauthentication key pairs areavailable without a passphrase forthe Zero Downtime Migrationsoftware installed user.If a new key pair must begenerated without the passphrase,then, as a Zero DowntimeMigration software installed user,generate new key pairs asdescribed in Generating a PrivateSSH Key Without a Passphrase.

2. Rename the private key file.Rename theZDM_installed_user_home/.ssh/id_rsa file name toZDM_installed_user_home/.ssh/ZDM_service_host_name.ppk

3. Add the contents of theZDM_installed_user_home/.ssh/id_rsa.pub file to theopc_user_home/.ssh/authorized_keys file on all of thesource and target databaseservers.Note that the opc user is astandard Oracle Cloud user that isused to access the Oracle CloudInfrastructure Classic and ExadataCloud Service database servers.

4. Add the source and targetdatabase server names and IPaddress details to the ZeroDowntime Migration servicehost /etc/hosts file.For example,

#OCI-C public IP of twonode RAC server details

192.0.2.1 zdm122011

192.0.2.2 zdm122012

#ExaCS public IP of twonode RAC server details

192.0.2.3 exacstarget1

192.0.2.4 exacstarget2

5. Make certain that port 22 in thesource and target database serversaccept incoming connections fromthe Zero Downtime Migrationservice host.

Note 1: If you have root access tosource database server, thenconfiguring connectivity through SSHkeys for the source database server isnot required.Note 2: If you configure connectivitythrough SSH keys, then the ZeroDowntime Migration service hostshould be able to connect to thesource and target database serversusing a private key file, withoutprompting for any password.Note 3: If your Zero DowntimeMigration service host needs proxydetails to connect to the target server,then along with SSH keys you alsoneed to configure theZDM_installed_user_home/.ssh/config with the following details,otherwise configuring theZDM_installed_user_home/.ssh/config file is not required.

catZDM_installed_user_home/.ssh/config

Host *

ServerAliveInterval 10

ServerAliveCountMax 2

Host Target_server_name

HostNameTarget_server_IP_address

IdentityFilePrivate_key_file_location

User Target_user_login

ProxyCommand /usr/bin/nc --proxy proxy_url:port %h %p

For example

Host *



Host exacstarget1

HostName 192.0.2.3

IdentityFile /home/zdmuser/.ssh/zdm_service_host.ppk

User opc

ProxyCommand /usr/bin/nc --proxy www-proxy-example.com:80%h %p

Chapter 3Configuring Connectivity From the Zero Downtime Migration Service Host to the Source and Target Database Servers

3-5

Requirement


6. Test the connectivity from the ZeroDowntime Migration service host toall source and target databaseservers.zdmuser> ssh -iZDM_service_node_private_key_file_locationuser@source/target_database_server_name

For example,

zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppkopc@zdm122011

zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppkopc@zdm122012

zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppkopc@exacstarget1

zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppkopc@exacstarget2

Note 4: The authorized_keys filepermissions should be similar to thefollowing.

/home/opc/.ssh>ls -lauthorized_keys

-rw------- 1 opc opc 1679 Oct16 10:05 authorized_keys

3.3 Configuring Connectivity Between the Source andTarget Database Servers

Chapter 3Configuring Connectivity Between the Source and Target Database Servers

3-6

Requirement


Configureconnectivitybetween thesource andtargetdatabaseservers

You can configure connectivity betweenthe source and target database serversusing one of two options.

Option 1The source database server specified inthe ZDMCLI command -sourcenodeparameter can connect to the targetdatabase instance over target SCANthrough the respective SCAN port andvice versa. The SCAN of the targetshould be resolvable from the sourcedatabase server, and the SCAN of thesource should resolve from the targetserver.

Having connectivity from both sides,you can synchronize between thesource database and target databasefrom either side. If the source databaseserver SCAN cannot be resolved fromthe target database server, then theSKIP_FALLBACK parameter in theresponse file must be set to TRUE, andyou cannot synchronize between thetarget database and source database.

To test the connectivity for Option 1:

1. Test connectivity from the source totarget environments.Add the TNS entry of the targetdatabase to the source databaseserver tnsnames.ora file.

[oracle@zdm122011 ~]tnspingtarget-tns-string

2. Test connectivity from the target tothe source environment.Add the TNS entry of the sourcedatabase to the target databaseserver tnsnames.ora file.

[oracle@exacstarget1~]tnsping source-tns-string

Option 2If connectivity through SCAN and theSCAN port is not possible between thesource and target database servers, setup an SSH tunnel from the sourcedatabase server to the target databaseserver using the procedure below.Using this option, you will not be able tosynchronize between the targetdatabase and source database.

To set up an SSH tunnel on the sourcedatabase servers for the root user:

Ensure that the source databaseserver is able to connect to targetdatabase server without prompting forany password, otherwise Data GuardSync cannot occur from the source tothe target side.


3-7

Requirement


1. Generate a private SSH key filewithout a passphrase for the opcuser on the target server.See Generating a Private SSH KeyWithout a Passphrase.If the target is an Oracle RACdatabase, then generate a privateSSH key file without a passphrasefrom the first Oracle RAC server.

2. Add the contents of the targetserver opc_user_home/.ssh/id_rsa.pub file into the sourceserver opc_user_home/.ssh/authorized_keys file.If the source is an Oracle RACdatabase, add the contents of thetarget serveropc_user_home/.ssh/id_rsa.pub file into theopc_user_home/.ssh/authorized_keys file on allOracle RAC source servers.

3. Copy the target server private SSHkey file onto the source server inthe /root/.ssh/ directory.If the source is an Oracle RACdatabase, copy the file into all ofthe source servers. For bettermanageability, keep the privateSSH key file name the same as thetarget server name, and keepthe .ppk extension. For example,exacstarget1.ppk (whereexacstarget1 is the target servername).The file permissions should besimilar to the following.

/root/.ssh>ls -lexacstarget1t.ppk

-rw------- 1 root root 1679Oct 16 10:05exacstarget1.ppk

4. Put the following entries in thesource server /root/.ssh/config file.Host *



Host Target_server_name

HostNameTarget_server_IP_address


3-8

Requirement


IdentityFilePrivate_key_file_location

User Target_user_login

Where Target_server_name isthe target database server namewithout the domain name. For anOracle RAC database, use the firstOracle RAC server name withoutthe domain name.

Target_server_IP_address isthe target database server IPaddress. For an Oracle RACdatabase use the first Oracle RACserver IP address.

Private_key_file_location isthe location of the private key file.

Target_user_login is the OSuser used to access the targetdatabase servers.For example, after specifying therelevant values, the /root/.ssh/config file contents similar to thefollowing.

Host *



Host exacstarget1

HostName 192.0.2.3

IdentityFile ~/.ssh/exacstarget1.ppk

User opc

The file permissions should besimilar to the following.

/root/.ssh>ls -l config

-rw------- 1 root root 1679Oct 16 10:05 config

In the above example, the targetserver name is exacstarget1, andthe target server public IP addressis 192.0.2.3.If the source is an Oracle RACdatabase, then copy the same /root/.ssh/config file onto all ofthe source Oracle RAC databaseservers.Make sure that you can SSH to firsttarget server from the sourceserver before you enable the SSHtunnel.


3-9

Requirement


For an Oracle RAC database, testthe connection from all of thesource servers to the first targetserver.Test the connectivity using theprivate key file and ensure sourcedatabase server is able to connectto target database server withoutprompting for any password.

[root@zdm122011 ~] ssh -i /root/.ssh/exacstarget1.ppkopc@exacstarget1

[root@zdm122012 ~] ssh -i /root/.ssh/exacstarget1.ppkopc@exacstarget1

5. Run the following command on thesource server to enable the SSHtunnel.ssh -fTarget_hostname_without_domain_name -L \ssh_tunnel_port_number:Target_server_IP_address:Target_server_listener_port-N

WhereTarget_hostname_without_domain_name is the target databaseserver name without a domainname. For an Oracle RACdatabase use the first Oracle RACserver name without domain name.

The ssh_tunnel_port_number isany available ephemeral port in therange (1024-65545). Make surethat the SSH tunnel port is not usedby any other process in the serverbefore using it.

Target_server_listener_portis the target database listener portnumber. The listener port must beopen between the source databaseservers and target servers.

Target_server_IP_address isconfigured based on databasearchitecture. For a single instancedatabase, specify the Target serverIP address. For an Oracle RACdatabase, specify the Target scanname with the domain name.If the scan name with domain nameis not resolvable or not working,


3-10

Requirement


then specify the IP addressobtained using the LSNRCTLSTATUS command output from thetarget server. For example

Listening EndpointsSummary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.9)(PORT=1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.10)(PORT=1521)))

The following is an example of thecommand run to enable the SSHtunel.

[root@zdm122011 ~]ssh -fexacstarget1 -L9001:192.0.2.9:1521 -N

For an Oracle RAC database, thisstep must be repeated on all of thesource servers.

6. Test the connectivity with SSHtunnel for Option 2.For Oracle RAC, this step must berepeated on all of the sourceservers.

Log in to source server, switch tothe oracle user and source thedatabase environment and run thefollowing command.

tnspinglocalhost:ssh_tunnel_port

For example

[oracle@zdm122011 ~]tnsping localhost:9001

The command output is similar tothe following.

TNS Ping Utility for Linux:Version 12.1.0.2.0 -Production on 22-JAN-201905:41:57

Copyright (c) 1997, 2014,Oracle. All rightsreserved.

Used parameter files:


3-11

Requirement


Used HOSTNAME adapter toresolve the alias

Attempting tocontact(DESCRIPTION=(CONNECT_DATA= (SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=9001)))

OK (50 msec)

If tnsping does not work, then theSSH tunnel is not enabled.

3.4 Prepare the Response File TemplatePrepare the response file template according to whether you will perform the migrationonline or offline.

• Preparing a Response File for Online Migration

• Preparing a Response File for Offline Migration (Backup and Recovery)

3.4.1 Preparing a Response File for Online Migration

Chapter 3Prepare the Response File Template

3-12

Requirement


Prepare theresponse filefor onlinemigration

Get the response file templatefrom $ZDM_HOME/rhp/zdm/template/zdm_template.rsp, and edit thefolowing settings.• Set TGT_DB_UNIQUE_NAME to the

target database db_unique_namevalue.

• Set MIGRATION_METHOD toDG_OSS, where DG stands for DataGuard and OSS stands for forObject Storage service.

• Set PLATFORM_TYPE to EXACS.• If an SSH proxy is required to

access the source database serverfrom the Zero Downtime Migrationservice host, setSRC_HTTP_PROXY_URL andSRC_HTTP_PROXY_PORT.

• If an SSH proxy is required toaccess the target database serverfrom the Zero Downtime Migrationservice host, setTGT_HTTP_PROXY_URL andTGT_HTTP_PROXY_PORT.

• If SSH tunneling is set up, set theTGT_SSH_TUNNEL_PORTparameter.

• Specify the target database datafiles storage (ASM or ACFS)properties as appropriate for(TGT_DATADG, TGT_REDODG, andTGT_RECODG) or (TGT_DATAACFS,TGT_REDOACFS, andTGT_RECOACFS).

• Set HOST and OPC_CONTAINERwith the Object Store URL andbucket name.

• Set SKIP_FALLBACK=TRUE if youdo not want to ship redo logs fromthe target to the source standby,either voluntarily or because thereis no connectivity between thetarget and the source.

• Set SHUTDOWN_SRC=TRUE if, afterthe database migration, you wantto shut down the source database.

• Set SRC_RMAN_CHANNELS with thenumber of RMAN channels to beallocated at the source and used toperform RMAN backups. Thedefault is 10.

• Set TGT_RMAN_CHANNELS with thenumber of RMAN channels to be

For example, copy the response fileto $ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rsp andadd values to the settings based onsource and target as shown below.TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=DG_OSS

PLATFORM_TYPE=EXACS

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_SSH_TUNNEL_PORT=9001

TGT_DATADG=+DATAC1

TGT_REDODG=+RECOC1

TGT_RECODG=+RECOC1

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SKIP_FALLBACK=TRUE

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=8

You can find a sample response filein /$ZDM_HOME/rhp/zdm/template/zdm_template.rsp.


3-13

Requirement


allocated at the target and used toperform RMAN restore. The defaultis 10.

3.4.2 Preparing a Response File for Offline Migration (Backup andRecovery)


3-14

Requirement


Prepare theresponse filefor offlinemigration(usingBackup andRecovery)

Get the response file templatefrom $ZDM_HOME/rhp/zdm/template/zdm_template.rsp, and edit thefollowing settings.

• Set TGT_DB_UNIQUE_NAME to thetarget database db_unique_namevalue.

• Set PLATFORM_TYPE to theappropriate value, depending onyour target environment.

• For Exadata Cloud Service, setPLATFORM_TYPE=EXACS.

• Set MIGRATION_METHOD toBACKUP_RESTORE_OSS, where OSSstands for Object Storage Service.

• Specify the target database datafiles storage (ASM or ACFS)properties as appropriate. ForASM, set TGT_DATADG,TGT_REDODG, and TGT_RECODG.For ACFS set TGT_DATAACFS,TGT_REDOACFS, andTGT_RECOACFS.

• If an SSH proxy is required toaccess the source database serverfrom the Zero Downtime Migrationservice host, setSRC_HTTP_PROXY_URL andSRC_HTTP_PROXY_PORT.

• If an SSH proxy is required toaccess the target database serverfrom the Zero Downtime Migrationservice host, setTGT_HTTP_PROXY_URL andTGT_HTTP_PROXY_PORT.

• Set HOST and OPC_CONTAINERwith the Object Store URL andbucket name.

• Set SHUTDOWN_SRC=TRUE if, afterthe database migration, you wantto shut down the source database.

• Set SRC_RMAN_CHANNELS with thenumber of RMAN channels to beallocated at the source and used toperform RMAN backups. Thedefault is 10.

• Set TGT_RMAN_CHANNELS with thenumber of RMAN channels to beallocated at the target and used toperform RMAN restore. The defaultis 10.

For example, copy the response filetemplate to $ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rsp andenter values for the settings based onthe source and target as shown here.

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=BACKUP_RESTORE_OSS

PLATFORM_TYPE=EXACS

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_DATADG=+DATAC1

TGT_REDODG=+RECOC1

TGT_RECODG=+RECOC1

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=8

You can find a sample response filein $ZDM_HOME/rhp/zdm/template/zdm_template.rsp.


3-15

3.5 Preparing for Automatic Application Switchover

Requirement


Prepare forautomaticapplicationswitchover

To minimize or eliminate serviceinterruptions on the application after youcomplete the database migration andswitchover, prepare your application toautomatically switch over connectionsfrom the source database to the targetdatabase.

In the following example connectstring, the application connects to thesource database, and when it is notavailable the connection is switchedover to the target database.

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

On the source database, create theservice, named zdm_prod_svc in theexamples.

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

3.6 Customizing a Migration Job

Chapter 3Preparing for Automatic Application Switchover

3-16

Requirement


Customizethe migrationjob

You can customize the Zero DowntimeMigration workflow by registering actionscripts or plug-ins as pre-actions orpost-actions to be performed as part ofthe operational phases involved in yourmigration job.

The following topics describe how tocustomize a migration job.

Registering Action Plug-insCustom plug-ins must be registered tothe Zero Downtime Migration servicehost to be plugged in as customizationsfor a particular operational phase.

Determine the operational phase thegiven plug-in has to be associated with,and run the ZDMCLI command adduseraction, specifying -optypeMIGRATE_DATABASE and the respectivephase of the operation, whether theplug-in is run -pre or -post relative tothat phase, and any on-errorrequirements. You can register customplug-ins for operational phases afterZDM_SETUP_TGT in the migration jobworkflow.

What happens at runtime if the useraction encounters an error can bespecified with the -onerror option,which you can set to either ABORT, toend the process, or CONTINUE, tocontinue the migration job even if thecustom plug-in exits with an error. Seethe example command usage below.

Use the Zero Downtime Migrationsoftware installed user (for example,zmduser) to add useractions to adatabase migration job. Adding useractions zdmvaltgt and zdmvalsrcwith the add useraction commandwould look like the following.

zdmuser>$ZDM_HOME/bin/zdmcliadd useraction -useractionzdmvaltgt -optypeMIGRATE_DATABASE -phaseZDM_VALIDATE_TGT -pre -onerrorABORT -actionscript /home/zdmuser/useract.sh

zdmuser>$ZDM_HOME/bin/zdmcliadd useraction -useractionzdmvalsrc -optypeMIGRATE_DATABASE -phaseZDM_VALIDATE_SRC -pre -onerror

none

Chapter 3Customizing a Migration Job

3-17

Requirement


CONTINUE -actionscript /home/zdmuser/useract1.sh

In the above command, the scripts /home/zdmuser/useract.sh and /home/zdmuser/useract1.sh arecopied to the Zero Downtime Migrationservice host repository, and they arerun if they are associated with anymigration job run using an actiontemplate.

Creating an Action TemplateAfter the user action plug-ins areregistered, you create an actiontemplate that combines a set of actionplug-ins which can be associated with amigration job.

An action template is created using theZDMCLI command add imagetype,where the image type, imagetype, is abundle of all of the user actions requiredfor a specific type of databasemigration.

Create an image type that associates allof the user action plug-ins needed forthe migration of the database. Oncecreated, the image type can be reusedfor all migration operations for which thesame set of plug-ins are needed.

The base type for the image typecreated here must be CUSTOM_PLUGIN,as shown in the example below.

For example, you can create an imagetype ACTION_ZDM that bundles both ofthe user actions created in the previousexample, zdmvalsrc and zdmvaltgt.

zdmuser>$ZDM_HOME/bin/zdmcliadd imagetype -imagetypeACTION_ZDM -basetypeCUSTOM_PLUGIN -useractionszdmvalsrc,zdmvaltgt

Updating Action Plug-insYou can update action plug-insregistered with the Zero DowntimeMigration service host.

The following example shows you howto modify the user action zdmvalsrc tobe a -post action, instead of a -preaction.

zdmuser>$ZDM_HOME/bin/zdmclimodify useraction -useractionzdmvalsrc -phase


3-18

Requirement


ZDM_VALIDATE_SRC -optypeMIGRATE_DATABASE -post

This change is propagated to all of theassociated action templates, so you donot need to update the actiontemplates.

Associating an Action Template witha Migration JobWhen you run a migration job you canspecify the image type that specifies theplug-ins to be run as part of yourmigration job.

As an example, run the migrationcommand specifying the actiontemplate ACTION_ZDM created inprevious examples, -imagetypeACTION_ZDM, including the image typeresults in running the useract.sh anduseract1.sh scripts as part of themigration job workflow.

By default, the action plug-ins are runfor the specified operational phase onall nodes of the cluster. If the accesscredential specified in the migrationcommand option -tgtarg2 is uniquefor a specified target node, then anadditional auth argument should beincluded to specify the auth credentialsrequired to access the other clusternodes. For example, specify -tgtarg2nataddrfile:auth_file_with_node_and_identity_file_mapping.

A typical nataddrfile for a 2 nodecluster with node1 and node2 is shownhere.

node1:node1:identity_file_path_available_on_zdmservice_node

node2:node2:identity_file_path_available_on_zdmservice_node


3-19

4Migrate the Database

The following topics instruct you on running the migration job.

• Evaluate the Database Migration Process

• Query the Migration Job Status

• Migrate the Database

• List Migration Job Phases

• Pause and Resume a Migration Job

• Rerun a Migration Job

• Post-Migration Tasks

4.1 Evaluate the Database Migration Process

4-1

Requirement


Verifyprechecksand setup

To evaluate the database migrationprocess, use the -eval option with theZDMCLI migrate databasecommand.Have the completed response fileavailable, and have the necessarycredentials ready, such as the sourcedatabase SYS password, Object Store(Bucket) swift authentication token, and,if the source server is accessed throughthe root user, then root user password.If connectivity to the source databaseserver users root credentials, then thecommand iszdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbsource_db_unique_name_value -sourcenodesource_database_server_name -srcroot -targetnodetarget_database_server_name -targethometarget_database_ORACLE_HOME -backupuserObject_store_login_user_name -rsp response_file_location -tgtauth zdmauth -tgtarg1user:target_database_server_login_user_name -tgtarg2identity_file:ZDM_installed_user_private_key_file_location -tgtarg3 sudo_location:/usr/bin/sudo -evalIf connectivity to the source databaseserver uses an SSH key, then thecommand is:zdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbsource_db_unique_name_value -sourcenodesource_database_server_name -srcauth zdmauth -srcarg1user:source_database_server_login_user_name -srcarg2identity_file:ZDM_installed_user_private_key_file_location -srcarg3 sudo_location:/usr/bin/sudo -targetnodetarget_database_server_name -targethometarget_database_ORACLE_HOME_value -backupuser

It is highly recommended that for eachmigration you run migrate databasein evaluation mode first. Theevaluation allows you to correct anypotential problems in the setup andconfiguration before performing theactual migration. In evaluation mode,the migration process runs withouteffecting the changes to source andtarget databases. It is safe to run thecommand with the -eval option asmany times as needed before runningthe actual migration.Zero Downtime Migration performs thefollowing pre-checks.• Discovers information about the

source database• Discovers information about the

target database• Sets up Zero Downtime Migration

helper modules on the sourcedatabase server

• Sets up Zero Downtime Migrationhelper modules on the targetdatabase server

• Generates random password forencrypting RMAN backupThis password is required to takea backup of the source databaseonto the Object Store.

• Validates the source database– Archive log mode check– TDE setup– SYS password– Patch level

• Validates the target database– Patch level– Data files storage locations

(ASM disk group or ACFS filesystem)

• Validates Object Store credentialsExampleFor the prompts, specify the sourcedatabase SYS password. If the backupdestination is Object Store (Bucket),then specify the your swiftauthentication token. If the backupdestination is Storage Classic(Container), then specify your tenancylogin password. If the source server isaccessed using the root user, thenspecify the root user password.If connectivity to the source databaseserver uses the root credentials thencommand would be

Chapter 4Evaluate the Database Migration Process

4-2

Requirement


Object_store_login_user_name -rsp response_file_location -tgtauth zdmauth -tgtarg1user:target_database_server_login_user_name -tgtarg2identity_file:ZDM_installed_user_private_key_file_location -tgtarg3 sudo_location:/usr/bin/sudo -eval

Note that if a source single instancedatabase is deployed without a GridInfrastructure home, then in the abovecommand use -sourcesid in place of-sourcedb.

Also, if a source database is configuredfor a PASSWORD based wallet, then addthe -tdekeystorepasswd option to thecommand above, and for the prompt,specify the source database TDEkeystore password value.

The migrate database commandchecks for connectivity to the sourceand target database servers.

The migrate database -evalcommand checks for patch compatibilitybetween the source and target homepatch level, and expects the targethome patch level to be equal to orhigher than the source. If the targethome patch level is not as expected,then the migration job is stopped andmissing patches are reported. You caneither patch the target home with thenecessary patches, or you can forcecontinue the migration by appending the–ignore PATCH_CHECK or -ignoreALL option to the migration command.

zdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbZDM12201_phx1sp -sourcenodezdm122011 -srcroot -targetnodeexacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1user:opc -tgtarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3sudo_location:/usr/bin/sudo -ignore ALL -eval

Enter source databaseZDM12201_phx1sp SYS password:

Enter source user "root"password:

Enter user"[email protected]"password:

Then the following message isdisplayed with the job ID number.Make note of the job ID number forlater use.

Operation "zdmcli migratedatabase" scheduled with thejob ID "5".

If connectivity to the source databaseserver uses an SSH key, thencommand is

zdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbZDM12201_phx1sp -sourcenodezdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 [email protected] -

Chapter 4Evaluate the Database Migration Process

4-3

Requirement


rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1user:opc -tgtarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3sudo_location:/usr/bin/sudo -ignore ALL -eval





See Prechecks Verification for samplecommand output.

4.2 Query the Migration Job Status

Chapter 4Query the Migration Job Status

4-4

Requirement


Query themigration jobstatus

You can query the migration job statuswhile the job is running.

Query the status of a databasemigration job using the ZDMCLI queryjob command, specifying the job ID.The job ID is shown in the commandoutput when the database migration jobis submitted.

zdmuser>$ZDM_HOME/bin/zdmcliquery job -jobid job-id

You can find the migration job consoleoutput in the file (Result file path:),given in the query job commandoutput. You can see migration progressmessages in the specified file, asshown in this sample output.

Result file path: "/u01/app/zdmbase/chkbase/scheduled/job-5-2019-12-16-06:37:04.log"

For example

zdmuser>$ZDM_HOME/bin/zdmcliquery job -jobid 5

4.3 Migrate the DatabaseBefore submitting the database migration job, ensure that the evaluation migration jobis successful to determine how the process may fare with your configuration andsettings. If the evaluation migration job is not sucessful, then this migration job will notbe successful.

Determine if the migration process needs to be paused and resumed before you startthe database migration. Once the migration job is started, the job system runs the jobas configured. If the migration job needs to pause and resume at a particular point,then see List Migration Job Phases, Pause and Resume a Migration Job, and Rerun aMigration Job for instructions.

Chapter 4Migrate the Database

4-5

Requirement


Migrate thedatabase

To migrate the database, have thecompleted response file, and keep thenecessary credentials ready, such asthe source database SYS password,Object Store (Bucket) swiftauthentication token, and if the sourcedatabase server is accessed using theroot user, then have the root userpassword.If connectivity to the source databaseserver uses the root credentials thenthe command is:zdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbsource_db_unique_name_value -sourcenodesource_database_server_name -srcroot -targetnodetarget_database_server_name -targethometarget_database_ORACLE_HOME -backupuserObject_store_login_user_name -rsp response_file_location -tgtauth zdmauth -tgtarg1user:target_database_server_login_user_name -tgtarg2identity_file:ZDM_installed_user_private_key_file_location -tgtarg3 sudo_location:/usr/bin/sudo

If connectivity to the source databaseserver uses an SSH key, then thecommand is:zdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbsource_db_unique_name_value -sourcenodesource_database_server_name -srcauth zdmauth -srcarg1user:source_database_server_login_user_name -srcarg2identity_file:ZDM_installed_user_private_key_file_location -srcarg3 sudo_location:/usr/bin/sudo -targetnodetarget_database_server_name -targethometarget_database_ORACLE_HOME_value -backupuserObject_store_login_user_name -rsp response_file_location -

ExampleFor the prompts, specify the sourcedatabase SYS password. If the backupdestination is Object Store (Bucket),then specify your swift authenticationtoken. If the backup destination isStorage Classic (Container), thenspecify your tenancy login password. Ifsource server is accessed using theroot user, then specify the root userpassword.If connectivity to the source databaseserver uses root credentials thencommand iszdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedbZDM12201_phx1sp -sourcenodezdm122011 -srcroot -targetnodeexacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1user:opc -tgtarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3sudo_location:/usr/bin/sudo -ignore ALL


Enter source user "root"password:

Enter user"[email protected]"password:Then the following message isdisplayed with the job ID number.Make note of the job ID number forlater use.Operation "zdmcli migratedatabase" scheduled with thejob ID "6".If connectivity to the source databaseserver uses an SSH key, thencommand iszdmuser>$ZDM_HOME/bin/zdmclimigrate database -sourcedb

Chapter 4Migrate the Database

4-6

Requirement


tgtauth zdmauth -tgtarg1user:target_database_server_login_user_name -tgtarg2identity_file:ZDM_installed_user_private_key_file_location -tgtarg3 sudo_location:/usr/bin/sudo

Note that if a source single instancedatabase is deployed without a GridInfrastructure home, then in the abovecommand use -sourcesid in place of-sourcedb.

Also, if a source database is configuredfor a PASSWORD based wallet, then addthe -tdekeystorepasswd option to thecommand above, and for the prompt,specify the source database TDEkeystore password value.

The migrate database commandchecks for patch compatibility betweenthe source and target home patch level,and expects the target home patch levelto be equal to or higher than the source.If the target home patch level is not asexpected, then the migration job isstopped and missing patches arereported. You can either patch thetarget home with the necessary patchesor you can force continue the migrationby appending the –ignorePATCH_CHECK or -ignore ALL optionto the migrate database command.

ZDM12201_phx1sp -sourcenodezdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1user:opc -tgtarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3sudo_location:/usr/bin/sudo -ignore ALL





Query the migration job status usingthe following command.

$ZDM_HOME/bin/zdmcli query job-jobid 6

See Migration Job Output for samplecommand output.

4.4 List Migration Job Phases

Chapter 4List Migration Job Phases

4-7

Requirement


Listmigration jobphases

To list the operation phases involved inthe migration job, add the -listphases option in the ZDMCLImigrate database command.

For example

zdmuser> $ZDM_HOME/bin/zdmclimigrate database -sourcedbZDM12201_phx1sp -sourcenodezdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1user:opc -tgtarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3sudo_location:/usr/bin/sudo -listphases

See List Migration Job Phases forsample command output.

4.5 Pause and Resume a Migration Job

Chapter 4Pause and Resume a Migration Job

4-8

Requirement


Pause andresume amigration job

You can pause a migration job at anypoint after the ZDM_SETUP_TGT phase,and resume the job at any time.

To pause a migration job, specify the –pauseafter option in the ZDMCLImigrate database command with avalid phase at which to pause. Choosea valid phase that is listed in the -listphases command output.

Pausing after the ZDM_SETUP_TGTphase is recommended.

For example, if you specify -pauseafterZDM_CONFIGURE_DG_SRC, themigration job will pause after completingthe ZDM_CONFIGURE_DG_SRC phase.

zdmuser> $ZDM_HOME/bin/zdmclimigrate database -sourcedbZDM12201_phx1sp -sourcenodezdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1user:opc -tgtarg2identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3sudo_location:/usr/bin/sudo -pauseafter ZDM_CONFIGURE_DG_SRC

A paused job can be resumed any timeby running the ZDMCLI resume jobcommand, and specifying the job ID.

To schedule another pause, specify the–pauseafter option in the resumejob command with a valid phase atwhich to pause. Choose a valid phaselater than phase the job is currentlypaused at, and that is listed in the -listphases command output.

Note: After the phaseZDM_CONFIGURE_DG_SRC completes,a standby is created on the target andsync will happen from source to target.You can monitor and decide to resumethe operation for the role change.

For example, to pause at anotherplace when resuming the migrationjob:

zdmuser> $ZDM_HOME/bin/zdmcliresume job -jobid 6 -pauseafter ZDM_SWITCHOVER_TGT

Chapter 4Pause and Resume a Migration Job

4-9

Requirement


The resume job command sytax is

zdmuser> $ZDM_HOME/bin/zdmcliresume job -jobid Job_ID [-pauseafter valid-phase]

Note that the -pauseafter optionallows only one phase to be specified.

4.6 Rerun a Migration Job

Requirement


Rerun amigration job

If there are unexpected errors in themigration workflow, you can correctthem and rerun the migration job.

The errors are recorded in the joboutput, which can be queried using theZDMCLI query job command. Whenthe error is resolved, the failed job canbe continued from the point of failure.

Rerun the migration job by running theZDMCLI resume job command,specifying the job ID of the job to bererun, as shown here.

zdmuser> $ZDM_HOME/bin/zdmcliresume job -jobid Job_ID

For example:

$ZDM_HOME/bin/zdmcli resumejob -jobid 6

4.7 Post-Migration Tasks

Chapter 4Rerun a Migration Job

4-10

Requirement


Run thedatapatchutility on thetargetdatabase

After you complete the databasemigration job, if the target databaseenvironment is at a higher patch levelthan the source database, you must runthe datapatch utility on the targetdatabase.For example, if your source database isat Oct 2018 PSU/BP and the target is atJan 2019 PSU/BP), you must run thedatapatch utility.Before running datapatch on the target,ensure you apply the target patch levelto the binaries at the source (standby)database.If you are running a multitenantarchitecture, open the PDBs.

SQL> alter pluggable databaseall open;

It is recommended that you rundatapatch on all of the PDBs; however,if you only want to open a subset of thePDBs in the CDB, you can use thefollowing command instead. Datapatchonly runs on the CDB and openedPDBs.

SQL> alter pluggable databasePDB_NAME open;

To run datapatch on a PDB later(previously skipped or newly pluggedin), open the database using the AlTERPLUGGABLE DATABASE command andrerun the datapatch utility.Go to the OPatch directory inORACLE_HOME and run the datapatchutility.

% cd $ORACLE_HOME/OPatch

% ./datapatch -verbose

The datapatch utility runs the necessaryapply scripts to load the modified SQLfiles into the database. An entry isadded to thedba_registry_sqlpatch viewindicating the patch application.Check for errors. Error logs are locatedin the $ORACLE_BASE/cfgtoollogs/sqlpatch/patch#/unique patch IDdirectory in the following format:

patch#_apply_database_SID_CDB_name_timestamp.log

where database_SID is the databaseSID, CDB_name is the name of themultitenant container database, and

none

Chapter 4Post-Migration Tasks

4-11

Requirement


timestamp is in the formatYYYYMMMDD_HH_MM_SS


4-12

Requirement


Register theExadataCloudServicedatabase

Register the Exadata Cloud Servicedatabase, and make sure its meets allof the requirements.

Run the following commands on theExadata Cloud Service database serveras the root user.

/root>dbaascli registerdbprereqs --dbname db_name --db_unique_name db_unique_name

/root>dbaascli registerdb begin--dbname db_name --db_unique_name db_unique_name

For example

/root>dbaascli registerdbprereqs --dbname ZDM12201 --db_unique_name ZDM12201_phx1xx

DBAAS CLI version 18.2.3.2.0

Executing command registerdbprereqs --db_unique_nameZDM12201_phx1xx

INFO: LogfileLocation: /var/opt/oracle/log/ZDM12201/registerdb/registerdb_2019-08-14_05:35:31.157978280334.log

INFO: Prereqs completedsuccessfully

/root>

/root>dbaascli registerdbbegin --dbname ZDM12201 --db_unique_name ZDM12201_phx1xx


Executing command registerdbbegin --db_unique_nameZDM12201_phx1xx

Logfile Location: /var/opt/oracle/log/ZDM12201/registerdb/registerdb_2019-08-14_05:45:27.264851309165.log

Running prereqs


Executing command registerdbprereqs --db_unique_nameZDM12201_phx1xx

INFO: LogfileLocation: /var/opt/oracle/log/ZDM12201/registerdb/registerdb_2019-08-14_05:45:29.000432309894.log

INFO: Prereqs completedsuccessfully

Prereqs completed

Running OCDE .. will taketime ..

OCDE Completed successfully.

INFO: Database ZDM12201registered as Cloud database


4-13

Requirement


/root>

Applypatches

Make sure that you can apply thepatches to migrated database, usingeither the console or commands andAPIs provided by the target platform.

none

Createbackups

Make sure that you can back up themigrated database, using either theconsole or commands and APIsprovided by the target platform.

none


4-14

5Troubleshooting and Known Issues

Requirement Description Comments

Troubleshootingand known issues

Check the Zero Downtime Migrationservice host log at $ZDM_BASE/crsdata/zdm_service_node/rhp/rhpserver.log.0

On the source or target databaseserver check the log associated withthe operational phase in /tmp/zdm-unique-id/zdm/log.

For example:

ls -ltrd /tmp/zdm*

zdm1748010429

cd /tmp/zdm1748010429/zdm/log

default.logmZDM_obc_install_19852.log

mZDM_backup_20603.logmZDM_oss_standby_setup_src_34039.log

mZDM_backup_29362.logmZDM_oss_standby_validate_src_18814.log

mZDM_backup_43124.logmZDM_resource_36058.log

Abort migrationjob : $ZDM_HOME/bin/zdmcliabort job -jobid Job_ID

See Oracle Zero Downtime MigrationRelease Notes for more informationabout knowing issues andtroubleshooting information.

5-1

https://docs.oracle.com/en/database/oracle/zero-downtime-migration/19.2/zdmrn/

https://docs.oracle.com/en/database/oracle/zero-downtime-migration/19.2/zdmrn/

6Additional Information

Requirement Description Comments

Find additionalinformation aboutZero DowntimeMigration

• Oracle Zero Downtime Migration Product Page• Oracle Zero Downtime Migration Documentation• Oracle Zero Downtime Migration MOS Note• Oracle Zero Downtime Migration Download• Introducing MOVE to the Oracle Cloud• Administering Oracle Database Exadata Cloud

Service• (ADB) MV2ADB: move data to Autonomous

Database in "one-click" (Doc ID 2463574.1)• (OCI) MV2OCI: move data to Oracle Cloud

Database in "one-click" (Doc ID 2514026.1)• Oracle Cloud Migration Documentation• Exadata Cloud Service in OCI Best Practices (Doc

ID 2570952.1)• Oracle Database Tablespace Encryption Behavior

in Oracle Cloud (Doc ID 2359020.1)

none

Learn aboutconsiderations forsetting upapplicationsbefore databasemigration

Oracle Cloud Infrastructure, "Network Setup for DBSystems"PeopleSoft application migration using Cloud Manager

For otherapplicationmigrations, seetheir respectivedocumentationsets.

6-1

http://www.oracle.com/goto/zdm

https://docs.oracle.com/en/database/oracle/zero-downtime-migration/19.2/zdmug/

https://support.oracle.com/rs?type=doc&id=2562063.1


http://www.oracle.com/goto/move

https://docs.oracle.com/en/cloud/paas/exadata-cloud/csexa/index.html

https://docs.oracle.com/en/cloud/paas/exadata-cloud/csexa/index.html





https://docs.oracle.com/en/cloud/migrate-oci.html





https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/network.htm#vcn-subnets

https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/network.htm#vcn-subnets

https://docs.oracle.com/cd/F18719_01/pcd92pbr9/eng/pcd/cmif/concept_UnderstandingTheLiftAndShiftProcess.html?pli=ul_d17e53_cmif

7Appendices

The following appendices contain information that you may need to complete therequirements in the previous topics.

• Setting Up the Transparent Data Encryption WalletFor Oracle Database 12c Release 2 and later, if the source database does nothave TDE enabled, then it is mandatory that you configure the TDE wallet beforemigration begins. Enabling TDE on Oracle Database 11g Release 2 (11.2.0.4) andOracle Database 12c Release 1 is not required.

• Generating a Private SSH Key Without a PassphraseIf, on the Zero Downtime Migration service host, source database server, or targetdatabase server, the authentication key pairs are not available without apassphrase for the Zero Downtime Migration software installed user, you cangenerate a new SSH key using the following procedure.

• Prechecks Verification

• List Migration Job Phases

• Migration Job Output

7.1 Setting Up the Transparent Data Encryption WalletFor Oracle Database 12c Release 2 and later, if the source database does not haveTDE enabled, then it is mandatory that you configure the TDE wallet before migrationbegins. Enabling TDE on Oracle Database 11g Release 2 (11.2.0.4) and OracleDatabase 12c Release 1 is not required.

If Transparent Data Encryption (TDE) is not already configured as required on thesource and target databases, use the following instructions to set up the (TDE) wallet.TDE should be enabled, the WALLET status on both source and target databases mustbe set to OPEN, and the WALLET_TYPE must be set to AUTOLOGIN.

1. Set ENCRYPTION_WALLET_LOCATION in $ORACLE_HOME/network/admin/sqlnet.orafile.

$ cat /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/sqlnet.ora

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

2. Connect to the database and configure the keystore.

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

7-1

identified by **********;keystore altered.

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

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

For a CDB environment, run the following command.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY ********** container = ALL;

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

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

For a CDB environment, run the following command.

SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY ********** with backup container = ALL;

Then run,

SQL> select * FROM v$encryption_keys;

3. Set up autologin.

SQL> SELECT * FROM v$encryption_wallet;

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

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

Chapter 7Setting Up the Transparent Data Encryption Wallet

7-2

If you are using an Oracle RAC database, copy the files below to the samelocation on each cluster node, or to a shared file system.

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

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

At this stage, the PASSWORD based wallet is enabled. To enable an AUTOLOGINbased wallet, complete the remaining steps in this procedure.

Close the password wallet.

SQL> administer key management set keystore close identified by **********;keystore altered.

Then verify that autologin is configured. Set TDE WALLET status to OPEN andWALLET_TYPE to AUTOLOGIN, otherwise the wallet configuration is not correctly setup.

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

Upon migration of your Oracle Database to the Oracle Cloud, bear in mind that Oracledatabases in the Oracle Cloud are TDE enabled by default. Zero Downtime Migrationwill take care of the encryption of your target database, even if your source OracleDatabase is not TDE enabled by default. However, once the switchover phase of themigration has taken place, the redo logs that the new primary database in the OracleCloud sends to the new standby database on your premises will be encrypted.Therefore, if you decide to switch back and role swap again making the on-premisesdatabase the primary again and the database in the Oracle Cloud the standby, the on-premises database will not be able to read the newly encrypted changed blocksapplied by the redo logs unless TDE is enabled on-premises.

Chapter 7Setting Up the Transparent Data Encryption Wallet

7-3

In order to avoid post migration conflict, prior to performing the original switchover aspart of the migration process, the recommended best practice is to performappropriate testing and validation. There are options outside of Zero DowntimeMigration for testing with a snapshot standby database, and once you are ready toproceed, delete the snapshot standby database and instruct Zero Downtime Migrationto perform the switchover and finalize the migration process.

7.2 Generating a Private SSH Key Without a PassphraseIf, on the Zero Downtime Migration service host, source database server, or targetdatabase server, the authentication key pairs are not available without a passphrasefor the Zero Downtime Migration software installed user, you can generate a new SSHkey using the following procedure.

SSH connectivity during Zero Downtime Migration operations requires direct, non-interactive access between the Zero Downtime Migration service host and the sourceand target database servers, and also between the source and target databaseservers, without the need to enter a passphrase.

Note:

The following steps show examples for generating a private SSH key for thesoftware installed user. You can also use these steps for the opc user.

Run the following command as the Zero Downtime Migration software installed useron the Zero Downtime Migration service host.

zdmuser> ssh-keygenGenerating public/private rsa key pair.Enter file in which to save the key (/home/opc/.ssh/id_rsa):Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /home/opc/.ssh/id_rsa.Your public key has been saved in /home/opc/.ssh/id_rsa.pub.The key fingerprint is:c7:ed:fa:2c:5b:bb:91:4b:73:93:c1:33:3f:23:3b:30 opc@rhost1The key's randomart image is:+--[ RSA 2048]----+| || || || . . . || S o . = || . E . * || X.+o.|| .= Bo.o|| o+*o. |+-----------------+

This command generates the id_rsa and id_rsa.pub files in the zdmuser home, forexample, /home/zdmuser/.ssh.

Chapter 7Generating a Private SSH Key Without a Passphrase

7-4

You can add the public key (for example, /home/zdmuser/.ssh/id_rsa.pub) to thesource and target database servers using the Oracle Cloud Infrastructure Console, oryou can add it manually to the authorized_keys file on those servers, as shown below.

Add the contents of the Zero Downtime Migration service host /home/zdmuser/.ssh/id_rsa.pub file to the Oracle Cloud Infrastructure server opc user /home/opc/.ssh/authorized_keys file, as shown here.

[[email protected]]$ export PS1='$PWD>'/home/opc/.ssh>lsauthorized_keys authorized_keys.bkp id_rsa id_rsa.pub known_hosts zdmkey/home/opc/.ssh>cat id_rsa.pub >> authorized_keys

You should save the private key in a separate, secure file, and use it to connect to thesource and target database servers. For example, create a zdm_service_node.ppk filewith permissions set to 600, and put the private key file into it on the Zero DowntimeMigration service host software installed user home/.ssh to connect source and targetdatabase servers.

7.3 Prechecks Verification

$ZDM_HOME/bin/zdmcli query job -jobid 5rachu3dom.hu.oracle.com: Audit ID: 79Job ID: 5User: zdmuserClient: rachu3domScheduled job command: "zdmcli migrate database -sourcedb ZDM12201_phx1sp -sourcenode zdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 -backupuser [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -ignore ALL -eval"Scheduled job execution start time: 2019-07-31T13:21:39+02. Equivalent local time: 2019-07-31 13:21:39Current status: SUCCEEDEDResult file path: "/u01/app/zdmbase/chkbase/scheduled/job-5-2019-07-31-13:21:39.log"Job execution start time: 2019-07-31 13:21:39Job execution end time: 2019-07-31 13:35:20Job execution elapsed time: 13 minutes 40 secondsZDM_GET_SRC_INFO .......... COMPLETEDZDM_GET_TGT_INFO .......... COMPLETEDZDM_SETUP_SRC ............. COMPLETEDZDM_SETUP_TGT ............. COMPLETEDZDM_GEN_RMAN_PASSWD ....... COMPLETEDZDM_PREUSERACTIONS ........ COMPLETEDZDM_PREUSERACTIONS_TGT .... COMPLETED

Chapter 7Prechecks Verification

7-5

ZDM_VALIDATE_SRC .......... COMPLETEDZDM_VALIDATE_TGT .......... COMPLETED

7.4 List Migration Job Phases

$ZDM_HOME/bin/zdmcli migrate database -sourcedb ZDM12201_phx1sp -sourcenode zdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 -backupuser [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -listphasesrachu3dom.hu.oracle.com: Processing response file ...pause and resume capable phases for this operation: "ZDM_GET_SRC_INFOZDM_GET_TGT_INFOZDM_SETUP_SRCZDM_SETUP_TGTZDM_GEN_RMAN_PASSWDZDM_PREUSERACTIONSZDM_PREUSERACTIONS_TGTZDM_VALIDATE_SRCZDM_VALIDATE_TGTZDM_OBC_INST_SRCZDM_OBC_INST_TGTZDM_BACKUP_FULL_SRCZDM_BACKUP_INCREMENTAL_SRCZDM_DISCOVER_SRCZDM_COPYFILESZDM_PREPARE_TGTZDM_SETUP_TDE_TGTZDM_CLONE_TGTZDM_FINALIZE_TGTZDM_CONFIGURE_DG_SRCZDM_SWITCHOVER_SRCZDM_SWITCHOVER_TGTZDM_MANIFEST_TO_CLOUDZDM_NONCDBTOPDB_PRECHECKZDM_NONCDBTOPDB_CONVERSIONZDM_POSTUSERACTIONSZDM_POSTUSERACTIONS_TGTZDM_CLEANUP_SRCZDM_CLEANUP_TGT"

Chapter 7List Migration Job Phases

7-6

7.5 Migration Job Output

$ZDM_HOME/bin/zdmcli query job -jobid 6rachu3dom.hu.oracle.com: Audit ID: 80Job ID: 6User: zdmuserClient: rachu3domScheduled job command: "zdmcli migrate database -sourcedb ZDM12201_phx1sp -sourcenode zdm122011 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -srcarg3 sudo_location:/usr/bin/sudo -targetnode exacstarget1 -targethome /u02/app/oracle/product/12.2.0/dbhome_3 -backupuser [email protected] -rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_ZDM12201.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk -tgtarg3 sudo_location:/usr/bin/sudo -ignore ALL"Scheduled job execution start time: 2019-07-31T13:47:27+02. Equivalent local time: 2019-07-31 13:47:27Current status: SUCCEEDEDResult file path: "/u01/app/zdmbase/chkbase/scheduled/job-6-2019-07-31-13:47:39.log"Job execution start time: 2019-07-31 21:37:13Job execution end time: 2019-07-31 21:40:18Job execution elapsed time: 23 minutes 5 secondsZDM_GET_SRC_INFO .............. COMPLETEDZDM_GET_TGT_INFO .............. COMPLETEDZDM_SETUP_SRC ................. COMPLETEDZDM_SETUP_TGT ................. COMPLETEDZDM_GEN_RMAN_PASSWD ........... COMPLETEDZDM_PREUSERACTIONS ............ COMPLETEDZDM_PREUSERACTIONS_TGT ........ COMPLETEDZDM_VALIDATE_SRC .............. COMPLETEDZDM_VALIDATE_TGT .............. COMPLETEDZDM_OBC_INST_SRC .............. COMPLETEDZDM_OBC_INST_TGT .............. COMPLETEDZDM_BACKUP_FULL_SRC ........... COMPLETEDZDM_BACKUP_INCREMENTAL_SRC .... COMPLETEDZDM_DISCOVER_SRC .............. COMPLETEDZDM_COPYFILES ................. COMPLETEDZDM_PREPARE_TGT ............... COMPLETEDZDM_SETUP_TDE_TGT ............. COMPLETEDZDM_CLONE_TGT ................. COMPLETEDZDM_FINALIZE_TGT .............. COMPLETEDZDM_CONFIGURE_DG_SRC .......... COMPLETEDZDM_SWITCHOVER_SRC ............ COMPLETEDZDM_SWITCHOVER_TGT ............ COMPLETEDZDM_MANIFEST_TO_CLOUD ......... COMPLETEDZDM_NONCDBTOPDB_PRECHECK ...... COMPLETEDZDM_NONCDBTOPDB_CONVERSION .... COMPLETEDZDM_POSTUSERACTIONS ........... COMPLETEDZDM_POSTUSERACTIONS_TGT ....... COMPLETED

Chapter 7Migration Job Output

7-7

ZDM_CLEANUP_SRC ............... COMPLETEDZDM_CLEANUP_TGT ............... COMPLETED

Chapter 7Migration Job Output

7-8

Index

Kkey pair without passphrase, 7-4

SSSH key without passphrase, 7-4

TTransparent Data Encryption

wallet setup, 7-1

Index-1

runbook: move on-premise databases and oracle cloud ... · 4.5 pause and resume a migration job...

Documents