Migrate an On-Premises Oracle Database Deployment to an Autonomous Database

Simplify your database provisioning, maintenance, and management operations by moving your on-premises deployment of Oracle Database Enterprise Edition to an Oracle Autonomous Transaction Processing database in Oracle Cloud Infrastructure. Oracle Autonomous Transaction Processing delivers a self-driving, self-securing, self-repairing database service that can instantly scale to meet the demands of your mission-critical applications.

Architecture

This architecture shows the resources and topology required to migrate an on-premises deployment of Oracle Database Enterprise Edition to an Oracle Autonomous Transaction Processing database provisioned on shared Exadata infrastructure in Oracle Cloud.

Description of migrate-atp.png follows
Description of the illustration migrate-atp.png

The architecture has the following components:

  • On-premises deployment

    The on-premises deployment includes an application server running on a 4-core Intel server and Oracle Database Enterprise Edition on a 16-core Intel server. The database server is connected to a storage device. The on-premises network is connected to an Oracle Cloud region using Oracle Cloud Infrastructure FastConnect or IPSec VPN. The architecture assumes that the on-premises servers are running Oracle Linux.

  • Region

    A region is a localized geographic area composed of one or more availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you place Compute instances across multiple fault domains, applications can tolerate physical server failure, system maintenance, and many common networking and power failures inside the availability domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a software-defined network that you set up in an Oracle Cloud Infrastructure region. VCNs can be segmented into subnets, which can be specific to a region or to an availability domain. Both region-specific and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.

    In this architecture, the application tier and the Oracle Autonomous Transaction Processing database are isolated in separate private subnets within a single VCN.

  • Route tables

    Virtual route tables contain rules to route traffic from subnets to destinations outside the VCN, typically through gateways.

    This architecture uses a route rule to send traffic from the database subnet to Oracle Cloud Infrastructure Object Storage through the service gateway. If you plan to take manual backups of your database, then this rule is required.

  • Security lists

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

    This architecture uses ingress and egress rules in the security lists attached to the application server and database subnets. These rules enable connectivity between the application and database. Ingress rules are temporarily added in the security lists attached to the application server and database server subnets during migration, for transferring application files, shell scripts, and configuration data.

  • Dynamic routing gateway

    The dynamic routing gateway provides a path for private network traffic between the VCN and the on-premises network. You can also use it for private connectivity between VCNs in different regions.

  • Service gateway

    The service gateway provides access from the VCN to other services, such as Oracle Cloud Infrastructure Object Storage.

  • Block volumes

    With block storage volumes, you can create, attach, connect, and move storage volumes, and change volume performance to meet your storage, performance, and application requirements. After you attach and connect a volume to an instance, you can use the volume like a regular hard drive. You can also disconnect a volume and attach it to another instance without losing data.

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

  • Database system

    The on-premises database is migrated to a 16-core Oracle Autonomous Transaction Processing database provisioned on shared Exadata infrastructure.

  • Application server

    The on-premises application server is migrated to a 4-core compute instance.

Recommendations

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

  • Compute shapes

    This architecture uses an Oracle Linux compute instance with a VM.Standard2.4 shape for the application server. If the application needs more processing power, memory, or network bandwidth, then choose a larger shape.

  • Block volumes

    This architecture uses a 100-GB block volume for the application server. You can use the volume for installing the application, or to store application logs and data.

  • Database

    This architecture uses an Oracle Autonomous Transaction Processing database on shared Exadata infrastructure, with 16 cores enabled at provisioning time. You can enable autoscaling to give the database workloads up to three times the processing power.

    If you need self-service capability within a private database environment running in the public cloud, consider using Oracle Autonomous Transaction Processing on dedicated Exadata infrastructure.

  • VCN

    When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.

    Select an address range that doesn’t overlap with your on-premises network, so that you can set up a connection between the VCN and your on-premises network using Oracle Cloud Infrastructure FastConnect or IPSec VPN.

    After you create a VCN, you can't change its address range.

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

    Use separate regional private subnets for the application tier and the database.

  • Database migration method

    In this reference architecture, the Move to Autonomous Database (MV2ADB) tool is used to migrate data from an on-premises Oracle Database Enterprise Edition deployment to an Oracle Autonomous Transaction Processing database.

    MV2ADB uses Oracle Data Pump. A single command (mv2adb auto) exports data from the specified source database to Oracle Cloud Infrastructure Object Storage, and then loads the data to the Oracle Autonomous Transaction Processing database.

    The following are the prerequisites to use MV2ADB:
    • HTTP connectivity between your on-premises data center and Oracle Cloud Infrastructure Object Storage.
    • SQL*Net connectivity between the on-premises data center and the Oracle Autonomous Transaction Processing database. Consider using Oracle Cloud Infrastructure FastConnect or IPSec VPN.
    • The client credentials wallet for the Oracle Autonomous Transaction Processing database. Download the wallet and copy it to the source database server.
    • The following tools and utilities on the source database server:
      • The latest version of Oracle Instant Client.
      • The latest version of the Oracle Cloud Infrastructure CLI.
      • The java executable. Make sure that the path is specified in the user's PATH variable.
      • Perl release 5.10 or higher.
      • The Perl Data::Dumper module.
    Here's an overview of the data migration process:
    1. You first create a bucket in Oracle Cloud Infrastructure Object Storage by using either mv2adb createbucket, the Oracle Cloud Infrastructure CLI, or any other interface.
    2. Then, you load the data to Oracle Autonomous Transaction Processing database by using the mv2adb auto command.
      The command performs the following tasks:
      1. Exports data from the source database (schema-based).
      2. Uploads the dump files to the specified bucket in Oracle Cloud Infrastructure Object Storage.
      3. Imports data from Oracle Cloud Infrastructure Object Storage to the Oracle Autonomous Transaction Processing database.

      If required, you can perform these tasks individually, by using the mv2adb operations expdp, putdump, and impdp, respectively.

      Note:

      To minimize the time required to migrate data from large databases, use Oracle Cloud Infrastructure FastConnect.

Considerations

  • Scalability
    • Application tier:

      You can scale the application server vertically by changing the shape of the compute instance. A shape with a higher core count provides more memory and network bandwidth as well. If more storage is required, increase the size of the block volumes attached to the application server.

    • Database tier

      You can scale the database vertically by enabling additional cores for the Oracle Autonomous Transaction Processing database. Both the cores and storage can be scaled up without any database downtime.

  • Availability

    Fault domains provide the best resilience for workloads deployed within a single availability domain. This architecture doesn’t show redundant resources, because the focus is on the migration approach. For high availability in the application tier, deploy the application servers in different fault domains, and use a load balancer to distribute client traffic across the application servers.

    The Oracle Autonomous Transaction Processing database provides high availability for the database tier.

  • Cost
    • Application tier

      Select the compute shape based on the cores, memory, and network bandwidth that your application needs. You can start with a 4-core shape for the application server. If you need more performance, memory, or network bandwidth, you can change to a larger shape.

    • Database tier

      For Oracle Autonomous Transaction Processing with shared Exadata infrastructure, the CPU and storage usage are billed by the second.

      You can either pay for the required database licenses or bring your own licenses (BYOL).

Deploy

The Terraform code to deploy the target cloud topology is available on GitHub. You can use the code to provision the required networking resources, a compute instance for the application server, and an Oracle Autonomous Transaction Processing database.

  1. Go to GitHub.
  2. Download the code to your local computer.
  3. Complete the prerequisite steps described in the README.
  4. Apply the configuration using the Terraform CLI.