1. Learn about deploying on-premises databases on Oracle Cloud using Oracle Exadata Database Service
  2. Plan the Migration

Plan the Migration

The architecture supports multiple migration scenarios.

Consider Migration Options

With Oracle Exadata Database Service or Oracle Database Exadata Cloud at Customer, there are four common deployment models to consider:

  1. Move your large, on-premises database to Oracle Database Exadata Cloud at Customer “as-is” while also providing an OCI disaster recovery (DR) instance connected by Oracle Data Guard.
    Component On Premises Exadata (half rack)
    Database size 47 TB 47 TB
    Cores 24 16
    System Global Area and Program Global Area 4 TB 1.5 TB
  2. Consolidate multiple on-premises databases to multiple pluggable databases (PDBs) on Oracle Exadata Database Service or Oracle Database Exadata Cloud at Customer while also providing an OCI DR instance connected by Oracle Data Guard.
    Component On Premises Exadata (10 full rack)
    Databases 1000 1000
    DB Configuration 2-16 TB per DB CDB = 29

    PDB = 1000 of varying sizes
  3. Run production workloads on-premises using Oracle Database Exadata Cloud at Customer and provide DR or Oracle Exadata Database Service on OCI with the database instances connected by Oracle Data Guard.
    Component On Premises Exadata (half rack)
    Database size 19.5 TB 19.5 TB
    Cores 24 12
    System Global Area and Program Global Area 2.5 TB 1.5 TB
  4. Run production workloads on Oracle Exadata Database Service on OCI and DR using on-premises hardware with the database instances connected by Oracle Data Guard.
    Component On Premises Exadata (half rack)
    Database size 19.5 TB 19.5 TB
    Cores 24 12
    System Global Area and Program Global Area 2.5 TB 1.5 TB

Use Zero Downtime Migration Services

To migrate your large, on-premises databases to Oracle Cloud Infrastructure (OCI), consider using Zero Downtime Migration (ZDM) services.

Whether you're using Oracle Exadata Database Service or Oracle Database Exadata Cloud at Customer, both involve creating a backup of the source database and restoring it to the target database. You then need to run RMAN, perform an Oracle Active Data Guard synchronization, and switch the primary role from the source database over to the target database. Zero Downtime Migration also supports various migration methods, based on your chosen backup medium. The backup medium can be Oracle Cloud Infrastructure Object Storage, Zero Data Loss Recovery Appliance, or network file system (NFS) storage.


Description of exadata-physical-migration-oci.png follows
Description of the illustration exadata-physical-migration-oci.png

The following table shows the requirements and conditions for several Zero Downtime Migration (ZDM) scenarios.

Migration Method Migration Time Downtime Requirement* Oracle Tools Used When to Use
ZDM – Physical Online 8 Hours

2-5 Minutes

(independent of database size)
  • Oracle Cloud
  • ZDM
  • Oracle DataGuard
  • RMAN
  • Source and target DB versions same
  • Non-CDB to PDB
  • Minimal downtime requirement
ZDM – Physical Offline 8 Hours ~8 Hours per TB
  • Oracle Cloud
  • ZDM
  • RMAN
  • Source and target DB versions same
  • Non-CDB to PDB
  • Can afford longer downtime
ZDM – Logical Online 12 Hours

2-5 Minutes

(independent of database size)
  • Oracle Cloud
  • ZDM
  • Oracle GoldenGate
  • Oracle Data Pump
  • RMAN
  • In-flight upgrade
  • Non-CDB to PDB
  • Minimal downtime requirement
  • Cross-platform migration
ZDM – Logical Offline 16 Hours ~16 Hours per TB
  • Oracle Cloud
  • ZDM
  • Oracle Data Pump
  • In-flight upgrade
  • Non-CDB to PDB
  • Source database on AWS RDS
  • Can afford downtime
  • Cross-platform migration

* These downtime numbers are derived from our experience and should be used as overall guidance, not as exact numbers. Downtime requirements can vary greatly, so thorough analysis and testing is necessary before planning any production cutover.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.

  • Cloud Guard

    Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect Object Storage buckets that have visibility set to public.

    Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.

    You can also use the Managed List feature to apply certain configurations to detectors.

  • Security Zones

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

Considerations

When you deploy on-premises databases on Oracle Cloud using Oracle Exadata Database Service, consider the following:

  • Zero Downtime Migration (ZDM)

    ZDM can run on-premises as well as in the cloud. ZDM supports on-premises databases to be migrated to a variety of targets:

    • Oracle Base Database Service
    • Oracle Exadata Database Service on Dedicated Infrastructure
    • Oracle Exadata Database Service Cloud at Customer
    • Oracle Exadata On-Premises
    • Oracle Autonomous Database
      • Oracle Autonomous Transaction Processing (Dedicated and Shared)
      • Oracle Autonomous Data Warehouse (Dedicated and Shared)
  • ZDM and Oracle Cloud Infrastructure Database Migration service (DMS)

    The primary differences between ZDM and DMS are:

    • ZDM works as the main engine supporting most methods/sources/targets and it is based on a command line interface (CLI).

    • DMS uses ZDM under the covers and allows for logical offline/online migration with a user interface to OCI-native database services.

    • Database Migration is a fully-managed service that provides you a high performing, self-service experience for migrating databases to Oracle Cloud Infrastructure (OCI).

    • 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 size

    There are no size restrictions for either ZDM or DMS. The theoretical restriction will be the maximum size of the Oracle Database that your operating system can have. The maximum number of data files and the maximum size of a data file depends on your operating system.

    For a small (<1) terabyte database migration to an Autonomous Database, you can use ZDM logical offline or online method, depending on your downtime requirements. The logical online option requires only a couple of minutes of downtime, whereas the logical offline option takes a few hours of downtime, depending on the size of database.

    For an on-premises database size that is 400 TB or more, the migration will be from on-premises to Oracle Exadata Database Service Cloud at Customer (which will also be at the customer's data center). Use ZDM physical online migration to keep your downtime low and to reduce risk during migration with the use of Data Guard. However, the source and target databases will have to be on same version. If you want to do an in-flight upgrade from a lower version to a higher version, then use the ZDM logical online method. Any offline method will incur large downtime which may not be acceptable for your business.

  • Data Guard and Active Data Guard

    Both Data Guard (DG) and Active Data Guard (ADG) provide a comprehensive set of services that create, maintain, manage and monitor one or more standby databases to enable primary Oracle databases to survive disasters and data corruptions. Standby databases are maintained as copies of the production database. However, with ADG, you can have your standby database open for read-only (for example for reporting purpose) while it is being kept in-sync with the primary database. With DG, you must pause the sync process to open your standby database in read-only mode.

  • Exadata virtualization

    You can virtualize Exadata on a virtual machine or you can perform a bare metal install. The architecture of the options can be significantly different. With a bare metal install, you have one Oracle cluster for an entire Exadata machine, unless you physically partition your Exadata machine. With a virtualized Exadata machine, you have one management domain (dom0) and at least one user domain (domU), depending on the number of VM clusters being deployed.

  • Real Application Testing (RAT)

    See the link in the Explore More section.