Move to Oracle Database@Azure with Oracle Zero Downtime Migration

Oracle Database@Azure enables you to run your mission-critical Oracle databases on Oracle Exadata Database Service on Dedicated Infrastructure in Microsoft Azure datacenter.

Take advantage of the built-in high availability, performance, and scalability provided by Oracle Exadata Database Service and Oracle Real Application Clusters (Oracle RAC) while benefiting from low-latency to your Azure applications.

Database migration to the cloud is usually a manual process associated with downtime for your business. Oracle Zero Downtime Migration simplifies and automates Oracle database migrations with zero to minimal downtime, incorporates Oracle Maximum Availability Architecture (Oracle MAA) best practices by default, supports fleet migrations, and is free of charge, among other benefits.

Since its release in 2019, Oracle Zero Downtime Migration has been the trusted migration tool for customers worldwide for Oracle database migrations to on-premises Oracle Exadata machines, Oracle Exadata Database Service on Cloud@Customer, and Oracle Cloud Infrastructure (OCI). See Explore More to learn more about Oracle Zero Downtime Migration.

Architecture

This reference architecture describes Oracle Database migrations from on-premises to Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure using the physical online migration workflow based on Oracle Data Guard and direct data transfer, providing simplicity, automation, and business continuity during your database migrations to Oracle Database@Azure.

The Oracle Zero Downtime Migration service host is installed on a separate on-premises virtual machine (VM) next to the source database. The target Oracle Exadata Database Service on Dedicated Infrastructure is provisioned in Azure’s data center within the Azure Virtual Network (VNet) in a delegated subnet to Oracle Database@Azure. The on-premises data center is connected to Azure’s data center via Azure ExpressRoute or site-to-site VPN. The Oracle Zero Downtime Migration physical online workflow based on direct data transfer creates the target database by using the restore from a service method and avoids backing up the source database to an intermediate storage location. Oracle Zero Downtime Migration automatically leverages Oracle Data Guard to replicate the data from the on-premises database to the target database. Oracle Zero Downtime Migration automatically sets up Oracle Data Guard, maintains it, and cleans up the configuration after the migration completes. Hence, knowledge in setting up and maintaining Oracle Data Guard is not required. After the migration completes, the target database can use the Automatic Backup feature to back up the database into Oracle Database Autonomous Recovery Service.

The following diagram illustrates this reference architecture.



oracle-db-azure-zdm-oracle.zip

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • On-premises network

    This network is the local network used by your organization. It is one of the spokes of the topology.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.

  • Site-to-Site VPN

    Site-to-Site VPN provides IPSec VPN connectivity between your on-premises network and VCNs in Oracle Cloud Infrastructure. The IPSec protocol suite encrypts IP traffic before the packets are transferred from the source to the destination and decrypts the traffic when it arrives.

  • VNIC

    A virtual network interface card (VNIC) enables an instance to connect to a VCN and determines how the instance connects with endpoints inside and outside the VCN. Each VNIC resides in a subnet in a VCN and includes these items:

    • A primary private IPv4 address from the subnet the VNIC is in, chosen by either you or Oracle.
    • Optional secondary private IPv4 addresses from the same subnet the VNIC is in, chosen by either you or Oracle.
    • An optional public IPv4 address for each private IP, chosen by Oracle but assigned by you at your discretion.
    • An optional hostname for DNS for each private IP address.
    • A MAC address.
    • A VLAN tag assigned by Oracle and available when attachment of the VNIC to the instance is complete (relevant only for bare metal instances).
    • A flag to enable or disable the source/destination check on the VNIC's network traffic.
    • Optional membership in one or more network security groups (NSGs) of your choice. NSGs have security rules that apply only to the VNICs in that NSG.
    • Optional IPv6 addresses. IPv6 addressing is supported for all commercial and government regions.
  • Data Guard

    Oracle Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to remain available without interruption. Oracle Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage.

  • Exadata Database Service

    Oracle Exadata Database Service enables you to leverage the power of Exadata in the cloud. You can provision flexible Exadata X9M systems that allow you to add database compute servers and storage servers to your system as your needs grow. Exadata X9M systems offer RDMA over Converged Ethernet (RoCE) networking for high bandwidth and low latency, persistent memory (PMEM) modules, and intelligent Exadata software. You can provision Exadata X9M systems by using a shape that's equivalent to a quarter-rack X9M system, and then add database and storage servers at any time after provisioning.

    Oracle Exadata Database Service on Dedicated Infrastructure provides Oracle Exadata Database Machine as a service in an Oracle Cloud Infrastructure (OCI) data center. The Oracle Exadata Database Service on Dedicated Infrastructure instance is a virtual machine (VM) cluster that resides on Exadata racks in an OCI region.

    Oracle Exadata Database Service on Cloud@Customer provides Oracle Exadata Database Service that is hosted in your data center.

  • Object storage

    Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.

  • Azure VNIC

    The services in Azure data centers have physical network interface cards (NICs). Virtual machine instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that's automatically created and attached during launch and is available during the instance's lifetime.

  • Azure Virtual Network Gateway

    Azure Virtual Network Gateway is a service that establishes secure, cross-premises connectivity between an Azure virtual network and an on-premises network. It allows you to create a hybrid network that spans your datacenter and Azure.

  • Azure Delegated subnet

    Subnet delegation is Microsoft's ability to inject a managed service, specifically a platform-as-a-service service, directly into your virtual network. This means you can designate or delegate a subnet to be a home for an external managed service inside your virtual network. In other words, that external service will act as a virtual network resource, even though it technically is an external platform-as-a-service service.

  • Azure Virtual Network

    Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many Azure resources, such as Azure virtual machines, to securely communicate with each other, the internet, and on-premises networks.

  • Zero Downtime Migration service host

    The Oracle Zero Downtime Migration service host should be a dedicated system, but it can be shared for other purposes.

    Oracle Zero Downtime Migration software requires a standalone Oracle Linux host running on any one of the following platforms: Oracle Linux 7, Oracle Linux 8, or Red Hat Enterprise Linux 8.

    The Oracle Zero Downtime Migration service host must be able to connect to the source and the target database servers; as long as connectivity is guaranteed, the service host can be located anywhere.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.
  • Download the latest Oracle Zero Downtime Migration software version from My Oracle Support (MOS) by searching for patch number 33509650 in the Patches & Updates tab.
  • Install the Oracle Zero Downtime Migration service host on-premises next to your source database.
  • Ensure the Oracle Zero Downtime Migration service host has at least 100GB of free storage.
  • Ensure secure and private network connectivity between on-premises and Azure via site-to-site VPN or Azure ExpressRoute.
  • Depending on your database size, ensure sufficient network throughput from your on-premises network to Azure.

Considerations

Consider the following points when deploying this reference architecture.

  • The target database must:
    • Be provisioned using Oracle Cloud tooling without enabling automatic backups.
    • Have a time zone file version that is the same or higher than the source database.
  • The source and target databases must:
    • Have the same database name (DB_NAME).
    • Have different database unique names (DB_UNIQUE_NAME).
    • Use a server parameter file (SPFILE).
    • Use the same character set.
    • Have the same encryption algorithm defined in the sqlnet.ora file.
    • Have the same major release version (for example, 19c). However, the target database could have a higher patch level (for example, source at 19.21 and target at 19.22). If the target database is at a higher patch level than the source database, Oracle Zero Downtime Migration automatically runs datapatch as part of the migration.
  • The SYS user account password must be the same on the source and target databases.
  • The COMPATIBLE database initialization parameter must be the same on the source and target databases.
  • For Oracle Database 12c Release 2 and later, the TDE wallet must exist on the source and the wallet status must be in the OPEN state. The source database does not necessarily need to be encrypted, but a TDE wallet must be configured.
  • Oracle Zero Downtime Migration requires the SSH key on the Oracle Zero Downtime Migration service host to be in RSA format (in Oracle Linux 8, the default is OPENSSH).

Acknowledgments

  • Authors: Sinan Petrus Toma, Ricardo Gonzalez, Thomas Van Buggenhout
  • Contributors: Emiel Ramakers, Wei Han, John Sulyok