Domain 7: Migrate Oracle Databases to OCI Database Services (20%)

Domain 7 is the second-heaviest domain on the OCI 2025 Migration Architect Professional exam (1Z0-1123-25), representing approximately 10 questions. It covers the full spectrum of Oracle database migration strategies, tools, and services. You must know when to use each migration method, understand the tradeoffs between physical and logical approaches, and be able to design end-to-end migration plans for various source environments.

1. OCI Database Services Overview

Before selecting a migration method, you must know what target services are available and which workloads they serve. (OCI Database Overview)

Exam trap: Autonomous Database targets require logical migration methods (Data Pump, GoldenGate). You cannot use RMAN backup/restore or Data Guard standby to migrate directly to ADB-S. Physical migration methods (RMAN, Data Guard) work with ExaDB-D, ExaDB-C@C, and Base Database Service targets.

2. Physical vs. Logical Migration

Every migration method falls into one of two categories. Understanding this distinction is fundamental to every decision on this exam.

(Oracle Database Migration Technologies)

Exam trap: "Physical migration is always faster" is generally true for data transfer speed, but Data Guard physical migration achieves lower downtime than a full RMAN restore because it uses redo apply to stay synchronized. Do not confuse transfer speed with downtime.

3. RMAN-Based Migration

RMAN (Recovery Manager) is Oracle's native backup and recovery utility. For migration, it creates a physical copy of the database that can be restored on OCI. (Migrate with RMAN)

3.1 Migration Patterns

3.2 Oracle Database Cloud Backup Module

This module provides an SBT (System Backup to Tape) interface that integrates RMAN with OCI Object Storage. It requires:

• JDK 1.7+
• OCI Object Storage bucket
• Authentication credentials (tenancy OCID, user OCID, API key fingerprint, private key file)
• The libopc.so (Linux) or libopc.dll (Windows) SBT library

Configuration: CONFIGURE CHANNEL DEVICE TYPE SBT PARMS='SBT_LIBRARY=/path/libopc.so,SBT_PARMS=(OPC_PFILE=/path/opc_config.ora)'

(Back Up a Database to Object Storage Using RMAN)

3.3 Key Considerations

• Downtime: Source database must be quiesced for the final incremental backup and RESETLOGS open on target. Downtime proportional to the final incremental size.
• Incremental strategy: Take a full backup first, then incremental backups. Restore full + apply incrementals. Final incremental captures last changes before cutover.
• Encryption: RMAN backups to Object Storage should be encrypted. Use SET ENCRYPTION ON with a password or use TDE wallet-based encryption.
• Cross-platform: RMAN supports cross-platform migration using CONVERT DATABASE or CONVERT DATAFILE, but source and target must have compatible endianness (or explicit conversion).

Exam trap: RMAN backup to Object Storage does NOT require VPN or FastConnect. The Cloud Backup Module uses HTTPS over the public internet. This makes it viable even without dedicated connectivity.

4. Data Pump Export/Import

Oracle Data Pump (expdp/impdp) is a logical migration tool that exports database objects as dump files and imports them into a target database. (Data Pump Migration Methods)

4.1 Export Modes

4.2 Data Transfer Methods

4.3 Parallel Execution and Tuning

Parallelism is the primary performance lever for Data Pump.

4.4 Key Considerations

• Cross-version: Data Pump supports importing from lower versions to higher versions. You can export from 11.2 and import into 19c.
• Character set: Data Pump handles character set conversion, but verify compatibility to avoid data loss.
• No ongoing sync: Data Pump is a point-in-time export. Changes after the export begins are NOT captured (unlike GoldenGate).
• Downtime: Proportional to database size. For large databases, downtime can be significant.

Exam trap: Network link Data Pump (NETWORK_LINK) transfers data directly without dump files, but performance depends entirely on network bandwidth for the entire duration. Oracle recommends Object Storage transfer for databases over 50 GB because parallelism is better. (OCI DMS Documentation)

5. Multitenant Architecture Migration (PDB)

Oracle Multitenant (12c+) provides two migration methods unique to the pluggable database architecture. (Remote PDB Cloning)

5.1 Remote Cloning (PDB Clone Over DB Link)

Remote cloning creates a copy of a PDB from a source CDB to a target CDB using a database link.

Steps:

1. Create a database link on the target CDB pointing to the source CDB
2. Execute CREATE PLUGGABLE DATABASE target_pdb FROM source_pdb@dblink
3. The target CDB copies all datafiles over the network

Hot Cloning (12.2+): If the target CDB is in ARCHIVELOG mode and LOCAL UNDO mode, the source PDB can remain open read/write during cloning. No downtime required for the clone operation itself.

Prerequisites:

• Same endianness (both little-endian for OCI)
• Compatible character sets
• Same or compatible database options installed
• CREATE PLUGGABLE DATABASE privilege on the DB link user
• SQL*Net connectivity between source and target

OCI API support: Remote cloning can be initiated via OCI Console, CLI, SDKs, or Terraform using the RemoteClonePluggableDatabase API.

5.2 Unplug/Plug (PDB Relocation)

Unplug/Plug physically moves a PDB's datafiles from one CDB to another.

Steps:

1. Close the PDB on the source CDB: ALTER PLUGGABLE DATABASE pdb CLOSE
2. Unplug the PDB: ALTER PLUGGABLE DATABASE pdb UNPLUG INTO '/path/pdb.xml'
3. Copy the PDB datafiles and the XML manifest to OCI (Object Storage, NFS, or direct copy)
4. Plug into the target CDB: CREATE PLUGGABLE DATABASE pdb USING '/path/pdb.xml'
5. Run compatibility checks and open the PDB

Key constraints:

• Source platform must be little-endian (or use RMAN CONVERT for endian conversion)
• Oracle Database 12c or higher required
• Source and target must be same or compatible database version
• PDB must be closed during unplug (downtime required)

Exam trap: Unplug/Plug requires the PDB to be CLOSED before unplugging. Remote Cloning (12.2+ hot clone) does NOT require the source PDB to be closed. If the question asks about "minimal downtime PDB migration," the answer is remote cloning with hot clone, not unplug/plug.

6. Data Guard for Migration

Oracle Data Guard maintains a synchronized standby database using redo transport and apply. When used for migration, the OCI database starts as a standby and becomes the primary via switchover. (Hybrid Data Guard Configuration)

6.1 Migration Architecture

On-Premises Primary  ──── redo transport ────▶  OCI Standby
     (source)               (FastConnect/VPN)        (target)
                                                       │
                          switchover ◀────────────────┘
                                                       │
OCI Primary (new)    ◀─── role transition ────  On-Prem Standby (fallback)

6.2 Steps

1. Provision target: Create a database on OCI (ExaDB-D, Base DB VM/BM) with the same version, character set, and options as the source
2. Network configuration: Establish FastConnect or VPN connectivity; configure SQL*Net (port 1521) between primary and standby
3. Instantiate standby: Use RMAN DUPLICATE ... FOR STANDBY FROM ACTIVE DATABASE or restore from backup
4. Enable redo transport: Configure LOG_ARCHIVE_DEST_n to ship redo to the OCI standby
5. Apply redo: Enable managed recovery process (MRP) on the standby to apply redo in real time
6. Validate synchronization: Confirm no apply lag using V$DATAGUARD_STATS
7. Switchover: Execute ALTER DATABASE SWITCHOVER TO target_db (Data Guard Broker: SWITCHOVER TO target_db)
8. Post-switchover: The OCI database is now primary. The on-premises database becomes a standby (fallback option)

6.3 Key Considerations

Exam trap: Data Guard switchover is a planned, graceful role transition with zero data loss. Failover is an unplanned transition (used in disaster recovery) that may lose data depending on protection mode. For migration, you always use switchover, not failover.

7. GoldenGate for Zero-Downtime Migration

Oracle GoldenGate provides real-time data replication for zero-downtime (or near-zero-downtime) migration. It is the only method that supports heterogeneous databases, cross-version migration, and continuous bidirectional replication. (Oracle GoldenGate)

7.1 Architecture Components

7.2 Migration Pattern

1. Initial Load: Full export of source data to target (via Data Pump, RMAN, or GoldenGate direct load)
2. Change Data Capture: Extract captures ongoing changes from source redo logs starting from the SCN of the initial load
3. Apply changes: Replicat applies trail data to the target, keeping it synchronized
4. Cutover: When apply lag reaches near-zero, stop application writes to source, let Replicat drain remaining changes, switch application connections to target

7.3 OCI GoldenGate Service

OCI GoldenGate is a fully managed service. Key facts:

• No infrastructure to provision or manage
• Supports Oracle-to-Oracle and heterogeneous replication (Oracle to MySQL, PostgreSQL, Kafka, etc.)
• Integrates with OCI Vault for credential storage
• Auto-scaling and high availability built in
• Supports bidirectional replication for active-active configurations
• Replicates DDL operations by default

7.4 Key Considerations

Exam trap: GoldenGate requires supplemental logging on the source. Without it, GoldenGate cannot capture enough information to replicate DML operations. This is a prerequisite that candidates forget.

8. OCI Database Migration Service (DMS)

OCI Database Migration (DMS) is a fully managed service that automates database migration to OCI. It is internally driven by Zero Downtime Migration (ZDM) but abstracts the complexity behind a console-based workflow. (OCI Database Migration Overview)

8.1 Architecture

┌──────────────────────┐      ┌─────────────────────────────┐
│  DMS Service Tenancy │      │     Customer Tenancy         │
│  (Oracle-managed)    │      │                              │
│                      │ PE   │  ┌─────────┐   ┌─────────┐  │
│  ZDM Engine ─────────┼──────┤  │ Source   │   │ Target  │  │
│                      │      │  │ DB Conn  │   │ DB Conn │  │
│                      │      │  └─────────┘   └─────────┘  │
│                      │      │       │              │       │
│                      │      │  ┌────┴────┐  ┌─────┴────┐  │
│                      │      │  │ Source   │  │  Target  │  │
│                      │      │  │ Database │  │ Database │  │
│                      │      │  └─────────┘  └──────────┘  │
│                      │      │                              │
│                      │      │  ┌──────────────────────┐   │
│                      │      │  │ OCI GoldenGate       │   │
│                      │      │  │ (online migrations)  │   │
│                      │      │  └──────────────────────┘   │
│                      │      │                              │
│                      │      │  ┌──────────────────────┐   │
│                      │      │  │ Object Storage /     │   │
│                      │      │  │ DB Link (data xfer)  │   │
│                      │      │  └──────────────────────┘   │
└──────────────────────┘      └─────────────────────────────┘

• DMS runs in Oracle's service tenancy, not the customer's
• Communicates with customer resources via Private Endpoints (PEs)
• Uses OCI Vault to store database credentials securely
• Data flows through GoldenGate and Data Pump within the customer tenancy

8.2 Migration Types

8.3 Migration Lifecycle

8.4 Supported Sources and Targets

8.5 Data Transfer Medium

Exam trap: DMS is internally driven by ZDM, but you do NOT need to install or configure ZDM yourself. DMS is a managed service. If the question asks about a "fully managed, console-driven migration service," the answer is DMS, not ZDM. ZDM is the installable tool you run on your own host.

9. Zero Downtime Migration (ZDM)

ZDM is an installable migration tool (not a managed service) that orchestrates end-to-end database migration using MAA best practices. It supports both physical and logical workflows. (ZDM Documentation)

9.1 ZDM vs. DMS

9.2 Workflow Matrix

9.3 ZDM Service Host Requirements

9.4 Supported Database Versions

ZDM supports source databases from 11.2.0.4 through 26ai. Physical workflows require version compatibility between source and target. Logical workflows allow cross-version migration.

Exam trap: ZDM physical online workflow uses Data Guard under the hood. ZDM logical online workflow uses GoldenGate under the hood. If a question describes a "ZDM physical migration with near-zero downtime," the underlying technology is Data Guard, not GoldenGate.

10. Pre-Migration Assessment and Workload Analysis

10.1 AWR and ADDM

Before migration, analyze the source database workload to select the right OCI target and size it correctly.

Best practice: Collect AWR snapshots spanning 3-6 months (covering peak and off-peak periods) before planning migration. Use ADDM findings to identify performance issues that should be resolved BEFORE migration, not after.

10.2 Sizing Guidance

Exam trap: Size for the 80th percentile workload, not the absolute peak. OCI allows scaling up for occasional peaks. Over-provisioning wastes money; under-provisioning causes performance issues during migration validation.

11. Migration Method Selection Decision Tree

Use this decision matrix to select the appropriate migration method. This is heavily tested on the exam.

Decision Criteria

1. Is the TARGET Autonomous Database?
   ├── YES → Logical migration only (Data Pump, GoldenGate, DMS)
   └── NO → Continue to #2

2. Is ZERO (or near-zero) downtime required?
   ├── YES → Data Guard (physical online) or GoldenGate (logical online) or ZDM/DMS online
   └── NO → Continue to #3

3. Is the source platform BIG-ENDIAN (Solaris SPARC, AIX, HP-UX)?
   ├── YES → Logical migration (Data Pump, GoldenGate) or RMAN with CONVERT
   └── NO → Continue to #4

4. Must the migration include a VERSION UPGRADE?
   ├── YES → Logical migration (Data Pump, GoldenGate) or physical + separate upgrade
   └── NO → Continue to #5

5. Is the database a PLUGGABLE DATABASE (12c+)?
   ├── YES → Consider Remote Cloning (hot clone for minimal downtime) or Unplug/Plug
   └── Also consider other methods below

6. Is the database VERY LARGE (multi-TB)?
   ├── YES → RMAN (fastest bulk transfer) or Data Guard (minimal downtime) or
   │         Transportable Tablespaces (hybrid physical+logical)
   └── NO → Data Pump (simplest for smaller databases)

Comprehensive Comparison Table

12. Post-Migration Validation

After migration, validate before decommissioning the source.

12.1 Validation Checklist

12.2 Common Post-Migration Issues

13. Exam Tips and Common Traps

1. ADB = logical only: You cannot use RMAN or Data Guard to migrate directly to Autonomous Database. Data Pump, GoldenGate, or DMS are the only options.

2. DMS vs. ZDM: DMS is a managed service (OCI Console). ZDM is an installable tool (CLI). DMS uses ZDM internally but abstracts it. DMS only supports logical workflows. ZDM supports both physical and logical.

3. Data Guard = physical, near-zero downtime: Data Guard uses redo apply to keep a standby synchronized, then switchover completes in seconds. It requires same version and same endianness.

4. GoldenGate = logical, zero downtime, highest complexity: GoldenGate captures from redo logs and replays transactions. It supports cross-version, cross-platform, and even non-Oracle sources. But it requires supplemental logging and careful Extract/Replicat configuration.

5. Data Pump is NOT zero downtime: Data Pump creates a point-in-time snapshot. Changes after export starts are lost. For large databases, downtime can be hours.

6. Object Storage transfer > DB Link for large databases: Oracle recommends Object Storage for databases over 50 GB because parallelism is better and network dependency is reduced.

7. Physical online ZDM = Data Guard underneath: When ZDM runs a physical online workflow, it is orchestrating Data Guard. When it runs logical online, it is orchestrating GoldenGate.

8. Switchover vs. Failover: Migration uses switchover (planned, zero data loss). Failover is for disaster recovery (unplanned, potential data loss depending on protection mode).

9. Hot clone requires ARCHIVELOG + LOCAL UNDO: Remote PDB cloning without source downtime (hot clone) requires the target CDB to be in ARCHIVELOG mode with LOCAL UNDO mode enabled. Available from 12.2+.

10. Cloud Premigration Advisor Tool (CPAT): Run this before migration to identify incompatible features, unsupported options, and required remediation. It is integrated with ZDM logical workflows.

References

• OCI Database Services Overview
• OCI Database Migration Service
• Migrating Databases to OCI
• Oracle Database Migration Technologies
• Zero Downtime Migration Documentation
• Migrate with RMAN
• Back Up a Database to Object Storage Using RMAN
• Data Guard Hybrid Cloud Configuration
• Hybrid Data Guard to OCI (PDF)
• Remote PDB Cloning on ExaDB-C@C
• Oracle GoldenGate
• OCI GoldenGate Service
• Import Data Using Data Pump on ADB
• Migration Decision Tree
• OCI Ops Insights AWR Hub
• Oracle Database Migration FAQ