Learn About Migrating x86 Databases to Oracle Exadata Database Service on Cloud@Customer
Migrate your x86 Oracle database workloads to Oracle Exadata Database Service on Cloud@Customer to consolidate to a high-performance database platform. Using Oracle Zero Downtime Migration, automate your migration while experiencing minimal downtime when migrating your data from on-premises to the cloud. Oracle Exadata Database Service on Cloud@Customer keeps data on premise to meet regulatory and customer data residency requirements. Start your journey inside your data center, behind your firewall.
Architecture
This architecture shows a migration from an x86 database server to Oracle Exadata Database Service on Cloud@Customer. An Oracle ZFS Storage Appliance (NAS) is used during migration for intermediate storage. Oracle Zero Downtime Migration software performs the logical or physical migration to Oracle Exadata Database Service on Cloud@Customer. Use this diagram to understand the migration process.
Before You Begin
Before you begin, ensure these requirements are met:
-
Ensure the source database is running Linux 7.9, on Oracle Database version 19C or above.
-
The target database must be Oracle Exadata Database Service on Cloud@Customer X8 or above, on Oracle Database version 19C or above.
- Zero Downtime Migration must be version 21.3 or above.
-
Intermediate storage Oracle ZFS Storage Appliance (NAS) .
Review Documentation
This solution playbook provides instructions for performing your migration. You may find these additional resources helpful for context, details, and reference.
- Oracle Zero Downtime Migration
- Oracle Zero Downtime Migration Video
- Oracle Zero Downtime Physical Migration Step-By-Step Guide
- "Zero Downtime Migration Physical Migration Parameters" in Move to Oracle Cloud Using Zero Downtime Migration Guide
- "Setting Logical Migration Parameters" in Move to Oracle Cloud Using Zero Downtime Migration Guide
About Required Services and Roles
This solution requires the following services:
- Zero Downtime Migration Server
- Oracle Database x86 Server
- Oracle Cloud Infrastructure Identity and Access Management
- Oracle Exadata Database Service on Cloud@Customer
These are the roles needed for each service.
Service Name: Role | Required to... |
---|---|
Zero Downtime Migration Server: zdmuser |
Run Zero Downtime Migration |
Oracle Database X86 Server: sudoer user |
|
Oracle Database X86 Server: sys |
Back up data using Oracle Recovery Manager (RMAN) for physical migrations |
Oracle Cloud Infrastructure Identity
and Access Management: OCI_user |
Create API authorization tokens for logical migrations |
Oracle Exadata Database Service
on Cloud@Customer: Database Admin |
Create a target Oracle Exadata Database Service on Cloud@Customer database |
Oracle Exadata Database Service
on Cloud@Customer VM Cluster Nodes: opc (sudoer user) |
|
See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.
About Logical and Physical Migrations
Oracle Zero Downtime Migration supports two types of database migrations from x86 to Oracle Exadata Database Service on Cloud@Customer: Logical Migration and Physical Migration.
Logical Migrations use a combination of Oracle Data Pump and Oracle GoldenGate, while physical migrations use a combination of Oracle Recovery Manager (RMAN) and Oracle Data Guard. The following table explains the scenarios in which a logical or physical migration should be used.
Logical Migrations | Physical Migrations |
---|---|
Recommended when a few pluggable databases and/or schemas are migrated. | Recommended when full databases are migrated. For example, container databases with all pluggable databases, or lift and shift. |
Selective pluggable databases (PDBs) and/or schemas can be migrated. | Container databases will be migrated to container databases, and non-container databases will be migrated to non-container databases. |
Sys password on the source and target can be different. Database names between the source and target can be different.
|
Sys password and database name on both the source and target should be identical. DB_UNIQUE_NAME on the source and target must be different.
|
Databases can be upgraded during migration. | Databases cannot be upgraded as part of migration. |