Migrate an on-premises Oracle database to Amazon EC2 by using Oracle Data Pump
Created by Navakanth Talluri (AWS)
Environment: PoC or pilot | Source: On-premises Oracle database | Target: Oracle database on Amazon EC2 |
R Type: Rehost | Workload: Oracle | Technologies: Migration; Databases |
AWS services: Amazon EC2; AWS Direct Connect |
Summary
When migrating databases, you must consider factors such as the source and target database engines and versions, migration tools and services, and acceptable downtime periods. If you’re migrating an on-premises Oracle database to Amazon Elastic Compute Cloud (Amazon EC2), you can use Oracle tools, such as Oracle Data Pump and Oracle Recovery Manager (RMAN). For more information about strategies, see Migrating Oracle databases to the AWS Cloud.
Oracle Data Pump helps you extract the logical, consistent backup of the database and restore it to the target EC2 instance. This pattern describes how to migrate an on-premises Oracle database to an EC2 instance by using Oracle Data Pump and the NETWORK_LINK parameter, with minimal downtime. The NETWORK_LINK parameter starts an import through a database link. The Oracle Data Pump Import (impdp) client on the target EC2 instance connects to the source database, retrieves data from it, and writes the data directly to the database on the target instance. There are no backup, or dump, files used in this solution.
Prerequisites and limitations
Prerequisites
An active AWS account.
An on-premises Oracle database that:
Isn’t an Oracle Real Application Clusters (RAC) database
Isn’t an Oracle Automatic Storage Management (Oracle ASM) database
Is in read-write mode.
You have created an AWS Direct Connect link between your on-premises data center and AWS. For more information, see Create a connection (Direct Connect documentation).
Product versions
Oracle Database 10g release 1 (10.1) and later
Architecture
Source technology stack
A standalone (non-RAC and non-ASM) Oracle database server in an on-premises data center
Target technology stack
An Oracle database running on Amazon EC2
Target architecture
The reliability pillar of the AWS Well-Architected Framework recommends creating data backups to help provide high availability and resiliency. For more information, see Architecting for high availability in Best Practices for Running Oracle Database on AWS. This pattern sets up primary and standby databases on EC2 instances by using Oracle Active Data Guard. For high availability, the EC2 instances should be in different Availability Zones. However, the Availability Zones can be in the same AWS Region or in different AWS Regions.
Active Data Guard provides read-only access to a physical standby database and applies redo changes continuously from the primary database. Based on your recovery point objective (RPO) and recovery time objective (RTO), you can choose between synchronous and asynchronous redo transport options.
The following image shows the target architecture if the primary and standby EC2 instances are in different AWS Regions.
Data migration architecture
After you have finished setting up the target architecture, you use Oracle Data Pump to migrate the on-premises data and schemas to the primary EC2 instance. During cutover, applications can’t access the on-premises database or the target database. You shut down these applications until they can be connected to the new target database on the primary EC2 instance.
The following image shows the architecture during the data migration. In this sample architecture, the primary and standby EC2 instances are in different AWS Regions.
Tools
AWS services
AWS Direct Connect
links your internal network to a Direct Connect location over a standard Ethernet fiber-optic cable. With this connection, you can create virtual interfaces directly to public AWS services while bypassing internet service providers in your network path. Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the AWS Cloud. You can launch as many virtual servers as you need and quickly scale them up or down.
Other tools and services
Oracle Active Data Guard
helps you create, maintain, manage, and monitor standby databases. Oracle Data Pump
helps you move data and metadata from one database to another at high speeds.
Best practices
Epics
| Task | Description | Skills required |
|---|---|---|
Identify the source hardware configuration for the on-premises host and the kernel parameters. | Validate the on-premises configuration, including storage size, input/output operations per second (IOPS), and CPU. This is important for Oracle licensing, which is based on CPU cores. | DBA, SysAdmin |
Create the infrastructure on AWS. | Create the virtual private clouds (VPCs), private subnets, security groups, network access control lists (ACLs), route tables, and internet gateway. For more information, see the following: | DBA, AWS systems administrator |
Set up the EC2 instances by using Active Data Guard. | Configure AWS EC2 instances by using an Active Data Guard configuration, as described in the AWS Well-Architected Framework. The version of Oracle Database on the EC2 instance can be different from the on-premises version because this pattern uses logical backups. Note the following:
For more information, see:
| DBA, AWS systems administrator |
| Task | Description | Skills required |
|---|---|---|
Create a dblink to the on-premises database from the EC2 instance. | Create a database link (dblink) between the Oracle database on the EC2 instance and the on-premises Oracle database. For more information, see Using Network Link Import to Move Data | DBA |
Verify the connection between the EC2 instance and the on-premises host. | Use the dblink to confirm that the connection between the EC2 instance and the on-premises database is functioning. For instructions, see CREATE DATABASE LINK | DBA |
Stop all applications connected to the on-premises database. | After the database downtime is approved, shut down any applications and dependent jobs that connent to your on-premises database. You can do this either from the application directly or from the database by using cron. For more information, see Use the Crontab Utility to Schedule Tasks on Oracle Linux | DBA, App developer |
Schedule the data migration job. | On the target host, use the command | DBA |
Validate the data migration. | Data validation is a crucial step. For data validation, you can use custom tools or Oracle tools, such as a combination of dblink and SQL queries. | DBA |
| Task | Description | Skills required |
|---|---|---|
Put the source database in read-only mode. | Confirm that the application is shut down and no changes are being made to the source database. Open the source database in read-only mode. This helps you avoid any open transactions. For more information, see | DBA, DevOps engineer, App developer |
Validate the object count and data. | To validate the data and object, use custom tools or Oracle tools, such as a combination of dblink and SQL queries. | DBA, App developer |
Connect the applications to the database on the primary EC2 instance. | Change the application’s connection attribute to point to the new database you created on the primary EC2 instance. | DBA, App developer |
Validate the application performance. | Start the application. Validate the functionality and performance of the application by using Automated Workload Repository | App developer, DevOps engineer, DBA |
Related resources
AWS references
Oracle references
