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.



migrate-x86-db-exadata-db-cloud-customer.zip

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) .

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
  • Mount network file system share from network attached storage device to backup database
  • Enable passwordless ssh from Zero Downtime Migration server
  • Install Zero Downtime Migration software
  • Run sudo commands to backup or export database
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)
  • Mount network file system share from network attached storage device to restore database
  • Enable passwordless ssh from Zero Downtime Migration server
  • Install Zero Downtime Migration software
  • Run sudo commands to restore or import database

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.