Oracle® Cloud

Using Oracle Cloud Infrastructure Database

Migration Service

F40519-19
October 2023
Oracle Cloud Using Oracle Cloud Infrastructure Database Migration Service,

F40519-19

Copyright © 2021, 2023, Oracle and/or its affiliates.

Primary Authors: Roopam Jain, Virginia Beecher

Contributors: Alex Kotopoulis, Jean-Francois Verrier, Prakash Jashnani, Gaurav Taneja, Jorge Martinez,
Sergey Demyanenko, Luis Chapa, Shariful Haque, Costa Siourbas , Abigail Martinez , Tom O'Shaughnessy,
Christian Gomez

This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license 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 for interoperability, is
prohibited.

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

If this is software, software documentation, data (as defined in the Federal Acquisition Regulation), or related
documentation that is delivered to the U.S. Government or anyone licensing it on behalf 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 embedded, installed, or activated on delivered hardware, and modifications of such programs)
and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end
users are "commercial computer software," "commercial computer software documentation," or "limited rights
data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation
of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated
software, any programs embedded, installed, or activated on delivered hardware, and modifications of such
programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and
limitations specified in the license contained in the applicable contract. The terms governing the U.S.
Government's use of Oracle cloud services are defined by the applicable contract for such services. 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 that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.

Oracle®, Java, and MySQL are registered trademarks of Oracle and/or its affiliates. Other names may be
trademarks of their respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc,
and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. 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 expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise
set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be
responsible 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
Audience vii
Documentation Accessibility vii
Related Resources vii
Conventions vii

1 Overview of Oracle Cloud Infrastructure Database Migration

About Oracle Cloud Infrastructure Database Migration 1-1
What's New in Database Migration 1-2
Database Migration Terminology 1-2
Offline Migration 1-3
Online Migration 1-3
What Is Migrated During Initial Load 1-3
Data Replication 1-4
About Zero Downtime Migration 1-4
Resource Identifiers 1-4
Service Limits 1-4
Compartment Quotas 1-5
Metering and Billing 1-5
Source Database Requirements 1-5
Target Database Requirements 1-6
Supported Database Architectures for Migration 1-6
Oracle Database Edition Support 1-7
Integrated Services 1-7
IAM 1-7
Work Requests 1-7
Monitoring 1-7

2 Getting Started with Oracle Cloud Infrastructure Database Migration

Before You Begin 2-1
Creating Resources 2-1

iii
 Giving Permissions to Database Migration Users 2-2
Configuring SUDO Access 2-4
Accessing the Database Migration Service 2-4

3 Preparing Your Databases for Migration

Preparing the Source Database for Migration 3-2
Additional Configurations for Preparing the Source Database for Online Migration 3-3
Use Case for Preparing the Source Database for Migration 3-7
Preparing the Target Database for Migration 3-10
Additional Configurations for Preparing the Target Database for Online Migration 3-11
Use Case for Preparing the Target Database for Migration 3-13

4 Managing Connections
Creating Connections 4-1
Testing Connectivity of a Database Connection 4-4
Viewing Connection Details 4-5
Editing a Connection 4-7
Moving a Connection 4-8
Deleting a Connection 4-8
Managing Tags for Connections 4-9
Using the Connection API 4-9

5 Managing Migrations
Creating Migrations 5-1
Selecting Objects for Migration 5-6
Configuring Optional Initial Load Advanced Options 5-9
Configuring Validation Options 5-11
Configuring Optional Replication Advanced Options 5-11
Viewing Migration Details 5-13
Editing a Migration 5-14
Cloning a Migration 5-16
Moving a Migration 5-16
Deleting a Migration 5-16
Managing Tags for Migrations 5-17
Using the Migration API 5-17

6 Managing Migration Jobs

Validating a Migration 6-1

iv
 Checking the Interactive Validation Premigration Advisor Report 6-1
Running a Migration Job 6-3
Pausing and Resuming a Job 6-3
Viewing Job Details 6-4
Monitoring Job Status 6-5
Preparing for Application Switchover 6-6
Terminating a Job 6-6
Deleting a Job 6-6
Managing Tags for Jobs 6-7
Using the Job API 6-7

7 Managing Agents
About the Database Migration Agent 7-1
Prepare a Host for Database Migration Agent Installation 7-1
Create a Stream 7-2
Create an API Key 7-3
Installing a Database Migration Agent 7-3
Managing Database Migration Agents 7-6
Starting and Stopping the Database Migration Agent 7-6
Getting Database Migration Agent Status 7-7
Listing Database Migration Agents 7-7
Moving a Database Migration Agent 7-7
Deleting a Database Migration Agent 7-7
Managing Tags for Database Migration Agents 7-8
Using the Agent API 7-8

8 Troubleshooting Database Migration

Metrics 8-1
Alarms 8-1
Logs 8-2
Error Messages 8-3
Work Request Details 8-3
Troubleshooting Connection Creation Failures 8-3
Troubleshooting Network Connectivity Issues for Database Connections 8-6
Troubleshooting Migration Creation Failures 8-6

9 Database Migration Policies

About IAM Policies 9-1
Basic Syntax for Policies 9-1

v
 Database Migration Resource-Types 9-1
Supported Variables 9-1
Details for Verbs + Resource-Type Combinations 9-2
odms-connection 9-2
odms-agent 9-2
odms-migration 9-3
odms-job 9-3
Permissions Required for Database Migration API Operations 9-4
Required Database Migration Policies 9-5
Creating a Policy 9-6

10 Database Migration Metrics

Overview 10-1
Prerequisites 10-1
Available Metrics 10-2
Using the Console 10-3

11 Reference
Set Up Source and Target Configurations for Online Migrations for Your GoldenGate
Instance 11-1
Database Migration Data Pump Defaults 11-3
Database Migration Job Phases 11-5
Database Migration Events 11-11
Database Migration Port Requirements 11-12
Migrating Databases from Amazon Web Services RDS to Oracle Autonomous Database 11-19

vi
Preface
Topics

Audience
Oracle Cloud Infrastructure Database Migration is intended for database administrators
responsible for identifying migration strategies and timelines, setting up connections to
source and target data sources, configuring and executing migrations, and validating and
generating audit and compliance reports.

Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
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 support through 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=trs if you are hearing impaired.

Related Resources
See these Oracle resources:
• Get Started with Oracle Cloud
• Oracle Public Cloud
https://cloud.oracle.com

Conventions
The following text conventions are used in this document:

Convention Meaning
boldface Boldface type indicates graphical user interface elements associated with an
action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for which
you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code in
examples, text that appears on the screen, or text that you enter.

vii
1
Overview of Oracle Cloud Infrastructure
Database Migration
Learn about the Oracle Cloud Infrastructure Database Migration service.
The following topics explain what Oracle Cloud Infrastructure Database Migration can do and
describe the concepts you need to know about the service.
To learn more about the service, see OCI Database Migration.

About Oracle Cloud Infrastructure Database Migration

Oracle Cloud Infrastructure Database Migration is a fully-managed service that provides you
a high performing, self-service experience for migrating databases to Oracle Cloud
Infrastructure (OCI).
Database Migration runs as a managed cloud service separate from your tenancy and
resources. The service operates as a multitenant service in a Database Migration service
tenancy and communicates with your resources using Private Endpoints (PEs). PEs are
managed by Database Migration.
Database Migration includes the following capabilities:
• Migration of data from on-premises, Oracle Cloud, and Amazon RDS Oracle databases
into co-managed, Autonomous Data Warehouse, or Autonomous Transaction Processing
services on Oracle Cloud Infrastructure
• Simple offline migration option or enterprise-level logical migration with minimal downtime
option
• Based on industry-leading Oracle GoldenGate replication and powered by the Zero
Downtime Migration engine
• Compliant with Oracle Maximum Availability Architecture (MAA) and supports Oracle
Database 11g Release 2 (11.2.0.4) and later database releases.
• Seamless transition from initial load to streamed replication
• Performs change data capture on the source database and replicates these changes to
the target
• Job subsystem lets you perform and manage database migrations at a fleet scale.
• Pause and resume functionality lets you pause and resume your migration job if needed,
which is useful to conform to a maintenance window, for example
• Job termination lets you terminate a running migration job, rather than waiting for it to
complete
• Re-run (resume) migration jobs from a point of failure
• Job pre-checks for migration tasks to prevent errors during database migration

1-1
 Chapter 1
What's New in Database Migration

What's New in Database Migration

For information about new features and enhancements, check What's New for Oracle
Cloud Infrastructure Database Migration Service and Database Migration Release
Notes on OCI.

Database Migration Terminology

The following concepts are essential for working with Oracle Cloud Infrastructure
Database Migration service.

Migration
Represents a single migration operation and contains the specifications by which the
migration should run. Migration specifications include whether or not to perform bulk
data copy, and/or capture ongoing changes, and the source and target database
selections.

Migration Job
Represents an active or past migration execution. A migration job is created implicitly
when you start a migration. A migration job is a snapshot with runtime information
about the migration. You use this information to audit logs and investigate failures.

Validation Job
Validates the prerequisites and connectivity for source and target databases, Oracle
GoldenGate instances, and Oracle Data Pump. A validation job is created when you
evaluate the migration.

Database connection
Represents a database instance, containing the database metadata and connection
details. A data asset can have one or many connections to include all schemas within
a database that need to be migrated.

Agent
Contains the necessary details to establish a connection from Oracle Cloud
Infrastructure to a source database that is not directly accessible on OCI, for example,
a database in a different region or tenancy in OCI, an on-premises database, or a
manually installed cloud database.

Private Endpoint
Gives hosts within your virtual cloud network (VCN) and your on-premises network
access to a single resource within the Oracle service of interest (for example, one
Autonomous Database with shared Exadata infrastructure). Connection to either a
source or target database in the migration is currently supported by the service. Make
sure security rules or network security groups allow traffic required for database
migration jobs. Learn more at Database Migration Port Requirements.

Schema
Organizational concepts of databases to hold database objects such as tables, views,
stored procedures, and so on.

1-2
 Chapter 1
Offline Migration

Offline Migration
When using the online migration method, you must stop updates to the source database
before you start a migration.
Using the offline migration method, Database Migration service transports the data from the
source database using the preferred transfer medium, and then imports the data from the
selected transfer medium to the target database on the Cloud using Oracle Data Pump.

Online Migration
An online migration enables you to perform database migration without any downtime of your
source database.
• Online migrations consist of the following steps;
1. Initial load
2. Real-time replication
• When using the online migration method, you do not need to stop updates to the source
database before you start a migration.
• Online migrations are facilitated by Oracle GoldenGate's replication technology to allow
zero downtime of your source database.
To take advantage of parallelism and achieve the best data transfer performance, Oracle
recommends that you transfer data using Object Store for databases over 50GB in size. The
database link transfer medium can be convenient for smaller databases, but this choice may
involve uncertainty in performance because of its dependence on network bandwidth for the
duration of the transfer.
As part of a migration job, Database Migration uses GoldenGate's replication technology to
facilitate database replication between the source and target databases.
When the application switches over to the target database, Database Migration tears down
the replication so that the target database in the Cloud can then be used as the production
database. Note that bi-directional synchronization is not currently supported. Synchronization
is always from the source database to the target database.

What Is Migrated During Initial Load

The initial load phases of an Oracle Cloud Infrastructure Database Migration service
migration job work flow moves the contents of all selected schemas from the source
database to schemas of the same name in the target database.
You can elect to include or exclude specific objects, and rename objects when you create a
migration.
See Selecting Objects for Migration for information about how to configure object selection
rules, and what objects are excluded by default.

1-3
 Chapter 1
Data Replication

Data Replication
During the Oracle Cloud Infrastructure Database Migration service migration job work
flow replication phase, all data and metadata operations in transactions committed
after the initial load are replicated until you resume the migration job after the Monitor
Replication Lag phase.
During the migration job it is recommended that your database avoid Data Definition
Language (DDL) operations to provide the most optimal environment for fast database
replication. When DDL is replicated, Oracle GoldenGate Replicat serializes data to
ensure that there are no locking issues between DML and DDL on the same objects.
By default, Database Migration excludes all DDL from GoldenGate replication.
The following objects are not supported:
• Changes to external tables
• Oracle GoldenGate Unsupported Types (see Understanding What’s Supported)

About Zero Downtime Migration

Oracle Cloud Infrastructure Database Migration service is internally driven by the Zero
Downtime Migration Server, which is an integral part of the Oracle product, Zero
Downtime Migration.
Zero Downtime Migration configuration is handled automatically by Database
Migration, so you don't have to perform any Zero Downtime Migration set up.
To learn more about Zero Downtime Migration see Zero Downtime Migration on Oracle
Help Center and Oracle Zero Downtime Migration on Oracle's Database Technologies
web site.

Resource Identifiers
Database Migration resources have a unique, Oracle-assigned identifier called an
Oracle Cloud ID (OCID).
Database Migration resources are OdmsAgent, OdmsConnection, OdmsMigration, and
OdmsJob.

For example, the OCID format for OdmsJob is ocid1.odmsjob.oc1.[REGION][.FUTURE

USE].<UNIQUE ID>.

For information about the OCID format and other ways to identify your resources, see
Resource Identifiers.

Service Limits
Oracle Cloud Infrastructure Database Migration service limits you to 10 Connections, 5
migrations, and 5 agents.
Your tenancy has limits on the maximum number of resources that you are allowed to
use. To view your tenancy's limits for Oracle Cloud Infrastructure Database Migration
service, see Limits by Service. If you are an administrator in an eligible account, you

1-4
 Chapter 1
Compartment Quotas

can request to increase the service limits in the OCI Console, see Requesting a Service Limit
Increase.

Compartment Quotas
In Oracle Cloud Infrastructure Database Migration service, creating a quota lets you limit the
number of migration resources in a compartment.
For example:

set database-migration quota odms-migration-count to 10 in compartment

compartment_name

See Overview of Compartment Quotas for information.

Metering and Billing

Metering and billing for Oracle Cloud Infrastructure Database Migration Service is based on
the number of Migration Hours elapsed.
A Migration Hour is defined as the amount of time that a Migration Job is running, where
running is defined as a Migration Job being in an IN_PROGRESS or WAITING state. Partial
Migration Hours consumed are billed as partial hours with a one-minute minimum.
Migration Jobs are only metered if either of the following is true:
• The Migration Job is running more than 183 days (6 months) after creation
• The Migration Job is running for more than 60 days idle (no data transferred)
Migration Hours are billed down to the Second level. Note that the minimum amount billed will
be 1 minute. That is, if a resource is spun up for less than 60 seconds, the customer will still
be charged for 1 minute. For any usage over 1 minute, all usage will be tracked at the
Second level.
You can monitor the Migration Hours of a Migration Job in the Console under Governance &
Administration, in Cost and Usage Reports. The migration billing meter should be included in
the report as service name DATABASEMIGRATION.

Source Database Requirements

Your source database environment must meet these requirements to use Oracle Cloud
Infrastructure Database Migration.

Supported Source Database Versions

The following Oracle Database versions can be migrated using Database Migration, and the
source database can be at any configuration.
• Oracle Database 11g Release 2 (11.2.0.4)
• Oracle Database 12c Release 1 (12.1.0.2)
• Oracle Database 12c Release 2 (12.2.0.1)
• Oracle Database 19c

1-5
 Chapter 1
Target Database Requirements

• Oracle Database 21c

• All subsequent Oracle Database releases

Supported Source Environments

• Oracle Cloud Infrastructure co-managed databases or on-premises environments
• Amazon Web Services RDS Oracle Database (both offline and online migrations)

Note:
Amazon Web Services RDS Oracle Database Multitenant architecture
(CDB) is currently not supported for online migrations.

• Linux-x86-64, IBM AIX, and Oracle Solaris.

Target Database Requirements

Your target database environment must meet these requirements to use Oracle Cloud
Infrastructure Database Migration.

Supported Migration Targets

Database Migration supports the following Oracle Cloud Infrastructure Database
Service offerings as migration targets.
• Oracle Autonomous Database Serverless
• Oracle Autonomous Database on Dedicated Exadata Infrastructure
• Oracle Cloud Infrastructure co-managed Oracle Base Database service (Oracle
Base Database (VM, BM) and Exadata on Oracle Public Cloud)

Note:
A target co-managed database can be either a pluggable database (PDB) in
a multitenant container database (CDB), or a traditional non-CDB Oracle
database.
For Bare Metal and Virtual Machine Database Systems, the user is
responsible for securing, patching, and hardening the environment. To learn
more about this, see Bare Metal and Virtual Machine DB Systems.

Supported Database Architectures for Migration

Oracle Cloud Infrastructure Database Migration supports the following database
architecture implementations.
• Oracle RAC One Node, which can be migrated to an Oracle RAC database target
• Oracle RAC, which can be migrated to an Oracle RAC database target

1-6
 Chapter 1
Oracle Database Edition Support

Oracle Database Edition Support

Oracle Cloud Infrastructure Database Migration service supports the migrations of Standard
and Enterprise Edition Oracle databases for source and targets.

Integrated Services
The Database Migration service is integrated with various Oracle Cloud Infrastructure
services and features.

IAM
Database Migration integrates with the Identity and Access Management (IAM) service for
authentication and authorization for the Console, SDK, CLI, and REST API.
To learn more about IAM, see IAM Overview.

Work Requests
The Database Migration service uses its own API for Work Requests. See WorkRequest.

Monitoring
Oracle Cloud Infrastructure Monitoring lets you actively and passively monitor your Oracle
Cloud Infrastructure Database Migration resources and alarms.
Database Migration Metrics capture CPU utilization, OCPU consumption, memory utilization,
deployment health, and inbound and outbound lag. You can view these metrics using the
Monitoring service.
See Troubleshooting Database Migration Service for topics about monitoring resource status
and accessing logs.

1-7
2
Getting Started with Oracle Cloud
Infrastructure Database Migration
Before you can start using Oracle Cloud Infrastructure Database Migration service and before
migrating your databases, you must perform the following preparatory tasks:
1. Create Database Migration policies in your tenancy.
2. Create any dependent objects needed for the migration.
3. Configure the source and target databases as required.

Before You Begin

Before you begin working with Oracle Cloud Infrastructure Database Migration, you must
have an Oracle Cloud Infrastructure account with administrator privileges.
See Add a User with Oracle Cloud Administrator Permissions for details.

Creating Resources
Use the following instructions to create the resources that Oracle Cloud Infrastructure
Database Migration operations depend on.

Create a Compartment
If you don't already have a compartment, create a compartment in your tenancy.
For more information, see Working with Compartments.

Create a Virtual Cloud Network

Create a Virtual Cloud Network (VCN) with at least one subnet in the compartment.
The subnet must be regional, spanning all availability domains.
For more information, see VCNs and Subnets.

Note:
If you don't see your subnet listed, go back and check that it was created as a
regional subnet. By default, the VCN wizard creates non-regional subnets.

Create a Database Migration User Group

Create a user group to manage agents, database connections, migrations, and jobs, and
then add users in charge of database migrations to the group.

2-1
 Chapter 2
Giving Permissions to Database Migration Users

Take note of the group name. You will create policies for the group in Creating
Resource Policies. For more information, see Managing Groups.

Create an OCI API Key Pair

Create an OCI API key pair if you intend to directly use the REST API, OCI Software
Development Kits and Command Line Interface, or if you are installing the Database
Migration agent.
Follow the instructions in Required Keys and OCIDs.

Select a Data Transfer Medium

The following data transfer mediums are available:
• Data Pump via database link
• Data Pump via object storage
If you are not using a database link to transfer files directly from the source to the
target database server, you must set up an Object Storage Service bucket for
temporary storage of the Data Pump export dumps.
See Creating a Bucket for details.
Make sure that the file system used for the Data Pump export directory has sufficient
space to store Data Pump dump files.

Select or Create a Vault

Create a Vault and Create a Secret in a Vault.
Alternatively, select a vault when creating database connections. Create a key in the
Master Encryption Keys to use with Database Migration. Optionally, you can create
vault during database migrations.

Giving Permissions to Database Migration Users

Use IAM policies to grant certain capabilities to the Oracle Cloud Infrastructure
Database Migration user group.
Previously, in Creating Resources you created a user group for Oracle Cloud
Infrastructure Database Migration. Now you will configure group permissions so that
members can manage Database Migration resources.
The examples in this procedure use the group name dmsGroup.

Remember that only resources within the same compartment can access each other,
unless the proper permissions are granted. Ensure that you have the proper
permissions to view and select the appropriate VCN and subnet when creating
Connections.
Allowing Database Migration resource management
The following statements give a group of users permission to manage connections
(database registrations), migrations, agents, and jobs in Database Migration:

allow group dmsGroup to manage odms-connection in compartment

dmsCompartment

2-2
 Chapter 2
Giving Permissions to Database Migration Users

allow group dmsGroup to manage odms-migration in compartment dmsCompartment

allow group dmsGroup to manage odms-agent in compartment dmsCompartment
allow group dmsGroup to manage odms-job in compartment dmsCompartment

The manage permission lets users create and delete Database Migration resources, such as
migrations and database registrations.
Limiting users to only "use" capability
If you want a group of users that only have the ability to use the Database Migration
resources, but not create and delete them, then create a separate group for users and
replace manage with use.

allow group dmsUserGroup to use odms-connection in compartment dmsCompartment

allow group dmsUserGroup to use odms-migration in compartment dmsCompartment
allow group dmsUserGroup to use odms-agent in compartment dmsCompartment
allow group dmsUserGroup to use odms-job in compartment dmsCompartment

Only users with a manage permission for the odms-migration resources can create and delete
migrations. Users with the use permission can perform migrations and edit resources, but
cannot create or delete the resources.
Allowing network resource management
To let users of dmsGroup manage the network resources for Database Migration resources:

allow group dmsGroup to manage virtual-network-family in compartment

dmsCompartment

If the manage virtual-network-family policy is restricted because of security reasons then

the following policies are required:

allow group dmsGroup to inspect vcns in compartment dmsCompartment

allow group dmsGroup to use subnets in compartment dmsCompartment
allow group dmsGroup to manage vnic in compartment dmsCompartment

This way, you can view the list of existing VCNs, view and work with subnets, and have all of
the permissions on VNIC. These policies are required when you create a database
registration.
Allowing tag-namespaces and tag management

To let users of dmsGroup manage tag-namespaces and tags, add the policy:

allow group dmsGroup to manage tag-namespaces in compartment dmsCompartment

Note:
To apply a defined tag, you must at least have permission to use the tag
namespace. To learn more about tagging, see Resource Tags.

2-3
 Chapter 2
Configuring SUDO Access

Configuring SUDO Access

You may need to grant certain users authority to perform operations using sudo on the
source database servers.
To configure sudo access for source database servers:

If the source database server is accessed through SSH, then configure sudo
operations to run without prompting for a password for the database installed user and
the root user.

For example, if database installed user is oracle, then run sudo su - oracle.

Note that the opc user is a standard Oracle cloud user that is used to access database
servers, but you can use any privileged user that has sudo privileges.

For the root user run sudo su -.

Also, note that because the target database server is on the cloud only any sudo
operations are configured already.

Accessing the Database Migration Service

You can access Oracle Cloud Infrastructure Database Migration using the Oracle
Cloud Interface Console (a browser based interface), REST APIs, or Oracle Cloud
Infrastructure Software Development Kits and Command Line Interface.
To access Database Migration using the Console:
1. Use a supported browser to access the Console.
See Signing In to the Console for details.
2. Enter your cloud tenant, user name, and password, when prompted.
3. Click Sign in.
4. In the upper-right corner of the window, select a region that offers the Database
Migration service enabled; for example, US East (Ashburn).
Database Migration resources, such as database registrations, migrations, agents,
and jobs, are region-specific. Therefore, you want to make sure that you select
Database Migration in the region that contains the resources that you need.
5. From the navigation menu, select Database Migration.
The Migrations page for the Database Migration service is displayed.

Using Database Migration APIs

OCI Database Migration service APIs are documented at https://docs.oracle.com/
iaas/api/#/en/database-migration/20210929/.
See REST APIs and Software Development Kits and Command Line Interface for
more information about using REST APIs and the OCI Software Development Kits and
Command Line Interface.

2-4
3
Preparing Your Databases for Migration
Before you can begin the migration of your data with Oracle Cloud Infrastructure Database
Migration Service, you must configure your source and target databases as described here.
Prepare your databases using either of the following methods:
• Prepare your database by running scripts generated by the database preparation utility
(Recommended option).
• Manually configure your databases by following the documentation and running the SQL
commands.
Preparing your databases using the database preparation utility:
To prepare your databases for migration:
1. Refer to this MOS note.
2. Download the database preparation utility which is a shell script file.
3. Follow the instructions to proceed.
4. Run the script locally.
The database preparation utility:
1. Accepts the inputs that are specific to your migration and generates a SQL script that you
can run for your source and target databases.
2. Analyzes your databases for any missing required configurations or privileges.
3. Checks the current status of the database and provides information on the operations
that will be performed on your databases.
4. Generates a final script that performs the required operations on your databases to
prepare them for the migration.

Note:

• You must review and make necessary corrections to the scripts generated
by the database preparation utility before you run them for your database.
• You must run the utility script twice, once for the source database and then
for the target database.

Consequently, the configuration SQL script prepares the database for migration.
Manually configuring your databases for migration:
To prepare your source and target database manually using the SQL commands, see the
following topics:
• Preparing the Source Database for Migration

3-1
 Chapter 3
Preparing the Source Database for Migration

• Preparing the Target Database for Migration

Preparing the Source Database for Migration

Before you can migrate data with Oracle Cloud Infrastructure Database Migration,
manually configure your source database as described here.
• To configure a single-tenant (Non CDB) as a source for migration, run the following
SQL commands:

-- Archive Log Mode

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- Stream Pool Size

ALTER SYSTEM SET STREAMS_POOL_SIZE=256M;

-- Force Logging
ALTER DATABASE FORCE LOGGING;

-- Supplemental Logging
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK;

• To configure a multi-tenant (CDB) as a source for migration, run the following SQL
commands:

-- Connect to CDB and run:

-- Archive Log Mode

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- Stream Pool Size

ALTER SYSTEM SET STREAMS_POOL_SIZE=256M SCOPE=BOTH;

-- Force Logging
ALTER DATABASE FORCE LOGGING;

-- Supplemental Logging
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

3-2
 Chapter 3
Preparing the Source Database for Migration

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK;
ALTER SESSION SET CONTAINER=PDB;
ALTER USER SYSTEM ACCOUNT UNLOCK;

• To configure Amazon RDS (non-CDB) as a source for migration, run the following SQL
commands:

-- Remember to set the following parameters thru the Parameter groups

functionality:
-- STREAMS_POOL_SIZE=2147483648
-- GLOBAL_NAMES=FALSE
-- To see how Parameter groups work refer to https://docs.aws.amazon.com/
AmazonRDS/latest/UserGuide/parameter-groups-overview.html

-- Archive Log Mode

EXEC RDSADMIN.RDSADMIN_UTIL.SET_CONFIGURATION('ARCHIVELOG RETENTION
HOURS',72);

-- Force Logging
EXEC RDSADMIN.RDSADMIN_UTIL.FORCE_LOGGING(P_ENABLE => TRUE);

-- Supplemental Logging
EXEC RDSADMIN.RDSADMIN_UTIL.ALTER_SUPPLEMENTAL_LOGGING('ADD');

Additional Configurations for Preparing the Source Database for Online

Migration
Before you can migrate data with Oracle Cloud Infrastructure Database Migration, perform
additional configurations for your source database for online migration as described here.
• To configure a single-tenant (Non CDB) as a source for online migration, run the following
SQL commands:

-- Archive Log Mode

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- Stream Pool Size

ALTER SYSTEM SET STREAMS_POOL_SIZE=2G;

-- Force Logging
ALTER DATABASE FORCE LOGGING;

-- Enable GoldenGate
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE;

-- Supplemental Logging

3-3
 Chapter 3
Preparing the Source Database for Migration

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK;

-- Create GoldenGate nonCDB user

CREATE TABLESPACE GG_ADMIN DATAFILE '+DATA/ggadmin_data.dbf' SIZE 100m
AUTOEXTEND ON NEXT 100m;
CREATE USER GGADMIN IDENTIFIED BY ggadmin_pwd DEFAULT TABLESPACE
GG_ADMIN TEMPORARY TABLESPACE TEMP QUOTA 100M ON GG_ADMIN;
GRANT CONNECT TO GGADMIN;
GRANT RESOURCE TO GGADMIN;
GRANT CREATE TO GGADMIN;
GRANT SELECT_CATALOG_ROLE TO GGADMIN;
GRANT DV_GOLDENGATE_ADMIN TO GGADMIN;
GRANT DV_GOLDENGATE_REDO_ACCESS TO GGADMIN;
GRANT ALTER SYSTEM TO GGADMIN;
GRANT ALTER USER TO GGADMIN;
GRANT DATAPUMP_EXP_FULL_DATABASE TO GGADMIN;
GRANT DATAPUMP_IMP_FULL_DATABASE TO GGADMIN;
GRANT SELECT ANY DICTIONARY TO GGADMIN;
GRANT SELECT ANY TRANSACTION TO GGADMIN;
GRANT INSERT ANY TABLE TO GGADMIN;
GRANT UPDATE ANY TABLE TO GGADMIN;
GRANT DELETE ANY TABLE TO GGADMIN;
GRANT LOCK ANY TABLE TO GGADMIN;
GRANT CREATE ANY TABLE TO GGADMIN;
GRANT CREATE ANY INDEX TO GGADMIN;
GRANT CREATE ANY CLUSTER TO GGADMIN;
GRANT CREATE ANY INDEXTYPE TO GGADMIN;
GRANT CREATE ANY OPERATOR TO GGADMIN;
GRANT CREATE ANY PROCEDURE TO GGADMIN;
GRANT CREATE ANY SEQUENCE TO GGADMIN;
GRANT CREATE ANY TRIGGER TO GGADMIN;
GRANT CREATE ANY TYPE TO GGADMIN;
GRANT CREATE ANY SEQUENCE TO GGADMIN;
GRANT CREATE ANY VIEW TO GGADMIN;
GRANT ALTER ANY TABLE TO GGADMIN;
GRANT ALTER ANY INDEX TO GGADMIN;
GRANT ALTER ANY CLUSTER TO GGADMIN;
GRANT ALTER ANY INDEXTYPE TO GGADMIN;
GRANT ALTER ANY OPERATOR TO GGADMIN;
GRANT ALTER ANY PROCEDURE TO GGADMIN;
GRANT ALTER ANY SEQUENCE TO GGADMIN;
GRANT ALTER ANY TRIGGER TO GGADMIN;
GRANT ALTER ANY TYPE TO GGADMIN;
GRANT ALTER ANY SEQUENCE TO GGADMIN;
GRANT CREATE DATABASE LINK TO GGADMIN;
GRANT EXECUTE ON dbms_lock TO GGADMIN;
EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN');

3-4
 Chapter 3
Preparing the Source Database for Migration

• To configure a multi-tenant (CDB) as a source for online migration, run the following SQL
commands:

-- Connect to CDB and run:

-- Archive Log Mode

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- Stream Pool Size

ALTER SYSTEM SET STREAMS_POOL_SIZE=2G SCOPE=BOTH;

-- Force Logging
ALTER DATABASE FORCE LOGGING;

-- Enable GoldenGate
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;

-- Supplemental Logging
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK CONTAINER=ALL;

-- Create GoldenGate users

-- CDB user
ALTER SESSION SET CONTAINER = CDB$ROOT;
CREATE USER C##GGADMIN IDENTIFIED BY cggadmin_pwd CONTAINER=ALL DEFAULT
TABLESPACE USERS TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON USERS;
GRANT CONNECT TO C##GGADMIN CONTAINER=ALL;
GRANT RESOURCE TO C##GGADMIN CONTAINER=ALL;
GRANT CREATE TABLE TO C##GGADMIN CONTAINER=ALL;
GRANT CREATE VIEW TO C##GGADMIN CONTAINER=ALL;
GRANT CREATE SESSION TO C##GGADMIN CONTAINER=ALL;
GRANT SELECT_CATALOG_ROLE TO C##GGADMIN CONTAINER=ALL;
GRANT DV_GOLDENGATE_ADMIN TO C##GGADMIN CONTAINER=ALL;
GRANT DV_GOLDENGATE_REDO_ACCESS TO C##GGADMIN CONTAINER=ALL;
GRANT ALTER SYSTEM TO C##GGADMIN CONTAINER=ALL;
GRANT ALTER USER TO C##GGADMIN CONTAINER=ALL;
GRANT SELECT ANY DICTIONARY TO C##GGADMIN CONTAINER=ALL;
GRANT SELECT ANY TRANSACTION TO C##GGADMIN CONTAINER=ALL;
GRANT EXECUTE ON dbms_lock TO C##GGADMIN CONTAINER=ALL;
EXEC
DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('C##GGADMIN',CONTAINER=>'ALL');

-- PDB User
ALTER SESSION SET CONTAINER = v_pdb_name;
CREATE TABLESPACE GG_ADMIN DATAFILE '+DATA/ggadmin_data.dbf' SIZE 100m
AUTOEXTEND ON NEXT 100m;
CREATE USER GGADMIN IDENTIFIED BY ggadmin_pwd CONTAINER=CURRENT DEFAULT

3-5
 Chapter 3
Preparing the Source Database for Migration

TABLESPACE GG_ADMIN TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON

GG_ADMIN;
GRANT CONNECT TO GGADMIN CONTAINER=CURRENT;
GRANT RESOURCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE TO GGADMIN CONTAINER=CURRENT;
GRANT SELECT_CATALOG_ROLE TO GGADMIN CONTAINER=CURRENT;
GRANT DV_GOLDENGATE_ADMIN TO GGADMIN CONTAINER=CURRENT;
GRANT DV_GOLDENGATE_REDO_ACCESS TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER SYSTEM TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER USER TO GGADMIN CONTAINER=CURRENT;
GRANT DATAPUMP_EXP_FULL_DATABASE TO GGADMIN CONTAINER=CURRENT;
GRANT DATAPUMP_IMP_FULL_DATABASE TO GGADMIN CONTAINER=CURRENT;
GRANT SELECT ANY DICTIONARY TO GGADMIN CONTAINER=CURRENT;
GRANT SELECT ANY TRANSACTION TO GGADMIN CONTAINER=CURRENT;
GRANT INSERT ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT UPDATE ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT DELETE ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT LOCK ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY INDEX TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY CLUSTER TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY INDEXTYPE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY OPERATOR TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY PROCEDURE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY TRIGGER TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY TYPE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY VIEW TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY INDEX TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY CLUSTER TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY INDEXTYPE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY OPERATOR TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY PROCEDURE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY TRIGGER TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY TYPE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE DATABASE LINK TO GGADMIN CONTAINER=CURRENT;
GRANT EXECUTE ON dbms_lock TO GGADMIN CONTAINER=CURRENT;
EXEC
DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN',CONTAINER=>'CURREN
T');

• To configure Amazon RDS (non-CDB) as a source for online migration, run the
following SQL commands:

-- Remember to set the following parameters thru the Parameter

groups functionality:
-- STREAMS_POOL_SIZE=2147483648
-- ENABLE_GOLDENGATE_REPLICATION=TRUE
-- GLOBAL_NAMES=FALSE
-- To see how Parameter groups work refer to https://

3-6
 Chapter 3
Preparing the Source Database for Migration

docs.aws.amazon.com/AmazonRDS/latest/UserGuide/parameter-groups-
overview.html

-- Archive Log Mode

EXEC RDSADMIN.RDSADMIN_UTIL.SET_CONFIGURATION('ARCHIVELOG RETENTION
HOURS',72);

-- Force Logging
EXEC RDSADMIN.RDSADMIN_UTIL.FORCE_LOGGING(P_ENABLE => TRUE);

-- Supplemental Logging
EXEC RDSADMIN.RDSADMIN_UTIL.ALTER_SUPPLEMENTAL_LOGGING('ADD');

-- Create GoldenGate user

CREATE USER GGADMIN IDENTIFIED BY ggadmin_pwd DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP QUOTA 100M ON USERS;
GRANT UNLIMITED TABLESPACE TO GGADMIN;
GRANT CONNECT, RESOURCE TO GGADMIN;
GRANT SELECT ANY DICTIONARY TO GGADMIN;
GRANT CREATE VIEW TO GGADMIN;
GRANT EXECUTE ON DBMS_LOCK TO GGADMIN;
GRANT SELECT ON SYS.CCOL$ TO GGADMIN;
GRANT SELECT ON SYS.CDEF$ TO GGADMIN;
GRANT SELECT ON SYS.COL$ TO GGADMIN;
GRANT SELECT ON SYS.CON$ TO GGADMIN;
GRANT SELECT ON SYS.DEFERRED_STG$ TO GGADMIN;
GRANT SELECT ON SYS.ICOL$ TO GGADMIN;
GRANT SELECT ON SYS.IND$ TO GGADMIN;
GRANT SELECT ON SYS.LOB$ TO GGADMIN;
GRANT SELECT ON SYS.LOBFRAG$ TO GGADMIN;
GRANT SELECT ON SYS.OBJ$ TO GGADMIN;
GRANT SELECT ON SYS.SEG$ TO GGADMIN;
GRANT SELECT ON SYS.TAB$ TO GGADMIN;
GRANT SELECT ON SYS.TABCOMPART$ TO GGADMIN;
GRANT SELECT ON SYS.TABPART$ TO GGADMIN;
GRANT SELECT ON SYS.TABSUBPART$ TO GGADMIN;
EXEC RDSADMIN.RDSADMIN_DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE
(GRANTEE=>'GGADMIN',PRIVILEGE_TYPE=>'CAPTURE',GRANT_SELECT_PRIVILEGES=>TRU
E,DO_GRANTS=>TRUE);

Use Case for Preparing the Source Database for Migration

Following is a sample use case to prepare your source database for migration. To configure a
PDB as a source for your migration, the steps are similar to setting up a classic database as
a source, but there are requirements for using the CDBROOT as ggaliassrc.

The steps differ slightly if you're using a PDB as your source database, so make sure you
follow the recommendations if your database is in a multitenant environment.
1. Configure the streams pool with the initialization parameter STREAMS_POOL_SIZE.
• For offline logical migrations, for optimal Data Pump performance, it is required that
you set STREAMS_POOL_SIZE to a minimum of 256MB-350MB, to have an initial pool
allocated, otherwise you might see a significant delay during start up.

3-7
 Chapter 3
Preparing the Source Database for Migration

• For online logical migrations, set STREAMS_POOL_SIZE to at least 2GB.

For the explanation of 1GB STREAMS_POOL_SIZE per integrated extract +
additional 25 percent recommendation, see Integrated Extract / Replicat and
STREAMS_POOL_SIZE (Doc ID 2078459.1).
2. Check the GLOBAL_NAMES parameter. If it's set to true, change it to false.

sqlplus > show parameter global

NAME TYPE VALUE
------------------------------------ -------
------------------------------
global_names boolean TRUE

sqlplus > alter system set global_names=false

3. Enable ARCHIVELOG if it is not already enabled.

a. Check whether archivelog is enabled:

sqlplus > archive log list

Sample output returned:

Database log mode Archive log Mode

Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 33
Next log sequence to archive 35
Current log sequence 35

b. Enable archivelog mode:

sqlplus > shutdown immediate

sqlplus > startup mount
sqlplus > alter database archivelog;
sqlplus > alter database open;

c. Disable archivelog mode (for clean up later)

sqlplus > shutdown immediate

sqlplus > startup mount
sqlplus > alter database noarchivelog;
sqlplus > alter database open;

4. Enable logging:
a. Check if logging is enabled:

sqlplus > SELECT supplemental_log_data_min, force_logging FROM

v$database;

3-8
 Chapter 3
Preparing the Source Database for Migration

b. Enable logging:

sqlplus > ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

sqlplus > ALTER DATABASE FORCE LOGGING;

c. Disable logging (for cleanup later)

sqlplus > ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

sqlplus > ALTER DATABASE NO FORCE LOGGING;

5. Create a database administrator user that has full Oracle Data Pump privileges for initial
load to be performed. A user that has the DATAPUMP_EXP_FULL_DATABASE role is required
for the export operation at the source database. This user is selected as database
administrator when you create Database connections with the source databases.
See Oracle Data Pump in the Oracle Database Utilities guide for more information.
6. In the PDB being exported, if there is any dependency created on local objects in the C##
user's schema, then they would fail to be imported in the target Autonomous Database.
Exclude the problematic schema from the migration job.
7. If you are using Object Storage as a data transfer medium, ensure that an export
Directory Object exists and is usable by Data Pump to store generated dump files.
• The directory object is a file path on the source database server file system. The
name needs to comply with Oracle Database directory object rules. See CREATE
DIRECTORY in Oracle Database SQL Language Reference for details.
• The export Directory Object must be owned by same OS user who owns the
database Oracle home.
• This step is not required if you are using a database link transfer medium.
8. If you plan to transfer data using a database link, then you must set up SSL encryption on
the source database. Using Data Pump with a database link to an Autonomous Database
target requires that the source database have SSL encryption enabled. Creating a
database link from an Autonomous Database Shared Infrastructure target to a source
database with a private IP requires assistance from Oracle Support.
See Configuring Transport Layer Security Authentication in Oracle Database Security
Guide for more information.
9. For online logical migrations, if you plan to run migrations with replication, enable
GoldenGate Replication:
a. In a multitenant environment, if you are migrating a PDB, enable GoldenGate
Replication on the CDB.

sqlplus > ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE

SCOPE=BOTH;

b. Apply the mandatory RDBMS patches on the source database, based on your source
database version:
• Oracle Database 11.2:
My Oracle Support note Oracle GoldenGate -- Oracle RDBMS Server
Recommended Patches (Doc ID 1557031.1) recommends the following updates:
Database PSU 11.2.0.4.210720 includes a fix for Oracle GoldenGate
performance bug 28849751 - IE PERFORMANCE DEGRADES WHEN

3-9
 Chapter 3
Preparing the Target Database for Migration

NETWORK LATENCY BETWEEN EXTRACT AND CAPTURE IS MORE

THAN 8MS
OGG RDBMS patch 32248879 MERGE REQUEST ON TOP OF
DATABASE PSU 11.2.0.4.201020 FOR BUGS 32048478 20448066 - This
patch contains mandatory fix for Oracle GoldenGate Microservices bug
20448066 DBMS_XSTREAM_GG APIS SHOULD BE ALLOWED FOR
SCA PROCESSES
• Oracle Database 12.1.0.2 or later
My Oracle Support note Latest GoldenGate/Database (OGG/RDBMS)
Patch recommendations (Doc ID 2193391.1) lists the additional RDBMS
patches needed on top of the latest DBBP/RU for Oracle Database 12c
and later if using Oracle GoldenGate.

Preparing the Target Database for Migration

Before you can migrate data with Oracle Cloud Infrastructure Database Migration,
manually configure your target database as described here.
• To configure an Autonomous database as a target for migration, run the following
SQL commands:

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

• To configure a non-Autonomous, single-tenant (non-CDB) as a target for

migration, run the following SQL commands:

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK;

• To configure a non-Autonomous, multi-tenant (CDB) as a target for migration, run

the following SQL commands:

-- Connect to CDB and run:

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK
SCOPE=BOTH;

3-10
 Chapter 3
Preparing the Target Database for Migration

Additional Configurations for Preparing the Target Database for Online

Migration
Before you can migrate data with Oracle Cloud Infrastructure Database Migration, perform
additional configurations for your target database for online migration as described here.
You must unlock the ggadmin user from the Oracle Cloud Infrastructure Console by
performing the following steps:
1. Follow step 1 through step 3 mentioned in Manage Users and User Roles on
Autonomous Database - Connecting with Database Actions.
2. Turn off the Account is locked toggle.
3. Provide a password with its corresponding confirmation.
• Alternatively, to configure an Autonomous database as a target for online migration, run
the following SQL commands:

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- Create GoldenGate user if doesn't exist

CREATE TABLESPACE GG_ADMIN DATAFILE '+DATA/ggadmin_data.dbf' SIZE 100m
AUTOEXTEND ON NEXT 100m;
CREATE USER GGADMIN IDENTIFIED BY ggadmin_pwd CONTAINER=CURRENT DEFAULT
TABLESPACE GG_ADMIN TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON GG_ADMIN;

-- Or unlock it if exists
ALTER USER GGADMIN IDENTIFIED BY ggadmin_pwd ACCOUNT UNLOCK;

• To configure a non-Autonomous, single-tenant (non-CDB) as a target for online migration,

run the following SQL commands:

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK;

-- Create GoldenGate nonCDB user

CREATE TABLESPACE GG_ADMIN DATAFILE '+DATA/ggadmin_data.dbf' SIZE 100m
AUTOEXTEND ON NEXT 100m;
CREATE USER GGADMIN IDENTIFIED BY ggadmin_pwd DEFAULT TABLESPACE GG_ADMIN
TEMPORARY TABLESPACE TEMP QUOTA 100M ON GG_ADMIN;
GRANT CONNECT TO GGADMIN;
GRANT RESOURCE TO GGADMIN;
GRANT CREATE TO GGADMIN;
GRANT SELECT_CATALOG_ROLE TO GGADMIN;
GRANT DV_GOLDENGATE_ADMIN TO GGADMIN;
GRANT DV_GOLDENGATE_REDO_ACCESS TO GGADMIN;
GRANT ALTER SYSTEM TO GGADMIN;
GRANT ALTER USER TO GGADMIN;
GRANT DATAPUMP_EXP_FULL_DATABASE TO GGADMIN;

3-11
 Chapter 3
Preparing the Target Database for Migration

GRANT DATAPUMP_IMP_FULL_DATABASE TO GGADMIN;

GRANT SELECT ANY DICTIONARY TO GGADMIN;
GRANT SELECT ANY TRANSACTION TO GGADMIN;
GRANT INSERT ANY TABLE TO GGADMIN;
GRANT UPDATE ANY TABLE TO GGADMIN;
GRANT DELETE ANY TABLE TO GGADMIN;
GRANT LOCK ANY TABLE TO GGADMIN;
GRANT CREATE ANY TABLE TO GGADMIN;
GRANT CREATE ANY INDEX TO GGADMIN;
GRANT CREATE ANY CLUSTER TO GGADMIN;
GRANT CREATE ANY INDEXTYPE TO GGADMIN;
GRANT CREATE ANY OPERATOR TO GGADMIN;
GRANT CREATE ANY PROCEDURE TO GGADMIN;
GRANT CREATE ANY SEQUENCE TO GGADMIN;
GRANT CREATE ANY TRIGGER TO GGADMIN;
GRANT CREATE ANY TYPE TO GGADMIN;
GRANT CREATE ANY SEQUENCE TO GGADMIN;
GRANT CREATE ANY VIEW TO GGADMIN;
GRANT ALTER ANY TABLE TO GGADMIN;
GRANT ALTER ANY INDEX TO GGADMIN;
GRANT ALTER ANY CLUSTER TO GGADMIN;
GRANT ALTER ANY INDEXTYPE TO GGADMIN;
GRANT ALTER ANY OPERATOR TO GGADMIN;
GRANT ALTER ANY PROCEDURE TO GGADMIN;
GRANT ALTER ANY SEQUENCE TO GGADMIN;
GRANT ALTER ANY TRIGGER TO GGADMIN;
GRANT ALTER ANY TYPE TO GGADMIN;
GRANT ALTER ANY SEQUENCE TO GGADMIN;
GRANT CREATE DATABASE LINK TO GGADMIN;
GRANT EXECUTE ON dbms_lock TO GGADMIN;
EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN');

• To configure a non-Autonomous, multi-tenant (CDB) as a target for online

migration, run the following SQL commands:

-- Connect to CDB and run:

-- Global Names
ALTER SYSTEM SET GLOBAL_NAMES=FALSE;

-- User system for Datapump

ALTER USER SYSTEM IDENTIFIED BY system_pwd ACCOUNT UNLOCK
CONTAINER=ALL;

-- Create GoldenGate PDB User

ALTER SESSION SET CONTAINER = v_pdb_name;
CREATE TABLESPACE GG_ADMIN DATAFILE '+DATA/ggadmin_data.dbf' SIZE
100m AUTOEXTEND ON NEXT 100m;
CREATE USER GGADMIN IDENTIFIED BY ggadmin_pwd CONTAINER=CURRENT
DEFAULT TABLESPACE GG_ADMIN TEMPORARY TABLESPACE TEMP QUOTA
UNLIMITED ON GG_ADMIN;
GRANT CONNECT TO GGADMIN CONTAINER=CURRENT;
GRANT RESOURCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE TO GGADMIN CONTAINER=CURRENT;

3-12
 Chapter 3
Preparing the Target Database for Migration

GRANT SELECT_CATALOG_ROLE TO GGADMIN CONTAINER=CURRENT;

GRANT DV_GOLDENGATE_ADMIN TO GGADMIN CONTAINER=CURRENT;
GRANT DV_GOLDENGATE_REDO_ACCESS TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER SYSTEM TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER USER TO GGADMIN CONTAINER=CURRENT;
GRANT DATAPUMP_EXP_FULL_DATABASE TO GGADMIN CONTAINER=CURRENT;
GRANT DATAPUMP_IMP_FULL_DATABASE TO GGADMIN CONTAINER=CURRENT;
GRANT SELECT ANY DICTIONARY TO GGADMIN CONTAINER=CURRENT;
GRANT SELECT ANY TRANSACTION TO GGADMIN CONTAINER=CURRENT;
GRANT INSERT ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT UPDATE ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT DELETE ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT LOCK ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY INDEX TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY CLUSTER TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY INDEXTYPE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY OPERATOR TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY PROCEDURE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY TRIGGER TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY TYPE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE ANY VIEW TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY TABLE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY INDEX TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY CLUSTER TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY INDEXTYPE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY OPERATOR TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY PROCEDURE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY TRIGGER TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY TYPE TO GGADMIN CONTAINER=CURRENT;
GRANT ALTER ANY SEQUENCE TO GGADMIN CONTAINER=CURRENT;
GRANT CREATE DATABASE LINK TO GGADMIN CONTAINER=CURRENT;
GRANT EXECUTE ON dbms_lock TO GGADMIN CONTAINER=CURRENT;
EXEC
DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('GGADMIN',CONTAINER=>'CURRENT')
;

Use Case for Preparing the Target Database for Migration

Following is a sample use case for preparing a target database for migration.

1. Create an Autonomous Database. If the target autonomous database is already present

you can skip this step.
2. Check the GLOBAL_NAMES parameter. If it's set to true, change it to false.

sqlplus > show parameter global

NAME TYPE VALUE
------------------------------------ -------
------------------------------
global_names boolean TRUE

3-13
 Chapter 3
Preparing the Target Database for Migration

sqlplus > alter system set global_names=false

3. Create a database administrator user that has full Oracle Data Pump privileges for
initial load to be performed. A user that has the DATAPUMP_IMP_FULL_DATABASE role
is required for the export operation at the target database. This user is selected as
database administrator when you create Database connections with the target
databases.
See Oracle Data Pump in the Oracle Database Utilities guide for more information.

3-14
4
Managing Connections
To perform migration, create connections to your source and target databases by creating
database connection resources. Database Connection resources enable network connectivity
to the source and target databases.

Creating Connections
Oracle Cloud Infrastructure Database Migration database connection resources contain the
connectivity details of the migration source and target databases. Create connection
database resources in the Database Migration Databases Connections page.

Note:
Oracle Cloud Infrastructure Database Migration service runs network connectivity
tests followed by database login tests (to validate credentials) using the information
that you provided while creating database connections. See Testing Connectivity of
a Database Connection.

Note:
If the source database is a multitenant container database (CDB), and you are
performing an online migration, you must create two connection entries for the
source database: one for the PDB and one for the CDB. For offline migrations only
the PDB connection is required.
You will create only one database connection resource for the target database.

1. Log in to the Console as a user with permissions to create database connections in

Database Migration.
2. Open the navigation menu. Under Database Migrations click Database Connections.
3. Click Create Connection.
4. On the Database Details step, in the Name field, enter a display name for the database
connection resource.
This is not the actual database name, but a name that will appear in a list of databases
connections on completion of this procedure. Note that the database connection
resources for all source databases (CDB and PDB) and target databases will appear the
same list.
5. In Compartment select the compartment in which the Database Connection resource will
be created.
6. In Vault in Compartment select the security vault.

4-1
 Chapter 4
Creating Connections

Database Migration uses the OCI Vault to store user secrets such as passwords,
wallets, and keys, and encrypts them with the user-supplied encryption key.
You can select a vault in a different compartment by clicking Change
Compartment.
7. In Encryption Key in Compartment select the keystore that you configured in the
vault.
Only AES algorithm type keys are supported.
8. Select and enter the appropriate information for one of the following options.
• Select Database: You can use this option to select a database configured in
the same region on OCI.
Note that for this option the following fields are pre-filled with values for the
CDB, so if you are registering a PDB you will need to correct the values.
– Database Type: Select Database (Bare Metal, VM, Exadata) or
VM Cluster Database for this option. Note that Autonomous Database
is not supported as a source database.
– Database System in Compartment: Select an OCI database.
– Database Home: The database home (not applicable to Autonomous
Database or VM Cluster)
– Database: The database (not applicable to Autonomous Database)
– Connect String: This is the full connect string with host, port, and service
name. The default connect string is for the CDB of the given database
system. When creating connection for a PDB, update the service name in
the connect string. (not applicable to Autonomous Database)
• Manually Configure Database: Use this option to select a source database
that is not directly accessible on OCI.
Use this choice if the source database is not in the same region or tenancy in
OCI, an on premises database, or a manually installed cloud database.

Note:
Databases configured manually cannot be used as target databases
in migrations.

– Database Type: Select Oracle or Amazon RDS for this option.

– Based on the Database Type selected you then enter connection
information in the following fields.
* For Database Type Oracle:
Host: listener host IP address
Port: listener port number
Service Name: database CDB, PDB, or non-CDB database service
name
* For Database Type Amazon RDS:

4-2
 Chapter 4
Creating Connections

Connect String: This is the full connect string with host, port, and service
name, for example:
host:port/db-service-name
If a private endpoint is specified in the connection, the host entry should be a
valid IP address.

Note:
Amazon RDS is only supported as a source database. For more
information about the Amazon RDS source database use case, see
Migrating Databases from Amazon Web Services RDS to Oracle
Autonomous Database

9. Create private endpoint to access this database indicates whether the database is
publicly accessible or if you want to create a private endpoint.
Check this box if you plan to connect your database over a private IP address. Do not
check it if the database has a public IP address.
Note that if you are creating connection for an Autonomous Database, the Subnet in
Compartment field is populated automatically with the connection string.
10. In Subnet in Compartment, select the subnet to which a private endpoint is created
from the Oracle Cloud Infrastructure Database Migration service tenancy. This creates a
network route for the Oracle Cloud Infrastructure Database Migration deployment to
connect to the database within your customer tenancy. Select the subnet containing the
appropriate Virtual Cloud Network (VCN), then click Next.Click Change Compartment to
select a subnet in a different compartment.
If the source database is a PDB, you only need to fill this out in the database connection
resource for the PDB, not the CDB.
11. The Advanced Options section allows you to optionally create tags.

12. On the Connection Details step, the fields displayed are dependent on which database
type you selected in the previous step.
• Database administrator credentials:
Enter the database administrator credentials in Initial load database username and
Initial load database password.
For source and target database connections, the user entered must have the
required initial load privileges. See Preparing Your Databases for Migrationfor further
details.
SYS is not accepted.
• Select Use different credentials for replication to enter the credentials for
replication. Select this option if you want to use a separate database user for
performing replication for your online migrations. The following options are available:
– Replication database username
– Replication database password
• In Show optional SSH settings, provide the SSH information for your database
hosts if you wish to provide SSH access to the service to perform the migrations.
Provide the SSH related information as follows:
SSH settings:

4-3
 Chapter 4
Testing Connectivity of a Database Connection

Note:
Ensure that the private SSH key file is an RSA key in PEM format.
See Required Keys and OCIDs for more information.

In SSH database server hostname, enter the IP address of the database

host. This will be used by the service to connect to your host through/via SSH
to perform the migration. Select the valid private key file used for database
host access.

Note:
Enter a valid SSH username that will be used by the service to
create a ssh session to the database host. This user should have the
sudo privilege to perform the necessary operations.

In SSH Private Key, select the private key file used to access the database
server host.
In SSH Username enter an OS user name for the database host. This user
must be a privileged user allowed to run sudo.
Note that the opc user is a standard Oracle cloud user that is used to access
database servers, but you can use any privileged user that has sudo
privileges.
In SSH Sudo Location enter the sudo binary location on the database host.
13. Click Create.

After you click Create, the database connection name appears in the Connection list
while the creating connection operation runs. The creating connection operation can
take a few minutes.
You can monitor the operation status in the State column. When the state is Active,
the database connection creation is complete and successful.
When the resource creation is complete and successful, check the Security Vault
service to verify that the SSH private key file was uploaded and enabled in the vault
you configured.

Note:
Remember to run through this procedure twice if your source database is a
PDB, to create two source database connection resources: one for the PDB
and one for the CDB.

Testing Connectivity of a Database Connection

4-4
 Chapter 4
Viewing Connection Details

You can test the connectivity of a database connection before you start or create a migration.
You can get information about the connection and fix any configuration issues before running
the migration.
You can diagnose issues with a database connection such as:
• Incorrect IP address and/or port.
• Incorrectly declaring a connection public or private.
• Incorrect, expired, or locked database credentials.
• Missing entries in security lists or NSGs to allow communication with database IP or port.
• Connection failures through FastConnect, VPN, or any other network connectivity issues
for your on-premises database.
Oracle Cloud Infrastructure Database Migration service runs a network connectivity
check followed by JDBC Connection or Socket Connectivity using the Database
Connection data that you provide.
To test the connectivity of a database connection use either of the following methods:
• From the action menu (three dots), select Test connection.
• Select the database connection, which opens the Database connection details page and
click the Test connection button.
The Test connection dialog is displayed.
The Test connection dialog displays the following details:
• Result of the connection test. Following results are available:
– Diagnostic tests passed, connection to your database was successful.
– Connection diagnostics test failed
• Error codes and the accompanying error messages.
• Cause: The issue causing the connection failure.
• Action: The action you can perform to resolve the error.

Viewing Connection Details

Database connection details page
On the Database connection details page you can view a list of your Connections in a table,
which includes the following information:
• Name of the Connection resource
• State of the Connection resource, which can be any one of the following:
– Creating: The new Connection resource is being created in OCI.
– Updating: Changes to the Connection resource are being registered in OCI.
– Active: The Connection resource has finished being created or updated and is ready
for use.
– Inactive: A fallback state for unexpected errors.
– Deleting: This state appears when you delete a Connection resource. The resource
remains in this state until deletion is completed, at which point the resource is no
longer listed in the console.

4-5
 Chapter 4
Viewing Connection Details

– Failed: There are problems with the Connection resource. You can review the
Connection resource work requests to investigate the issue.
• Created date and time

Database connection details page

Select a Connection from the Database connection details to view its details.
On the Database connection details page you can view the Connection information,
including:
• OCID: The resource's unique Oracle Cloud ID.
• Compartment: The compartment where the Connection resides.
• Created: The date and time when the Connection was created.
• Encryption Vault: The link takes you to the Vault Details page.
• Encryption Key: The link takes you to the Key Details page
• Subnet: The link takes you to the Subnet Details page.
• Database Type: Autonomous Database, Database (BareMetal, VM, Exadata), VM
Cluster Database (Exadata), Oracle, or Amazon RDS
• Database: For OCI co-managed databases--Autonomous Database, Database
(BareMetal, VM, Exadata), VM Cluster Database (Exadata)--the display name of
this Connection is also shown. The link takes you to the Database Details page in
OCI.
Network security groups
On the Database connection details page, under the Resources on the left side of the
page, you can find the Network Security Groups that can be associated, with this
database connection.

Note:

• You can associate NSGs available in your VCN to the connection. The
NSGs that are listed for a subnet are only applicable to your current
VCN.
• You can add network security groups in Database Migration Service to
control traffic, if you have connected over private endpoints while
registering databases. The advantage of network security groups
(NSGs) is that rules can be limited to individual resources within a
subnet, whereas Security Lists apply to all resources within a subnet.
• Associating NSGs to database connections provides you fine grained
control over the access to your database connection resources that are
involved in the migration process (Source and Target). See Network
Security Groups for more information.

1. Click Add network security groups to open the Add network security groups
panel.

4-6
 Chapter 4
Editing a Connection

2. Select a network security group from the compartment and click Add network security
groups.
3. You can add up-to five unique network security groups by clicking on Another network
security group.
You can view the following details associated with the Network security groups Resource:
• Name : The name of the added network security group.
• State: The state of the network security group.
• Compartment : The compartment where the network security group resides.
• Created : The date and time when the network security group was created.
Select single or multiple network security groups to remove them by clicking Remove in the
Remove network security groups confirmation dialog.
Select View details from the actions menu (three dots) for a specific NSG to view information
related to VCN.

Work Requests
On the Database connection details page, under the Connection information box you can find
the Work Requests list. Work Requests lists any work requests sent to OCI to facilitate the
creation, update, or deletion of this resource. Click the work request to go to the Work
Request Details page for more information about the work request.

Editing a Connection
To edit a connection:
1. In the list of databases on the Databases connection details page, select the Name of the
Connection you want to edit.
2. In the Database connection details page, select Rename to change the name of the
Connection.
3. Select Edit next to any of the following fields to update the settings:
• Encryption Key: You can change the selected vault, encryption key, and
compartment in which to create a secret. Only AEP algorithm type keys are
supported.
• Subnet: You can update the subnet and private endpoint compartment network
connectivity settings.
• Database: you can update the database administrator user name and password
used to connect to the database. When editing a non-Autonomous database
connection, you can also edit connect string, SSH details, and TLS details. The
following options are available:
– Connect string
– Initial load database username
– Initial load database password
– If you select Use different credentials for replication , enter the following
details:
* Replication database username

4-7
 Chapter 4
Moving a Connection

* Replication database password

– Keep existing certificates/key pair configuration
– Remove certificate/key pair configuration
– Update certificate/key pair configuration
– In the Show optional SSH settings, provide the SSH information for your
database hosts if you wish to provide SSH access to the service to
perform the migrations. Provide the SSH related information.
4. Click Save Changes.

Moving a Connection
You can move a Connection from one compartment to another.
To move a Connection:
1. In the list of databases on the Database connection details page, select Move
Resource from the Actions (three dots) menu for the database you want to move.
You can also select Move Resource on the Database connection details page.
2. In the Move Resource to a Different Compartment dialog, select the
compartment to move the Connection to from the dropdown.
3. Click Move Resource.
After you move the Connection to the new compartment, inherent policies apply
immediately and may affect access to the Connection through the Console. For more
information, see Managing Compartments.

Deleting a Connection
Before you delete a Connection, ensure that you carefully review any resources that
reference the Connection. It is not possible to delete a Connection if it is references by
a migration. You must delete the migration before deleting the associated
Connections.
Deleting a Connection also deletes the private connection and database credentials,
so it will no longer be accessible to migrations. After you delete a Connection, it cannot
be restored.

Note:
Connections also capture and synchronize database credentials to Database
Migration. Any change made to the credential, such as updating or deleting,
synchronizes to Database Migration. You will encounter issues when the
Replicat or Extract attempts to reconnect to a deleted Connection.

To delete a Connection:
1. In the list of databases on the Database connection details page, select Delete
from the Actions (three dots) menu of the database you want to delete.

4-8
 Chapter 4
Managing Tags for Connections

You can also click Delete on the Database connection page.

2. In the Delete dialog, click Delete.

Managing Tags for Connections

Tags help you locate resources within your tenancy. You can add and view a connection's
tags from the Database Connections page and from the Database connection details page.
On the Database connection details page, from the Connection's Actions (three dots) menu,
select Add Tags or View Tags.
On the Database connection details page, you can select Add Tags above the Connection
Information box, or click the Tags tab to view and edit tags.
See Managing Tags and Tag Namespaces to learn more about tagging.

Using the Connection API

You can use the following operations to manage Connection resources:
• CreateConnection
• GetConnection
• ListConnections
• UpdateConnection
• DeleteConnection
• ChangeConnectionCompartment
For information about using the API and signing requests, see REST APIs and Security
Credentials. For more information about SDKs, see Software Development Kits and
Command Line Interface.

4-9
5
Managing Migrations
When you create a migration with Oracle Cloud Infrastructure Database Migration, you
specify how the migration should run, select the source and target databases, and then
configure the data transport settings. Optionally, you can configure advanced GoldenGate
and Data Pump settings in the migration using the Database Migration console.

Creating Migrations
A migration contains the parameter settings for running a migration job with Oracle Cloud
Infrastructure Database Migration.
The following procedure explains how to create migrations, which contain the settings for
running migration jobs with Database Migration. You can create multiple migration resources
with different parameter settings to test different scenarios.

Creating a Migration
1. Log in to the Console as a user with permissions to access Database Migration.
2. Open the navigation menu. Under Database Migrations click Migrations. A list of the
migration resources in the currently selected compartment is displayed.
3. Click Create migration.
This opens the Create migration wizard.
4. In the Add details step, configure the following settings, then click Next.
• Name: Enter a unique name for the migration.
On completion of the Create Migration wizard, the name you enter here is displayed
in the list of migrations on the Migrations page.
• Compartment: Select the compartment in which the Database Migration service is
hosted.
• Choose the source database connection type.
Direct connection to source database: Leave this option selected if the source
database is directly accessible from the cloud. You can do online and offline
migrations with this option.
No direct connection to source database: Lets you select a Database Migration
agent to use as a bridge to the source database.
You must install and register an agent before configuring a migration with no direct
connection to the source database. The link to download the agent is located on the
Migrations page above the list.
See Managing Agents for details.

5-1
 Chapter 5
Creating Migrations

Note:
This option only allows offline migrations. With no direct connection
to the source database you won't be able to configure GoldenGate
replication.

• If you selected No direct connection to source database:, select a

Migration Agent using the drop-down list.
• Vault in Compartment: Select the compartment containing the security vault.
Database Migration uses the OCI Vault to store user secrets such as
passwords, wallets, and keys, and encrypts them with the user-supplied
encryption key.
If the vault is in another compartment, you can use Change Compartment to
select it.
• Encryption key in Compartment: Select the keystore that you configured in
the vault.
Only AES algorithm type keys are supported.
5. In the Select databases step, enter the following information, then click Next.
Enter the following information in the Source database box.
• Database connection in Compartment: Select the source database
connection entry.
If the source database is a PDB, make sure you selected the PDB database
connection in the drop-down, not the CDB connection.
Do not choose an Autonomous Database connection, as Autonomous is not
supported as a source database.
• Database is pluggable database (PDB): If the source database is a PDB,
check this box so you can also enter the CDB details.
Container database connection in Compartment: If the source database is
a PDB, select the CDB you selected here. The CDB connection is not required
if you are doing an offline migration.
Enter the following information in the Target database box.
• Database connection in Compartment: Select the target database
connection.
6. In the Migration options step, select one of the following transfer mediums based
on your requirement for your migration:
• Select an Initial load option:
Data Pump via database link: Enable this option to use a direct SQL*Net
connection between the source and target databases. Note that using Data
Pump with a database link to Autonomous Database targets requires that the
source database be set up with SSL encryption.

5-2
 Chapter 5
Creating Migrations

Note:
If your source database is Oracle Database Standard Edition 2, select the
Datapump via database link: option as the transfer medium. Encryption
for the exported Datapump dumps is not available for the object storage
transfer mediums.

Data Pump via object storage: This option lets Data Pump temporarily store the
exported database in an Object Storage bucket. If this option is enabled, also
configure the following settings.
– Amazon S3 bucket: Enter the details for the Amazon S3 bucket. This option is
only shown if the source database connection is of type Amazon RDS.
The bucket Name must be between 3 and 63 characters, and can consist only of
lower case letters, numbers, dots (.), and hyphens (-). It must begin and end with
a letter or number.
The Region must be in the same region as the RDS Oracle database. For
example us-east-1
For more information about the Amazon RDS source database use case, see
Migrating Databases from Amazon Web Services RDS to Oracle Autonomous
Database.
– Export directory object: Enter the file Name and Path to the directory object
that will be used by Data Pump export on the source database server file system.
Database Migration handles the directory object creation for you.
The name must comply with Oracle Database directory object rules. See
CREATE DIRECTORY in Oracle Database SQL Language Reference.
• Object storage bucket in Compartment: Select the object storage bucket. This
bucket is used for any Cloud Premigration Advisor Tool reports, Database Migration,
and Data Pump log storage, and Data Pump dump files.
If the bucket is in a different compartment, click Change Compartment to look in
another compartment.
7. If the source or the target database is non-ADB, then the following fields are shown when
the initial Data Pump load is performed via object storage:
• Export directory object name:
• Export directory object path:
• Database file system SSL Wallet Path

Note:
This field is displayed only when the SSH details are not provided during
source database connection.

• Import directory object name

• Import directory object path
• Database file system SSL Wallet Path

5-3
 Chapter 5
Creating Migrations

Note:
This field is displayed only when the SSH details are not provided
during target database connection.

If your source or target is non-ADB and you do not provide the SSH details during
the database connection, to achieve HTTPS connectivity, you must perform the
following steps in the source and target database host:
• Create SSL Wallet with Certificates
• Set up Network ACL
You can either download a pre-created wallet or manually create a wallet.
To download a wallet:
a. Download the wallet file.
b. Unzip the certificate files to a directory on the file system of your database
host.
c. Enter this location in SSL Wallet Path when creating the migration.
To create a wallet:
a. Download the necessary certificates.
b. Extract the files: $tar xvf dbc_certs.tar
c. Create the wallet directory by running the following command:

$ mkdir -p <wallet path>

For example:
$ mkdir -p /u01/app/oracle/myserverwallet

d. Create an auto-login wallet by running the following command:

orapki wallet create -wallet . -pwd <your_chosen_wallet_pw> -

auto_login

e. Import SSL certificates to a new auto-login wallet created under this new
directory:

for i in ls <location of cert files>/*cer

do
orapki wallet add -wallet . -trusted_cert -cert $i -pwd <SSL
Wallet password>
done

For more information, see Create SSL Wallet with Certificates.

The user performing the export or import requires the necessary network ACL to
be granted to access the network from the source and target database host.
In the following example, run the following commands as SYS if the export or
import user is SYSTEM. If your database is multitenant, then perform the following
actions in CDB$ROOT. Restrict the host as required.

5-4
 Chapter 5
Creating Migrations

Security consideration: Do not allow a complete network access from the database.
Restrict the host access to the required OCI object storage region. For example,
https://objectstorage.us-ashburn-1.oraclecloud.com and ACL can be time
restricted with relevant start_date and end_date arguments in
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL. For example:

@$ORACLE_HOME/rdbms/admin/sqlsessstart.sql
define clouduser=<user performing export at src or import at target e.g.,
SYSTEM>
define sslwalletdir=< OCI wallet path e.g., /opt/oracle/dcs/commonstore/
import_dmp/nossh_wallet>
begin
dbms_network_acl_admin.append_host_ace(
host =>'*',
lower_port => 443,
upper_port => 443,
ace => xs$ace_type(
privilege_list => xs$name_list('http', 'http_proxy'),
principal_name => upper('&clouduser'),
principal_type => xs_acl.ptype_db));
dbms_network_acl_admin.append_wallet_ace(
wallet_path => 'file:&sslwalletdir',
ace => xs$ace_type(privilege_list =>
xs$name_list('use_client_certificates', 'use_passwords'),
principal_name => upper('&clouduser'),
principal_type => xs_acl.ptype_db));
end;

/
@$ORACLE_HOME/rdbms/admin/sqlsessend.sql

Once the connect privilege is granted, connect as the relevant user such as, SYSTEM and
verify if the privilege is granted using the following query:

COLUMN host FORMAT A30

SELECT host, lower_port, upper_port, privilege, status FROM
user_network_acl_privileges;

For more information, see How To Set Network ACLs.

8. If you want to create an online migration, check the Use online replication option to
enable the replication of all data and metadata transactions from the source to the target
database, committed after the initial load has begun. For additional optional
configurations, see the Replication tab in the Show advanced options. Optionally, you
can set some additional properties which can affect the performance of your online
migration.

Note:
Oracle recommends using the default Use online replication option to perform
an online replication.

5-5
 Chapter 5
Selecting Objects for Migration

Note:
Skip this step for offline (Data Pump only) migrations.

9. Optionally, select Show Advanced Options to configure advanced Data Pump,

validation, and Oracle GoldenGate settings.
For details about these settings see Selecting Objects for Migration, Configuring
Optional Initial Load Advanced Options, Configuring Validation Options, and
Configuring Optional Replication Advanced Options.
10. Click Create.

The migration is loaded, and a new Migration Details page opens showing the
information, metrics, and operations for the migration.
The status of the creation operation is shown under the DM icon. When the status
is Active, you can run migration jobs with the migration.

Selecting Objects for Migration

As part of the migration creation, you can specify objects to include or exclude.
Alternatively, you can also perform the act of inclusion or exclusion of objects after a
migration has been created, using the Selected Objects menu option.
When creating a migration, specify rules for selecting objects in the Advanced
Settings on the Selected Objects tab.
Select the Use advanced editor toggle to add the objects you want to include or
exclude in bulk as follows:

schema_name1,object_name1,TABLE,EXCLUDE
schema_name2,object_name2,TABLE,EXCLUDE
schema_name3,object_name3,TABLE,EXCLUDE

Add all the objects to include or exclude by listing the Object Owner, Object Name,
Object Type , and Action (Include or Exclude), as shown in the above format
(comma separated).
To exclude a table from replication, enter information in the following comma
separated format:

schema_name1,object_name1,TABLE,EXCLUDE,EXCLUDEFROMREPLICATION

5-6
 Chapter 5
Selecting Objects for Migration

Note:
In the advanced editor:
• Use a comma separator character (,) to separate each item for every inclusion/
exclusion definition.
• Use the escape character (\) if your schema or object name has a comma (,)
character as part of its name.
• You can add multibyte character (Unicode) names for schema or object names.
For example, ƹ ƿschema,DŽobject,TABLE,EXCLUDE.
• The maximum input size is 500 KB.

Alternatively, you can choose either Include or Exclude from the Action list to specify if a
rule should include or exclude the specified database objects in the migration. 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 explained in Objects and Schemas Excluded by Default below.
If you specify Include rules, the migration will only move the specified objects and their
dependent objects; all other objects are automatically excluded.
When specifying Exclude rules, the migration will exclude the specified objects and their
dependent objects; all other objects are included in the migration.
To create a rule, enter values for each of the following fields:
• Object Owner specifies the owner of the selected database objects. When using Include
rules, all rules must be for the same owner, and wild characters are not allowed.
• Object Name specifies the name of selected database objects
• Object Type specifies the type of selected database objects. You can select ALL to
select objects of all types.
• Replication only: You can select this toggle when you want to exclude the tables from
replication. This option is enabled when the action is Exclude and the Object Type is
TABLE. This ensures that object types such as ROWID columns, unsupported by Oracle
GoldenGate, are not replicated during online migration.
You can filter Object Owner and Object Name fields using any valid pattern in Java class
Pattern. For example, you can enter .* in the Object Name field to select objects of any
name.
The objects included in a migration are also influenced by the Job Mode of the initial load, as
explained in Configuring Optional Initial Load Advanced Options.
Please note the following restrictions:
• When excluding an object in a specified schema, and an object of the same name exists
in a different schema that is also part of the migration, the objects will not be excluded
(that is, the rule is ignored). The exclusion can be accomplished by migrating the
schemas in separate migrations.
• When creating Include rules in Full job mode, only schema-level rules (Object Name is .*
and Object Type is ALL) are allowed.

5-7
 Chapter 5
Selecting Objects for Migration

• If an Include rule has .* in Object Name, no other rule for the same Object Type is
allowed. If the rule has ALL as Object Type, no other rule for any type is allowed.
• The Object type ALL is only allowed for schema-level rules (Object Name is .*).
• If you define a rule with an Object owner pattern other than .* and the Object
Name is .* then the Object type TABLE is not allowed.
• Object-level rules (Object Name is any pattern other than .*) can only be used for
the following object types: DIRECTORY, FUNCTION, JOB, MATERIALIZED_VIEW,
PACKAGE, PROCEDURE, TRIGGER, SEQUENCE, TABLE. All other object types must be
either included or excluded using the .* pattern in Object Name, and in addition for
exclude, the owner should be .*
Examples
Example 1: Include all objects of schema MySchema
Action = Include

Object Owner Object Name Object Type

MySchema .* ALL

Example 2: Include all tables starting with PROD and procedure MYPROC of schema
MySchema, including all dependent objects.
Action = Include

Object Owner Object Name Object Type

MySchema PROD.* TABLE
MySchema MYPROC PROCEDURE

Example 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.
Action = Exclude

Object Owner Object Name Object Type

Experimental.* .* ALL
MySchema OldTable TABLE
.* .* DB_LINK

Objects and Schemas Excluded by Default

The following object types are always excluded:
• GoldenGate administrators: identified in DBA_GOLDENGATE_PRIVILEGES, including
ggadmin and c##ggadmin users
• If target is Autonomous Data Warehouse Shared Infrastructure: CLUSTER,
DB_LINK, INDEXTYPE, STATISTICS

5-8
 Chapter 5
Configuring Optional Initial Load Advanced Options

• If target is Autonomous Data Warehouse Dedicated Infrastructure, Autonomous

Transaction Processing Shared or Dedicated Infrastructure: CLUSTER, DB_LINK,
STATISTICS
• All other targets: STATISTICS
The following schemas are excluded by default:
• Schema is marked as ORACLE_MAINTAINED in SYS.DBA_USERS on the source or target
database
• Schema is marked as excluded from export in SYS.KU_NOEXP_VIEW on the source
database
• Schema GGADMIN and C##GGADMIN

Configuring Optional Initial Load Advanced Options

Oracle Cloud Infrastructure Database Migration automatically sets optimal defaults for Oracle
Data Pump parameters to achieve better performance and ensure security of data.
To further tune performance, change the export modes, or rename database objects, there
are several Data Pump settings that you can configure in the Migration resource Advanced
Settings, Initial Load tab.
• Source data transfer mechanism: Type of dump transfer to use during Data Pump
Export. The options are CURL or OCI_CLI. The default is CURL.
• Target data transfer mechanism Type of dump transfer to use during Data Pump
Import. The options are CURL or OCI_CLI. The default is OCI_CLI.
• Job mode:
– Full performs a full database export.
– Schema (default) lets you specify a set of schemas to export.
Specify schema objects for inclusion or exclusion in the Advanced Settings, Selected
Objects tab. See Selecting Objects for Migration for details.
See Oracle Data Pump Export Modes in Oracle Database Utilities guide for more
information about the job modes.
• Table exists action sets the Data Pump TABLE_EXISTS_ACTION parameter, which
specifies the action to be performed when data is loaded into a preexisting table.
– Skip (default) no changes to the preexisting table.
– Truncate removes rows from a preexisting table before inserting rows from the
Import. Note that if Truncate is specified on tables referenced by foreign key
constraints, the truncate operation is changed to Replace.
– Replace replaces preexisting tables with new definitions. Before creating the new
table, the old table is dropped.
– Append - new rows are added to the existing rows in the table
• Cluster is enabled by default. When enabled, Data Pump workers are distributed among
the instances (nodes) in a cluster (Oracle RAC) architecture.
If this setting is not checked, all Data Pump workers are started on either the current
instance or on an instance usable by the job.

5-9
 Chapter 5
Configuring Optional Initial Load Advanced Options

• Export parallelism degree sets the Data Pump export SET_PARALLEL degree
parameter. This setting determines the maximum number of worker processes that
can be used for the migration job. You use this parameter to adjust the amount of
resources used for a job.
By default, Database Migration sets source database export parallelism to (Sum of
(2 x (no. of physical CPU) per node ) ) with Max 32 cap.
See SET_PARALLEL Procedure in Oracle Database PL/SQL Packages and Types
Reference for more details.
• Import parallelism degree, similar to Export Parallelism Degree, sets the Data
Pump import SET_PARALLEL degree parameter.
By default, Database Migration sets import parallelism for Autonomous Database
to the number of OCPUs.
• Auto-create tablespaces: For ADB-Dedicated (ADB-D) and co-managed/non-
ADB database targets, automatic tablespace creation is enabled by default.
Database Migration validates whether automatic tablespace creation is supported
on the specified target database. Oracle Autonomous Database Serverless targets
are not supported.
Database Migration automatically discovers the source database tablespaces
associated with user schemas that are being migrated, and automatically creates
them in the target database before the Data Pump import phase. Database
Migration generates the DDL required to pre-create the tablespaces, creates the
tablespaces on the target, and runs the generated DDL.
With automatic tablespace creation enabled, Database Migration skips automatic
creation for any tablespaces that are specified in the Metadata remaps section, or
that already exist in the target database.
Use big file: Autonomous Database systems support only BIGFILE tablespaces,
so Database Migration enforces BIGFILE tablespace by default on Autonomous
Database targets, and reports an error if SMALLFILE tablespaces are found. You
can explicitly remap any SMALLFILE tablespaces instead.
Extend size: enables tablespaces to AUTOEXTEND to avoid extend errors, with a
default extend size of 500MB.
• Remap target: When migrating to an Oracle Autonomous Database Serverless
target, all tablespaces are automatically mapped to DATA. You can override this by
explicitly mapping tablespaces to a different target in Metadata remaps.
• Block size of target database: Optionally, when creating or updating a migration
for ADB-Dedicated (ADB-D) and co-managed/non-ADB database targets, you can
select the database block size for the tablespace as automatic tablespace creation
is enabled by default.
Currently, there are two possible values to select the target database block size:
8K or 16K.

• Metadata remaps lets you rename database objects during a migration job.
Select the object to rename under Type, then enter the Old Value and New Value.
Supported objects are Datafile, Schema, Table, and Tablespace.
When migrating to an Oracle Autonomous Database Serverless target, all
tablespaces are automatically mapped to DATA. You can override this by explicitly
mapping tablespaces to a different target.

5-10
 Chapter 5
Configuring Validation Options

Quota grants for individual users to tablespaces are not remapped, so you must manually
create these grants for tablespace DATA.
To rename multiple objects, click + Another Metadata Remap.

Configuring Validation Options

Oracle Cloud Infrastructure Database Migration is integrated with the Oracle Cloud Pre-
Migration Advisor (CPAT) tool. CPAT analyzes the source database during validation and
advises you about database features and constructs that are problematic.
CPAT provides the following benefits:
• Warns you about any features used by your database that aren't supported in the target
environment
• Makes suggestions for remedial changes and/or parameters to use for the Data Pump
export and import operations

To configure CPAT settings:

When you are creating a migration you can configure CPAT settings in the Migration resource
Advanced Settings, Validation tab.
Run CPAT during validation: Enables CPAT to run during a migration validation job, in the
Validate Pre-migration Advisor phase
Continue CPAT validation on error: By default, a validation job stops running when CPAT
finds an issue. When checked, if CPAT finds an error, the CPAT validation will continue to its
conclusion.
This setting is useful if you want to proceed with a migration if error conditions have already
been reviewed and the problematic objects have been excluded, because since CPAT does
not review the exclusions list, it will still report any blocking issues on objects even if they are
excluded.
These settings can be changed after the migration is created. See Editing a Migration.
See Cloud Premigration Advisor Tool Support in the Zero Downtime Migration documentation
for more information about CPAT.

Configuring Optional Replication Advanced Options

In Oracle Cloud Infrastructure Database Migration, for online migrations using Oracle
GoldenGate, you can configure some Oracle GoldenGate performance settings in the
Migration resource Advanced Settings, Replication tab.

• Acceptable lag (in seconds) specifies the amount of lag. The lag is the time taken to
extract or apply the data from the time it was created on the source database. This
parameter specifies the amount of lag, in seconds, that triggers Oracle GoldenGate end-
to-end latency monitoring. Monitoring continues until the lag time is lower than the
specified value. The maximum value is 30 seconds, and the minimum is 2 seconds. The
default value is 30 seconds.
• Extraction settings
– Performance profile Sets the Oracle GoldenGate PERFORMANCEPROFILE parameter.
Valid for GoldenGate Extract in Integrated Capture mode.

5-11
 Chapter 5
Configuring Optional Replication Advanced Options

* HIGH (default) for high volume use cases

* MEDIUM
* LOW RES to minimize resource usage for memory or resource
constrained deployment
This setting helps achieve better performance by tuning the group of Oracle
GoldenGate parameters that affect performance. Once the performance profile
is set up, this option automatically configures the relevant parameters to
achieve the desired throughput and latency.
– Transaction maximum duration specifies the length of time, in seconds, that
a transaction can be open before Extract generates a warning message that
the transaction is long-running. You can remove the value from this field if you
don't want these error messages generated.
• Replication settings
– Performance profile simplifies the Replicat performance.
* Use HIGH when you have no concurrent workload on target. When HIGH
is set, set Replicat Mappers to 5 and Appliers to 2 * PDB CPU_COUNT .
* Use LOW when you have a concurrent workload on target. When LOW is
set, set Replicat Mappers to 4 and Appliers to PDB CPU_COUNT / 2 on
Target system.
• GoldenGate instance(Optional) Use Marketplace GoldenGate instance: Select
this option if you want to perform replication using your own Marketplace
GoldenGate instance provisioned by you in your tenancy.

Note:
Oracle recommends using the Use online replication default option.
Select the Use Marketplace GoldenGate instance option only when
you want to use your own Marketplace GoldenGate compute instance.

Enter the following details:

– GoldenGate instance OCID: The instance ID of the compute that is hosting
the Marketplace GoldenGate.
– GoldenGate hub URL: Enter a URL containing only the public host name or
IP address of your Marketplace GoldenGate instance.
– GoldenGate administrator username: Enter the user name for connecting to
your Marketplace GoldenGate instance.
– GoldenGate administrator password: Enter the password for connecting to
your Marketplace GoldenGate instance.

Note:
You must use Marketplace as the default name for your GoldenGate
deployment.

5-12
 Chapter 5
Viewing Migration Details

Viewing Migration Details

On the Migrations page of Oracle Cloud Infrastructure Database Migration service console,
you can view a list of your migrations in a table, which includes the following information:
• Name
• State of the migration resource, which can be any one of the following:
– Creating: The new migration resource is being created in OCI.
– Updating: Changes to the migration resource are being registered in OCI.
– Active: The migration resource has finished being created or updated and is ready for
validation. A migration resource in this state can be validated but cannot run a
migration job.
– In Progress: A validation job or migration job is currently running on this migration
resource.
– Accepted: The migration resource has been validated and can run another validation
job or a migration job.
– Succeeded: A migration job using this resource has completed successfully. Once a
migration resource has reached this state, jobs can no longer be run with it.
– Canceled: A migration job using this resource was canceled. You can run a new job
on a migration resource in this state.
– Waiting: A migration job using this resource is waiting for user input. This state
appears when a migration job is paused.
– Needs Attention: A validation job or migration job using this resource has failed and is
blocked. Note that you must cancel a job before you can rerun it.
– Inactive: A fallback state for unexpected errors.
– Deleting: This state appears when you delete a migration resource. The resource
remains in this state until deletion is completed, at which point the resource is no
longer listed in the console.
– Failed: There are problems with the migration resource. This can happen during
creation, update, and any issues other than job failures. You can review the migration
resource work request to investigate the issue.
• Last Migration shows the time stamp of the last job run with the migration
• Created time stamp when the migration was created
Select a migration from the Migrations page to view its details.
On the Migration Details page you can view the migration information, including:
• OCID: The resource's unique Oracle Cloud ID
• Compartment: The compartment where the migration resource resides
• Created: The date and time when the migration was created
• Encryption Vault: The link takes you to the Vault Details page
• Encryption Key: The link takes you to the Key Details page
• Source Database: The link takes you to the Database Details page. You can select Test
connection to test the connectivity of the database connection.

5-13
 Chapter 5
Editing a Migration

• Target Database: The link takes you to the Database Details page. You can select
Test connection to test the connectivity of the database connection.
• Migration Type: Online or Offline
• Replication: Enabled or Disabled
• Validation: CPAT Enabled or CPAT Disabled
Below the migration details, you can view information about resources associated with
the migration, such as Jobs (see Managing Migration Jobs), Excluded Objects (see
below), Work Requests (see below), and Metrics (see Database Migration Metrics).

Excluded Objects
The Excluded objects list displays objects that are excluded from migration.
Oracle Maintained: objects owned by Oracle-maintained users
(ORACLE_MAINTAINED = Y) are excluded from migration
Unsupported: objects not supported for migration by Oracle GoldenGate, such as
those owned by the ggadmin and c##ggadmin users, are excluded from migration
User Excluded: objects explicitly excluded by rules configured in your migration
Selected Objects.
See Selecting Objects for Migration for details about objects excluded by default and
explicitly selecting objects for migration.

Work Requests
On the Migration Details page, under the migration information box you can find the
Work Requests list. Work Requests lists any work requests sent to OCI to facilitate the
creation, update, validation, cloning, or deletion of this resource. Click the work
request to go to the Work Request Details page for more information about the work
request.

Editing a Migration
You can modify some of the settings in a migration resource configuration in Oracle
Cloud Infrastructure Database Migration.
In the list of migrations on the Migrations page, select the Name of the migration you
want to edit.
Select Edit next to any of the following modifiable settings:

Source Database
In the Edit Source Database dialog, you can choose a different source database.
Valid selection of source databases is the same as for when you create a new
migration resource; Non-autonomous non-CDBs or PDB/CDB combinations are
supported for the source.

Target Database
In the Edit Target Database dialog, you can choose a different target database.

5-14
 Chapter 5
Editing a Migration

Valid selection of target databases is the same as for when you create a new migration
resource; Autonomous Databases are supported for the target.

Migration Type
The Migration Type (Offline or Online) cannot be changed, but you can change the settings
that are valid for the migration type originally configured.
In the Edit Initial Load Settings dialog, you can choose to change the following settings.
• Initial Load: You can change the data transfer method to use Object Storage bucket or
database link.
• Object Storage Bucket: When your initial load data transfer method is Object Storage,
you can change the bucket in which to store the Data Pump dumps.
• Export Directory Object: When your initial load data transfer method is Object Storage,
you can change the export directory object by specifying a new name and path.
• Advanced Options: You can change the initial load advanced options. See Configuring
Optional Initial Load Advanced Options for information about these settings.

Replication
In the Edit replication settings dialog, you can enable or disable online replication, and you
can change the following GoldenGate settings.
• Use online replication: Select this option if you want to enable the replication of all data
and metadata transactions from the source to the target database committed after the
initial load.
• Acceptable lag (in seconds)
• Extraction settings
• Replication settings
• GoldenGate instance:
– (Optional). Use Marketplace GoldenGate instance: If you select this option, then
enter the following details:
– GoldenGate instance OCID: The instance ID of the compute that is hosting the
Marketplace GoldenGate.
– GoldenGate hub URL
– GoldenGate administrator username
– GoldenGate administrator password
• See Configuring Optional Replication Advanced Options for information about these
settings.

Encryption Key
In the Edit Encryption Key dialog, you can choose a different Vault, Encryption Key, and the
compartment in which to create a Secret.

Validation
In the Edit Validation Settings dialog, you can enable or disable the use of Cloud Pre-
Migration Advisor Tool (CPAT) during migration validation, and you can change whether
CPAT validation continues on error.

5-15
 Chapter 5
Cloning a Migration

Selected Objects
You can add or remove Include or Exclude database object rules in the Resources
section, under Selected Objects, which is located below the Migration Information
box.
To remove a rule, select the rule's checkbox and click Remove, or select the Remove
action from the actions list.
To add or edit rules, click Add Objects. See Selecting Objects for Migration for
information about configuring selected objects.

Cloning a Migration
To clone a migration:
1. In the list of migrations on the Migrations page, select Clone from the Actions
(three dots) menu of the migration you want to clone.
You can also click Clone on the Migration Details page.
2. In the Clone Migration dialog, enter a unique Name, then click Next to update any
of the source or target database details for the clone, and click Clone on the final
page of the dialog.

Moving a Migration
You can move a migration resource from one compartment to another.
To move a migration:
1. In the list of migrations on the Migrations page, select Move Resource from the
Actions (three dots) menu for the migration you want to move.
You can also select Move Resource on the Migration Details page.
2. In the Move Resource to a Different Compartment dialog, select the
compartment to move the migration to from the dropdown.
3. Click Move Resource.
After you move the migration to the new compartment, inherent policies apply
immediately and may affect access to the migration through the Console. For more
information, see Managing Compartments.

Deleting a Migration
Before you delete a migration, ensure that you carefully review any resources that
reference the migration. If not, you could encounter errors.
To delete a migration:
1. In the list of migrations on the Migrations page, select Delete from the Actions
(three dots) menu of the database you want to delete.
You can also click Delete from the More Actions menu on the Migration Details
page.
2. In the Delete dialog, click Delete.

5-16
 Chapter 5
Managing Tags for Migrations

Managing Tags for Migrations

Tags help you locate resources within your tenancy. In Oracle Cloud Infrastructure Database
Migration, you can add and view a migration's tags from the Migrations page and from the
Migration Details page.
On the Migrations page, from the migration's Actions (three dots) menu, select Add Tags or
View Tags.
On the Migration Details page, you can select Add Tags in the More Actions menu above
the Migration Information box, or click the Tags tab to view and edit tags.
Learn more about tagging in Managing Tags and Tag Namespaces.

Using the Migration API

You can use the following operations to manage migration resources:
• CreateMigration
• GetMigration
• ListMigrations
• UpdateMigration
• DeleteMigration
• CloneMigration
• ChangeMigrationCompartment
• RetrieveSupportedPhases
For information about using the API and signing requests, see REST APIs and Security
Credentials. For more information about SDKs, see Software Development Kits and
Command Line Interface.

5-17
6
Managing Migration Jobs
In Oracle Cloud Infrastructure Database Migration, a migration job is the process of moving
data from a source database to a target database. Run a validation pre-check on the
migration before you run a job to ensure that it is configured properly. You can manage the
jobs with several operations.

Validating a Migration
Before you can run a job with a migration resource in Oracle Cloud Infrastructure Database
Migration, the migration resource must be validated.
1. In the list of migrations on the Migrations page, select Validate from the Actions (three
dots) menu for the migration you want to validate.
You can also select Validate on the Migration Details page.
2. In the Validate Migration dialog, click Validate.
3. Click Jobs on the left side of the page to monitor the status of a validation job.
In the Jobs table the validation job is listed with type Evaluation.
If you enabled the Cloud Pre-migration Advisor Tool (CPAT) to run during the validation job,
the CPAT report and details about any failed checks are found in the Job Details page. See
Configuring Validation Options and Checking the Interactive Validation Premigration Advisor
Report for more information.

Checking the Interactive Validation Premigration Advisor Report

Database Migration provides you with an interactive validation report with its integration with
the Cloud Premigration Advisor Tool (CPAT). Using CPAT, Database Migration analyzes the
source database during a migration job, and advises you about database features and
constructs that are problematic, based on the specified Oracle Cloud target. CPAT runs by
default and provides you with the following features and benefits:
• Warns you about any features used by your database that aren't supported in the target
environment
• Makes suggestions for remedial changes and/or parameters to use for the Data Pump
export and import operations
• Generates remedial scripts for failing checks that you can run against the source
database
After a validation job runs, the job output displays the checks performed, descriptions of any
problems, and actions you can take to resolve the issues.
To view or download the CPAT results
1. On a migration resource detail page, click Jobs, then the job name, then Phases.
2. Click the Validate pre-migration advisor phase name to open the Validation pre-
migration advisor detail page.

6-1
 Chapter 6
Checking the Interactive Validation Premigration Advisor Report

From this page you can download the CPAT report, view the report statistics, and
drill down in the Checks list.
Checks List Operations
Filters: You can filter the checks listed using the Filters checkboxes on the left side.
Drill down on individual checks: Click a check name in the list to display details
about that check from the CPAT report.
Check Details
The View check details panel shows you
• Information about the check, including the issue that caused the result shown, its
potential impact on the migration, any action you can take to mitigate the issue,
and if applicable, the location of a fixup script you can run on the source database.
• A Reviewed indicator, which lets you mark a check as "reviewed" so that you can
see in the Validate premigration advisor list of checks whether you have
completed whatever tasks you wanted to do with the check.
Click the link in the check details to change it to a No or Yes value. The indicator
does not have any impact on how the checks are processed; it is available for your
convenience.
• A list of Objects that were flagged by the check as problematic.
Some checks will show a read-only list of objects and some checks let you
interactively update the objects listed.
Running Fixup Scripts
The location of the fixup script is shown on the View check details panel for an
individual check.
The Fixup script location specifies where the script is located on the source
database.
Running the fixup script against the source database requires sys admin privileges.
In multitenant architecture, fixup scripts should be run on the CDB. Running them on
the PDB will produce an error.
Excluding Problematic Objects
After a validation run, every object listed in the View check details pane shows a No
in the Is excluded column.
To exclude objects from the next validation run, you can check the boxes next to
objects in the list and click Exclude selected, or you can choose Exclude all to
exclude all objects that were listed in the check.
Any objects you choose to exclude will show a Yes in the Is excluded column. Objects
marked Yes are ignored by CPAT in the next validation run, and they will not appear in
the Objects list the next time you run the validation.
The migration's Selected Objects configuration is also updated to reflect this change.
You will see a new row with the exclusion rule in the Selected Objects on the Migration
details page. If you want to include this object again you must remove the rule in the
Selected Objects list.

6-2
 Chapter 6
Running a Migration Job

Note that Exclude all will exclude all of the objects on the page displayed, plus any objects
from pages not displayed. However, if you check the first box in the checkbox column and
click Exclude all, only the objects listed on the current page are excluded.

Note:
Excluding tables does not exclude them from CPAT analysis. Schemas can be
excluded from CPAT if the entire schema was excluded. The presence of an Oracle
Cloud unsupported table can lead to Blocker status in the CPAT report.

See Selecting Objects for Migration for information about explicitly including and excluding
objects.

Running a Migration Job

After a migration resource is validated you can run migration jobs with it in Oracle Cloud
Infrastructure Database Migration.
1. In the list of migrations on the Migrations page, select Start from the Actions (three dots)
menu for the migration you want to run.
You can also select Start on the Migration Details page.
2. (Optional) In the confirmation dialog, select a phase after which to require user input to
continue the migration job.
3. Click Start.

Pausing and Resuming a Job

When you start a migration job, you can configure it to pause at a specified phase, and then
you can resume the job when you are ready.
When you start a migration job, a confirmation dialog opens, and there you can configure the
job to pause at any point by selecting a phase in Require User Input After.
When the phase you selected to pause after completes, the job will enter a Waiting state
until you resume (or terminate) the job.
If you pause after the phase Monitor Replication Lag, the transaction replication continues
during the Waiting state. It will stop upon resume.
To start the job where it left off, do one of the following:
• In the Jobs table on the Migration Details page, select Resume from the Actions (three
dots) menu for the job you want to resume.
• Click Resume on the Job Details page.
At this time you can select another phase after which to pause the job again.

6-3
 Chapter 6
Viewing Job Details

Viewing Job Details

On the Migration Details page you can view a list of the jobs a migration resource has
performed in Oracle Cloud Infrastructure Database Migration, which includes the
following information:
• Name: Name of the job
• State: State of the job resource, which can be any one of the following:
– Accepted: The job is pending execution.
– In Progress: The validation job or migration job is currently running.
– Unknown: The status cannot be retrieved and Database Migration is waiting
for recovery to continue. No action is required.
– Terminated: Unfeasible to reach, similar to Canceled.
– Failed: For a validation job, the precheck failed, no user action required. For a
migration job, the job failed and it is waiting for user action (abort or resume
the job).
– Succeeded: The job has completed successfully.
– Waiting: A migration job is paused and waiting for user input.
– Canceling: A migration job is in the process of being stopped following an
Abort action.
– Canceled: A migration job has stopped following an Abort action. You can run
a new job on a migration resource once a job reaches this state.
• Type: Migration or Evaluation
• Status Details: Displays a supporting message with additional details regarding
the State.
For example, if a validation job fails, with State=Failed, Status Details informs you
that the job failed and Database Migration auto-terminated the job.
If the Unknown state is displayed, a Status Details informs you that Database
Migration is unable to retrieve the latest status of the job and is waiting for
downtime recovery.
• Created: Time stamp when the job was created
Select a job from the Jobs table to view its details.
On the Job Details page you can view the job information, including:
• OCID: The resource's unique Oracle Cloud ID
• Created: The date and time when the migration was created
Below the Job Information box, you can view information about resources associated
with the job, such as Metrics (see Database Migration Metrics), Phases ( see
Database Migration Job Phases), and Unsupported Objects.

6-4
 Chapter 6
Monitoring Job Status

Monitoring Job Status

In Oracle Cloud Infrastructure Database Migration, there are several places in the Console
from which you can monitor the status of a migration job to varying degrees.
Job Details page
On the Migration Details page, you can click Jobs, and see information about the jobs run
with this resource.
You can click Download Log to view the log generated by Database Migration Service.
Below the job information details you can click the Metrics, Phases, and Unsupported
Objects to get more information about the migration job.
Job Details - Phases
On a migration resource detail page, you can click Jobs, then the job name, then Phases,
and see the phases of the job that have completed, are pending, and are currently running
(labeled Started).
For any phase that has some error or warning text (or log) to display, the phase name is
displayed as a clickable hyperlink, and the phase's action items menu includes View Details.
Clicking on the phase name link or View details action opens a View phase details panel
which displays the details of the error or warning
If there is a log available for download, an option appears in the action menu to allow
download. You can also download logs using a button in the View phase details panel. The
View phase details panel displays the following information:
• Name: Name of the phase
• Status: Status of the phase. A failed status informs you that the job failed.
• Duration: Time elapsed from the beginning of the phase till the point where the error
occurred.
• Issue: The issue causing the job failure.
• Action: The action you can perform to resolve the error.
• Error messages: The validation or migration errors causing the job failure.
Download Log downloads the Data Pump log. Applies to jobs run in migration mode in the
Export Initial Load and Import Initial Load phases.
The Validate pre-migration advisor phase is a special case, because this link opens the
Validation pre-migration advisor detail page, from which you can download the Cloud Pre-
migration Advisor Tool (CPAT) report, view the CPAT report statistics, and drill down in the
Checks list.
For more information about the CPAT report and interactive details page, see Checking the
Interactive Validation Premigration Advisor Report.
For details about the migration work flow phases, see Database Migration Job Phases.
For information about metrics, see Database Migration Metrics.

6-5
 Chapter 6
Preparing for Application Switchover

Preparing for Application Switchover

The following procedure ensures zero data loss during a read-write application
switchover:
Both the source and target databases are opened read-write during the logical
migration work flow. The following conditions apply:
• For read-only applications, switchover can happen immediately after GoldenGate
Replicat has applied all outstanding source transactions, allowing for zero
application downtime for those services.
• Read-write applications require assurance that all transactions have been applied
on the target before switching the application over to ensure zero data loss.
If your application is read-write, you must do the following to ensure zero data loss:
1. Pause the migration job after phase ODMS_MONITOR_REPLICATION_LAG.
This phase monitors Oracle GoldenGate Extract and Replicat operations until
Replicat has caught up on the target database; end-to-end (E2E) replication lag
should be less than 30 seconds.
2. After phase ODMS_MONITOR_REPLICATION_LAG completes and the migration job
pauses, stop the workload on the source database (start of downtime).
3. Resume the migration job, scheduling another pause after phase
ODMS_SWITCHOVER.
This phase does the following:
a. Ensures replication E2E lag is still less than 30 seconds
b. Ensures that Extract has captured outstanding transactions on the source
database
c. Stops Extract
d. Ensures Replicat has applied all remaining trail file data
e. Stops Replicat
4. After phase ODMS_SWITCHOVER has completed, you can start the workload on the
target database (end of downtime).

Terminating a Job
You can terminate a migration job while it is running or paused.
1. In the list of jobs on the Migration Details page, select Abort from the Actions
(three dots) menu of the job you want to delete.
You can also click Abort on the Job Details page.
2. In the Abort Job dialog, click Abort.

Deleting a Job
1. In the list of Jobs on the Migration Details page, select Delete from the Actions
(three dots) menu of the job you want to delete.

6-6
 Chapter 6
Managing Tags for Jobs

You can also click Delete on the Job Details page.

2. In the Delete dialog, click Delete.

Managing Tags for Jobs

Tags help you locate resources within your tenancy. In Oracle Cloud Infrastructure Database
Migration, you can add and view a migration job's tags from the Migration Details page and
from the Job Details page.
On the Migration Details page, select Jobs under Resources on the left side of the page.
In the Jobs table, from the job's Actions (three dots) menu, select Add Tags or View Tags.
On the Job Details page, you can select Add Tags above the Job Information box, or click
the Tags tab to view and edit tags.
Learn more about tagging at Managing Tags and Tag Namespaces.

Using the Job API

You can use the following operations to manage migration jobs:
• EvaluateMigration
• StartMigration
• GetJob
• UpdateJob
• DeleteJob
• ResumeJob
• AbortJob
• GetJobOutputConten
• ListJobs
• ListJobOutputs
For information about using the API and signing requests, see REST APIs and Security
Credentials. For more information about SDKs, see Software Development Kits and
Command Line Interface.

6-7
7
Managing Agents
Oracle Cloud Infrastructure Database Migration uses agents to connect with source
databases that are that are not directly accessible from the cloud.
When you configure a migration resource with no direct connection to the source database,
you must first download and install an agent to use as a bridge to the source database.

Note:
This option only allows offline migrations.

About the Database Migration Agent

In Oracle Cloud Infrastructure Database Migration, when you want to migrate a source
database that doesn't have a direct connection with the target database on OCI, you must
deploy a agent to act as the bridge between the source database and the cloud target.
Note that migrations from indirect sources can only be done in offline mode.

Database Migration Agent Requirements

The Database Migration agent can be configured on Oracle Linux 7 (Linux-x86-64) or later
releases.
You can deploy the agent on a standalone server on-premises or on a standalone Linux
server (compute instance) in the Oracle Cloud. Oracle Linux is the supported platform for the
agent. Note that the agent host can be shared with other applications for other purposes.
The Database Migration agent host needs to access the source and target database servers
during a database migration. To perform the migration, the agent requires either root user or
SSH key-based access to one of the source database servers, and the agent host requires
SSH key-based access to one of the target database servers.
If you are migrating an Oracle RAC database, providing access to one of the Oracle RAC
nodes is adequate. The agent host copies the software needed for migration to the source
and target servers and cleans it up at the end of the operation.
An SSH private key is required to establish SSH connections. You can create and add a new
SSH key to your existing deployment using the Oracle Cloud Service Console.

Prepare a Host for Database Migration Agent Installation

If a host has not had Database Migration agent software installed on it previously, verify that it
complies with the requirements listed here.
Provision a host with the following prerequisites and complete the following tasks before
installing the agent on it.

7-1
 Chapter 7
Create a Stream

• The agent requires a standalone Linux host running Oracle Linux 7 or later
release.
• The agent host should be a dedicated system, but it can be shared for other
purposes; however, the agent host should not have Oracle Grid Infrastructure
running on it.
• The agent host must be able to connect to both the source and the target
database servers.
• Ensure that the Linux host has 100 GB of free storage space.
• You may use an existing user, or, as root user on the agent host create a dms
group and add dmsuser user to the group.
For example,

root> groupadd dms

root> useradd –g dms dmsuser

• Verify that the glibc-devel and expect packages are installed.

For Oracle Linux 7 installations with Base Environment "Minimal Install" you also
need to install the packages unzip libaio oraclelinux-developer-release-
el7.
• Verify that the /etc/hosts entry for the host name and IP address are configured
as expected, so that the agent host resolves to the correct IP address and the IP
address is reachable with ping.
• During the installation, the script might report any missing packages and
instructions for setting appropriate values for kernel parameters. Be sure to install
the missing packages and set the kernel parameters before installing the agent.
• Optionally, set a DMS_HOME environment variable to the absolute path of the
directory where the Database Migration agent will be installed. All of the examples
in this document use $DMS_HOME.

dmsuser> export DMS_HOME=absolute_path_to_dms_home

Create a Stream
The Oracle Cloud Infrastructure Database Migration agent requires a stream, created
in Oracle Streaming, to communicate asynchronously with the service.
1. In the Oracle Cloud Interface Console menu, go to Analytics > Streaming.
2. Select Create Stream.
3. Enter the following values, otherwise leave defaults:
• Stream Name: Enter a name, for example, DMSStream
– Press Create
4. Wait until the stream becomes active, then open the stream from list
5. Copy the OCID of the stream. You will need it later to configure the Database
Migration agent installer.
See Creating and Managing Streams for additional information about streams.

7-2
 Chapter 7
Create an API Key

Create an API Key

1. Create an API key in the Oracle Cloud Interface Console, or use an existing one. See
Required Keys and OCIDs for more information about creating an API key.
Note that there is a limit of 2 API keys per user.
2. Note the fingerprint value (for example,
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00) and the private key file location (for
example, ~/agent/agent_api_key.pem) of the API key. You will need this information to
run the agent installer.
3. Transfer the private key file to your agent host using SFTP or other means.

Installing a Database Migration Agent

The configuration information listed in the table below is required to install the Database
Migration agent and register it with Oracle Cloud Infrastructure. Some of this information is
gathered from the previous tasks, and some you will collect as you do the steps below.

Table 7-1 Required Database Migration Installation Information

Name Example Where to Find

home ~/agent/home Empty directory for the agent
home. You will create this
directory in the steps below.
base ~/agent/home Empty directory for the agent
base. You will create this
directory in the steps below.
ziploc ~/agent/install/dms_home.zip Location of the Home archive
that is unpacked from the
Installer archive in the steps
below.
region us-ashburn-1 OCI region of the Database
Migration service to be used.
tenancyId ocid1.tenancy.oc1..[…] OCID of the Tenancy where
Migrations will be located. This
information can be found in the
OCI Console Profile menu.
userId ocid1.user.oc1..[…] OCID of the User using this
Agent. This information can be
found in the OCI Console Profile
menu.
compartmentId ocid1.compartment.oc1.[…] OCID of the Compartment where
Migrations will be located. Can
be found in the OCI Console
Identity > Compartments
menu.
streamId ocid1.stream.oc1.[…] OCID of the OCI Streaming
Service Stream, which you
configured in the previous task
for creating the stream object.

7-3
 Chapter 7
Installing a Database Migration Agent

Table 7-1 (Cont.) Required Database Migration Installation Information

Name Example Where to Find

userFingerprint 00:00:00:00:00:00:00:00:00:00:0 Fingerprint of the API Key to be
0:00:00:00:00:00 used with the Agent, which you
configured in the previous task
for creating the API Key.
userPrivateKey ~/agent/agent_api_key.pem Private Key for the API Key to be
used with the Agent, which you
configured in the previous task
for creating the API Key.

The examples used in these steps assume that you will install the agent in an on-
premises host, but you can use any host that conforms to the agent host requirements,
including an Oracle Cloud Infrastructure instance.
All commands are run as dmsuser.

1. In the OCI Console Menu, go to Database Migration > Agents.

2. Click Download Agent Installer, located above the agent list.
3. When the save file dialog opens, save the file dmsagentkit_21_date.zip to your
agent host using SFTP or other means.
For example, save the agent installer file in /tmp/dmsagentkip_21_210303.zip on
the agent host.
4. Open an SSH terminal on the agent host as a non-root user, dmsuser for example,
and create an agent directory and three subdirectories as shown in this example.
You can choose your own names for the directories.
• mkdir ~/agent
• mkdir ~/agent/home
• mkdir ~/agent/base
• mkdir ~/agent/install
5. Change to the directory to where the agent installer is downloaded and unzip the
installer to the installation subdirectory you created, for example /agent/install.

dmsuser> cd agent_download_directory
dmsuser> unzip -q -d ~/agent/install dmsagentkip_21_210303.zip

6. Run the following commands using the information listed in the table at the
beginning of this task.

dmsuser> cd ~/agent/install

dmsuser> ./dmsagent_install.sh \
agentName=agentname \
home=agent_home_subdirectory_you_created_above \
base=agent_base_subdirectory_you_created_above \
ziploc=ziploc \
region=region \
compartmentId=compartmentId \

7-4
 Chapter 7
Installing a Database Migration Agent

streamId=streamId \
tenancyId=tenancyId \
userId=userId \
userFingerprint=userFingerprint \
userPrivateKey=userPrivateKey

7. Observe the output of the script. Output for a successful installation looks like the
following example.

[opc@dmsagent agent]$ ./install.sh

++ cd /home/opc/agent/install
++ ./dmsagent_install.sh agentName=testagent home=/home/opc/agent/home
base=/home/opc/agent/base ziploc=/home/opc/agent/install/zdm_home.zip
region=us-ashburn-1 compartmentId=ocid1.compartment.oc1..[snip]
streamId=ocid1.stream.oc1.iad.[snip]
tenancyId=ocid1.tenancy.oc1..[snip]
userId=ocid1.user.oc1..[snip]
userFingerprint=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
userPrivateKey=/home/opc/agent/ggsstage_api_key.pem
Mar 17, 2021 1:01:36 AM com.oracle.bmc.Services create
INFO: Registering new service:
Services.BasicService(serviceName=MIGRATIONDEPLOYMENT,
serviceEndpointPrefix=migrations,
serviceEndpointTemplate=https://odms.{region}.oci.{secondLevelDomain})
Mar 17, 2021 1:01:36 AM com.oracle.bmc.Region getEndpoint
INFO: Loaded service 'MIGRATIONDEPLOYMENT' endpoint mappings:
{US_ASHBURN_1=https://odms.us-ashburn-1.oci.oraclecloud.com}
Mar 17, 2021 1:01:36 AM com.oracle.bmc.util.JavaRuntimeUtils <clinit>
INFO: Determined JRE version as Java_8
Mar 17, 2021 1:01:36 AM com.oracle.bmc.http.DefaultConfigurator
setConnectorProvider
INFO: Setting connector provider to HttpUrlConnectorProvider
Mar 17, 2021 1:01:36 AM com.oracle.zdmcs.MigrationDeploymentClient
setEndpoint
INFO: Setting endpoint to https://odms.us-ashburn-1.oci.oraclecloud.com
Mar 17, 2021 1:01:36 AM com.oracle.zdmcs.MigrationDeploymentClient <init>
INFO: Authentication details provider configured for region
'US_ASHBURN_1',
but endpoint specifically set to 'https://odms.us-
ashburn-1.oci.oraclecloud.com'.
Using endpoint setting instead of region.
Mar 17, 2021 1:01:36 AM com.oracle.zdmcs.MigrationDeploymentClient
setEndpoint
INFO: Setting endpoint to https://odms.us-ashburn-1.oci.oraclecloud.com
Mar 17, 2021 1:01:38 AM com.oracle.bmc.ClientRuntime <init>
INFO: Using SDK: Oracle-JavaSDK/1.19.3-preview1-SNAPSHOT
Mar 17, 2021 1:01:38 AM com.oracle.bmc.ClientRuntime <init>
INFO: User agent set to: Oracle-JavaSDK/1.19.3-preview1-SNAPSHOT
(Linux/5.4.17-2036.102.0.2.el7uek.x86_64; Java/1.8.0_281;
Java HotSpot(TM) 64-Bit Server VM/25.281-b04)

DMS Agent OCID: ocid1.odmsagent.oc1.iad.[snip]

7-5
 Chapter 7
Managing Database Migration Agents

After the install script has successfully completed, the agent is registered with OCI
and is running. No further commands are necessary on the agent instance.
If the installation outcome is different from the above example, review the log file
at ~/install/zdminstall.trc for error messages.

Managing Database Migration Agents

The Oracle Cloud Infrastructure Database Migration agent accepts commands to start,
stop, list, and delete agents.
Whether you use the console, the dmsagent commands, or the API depends on what
operations you need to perform on the agent. There are different ways to manage
Database Migration agents depending on where they are installed.
Using the Console
You can manage agents in the Agents page of the Database Migration console. The
console lets you see all of the registered agents at a glance, and also lets you delete
agents, move the agent resources, copy OCIDs, and manage tags.
Using the Agent Commands
To run commands on the agent connect to the agent host as the Database Migration
agent installer user. The example user dmsuser is used to run agent commands
throughout this document.
For example, the following command gets the status of the agent.

dmsuser> ~/agent/home/bin/dmsagent status

Using the API

If you installed the agent on an Oracle Cloud Infrastructure instance, you can use the
Agent REST API to manage the agent. This can be done using the OCI CLI. See
Using the Agent API.

Starting and Stopping the Database Migration Agent

The Database Migration agent must be running before you can migrate your
databases with the OCI Database Migration service. The installation process starts the
agent, but if you need to stop and restart the agent use these dmsagent commands.

To start the agent, connect to the agent host and run:

dmsuser> ~/agent/home/bin/dmsagent start

To stop the agent, connect to the agent host and run:

dmsuser> ~/agent/home/bin/dmsagent stop

7-6
 Chapter 7
Getting Database Migration Agent Status

Getting Database Migration Agent Status

You can get agent status using the Oracle Cloud Infrastructure console, or use the dmsagent
status command.

Using the Console

The Database Migration > Agents page lists all of the agents, their states, versions, and the
dates they were created.
Using the Agent Commands
To check the agent status, connect to the agent host and run:

dmsuser> ~/agent/home/bin/dmsagent status

Listing Database Migration Agents

You can install multiple agents in a compartment. To list the agents in a given compartment
that are registered with OCI, you can use the Oracle Cloud Infrastructure console, or use the
API.
Using the Console
Go to the Database Migration > Agents page and select a compartment where agents are
registered. The agents in the given compartment are listed in the table.
You can filter the list by State or tags using the console controls.
Using the API
To list agents the in a given compartment, use the ListAgents API.

Moving a Database Migration Agent

You can move a Database Migration agent resource from one compartment to another.
To move an agent:
1. In the list of agents on the Agents page, select Move Resource from the Actions (three
dots) menu for the migration you want to move.
2. In the Move Resource to a Different Compartment dialog, select the compartment to
move the agent to from the dropdown.
3. Click Move Resource.
After you move the agent to the new compartment, inherent policies apply immediately and
may affect access to the agent through the Console. For more information, see Managing
Compartments.

Deleting a Database Migration Agent

You can delete an agent using the Oracle Cloud Infrastructure console or the API.
Using the Console

7-7
 Chapter 7
Managing Tags for Database Migration Agents

1. In the list of agents on the Agents page, select Delete from the Actions (three
dots) menu for the agent you want to move.
2. In the Delete dialog, click Delete.
Go to the Database Migration > Agents page and select a compartment where
agents are registered. The agents in the given compartment are listed in the table.
Using the API
To delete agents the in a given compartment, use the DeleteAgent API.

Managing Tags for Database Migration Agents

Tags help you locate resources within your tenancy. You can add and view an agent's
tags from the Agents page in Oracle Cloud Infrastructure Database Migration.
On the Agents page, from the agent's Actions (three dots) menu, select Add Tags or
View Tags.
Learn more about tagging at Managing Tags and Tag Namespaces.

Using the Agent API

You can use the following operations to manage Database Migration agents:
• GetAgent
• UpdateAgent
• DeleteAgent
• ChangeAgentCompartment
• ListAgents
• ListAgentImages
For information about using the API and signing requests, see REST APIs and
Security Credentials. For more information about SDKs, see Software Development
Kits and Command Line Interface.

7-8
8
Troubleshooting Database Migration
Depending on the type of issue you may encounter while using Oracle Cloud Infrastructure
Database Migration, you can use the Metrics graphs in the OCI Console, the log and trail files
found in the manual backup, or logs from the Migrations page to help determine the root
cause and update your migration configuration.

Metrics
Metrics are collected every five minutes for each deployment. The data produced can help
you troubleshoot issues that you may encounter.
For more information, see Database Migration Metrics.

Alarms
For each metric on the Details page, you can create an alert to inform you when a condition
is met. For example, you can create an alarm to notify you when OCPU consumption is less
than 50%.
To create an alarm:
1. From the Options dropdown of a metric chart, select Create an Alarm on this Query.
2. On the Create Alarm page, under Define Alarm, add the trigger.
3. For Alarm Settings, complete the following fields as needed:
• Alarm Name: Enter the name that serves as the title for notifications related to this
alarm. Avoid entering confidential information.
• Alarm Severity: Select the perceived type of response required when the alarm is in
the firing state.
• Alarm Body: Enter the content of the notification to deliver.
• Tags (optional): Select or enter free-form tags to apply to this resource.
• Metric description: The metric to evaluate for the alarm condition.
– Compartment: Select the compartment that contains the resources that emit the
metrics evaluated by the alarm. The selected compartment is also where the
alarm is stored.
– Metric Namespace: Enter the service or application emitting metrics for the
resources that you want to monitor.
– Resource Group (optional): Select the group that the metric belongs to.
– Metric Name: Enter the name of the metric. Only one metric can be specified.
– Interval: Select the aggregation window, or the frequency at which data points
are aggregated.
– Statistic: Select the aggregate function.

8-1
 Chapter 8
Logs

4. Confirm the values for Metric dimensions. Optionally, click + Additional

dimension to add another dimension to the alarm.
5. For Trigger rule, complete the Operator, Value, and Trigger delay minutes
fields. The graph displays the boundaries for which the alarm triggers a
notification.
6. For Notifications, complete the fields as needed:
• For Destination service, select Notifications Service.
• For Compartment, select the compartment to store the topic used for this
notification.
• For Topic, click Create topic to set up a topic and subscription protocol in the
designated compartment using the designated Destination service.
• (Optional) Click + Additional destination service to add another destination
service.
• (Optional) Enable Repeat Notification and select Notification Interval if you
want the alarm to resend notifications at the specified intervals when the alarm
is in the firing state.
• (Optional) Enable Suppress Notifications to specify a window of time to
suspend evaluations and notifications. This is useful for maintenance periods.
7. Click Save alarm.
For more information, see Viewing Default Metric Charts.

Logs
The Database Migration Jobs Details page provides detailed error information and
access to logs for troubleshooting performance.

Database Migration Service Job Log

Database Migration Service generates a log during every migration job.
On the Migration Details page, click Jobs, and then click Download Log to download
the log.

Data Pump Logs

On the Migration Details page, click Jobs, and then click Phases under the Resources
section.
Should a problem arise during the Data Pump Export or Data Pump Import phases of
a migration job, the phase name is displayed as a clickable hyperlink.
There are two ways to access the log:
• Click the action menu (three dots) and click Download Datapump Log
• Click the phase name, which opens the View Details panel, on which you can find
the Download Datapump Log button.

8-2
 Chapter 8
Error Messages

Error Messages
Error message are reported in the Jobs output log in Oracle Cloud Infrastructure Database
Migration.
If you see errors reported in Job output log, such as ORA and PR*, to understand the cause
and action for these errors you can look up the error by code in Oracle Database Error
Messages reference at Database Error Messages.

Work Request Details

The Database Migration Jobs Details and Migration Details pages provide a resource work
request list.
The Work Requests list allows you to monitor long-running operations such as resource
creation, update, validation, cloning, or deletion. Click the work request in the list to go to the
Work Request Details page and view more detailed information.
For more information about OCI work requests, see Work Requests

Troubleshooting Connection Creation Failures

In Oracle Cloud Infrastructure Database Migration, if you have a Connection (odms-
connection) resource in failed state use the following steps to gather more details about the
failure.
1. Get the connection OCID.
• Using the OCI Web Console:
Go to the OCI Console, and open Database Migration Service/Database Connections
(for example, https://console.us-phoenix-1.oraclecloud.com/odms/registrations).
Locate the failed Connection in the list, and select Copy OCID from the Actions
(three dots) menu.
• Using Oracle Database Migration Service (database-migration) OCI Command line
interface:
The compartment OCID where the failed connection was created is required. You
can find it using database-migration >> connection >> list as shown in the following
example.
– List all connection resources and find the failure:

oci database-migration connection list -c `compartmentOCID`

– If you know the connection display name, you can use it to filter results:

oci database-migration connection list -c `compartmentOCID` --

display-name `connectionDisplayName`

2. Get the Work Request OCID associated with the connection creation request.
• Using Oracle Database Migration Service (database-migration) OCI Command line
interface:

8-3
 Chapter 8
Troubleshooting Connection Creation Failures

The compartment OCID where the failed connection was created is required.
You can find it using database-migration >> work-request >> list as shown in
the following example.
– Use the connection OCID to list the work requests:

oci database-migration work-request list --resource-id odms-

connection-OCID --compartment-id odms-connection-compartment-
OCID

– Use the compartment OCID to list the work requests of the compartment:

oci database-migration work-request list --compartment-id

odms-connection-compartment-OCID

– Use the sort-by option to sort the results by displayName or timeCreated:

oci database-migration work-request list --compartment-id

odms-connection-compartment-OCID --sort-by displayName

– Use the sort-order option with asc or desc:

oci database-migration work-request list --compartment-id

odms-connection-compartment-OCID --sort-oder ASC

Only one sort order can be specified. Default order for --sort-by
timeCreated is descending.
• Using the Database Migration REST API:
– Use the connection OCID to list the work requests:
See ListWorkRequests

GET /20210929/workRequests?resourceId=odms-connection-
OCID&compartmentId=odms-connection-compartment-OCID

– Use the compartment OCID to list the work requests of the compartment:

GET /20210929/workRequests?compartmentId=compartment-OCID-of-
resource

– Use the sort-by option to sort the results by displayName or timeCreated:

GET /20210929/workRequests?compartmentId=compartment-OCID-of-
resource&sortBy=displayName

– Use the sort-orderoption with asc or desc:

GET /20210929/workRequests?compartmentId=compartment-OCID-of-
resource&sortOrder=ASC

Only one sort order can be specified. Default order for --sort-by
timeCreated is descending.

8-4
 Chapter 8
Troubleshooting Connection Creation Failures

3. Use the work request OCID to get details, logs, and errors related to the failure:
• Using Oracle Database Migration Service (database-migration) OCI Command line
interface:
– Use the work request identifier to get details:

oci database-migration work-request get --work-request-id

workRequestId

See database-migration >> work-request >> get

– Use the work request identifier to list the errors:

oci database-migration work-request-error list --work-request-id

workRequestId

See database-migration >> work-request-error >> list

– Use the work request identifier to list the logs:

oci database-migration work-request-logs list --work-request-id

workRequestId

See database-migration >> work-request-logs >> list

• Using the Database Migration REST API:
– Use the work request identifier to get the details:

GET /20210929/workRequests/{workRequestId}

See GetWorkRequest
– Use the work request identifier to get the errors:

GET /20210929/workRequests/{workRequestId}/errors

See ListWorkRequestErrors
– Use the work request identifier to get the logs:

GET /20210929/workRequests/{workRequestId}/logs

See ListWorkRequestLogs
4. Inspect the logs and errors in the work request and resolve the issues reported.
For more information about using the API and signing requests, see REST APIs and Security
Credentials. For information about SDKs, see Software Development Kits and Command
Line Interface.

8-5
 Chapter 8
Troubleshooting Network Connectivity Issues for Database Connections

Troubleshooting Network Connectivity Issues for Database

Connections
Use this feature to test the connectivity before you create or start the migration.
See Testing Connectivity of a Database Connection for more information.

Troubleshooting Migration Creation Failures

In Oracle Cloud Infrastructure Database Migration, if you have a Migration (odms-
migration) resource in failed state use the following steps to gather more details about
the failure:
1. Get the migration OCID.
• Using the OCI Web Console:
Go to the OCI Console, and open Database Migration Service/Migrations (for
example, https://console.us-phoenix-1.oraclecloud.com/odms/migrations).
Locate the failed Migration in the list, and select Copy OCID from the Actions
(three dots) menu.
• Using Oracle Database Migration Service (database-migration) OCI Command
line interface:
The compartment OCID where the failed migration was created is required.
– List all migration resources and find the failure:

oci database-migration migration list -c `compartmentOCID`

See database-migration >> migration >> list

– If you know the migration display name, you can use it to filter results:

oci database-migration migration list -c `compartmentOCID` --

display-name `migrationDisplayName`

2. Get the Work Request OCID associated with the migration creation request.
• Using Oracle Database Migration Service (database-migration) OCI Command
line interface:
The compartment OCID where the failed migration was created is required.
– Use the migration OCID to list the work requests:

oci database-migration work-request list --resource-id odms-

migration-OCID --compartment-id
odms-migration-compartment-OCID

See database-migration >> work-request >> list

8-6
 Chapter 8
Troubleshooting Migration Creation Failures

– Use the compartment OCID to list the work requests of the compartment:

oci database-migration work-request list --compartment-id odms-

migration-compartment-OCID

– Use the sort-by option to sort the results by displayName or timeCreated:

oci database-migration work-request list --compartment-id odms-

migration-compartment-OCID --sort-by displayName

– Use the sort-order option with asc or desc:

oci database-migration work-request list --compartment-id odms-

migration-compartment-OCID --sort-oder ASC

Only one sort order can be specified. Default order for --sort-by timeCreated is
descending.
• Using the Database Migration REST API:
– Use the migration OCID to list the work requests:

GET /20210929/workRequests?resourceId=odms-migration-
OCID&compartmentId=odms-migration-compartment-OCID

See ListWorkRequests
– Use the compartment OCID to list the work requests of the compartment:

GET /20210929/workRequests?compartmentId=compartment-OCID-of-
resource

– Use the sort-by option to sort the results by displayName or timeCreated:

GET /20210929/workRequests?compartmentId=compartment-OCID-of-
resource&sortBy=displayName

– Use the sort-orderoption with asc or desc:

GET /20210929/workRequests?compartmentId=compartment-OCID-of-
resource&sortOrder=ASC

Only one sort order can be specified. Default order for --sort-by timeCreated is
descending.
3. Use the work request OCID to get details, logs, and errors related to the failure:
• Using Oracle Database Migration Service (database-migration) OCI Command line
interface:
– Use the work request identifier to get details:

oci database-migration work-request get --work-request-id

workRequestId

8-7
 Chapter 8
Troubleshooting Migration Creation Failures

See database-migration >> work-request >> get

– Use the work request identifier to list the errors:

oci database-migration work-request-error list --work-

request-id workRequestId

See database-migration >> work-request-error >> list

– Use the work request identifier to list the logs:

oci database-migration work-request-logs list --work-request-

id workRequestId

See database-migration >> work-request-logs >> list

• Using the Database Migration REST API:
– Use the work request identifier to get the details:

GET /20210929/workRequests/{workRequestId}

See GetWorkRequest
– Use the work request identifier to get the errors:

GET /20210929/workRequests/{workRequestId}/errors

See ListWorkRequestErrors
– Use the work request identifier to get the logs:

GET /20210929/workRequests/{workRequestId}/logs

See ListWorkRequestLogs
4. Inspect the logs and errors in the work request and resolve the issues reported.
For more information about using the API and signing requests, see REST APIs and
Security CredentialsSecurity Credentials. For information about SDKs, see Software
Development Kits and Command Line Interface.

8-8
9
Database Migration Policies
To control access to Oracle Cloud Infrastructure Database Migration and the type of access
each user group has, you must create policies.
The following topics explain how to create policies for Database Migration.

About IAM Policies

A tenancy administrator can create policies in Oracle Cloud Infrastructure Identity and Access
Management (IAM) to grant permissions to groups on resources in compartments in a
tenancy.
For example, you can create an Administrators group whose members can access all
Database Migration resources. You can then create a separate group for everyone else who's
involved with Database Migration, and create policies that restrict their access to Database
Migration resources in different compartments.
For a complete list of Oracle Cloud Infrastructure policies, see policy reference.

Basic Syntax for Policies

A policy is a document that consists of one or more statements. A policy statement follows
this basic syntax:

Allow group <group_name> to <verb><resource-type> in compartment

<compartment_name>

Policy language uses simple verbs like inspect, read, use, and manage.

Database Migration Resource-Types

Database Migration offers individual resource-types for writing policies.

Resource-Type Description
odms-agent Software that allows migrations from sources
databases not accessible from Oracle Cloud
odms-connection Connection settings
odms-job Migration job operations
odms-migration Migration parameter settings

Supported Variables
When you add conditions to your policies, you can use either Oracle Cloud Infrastructure
general or service specific variables.

9-1
 Chapter 9
Details for Verbs + Resource-Type Combinations

Database Migration supports all general variables. For more information, see general
variables for all requests.

Details for Verbs + Resource-Type Combinations

There are various Oracle Cloud Infrastructure verbs and resource-types that you can
use when you create a policy. The topics in this section show the permissions and API
operations covered by each verb for Database Migration.
The level of access is cumulative as you go from inspect to read to use to manage.

odms-connection
Permission APIs Fully Covered
INSPECT
ODMS_CONNECTION_INSPECT ListConnection
READ
INSPECT + INSPECT+
ODMS_CONNECTION_READ GetConnection
USE
READ + READ +
ODMS_CONNECTION_USE N/A
MANAGE
USE + USE +
ODMS_CONNECTION_CREATE CreateConnection
ODMS_CONNECTION_UPDATE UpdateConnection
ODMS_CONNECTION_DELETE DeleteConnection
ODMS_CONNECTION_MOVE ChangeConnectionCompartment

odms-agent
Permission APIs Fully Covered
INSPECT
ODMS_AGENT_INSPECT ListAgents
READ
INSPECT + INSPECT+
ODMS_AGENT_READ GetAgent
USE
READ + READ +
N/A N/A
MANAGE
USE + USE +
ODMS_AGENT_UPDATE UpdateAgent
ODMS_AGENT_DELETE DeleteAgent
ODMS_AGENT_MOVE ChangeAgentCompartment

9-2
 Chapter 9
Details for Verbs + Resource-Type Combinations

odms-migration
Permission APIs Fully Covered
INSPECT
ODMS_MIGRATION_INSPECT ListAgentImages
ODMS_MIGRATION_INSPECT ListMigrations
READ
INSPECT + INSPECT+
ODMS_MIGRATION_READ GetMigration
ODMS_MIGRATION_READ RetrieveSupportedPhases
USE
READ + READ +
ODMS_MIGRATION_USE StartMigration
ODMS_MIGRATION_VALIDATE EvaluateMigration
MANAGE
USE + USE +
ODMS_MIGRATION_CREATE + CreateMigration
ODMS_CONNECTION_USE
ODMS_MIGRATION_CLONE + CloneMigration
ODMS_CONNECTION_USE
ODMS_MIGRATION_UPDATE + UpdateMigration
ODMS_CONNECTION_USE
ODMS_MIGRATION_DELETE DeleteMigration
ODMS_MIGRATION_MOVE ChangeMigrationCompartment

odms-job
Permission APIs Fully Covered
INSPECT
ODMS_JOB_INSPECT ListJobs
READ
INSPECT + INSPECT+
ODMS_JOB_READ GetJob
USE
READ + READ +
ODMS_JOB_USE ListJobOutputs
ODMS_JOB_USE GetJobOutputContent
ODMS_JOB_ABORT AbortJob
ODMS_JOB_RESUME ResumeJob
MANAGE
USE + USE +
ODMS_JOB_UPDATE UpdateJob
ODMS_JOB_DELETE DeleteJob

9-3
 Chapter 9
Permissions Required for Database Migration API Operations

Permissions Required for Database Migration API

Operations
Here's a list of the API operations for Oracle Cloud Infrastructure Database Migration
in logical order, grouped by resource-type.
The resource-types are odms-agent, odms-connection, odms-job and odms-
migration.

API Operation Permission

GetAgent ODMS_AGENT_READ
ListAgents ODMS_AGENT_INSPECT
DeleteAgent ODMS_AGENT_DELETE
UpdateAgent ODMS_AGENT_UPDATE
ChangeAgentCompartment ODMS_AGENT_MOVE
ValidateAgent ODMS_AGENT_REGISTER
RegisterHeartbeat ODMS_AGENT_REGISTER
GetActionGenerateToken ODMS_AGENT_REGISTER
CreateConnection ODMS_CONNECTION_CREATE
UpdateConnection ODMS_CONNECTION_UPDATE
GetConnection ODMS_CONNECTION_READ
ListConnections ODMS_CONNECTION_INSPECT
DeleteConnection ODMS_CONNECTION_DELETE
ChangeConnectionCompartment ODMS_CONNECTION_MOVE
ListAgentImages ODMS_MIGRATION_INSPECT
CreateMigration ODMS_CONNECTION_USE and
ODMS_MIGRATION_CREATE
CloneMigration ODMS_CONNECTION_USE and
ODMS_MIGRATION_CLONE
UpdateMigration ODMS_CONNECTION_USE and
ODMS_MIGRATION_UPDATE
GetMigration ODMS_MIGRATION_READ
RetrieveSupportedPhases ODMS_MIGRATION_READ
ListMigrations ODMS_MIGRATION_INSPECT
DeleteMigration ODMS_MIGRATION_DELETE
EvaluateMigration ODMS_MIGRATION_VALIDATE
StartMigration ODMS_MIGRATION_USE
ChangeMigrationCompartment ODMS_MIGRATION_MOVE
AbortJob ODMS_JOB_ABORT
ResumeJob ODMS_JOB_RESUME
DeleteJob ODMS_JOB_DELETE
GetJob ODMS_JOB_READ
ListJobs ODMS_JOB_INSPECT
UpdateJob ODMS_JOB_UPDATE

9-4
 Chapter 9
Required Database Migration Policies

API Operation Permission

ListJobOutputs ODMS_JOB_USE
GetJobOutputContent ODMS_JOB_USE

Required Database Migration Policies

At minimum, you need policies for the following:
• Allow users to use or manage Database Migration resources, so that they can work with
migrations, agents, jobs, and Connections
• Allow users to inspect network resources, so that they can view and select compartments
and subnets when creating Database Migration resources
Depending on whether or not you intend to use the following services, you will need to add
policies to enable access to these services as well:
• Oracle Autonomous Databases for your target databases
• Oracle Vault to store secrets
• Oracle Object Storage to store Data Pump dumps
You create policies using the Console. In the Console navigation menu, under Governance
and Administration, go to Identity, and then click Policies. Policies are written in the
following syntax:

allow group <group-name> to <verb> <resource-type> in <location> where

<condition>

• <group-name>: The name of the user group you're giving permissions to

• <verb>: Gives the group a certain level of access to a resource-type. As the verbs go
from inspect to read to use to manage, the level of access increases and the permissions
granted are cumulative.
• <resource-type>: The type of resource you're giving a group permission to work with,
such as odms-agent, odms-connection, odms-job, and odms-migration.
For more information, see resource-types.
• <location>: Attaches the policy to a compartment or tenancy. You can specify a single
compartment or compartment path by name or OCID, or specify tenancy to cover the
entire tenancy.
• <condition>: Optional. One or more conditions for which this policy will apply.

Creating a Network Resource Policy

Database Migration requires you to provide VCN and subnet information when creating
migrations and database registrations. In order to provide this information, you need to have
the ability to view cloud network information. The following statement gives the group

9-5
 Chapter 9
Creating a Policy

permission to inspect network resources in the compartment and select them when
creating Database Migration resources:

allow group <group-name> to inspect virtual-network-family in

compartment <compartment-name>

Creating a Tagging Policy

The following statement gives a group permission to manage tag-namespaces and
tags for workspaces:

allow group <group-name> to manage tag-namespaces in compartment

<compartment-name>

To add a defined tag, you must have permission to use the tag namespace.

Related Topics
Learn more about:
• Policies
• policy syntax
• Resource Tags
• Permissions

Creating a Policy
To create a policy:
1. In the Console navigation menu, under Governance and Administration, go to
Identity, and then click Policies.
2. Click Create Policy.
3. Enter a name and description for the policy.
4. In the Statement field, enter a policy rule in the following format:

allow <subject> to <verb> <resource-type> in <location> where

<condition>

Conditions are optional. See Verbs and Resource-type Combos.

5. (Optional) To add another statement, click + Another Statement.
6. Click Create.
For more information about policies, see how policies work, policy syntax, and policy
reference.

9-6
10
Database Migration Metrics
Monitor the health, capacity, and overall performance of your Oracle Cloud Infrastructure
Database Migration database registrations, migrations, agents, and jobs using metrics,
alarms, and notifications.
Resources: odms-agent, odms-connection, odms-job, odms-migration

Overview
Oracle Cloud Infrastructure Database Migration metrics help you measure the amount of data
replicated between source and target databases.

Note:
Capacity of target databases can be monitored through the target database service
and used to trigger alerts. For more information, see Use Autonomous Database
Metrics to Monitor Databases and Use Enterprise Manager to Manage and Monitor
Databases.

Terminology
The following terms are helpful for understanding metrics:
• Namespace: A container for Database Migration metrics. The namespace for Database
Migration is oci_database_migration_service.
• Metrics: The fundamental concept in telemetry and monitoring. Metrics define a time-
series set of datapoints. Each metric is uniquely defined by namespace, metric name,
compartment identifier, a set of one or more dimensions, and a unit of measure. Each
datapoint has a timestamp, a value, and a count associated with it.
• Dimensions: A key-value pair that defines the characteristics associated with the metric.
For example, resourceId, which is the Database Migration deployment OCID.
• Statistics: Metric data aggregations over specified periods of time. Aggregations are
done using the namespace, metric name, dimensions, and the datapoint unit of measure
within the time period specified.
• Alarms: Used to automate operations monitoring and performance. An alarm keeps track
of changes that occur over a specific period of time. It also performs one or more defined
actions, based on the rules defined for the metric.

Prerequisites
• IAM policies: To monitor resources, you must be given the required type of access in a
policy written by an administrator, whether you're using the Console or the REST API with
an SDK, CLI, or other tool. The policy must give you access to the monitoring services as
well as the resources being monitored. If you try to perform an action and get a message

10-1
 Chapter 10
Available Metrics

that you don’t have permission or are unauthorized, confirm with your
administrator the type of access you've been granted and which compartment you
should work in. For more information on user authorizations for monitoring, see
Monitoring or Notifications.
• The metrics listed on this page are automatically available for any Database
Migration resource you create. You do not need to enable monitoring on the
resource to get these metrics.

Available Metrics
Oracle Cloud Infrastructure Database Migration metrics may include the following
dimensions:
• resourceId: For all metrics, the resourceId is the Migration, Agent, or Job
resource OCID.
• resourceName: Name of the Migration, Agent, or Job resource.

Table 10-1 OCI Database Migration Metrics

Metric Metric Display Unit Description Dimensions

Name
AgentHealth Agent Health percent Measures health resourceId =
of a registered agentOcid
agent.
resourceName
0% - unhealthy =
100% - healthy agentDisplayN
ame
MigrationHeal Migration Health percent Measures health resourceId =
th of a migration. migrationOcid
0% - failed resourceName
migration =
100% - migrationProj
successful ectName
migration
DbImportProgr Database Import percent Percentage of resourceId =
ess Progress data imported jobOcid
into OCI resourceName =
database. jobName
DbExportProgr Database Export percent Percentage of resourceId =
ess Progress data exported jobOcid
from source resourceName =
database. jobName
ReplicationLa Replication seconds End-to-end resourceId =
tency Latency replication jobOcid
latency (using resourceName =
heartbeat table) jobName
ReplicationTh Replication GB per hour Replication resourceId =
roughput Throughput throughput in GB jobOcid
per hour resourceName =
jobName

10-2
 Chapter 10
Using the Console

Using the Console

To view Oracle Cloud Infrastructure Database Migration metrics:
1. In the Console navigation menu, under Solutions and Platform, go to Monitoring and
then select Service Metrics.
2. For Compartment, select the compartment that contains the Database Migration
resources you're interested in.
3. For Metric Namespace, select oci_database_migration_service.
Refresh your browser to view the latest metrics emitted by the service.

10-3
11
Reference
This section contains reference materials.

Set Up Source and Target Configurations for Online Migrations

for Your GoldenGate Instance
To use your own GoldenGate instance, Oracle Cloud Infrastructure Database Migration
service has a few additional prerequisite tasks, create GoldenGate users on the source
database and unlock the GoldenGate user on the target database (optional).

Note:
You can have a single user for database connection, if you have the required
privileges. For the source database, the user for CDB and PDBs has all the
privileges for GoldenGate and Data Pump.

Create GoldenGate Users on the Source Database

On the source database, you must create a GoldenGate administration user, for example
ggadmin.

If the source database is multitenant, create the user in the PDB, and also create a different
user in the CDB root, for example c##ggadmin.

To create ggadmin, connect to the PDB and run the following commands:

CREATE TABLESPACE gg_admin DATAFILE '+DATA/ggadmin_data.dbf' SIZE 100m

AUTOEXTEND ON NEXT 100m;
CREATE USER ggadmin IDENTIFIED BY ggadmin_pwd DEFAULT TABLESPACE gg_admin
TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON gg_admin;
GRANT CONNECT TO ggadmin;
GRANT RESOURCE TO ggadmin;
GRANT CREATE TO ggadmin;
GRANT SELECT_CATALOG_ROLE TO ggadmin;
GRANT DV_GOLDENGATE_ADMIN TO ggadmin;
GRANT DV_GOLDENGATE_REDO_ACCESS TO ggadmin;
GRANT ALTER SYSTEM TO ggadmin;
GRANT ALTER USER TO ggadmin;
GRANT DATAPUMP_EXP_FULL_DATABASE TO ggadmin;
GRANT DATAPUMP_IMP_FULL_DATABASE TO ggadmin;
GRANT SELECT ANY DICTIONARY TO ggadmin;
GRANT SELECT ANY TRANSACTION TO ggadmin;
GRANT INSERT ANY TABLE TO ggadmin;
GRANT UPDATE ANY TABLE TO ggadmin;
GRANT DELETE ANY TABLE TO ggadmin;

11-1
 Chapter 11
Set Up Source and Target Configurations for Online Migrations for Your GoldenGate Instance

GRANT LOCK ANY TABLE TO ggadmin;

GRANT CREATE ANY TABLE TO ggadmin;
GRANT CREATE ANY INDEX TO ggadmin;
GRANT CREATE ANY CLUSTER TO ggadmin;
GRANT CREATE ANY INDEXTYPE TO ggadmin;
GRANT CREATE ANY OPERATOR TO ggadmin;
GRANT CREATE ANY PROCEDURE TO ggadmin;
GRANT CREATE ANY SEQUENCE TO ggadmin;
GRANT CREATE ANY TRIGGER TO ggadmin;
GRANT CREATE ANY TYPE TO ggadmin;
GRANT CREATE ANY SEQUENCE TO ggadmin;
GRANT CREATE ANY VIEW TO ggadmin;
GRANT ALTER ANY TABLE TO ggadmin;
GRANT ALTER ANY INDEX TO ggadmin;
GRANT ALTER ANY CLUSTER TO ggadmin;
GRANT ALTER ANY INDEXTYPE TO ggadmin;
GRANT ALTER ANY OPERATOR TO ggadmin;
GRANT ALTER ANY PROCEDURE TO ggadmin;
GRANT ALTER ANY SEQUENCE TO ggadmin;
GRANT ALTER ANY TRIGGER TO ggadmin;
GRANT ALTER ANY TYPE TO ggadmin;
GRANT ALTER ANY SEQUENCE TO ggadmin;
GRANT CREATE DATABASE LINK TO ggadmin;
GRANT EXECUTE ON dbms_lock TO ggadmin;
EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('ggadmin');

To create c##ggadmin, connect to the CDB and run the following commands:

CREATE USER c##ggadmin IDENTIFIED BY cggadmin_pwd CONTAINER=ALL

DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP QUOTA UNLIMITED ON
USERS;
GRANT CONNECT TO c##ggadmin CONTAINER=ALL;
GRANT RESOURCE TO c##ggadmin CONTAINER=ALL;
GRANT CREATE TABLE TO c##ggadmin CONTAINER=ALL;
GRANT CREATE VIEW TO c##ggadmin CONTAINER=ALL;
GRANT CREATE SESSION TO c##ggadmin CONTAINER=ALL;
GRANT SELECT_CATALOG_ROLE TO c##ggadmin CONTAINER=ALL;
GRANT DV_GOLDENGATE_ADMIN TO c##ggadmin CONTAINER=ALL;
GRANT DV_GOLDENGATE_REDO_ACCESS TO c##ggadmin CONTAINER=ALL;
GRANT ALTER SYSTEM TO c##ggadmin CONTAINER=ALL;
GRANT ALTER USER TO c##ggadmin CONTAINER=ALL;
GRANT SELECT ANY DICTIONARY TO c##ggadmin CONTAINER=ALL;
GRANT SELECT ANY TRANSACTION TO c##ggadmin CONTAINER=ALL;
GRANT EXECUTE ON dbms_lock TO c##ggadmin CONTAINER=ALL;
EXEC
DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE('c##ggadmin',CONTAINER=>'ALL
');

Create or Unlock the GoldenGate User on the Target Database

On co-managed targets:
If the target is not Oracle Autonomous Database, create a ggadmin user in the target
PDB. This user is similar to the ggadmin user you created on the source database, but

11-2
 Chapter 11
Database Migration Data Pump Defaults

will require more privileges. See Establishing Oracle GoldenGate Credentials for information
about privileges required for a "Replicat all modes" user.
On Autonomous targets:
Autonomous Database has a pre-created ggadmin user that you must unlock. These
commands need to be run on the GoldenGate Target instance.
1. Connect to the target database as admin.

export TNS_ADMIN=/u02/deployments/Target/etc
export ORACLE_HOME=/u01/app/client/oracle19
$ $ORACLE_HOME/bin/sqlplus admin/ADW_password@ADW_name

An example of the ADW_name would be targetatp_high.

2. Unlock ggadmin.

SQL> ALTER USER ggadmin IDENTIFIED BY ggadmin_password ACCOUNT UNLOCK;

3. Verify that ggadmin is unlocked.

export TNS_ADMIN=/u02/deployments/Target/etc
export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus ggadmin/ADW_password@ADW_name

Note:
Oracle Cloud Infrastructure Database Migration Service supports only those
scenarios where the Target database and Oracle GoldenGate, both run on private
IP addresses.

Database Migration Data Pump Defaults

Oracle Cloud Infrastructure Database Migration automatically sets optimal defaults for Data
Pump parameters to achieve better performance and ensure security of data. There are also
Data Pump errors that are ignored by default.
The following table lists the Data Pump parameters set by Database Migration, and the
values they are set to. If there is a Database Migration migration setting available to override
the default, it is listed in the Optional DMS Setting to Override column.

11-3
 Chapter 11
Database Migration Data Pump Defaults

Table 11-1 Database Migration Data Pump Parameter Defaults

Data Pump Parameter Default Value Optional DMS Setting to

Override
EXCLUDE index (ADW-S) Excluded Objects: Object
cluster (ADB-D, ADB-S) Owner and Object Name
indextype (ADW-S) See Selecting Objects for
Migration
materialized_view (ADW-S)
materialized_view_log (ADW-
S)
materialized_zonemap (ADW-
S)
db_link (ADB)
statistics (User managed
Target and ADB)
PARALLEL Database Migration sets Import Parallelism Degree
PARALLEL parameter by Export Parallelism Degree
default as follows
See Configuring Optional
For user-managed database Initial Load Advanced Options
(Sum of (2 x (no. of physical
CPU) per node ) ) with Max 32
cap.
For Autonomous Database,
number of OCPUs
CLUSTER Database Migration always Cluster
sets the Cluster mode as See Configuring Optional
default Initial Load Advanced Options
COMPRESSION COMPRESSION_ALGORITH N/A
M is set to BASIC(for Oracle
Database 11.2) and MEDIUM
(for Oracle Database 12.1 and
later)
COMPRESSION is set to ALL
ENCRYPTION ENCRYPTION is set to ALL N/A
ENCRYPTION_ALGORITHM
is set to AES128
ENCRYPTION_MODE is set
to PASSWORD
FILESIZE FILESIZE is set to 5G N/A
FLASHBACK_SCN For offline migrations, sets N/A
FLASHBACK_TIME System
time now.
For online migrations, uses
neither FLASHBACK_SCN nor
FLASHBACK_TIME
REUSE_DUMPFILES Always set to YES N/A

11-4
 Chapter 11
Database Migration Job Phases

Table 11-1 (Cont.) Database Migration Data Pump Parameter Defaults

Data Pump Parameter Default Value Optional DMS Setting to

Override
TRANSFORM Always sets Allows additional
OMIT_ENCRYPTION_CLAUS TRANSFORM to be specified
E:Y for Oracle Database 19c
and later target releases
Always sets
LOB_STORAGE:SECUREFIL
E
For an Autonomous Database
target, the following transform
is set by default
SEGMENT_ATTRIBUTES:N
DWCS_CVT_IOTS:Y
CONSTRAINT_USE_DEFAUL
T_INDEX:Y
METRICS Always set to Yes N/A
LOGTIME Always set to ALL N/A
TRACE Always set to 1FF0b00 N/A
LOGFILE Always set to Data Pump job N/A
name and created under the
specified export or import
directory object.
For example, if a Data Pump
job is
ZDM_2_DP_EXPORT_8417
and directory object used is
DATA_PUMP_DIR, then the
operation log is created by
name
ZDM_2_DP_EXPORT_8417.l
og under DATA_PUMP_DIR.

Oracle Data Pump errors that are ignored by default are as follows:
• ORA-31684: XXXX already exists
• ORA-39111: Dependent object type XXXX skipped, base object type
• ORA-39082: Object type ALTER_PROCEDURE: XXXX created with compilation
warnings
This is not configurable.

Database Migration Job Phases

A migration job in Oracle Cloud Infrastructure Database Migration runs in operational phases
as a work flow.
The phases in Database Migration are shown in the console with user-friendly names (DMS
Phase), and in the REST API with the codes prefixed with "ODMS_", as shown in the table
below.

11-5
 Chapter 11
Database Migration Job Phases

Note that Database Migration harnesses the Zero Downtime Migration tool to run the
migration job work flow, so in the logs the migration phase names will have a "ZDM_"
prefix. Also note that one Database Migration phase corresponds to one or more Zero
Downtime Migration phases, which will give you a more granular look at the work flow.

Table 11-2 Database Migration Process Phase Descriptions

DMS Phase Name Description ZDM Phase Name Description

Console (API
Codes)
Validate Performs validation of Validate Source Validates the source
(ODMS_VALIDATE) the source and target (ZDM_VALIDATE_SRC) database access
database, the credentials, database
GoldenGate Hub, and parameter settings,
Data Pump ggadmin user
configuration. privileges, and
GoldenGate capture
support for objects in
source database
Validate Target Verifies that the target
(ZDM_VALIDATE_TGT) database exists and
that the database type
is Autonomous
Database, and
validates access
credentials, security,
and connectivity.
Validate Pre-migration Cloud Pre-Migration
Advisor Advisor Tool is run.
(ZDM_PRE_MIGRATION
_ADVISOR)
Validate GoldenGate Verifies GoldenGate
Hub (ZDM_VALIDATE Microservices REST
GG_HUB) endpoints, software
configuration, health,
and connectivity to the
source and target
databases.
Validate Datapump Validates the export
Source Settings directory object (if
(ZDM_VALIDATE_DATA applicable), and
PUMP_SETTINGS_SRC) checks for sufficient
space and permission
for specified user in
the source database
to export dumps.
Checks if the specified
Oracle Cloud Object
Store buckets, data
bucket, and wallet
bucket are accessible
from the source. Also
validates the proxy
configuration if
applicable.

11-6
 Chapter 11
Database Migration Job Phases

Table 11-2 (Cont.) Database Migration Process Phase Descriptions

DMS Phase Name Description ZDM Phase Name Description

Console (API
Codes)
Validate Datapump Verifies that the Data
Target Settings Pump import directory
(ZDM_VALIDATE_DATA object exists.
PUMP_SETTINGS_TGT) If a pre-existing
DBLINK was
specified, checks if it
exists and is valid, and
ensures that the ADB
requirements for the
DBLINK and wallet
files are met.
Prepare Prepares for and starts Prepare GoldenGate Registers database
(ODMS_PREPARE_RE the GoldenGate Extract Hub connection details and
PLICATION) process, and enables (ZDM_PREPARE_GG_HU credentials with
supplemental logging B) GoldenGate
Microservices.
ZDM_ADD_HEARTBEAT Creates GoldenGate
_SRC heartbeat table in the
source database. If
the table already
exists, sets update
frequency to 60
seconds.
ZDM_ADD_SCHEMA_TR Prepares the source
ANDATA_SRC database schemas for
instantiation by
enabling schema level
supplemental logging.
Create GoldenGate Starts the GoldenGate
Source Extract Extract process at the
(ZDM_CREATE_GG_EXT source database
RACT_SRC)
Prepare Creates any necessary Prepare Source Creates a new
(ODMS_PREPARE_IN directory objects for Datapump directory object for
ITIAL_LOAD) Data Pump, and creates (ZDM_PREPARE_DATAP Data Pump, if
a DBLINK, if applicable. UMP_SRC) required. Creates OCI
Auth Token to access
OCI OSS bucket if
required.

11-7
 Chapter 11
Database Migration Job Phases

Table 11-2 (Cont.) Database Migration Process Phase Descriptions

DMS Phase Name Description ZDM Phase Name Description

Console (API
Codes)
Prepare Target Creates a new
Datapump directory object for
(ZDM_PREPARE_DATAP Data Pump, if
UMP_TGT) required. Stores OCI
Auth token in the
database for secure
OSS access.
If migrating via
DBLINK, and a
DBLINK must be
created, creates the
necessary database
credentials to access
the source and create
a new DBLINK.
Ensures Autonomous
Database security
requirements are met
using DBLINK over
SSL.
Datapump Source Starts and monitors the Datapump Source Starts and monitors
Export Data Pump Export on Export the Data Pump Export
(ODMS_INITIAL_LO the source database. ZDM_DATAPUMP_EXPO on the source
AD_EXPORT) RT_SRC) database.
Upload Source Uploads Data Pump Upload Source Dump Uploads Data Pump
Dump Files dump files from the Files dump files from the
(ODMS_DATA_UPLOA source to OCI OSS. (ZDM_UPLOAD_DUMPS_ source to OCI OSS.
D) SRC)
Datapump Target Starts import of Data Datapump Target Starts import of Data
Import Pump Dumps to the Import Pump Dumps to the
(ODMS_INITIAL_LO target database, either (ZDM_DATAPUMP_IMPO target database, either
AD_IMPORT) from the OCI OSS RT_TGT) from the OCI OSS
bucket or via DBLINK, bucket or via DBLINK,
and monitors the Data and monitors the Data
Pump import progress. Pump import
progress.
Post Datapump Removes directory Post Source Removes any Data
(ODMS_POST_INITI objects, access Datapump Pump directory object
AL_LOAD) credentials, and (ZDM_POST_DATAPUMP created by Database
DBLINK that were _SRC) Migration.
created for Data Pump
by Database Migration.

11-8
 Chapter 11
Database Migration Job Phases

Table 11-2 (Cont.) Database Migration Process Phase Descriptions

DMS Phase Name Description ZDM Phase Name Description

Console (API
Codes)
Post Target Datapump Fixes any invalid
(ZDM_POST_DATAPUMP objects in the target
_TGT) database. Removes
the database access
and OCI OSS access
credentials that were
created for the
migration. Removes
any DBLINK created
by Database
Migration. Optionally,
removes source
database dumps
stored in OCI OSS
bucket.
Prepare GoldenGate Prepares for ZDM_ADD_HEARTBEAT Creates the
(ODMS_PREPARE_RE GoldenGate replication. _TGT GoldenGate heartbeat
PLICATION_TARGET table in the target
) database. If the table
already exists, sets
update frequency to
60 seconds.
ZDM_ADD_CHECKPOIN Creates GoldenGate
T_TGT checkpoint table in the
target database to
track Replicat
progress.
ZDM_CREATE_GG_REP Creates GoldenGate
LICAT_TGT Replicat process for
the target database.
ZDM_START_GG_REPL Starts GoldenGate
ICAT_TGT Replicat process for
the target database.

Monitor GoldenGate Polls the GoldenGate Monitor GoldenGate Polls the GoldenGate
Lag checkpoint and Lag checkpoint and
(ODMS_MONITOR_RE heartbeat data to (ZDM_MONITOR_GG_LA heartbeat data to
PLICATION_LAG) measure end-to-end G) measure end-to-end
apply lag until lag apply lag until lag
decreases below decreases below
desired threshold. desired threshold.
Switchover App If the source database Switchover App If the source database
(ODMS_SWITCHOVER) is idle, stops (ZDM_SWITCHOVER_AP is idle, stops
GoldenGate Extract, P) GoldenGate Extract,
waits for GoldenGate waits for GoldenGate
Replicat to complete Replicat to complete
apply, and stops apply, and stops
GoldenGate Replicat. GoldenGate Replicat.

11-9
 Chapter 11
Database Migration Job Phases

Table 11-2 (Cont.) Database Migration Process Phase Descriptions

DMS Phase Name Description ZDM Phase Name Description

Console (API
Codes)
Cleanup Performs cleanup Post Switchover Performs post-
(ODMS_CLEANUP) operations such as (ZDM_POST_SWITCHOV switchover actions for
deleting GoldenGate ER_TGT) the target database.
Extract and GoldenGate
Replicat processes and ZDM_RM_GG_EXTRACT Deletes GoldenGate
connection details on _SRC Extract process on
source and target source database
database respectively, ZDM_RM_GG_REPLICA Deletes GoldenGate
removing Autonomous T_TGT Replicat process on
Database access to target database
wallet, and so on.
ZDM_DELETE_SCHEMA Disables schema level
_TRANDATA_SRC supplemental logging
on source database
ZDM_RM_HEARTBEAT_ Drops the GoldenGate
SRC heartbeat table in
source database, if
the table was created
by Database
Migration. Otherwise,
resets update
frequency to original
setting.
ZDM_RM_CHECKPOINT Drops the GoldenGate
_TGT checkpoint table in the
target database.
ZDM_RM_HEARTBEAT_ Drops the GoldenGate
TGT heartbeat table in the
target database, if the
table was created by
Database Migration.
Otherwise, resets the
update frequency to
the original value.
Clean GoldenGate Deletes the database
Hub connection details and
(ZDM_CLEAN_GG_HUB) credentials saved with
GoldenGate
Microservices
Post Actions Removes Autonomous
(ZDM_POST_ACTIONS) Database access
wallet from Database
Migration.
ZDM_CLEANUP_SRC Deletes the Cloud
Pre-Migration Advisor
Tool related binaries
on source database
servers.

11-10
 Chapter 11
Database Migration Events

Database Migration Events

Oracle Cloud Infrastructure Database Migration service emits events in Oracle Cloud
Infrastructure (OCI), which are structured messages that indicate changes in resources.
You can define rules in the OCI Event Service to get notified of events happening in an OCI
native service and use the Notification Service (ONS) to send emails or other notifications
from these events.

Table 11-3 Database Migration Service Event Types

Object Attributes (Common for Event Type Notes

Object)
Agent compartmentName Agent- Create Event triggered by call to
compartmentId DMS API
agentName Agent- Update Event triggered by call to
DMS API
agentId
Agent- Delete Event triggered by call to
DMS API
Agent - State Change Called when state of agent
is changed
Migration compartmentName Migration - Create Event triggered by call to
compartmentId DMS API
migrationName Migration - Clone Event triggered by call to
DMS API
migrationId
Migration - Delete Event triggered by call to
migrationLifecycleState
DMS API
Migration - Evaluate Event triggered by call to
DMS API
Migration - Start Event triggered by call to
DMS API
Migration - Update Event triggered by call to
DMS API
Migration - State Change Called when state of
migration is changed
Job compartmentName Job - Abort Event triggered by call to
compartmentId DMS API
migrationName Job - Delete Event triggered by call to
migrationId DMS API
jobName Job - Resume Event triggered by call to
jobId DMS API
jobType Job - Update Event triggered by call to
jobLifecycleState DMS API
phaseName Job - State Change Called when state of job is
phaseStatus changed
Connection compartmentName Connection - Create Event triggered by call to
compartmentId DMS API
connectionName Connection - Update Event triggered by call to
DMS API
connectionId
Connection - Delete Event triggered by call to
DMS API

11-11
 Chapter 11
Database Migration Port Requirements

Table 11-3 (Cont.) Database Migration Service Event Types

Object Attributes (Common for Event Type Notes

Object)
Phase compartmentName Phase - Begin Called at the start of a
compartmentId phase
migrationName Phase - End Called at the end of a
phase
migrationId
jobName
jobId
phaseName
phaseStatus

Table 11-4 Example Use Cases

Description Event Type Attribute Filters Event Action

Start a process when Migration - Start migrationName=XYZ Function or Streaming
Migration XYZ is started
Start a function for a given Job - State Change jobId=job_OCID Function
job after the Data Pump file jobLifecycleState=PAUSED
is uploaded and before
phaseName=ZDM_UPLOA
import starts (You must
D_DATAPUMP_DUMP_FIL
also configure a pause
ES
after phase
ZDM_UPLOAD_DATAPUMP_D
UMP_FILES, and the
function must call the API
to resume the job)
Send a notification Job - State Change compartmentId=myCompar Notification
whenever a Migration in my tmentIdmigrationLifecycleSt
compartment is failing ate=FAILED
Send a notification when Job - State Change migrationName=XYZ Notification
Migration XYZ starts jobLifecycleState=PAUSED
waiting on replication
phaseName=ZDM_MONIT
OR_GG_LAG
Send a notification when Phase - Begin migrationName=XYZ Notification
Migration XYZ starts Data phaseName=ZDM_DATAP
Pump export UMP_EXPORT

For information about the migration job phases, see Database Migration Job Phases.

Database Migration Port Requirements

The ports required for communication when using Oracle Cloud Infrastructure
Database Migration are described in the following table.

11-12
 Chapter 11
Database Migration Port Requirements

Table 11-5 Database Migration Communication Ports

Initiator Target Protocol Port Purpose

Source database Oracle Cloud SSL 443 This port allows
servers Object Store Data Pump dumps
Service to be uploaded to
Oracle Cloud
Storage
Database Oracle TCP 1522 Allow Oracle client
Migration Autonomous connections to the
Database database over
Serverless target Oracle's SQL*Net
protocol
Database Oracle TCP 2484 Allow Oracle client
Migration Autonomous connections to the
Database on database over
Dedicated Exadata Oracle's SQL*Net
Infrastructure protocol
target

11-13
 Chapter 11
Database Migration Port Requirements

Table 11-5 (Cont.) Database Migration Communication Ports

Initiator Target Protocol Port Purpose

Database Source and target TCP 22 SSH
Migration agent database servers Authentication-
service host based operations
to run Database
Migration
operational phases
Source and target
database servers
should accept
incoming
connections from
the Database
Migration agent
service host
Not applicable to
Autonomous
Database targets

N
o
t
e
:
R
e
q
u
i
r
e
d
o
n
l
y
f
o
r
S
S
H
c
o
n
n
e
c
t

11-14
 Chapter 11
Database Migration Port Requirements

Table 11-5 (Cont.) Database Migration Communication Ports

Initiator Target Protocol Port Purpose

i
o
n
.

Target database Source database TCP 1521 or a database Should allow

servers servers SCAN Listener Oracle client
port applicable connections to the
database over
Oracle's SQL*Net
protocol
Allows redo log
shipping if source
database needs to
be in sync with the
new primary on
Oracle Cloud after
switchover.
Note: If you are
using a non-default
port number (that
is, something other
than port 1521) for
the local listener
address, then the
non-default port
should allow
connections.

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

Configuring Network Security Rules

If you have Oracle Database or Oracle GoldenGate compute instances in private subnets,
ensure their subnet security rules or network security groups allow traffic required for
Database Migration jobs.
Database Migration allows you to specify a subnet to create a Private Endpoint for Database
Migration Connections (Connections). Refer to steps 9 and 10 in Managing Connections. For
Autonomous Database Connections, the Console pre-populates the subnet field using the
Autonomous Database (ADB) subnet; however, you can use the dropdown list to select a
different subnet. The corresponding Database Migration API is CreateConnection.
1. The following EGRESS security rules must be configured for your subnet specified for
privateEndpointDetails when creating Database Migration connections:

11-15
 Chapter 11
Database Migration Port Requirements

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
SecurityList No Egress All TCP CIDR 1521-1523
(Classless
Inter-Domain
Routing) of
subnet hosting
Co-managed
database or
Oracle
Autonomous
Database
Serverless
SecurityList No Egress All TCP CIDR of 2484
subnet hosting
Oracle
Autonomous
Database on
Dedicated
Exadata
Infrastructure
SecurityList No Egress All TCP CIDR of 22
subnet hosting
Co-managed
database

Not
e:
Req
uire
d
only
for
SS
H
con
nect
ion.

SecurityList No Egress All TCP CIDR of 443

subnet hosting
Oracle
GoldenGate
compute
instance

2. The following INGRESS security rules must be configured for the subnets
hosting your databases or Oracle GoldenGate compute instances:
Subnet Hosting Co-managed System

11-16
 Chapter 11
Database Migration Port Requirements

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
SecurityList No Ingress CIDR of All TCP 1521-1523
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)
SecurityList No Ingress CIDR of All TCP 22
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)

Not
e:
Req
uire
d
only
for
SS
H
con
nect
ion.

Subnet Hosting ADB-S

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
SecurityList No Ingress CIDR of All TCP 1521-1523
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)

Subnet Hosting ADB-D

11-17
 Chapter 11
Database Migration Port Requirements

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
SecurityList No Ingress CIDR of All TCP 2484
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)

Subnet Hosting Oracle GoldenGate Compute Instance

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
SecurityList No Ingress CIDR of All TCP 443
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)
for target
database

3. Additionally, if you have configured Network Security Groups (NSGs) for ADB-S
or Oracle GoldenGate compute instances, then the following INGRESS rules
must be set for the Network Security Groups:
NSG Associated With ADB-S

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
NSG rule No Ingress CIDR of All TCP 1521-1523
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)

NSG Associated With Oracle GoldenGate Compute Instance

11-18
 Chapter 11
Migrating Databases from Amazon Web Services RDS to Oracle Autonomous Database

Rule Type Stateful Direction Source Port Protocol Destination Destination

Range Port Range
NSG rule No Ingress CIDR of All TCP 443
subnet
specified for
PrivateEndpoin
t for Database
Migration
Connection
(Connection)
for target
database

Network security groups (NSGs) are associated with individual virtual network interface cards
(VNIC), ADBs, compute instances, and so on. You can configure INGRESS and EGRESS
NSG rules.
Security lists apply to entire subnet.
You can use both security lists and NSGs. In this case, a union of security list rules and NSG
rules is applied.
For more details, see Comparison of Security Lists and Network Security Groups and If You
Use Both Security Lists and Network Security Groups

Private Endpoint Support

CreateConnection supports the following use cases for databases with private IP addresses:
1. Database is in subnetA and customer specifies subnetB to create a PrivateEndpoint:
• SubnetA must allow INGRESS from subnetB for relevant ports
• SubnetB must allow EGRESS to subnetA for relevant ports
2. Database is in subnetA and customer selects subnetA to create a PrivateEndpoint
• SubnetA’s INGRESS rules must not prohibit subnetA as source for relevant ports
• SubnetA’s EGRESS rules must not prohibit subnetA as destination for relevant ports

Migrating Databases from Amazon Web Services RDS to Oracle

Autonomous Database
You can migrate an Oracle Database from Amazon Web Services (AWS) RDS to Oracle
Autonomous Database (ADB) using the Oracle Cloud Infrastructure Database Migration
offline and online migration methods.

Configuring Secure Connections

Ensure that the subnet Amazon RDS security policy allows connections from Database
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

11-19
 Chapter 11
Migrating Databases from Amazon Web Services RDS to Oracle Autonomous Database

Allowing Database Migration to connect to Amazon RDS Oracle DB instance

using SSL/TLS
1. Enable Secure Socket Layer (SSL) or Transport Layer Security (TLS) in the
Amazon RDS Oracle Instance to secure the connection from Database Migration
to Amazon RDS Oracle Instance. See Encrypting client connections with SSL for
details.
2. Create an orapki wallet as detailed in Updating applications to use new SSL/TLS
certificates.

Configuring a Connection for an Amazon RDS Source

• Find the Amazon RDS Oracle Instance endpoint (DNS name) and port number in
the RDS console DB Instance Connectivity & security tab.
See Finding the endpoint of your Oracle DB instance for detailed help.
• In OCI Database Migration, create the Connection resource for the Amazon RDS
Oracle source database, using the following guidelines.
– In the Database Connections wizard, Database details step, select
Manually configure database, choose Amazon RDS in the Database type
list, and enter the full connect string with host, port, and service name in the
following format:
host:port/db-service-name
– In the Connection details step, enter the database administrator credentials
for the Amazon RDS Oracle source database. The user must have full Data
Pump Export privileges.
If you intend to use a database link to transfer the data, also set the TLS
parameters.

Configuring a Migration Resource with an Amazon RDS Source

To transfer the data from AWS, you have the following options:
• Amazon Simple Storage Service (Amazon S3) Bucket
• Database link
When you create the Migration resource, in the Migration options step configure one
of the initial load settings as follows.
• Datapump via database link: Enable this option to use a direct SQL*Net
connection between the source and target databases. Note that using Data Pump
with a database link to Autonomous Database targets requires that the source
database be set up with SSL encryption.
To use a database link to migrate Amazon RDS Oracle Database schema to
Oracle Autonomous Database (ADB), you must have direct network connectivity
between the Amazon RDS Oracle instance and the ADB target.
• Datapump via object storage: This option lets you select the Amazon S3
bucket option to let Data Pump temporarily store the exported database in an
Amazon S3 bucket.
Enter the details for the Amazon S3 bucket. This option is only shown if the source
Connection is of type Amazon RDS.

11-20
 Chapter 11
Migrating Databases from Amazon Web Services RDS to Oracle Autonomous Database

The bucket Name must be between 3 and 63 characters, and can consist only of lower
case letters, numbers, dots (.), and hyphens (-). It must begin and end with a letter or
number.
The Region must be in the same region as the RDS Oracle database. For example us-
east-1
Note that you must also configure the OCI Object Storage bucket so that Database
Migration can store Cloud Pre-migration Advisor Tool reports, Database Migration logs,
and Data Pump logs there.

11-21