AWS Cloud Operations Blog

7 Easy steps to migrate Oracle database to AWS in minutes

Lift and Shift Oracle Database with the least downtime using AWS Application Migration Service

Introduction

Customers migrating Oracle databases from their data centers to AWS run enterprise workloads that are vital for their business. They look for tools and mechanisms to enable them to migrate without disruption to current database operations and with minimum or no downtime. They might be currently using application-level migration (like Oracle native tools) or export/import. These approaches could include longer down times or cut-over times than desired.

Using AWS Application Migration Service, Oracle databases are migrated using block level replication while leaving the source database running and operational. Migrated databases can be tested while continuous replication takes place. This allows database teams to evaluate the migrated environment and enables a minimum cutover period for migration.

This post shows how to configure Application Migration Service and migrate an Oracle database from an on-premises server to AWS. It shows how to run non-disruptive testing as well. This post is a guide for DBAs, Technical Architects, Infrastructure Managers, and teams handling Oracle database migrations of production workloads. It focuses on automating the process for quick and scalable migrations. This is an ideal approach for situations where re-platforming is not feasible.

Overview of Application Migration Service

Application Migration Service is the recommended service for migrations to AWS. Application Migration Service simplifies and expedites migration to AWS by automatically converting your source servers from physical, virtual, or cloud infrastructure to run on AWS. It simplifies your migration and reduces costs by allowing you to use the same automated process for a wide range of applications, without changes to applications, their architecture, or the migrated servers. You can use Application Migration Service to perform non-disruptive tests prior to cutover. After testing, you can use Application Migration Service to quickly migrate your applications to the cloud during a short cutover window, typically measured in minutes. You can also use Application Migration Service to automate application modernization on your migrated servers, by running pre-configured and custom optimization actions.

Solution Architecture

In this post, I show the process of migrating an Oracle database 19c from an on-premises server running Red Hat Enterprise Linux 9 (RHEL9) to a destination AWS region using Application Migration Service. The source database is replicated to a staging area, where continuous replication maintains synchronization between the source and replicated volumes. A test launch is initiated to create an AWS instance. After testing, a cutover launch is performed to transition to the replicated instance in the destination subnet. The process involves network configuration, replication agent installation, testing, and DNS updates.

Application Migration Service Archiecture Diagram

Prerequisites

For a successful deployment, you need the following:

  1. An active AWS account.
  2. A source Oracle database in an on-premises data center
  3. AWS Identity and Access Management (IAM) user with required permissions, as defined in the AWS MGN documentation

Source environment

The database used for this post is Oracle database 19c running on RHEL9. Application Migration Service agent can be installed on RHEL 6.0 and higher as well as other operating systems.

    1. First, check the Linux version on the source database server using the following command
      $ cat /etc/os-release
      Linux version on the source database server
    2. Connect to the database using SQL*Plus. For this example, the database user name is testuser1 and the database name is ORCLPDB. My sample database is running release 19c Version 19.3.0.0.0
      $ sqlplus testuser1/{PASSWORD|>@//{database machine IP}:1521/ORCLPDB1
      SQLPlus login
    3. I will use a sample database on the source server for demonstration purposes. The source SQL and instructions for creating this database can be found here.
      ERD Diagram
    4. Query the sample database. The query results will be used to compare after the database has been migrated. 
      
SELECT c.name, o.order_date, o.order_id, o.status, p.product_name
FROM customers c, orders o, order_items i, products p
WHERE
o.customer_id = c.customer_id
AND o.order_id = i.order_id
AND i.order_id = o.order_id
AND p.product_id = i.product_id
AND c.customer_id = 1
AND o.order_id = 60
order by o.order_id asc;

      Query result shows the following orders.

      
	Name order_date order_id status product_name
			Raytheon	30-JUN-17	60	Shipped	G.Skill Ripjaws 4 Series
			Raytheon	30-JUN-17	60	Shipped	G.Skill Ripjaws V Series
			Raytheon	30-JUN-17	60	Shipped	G.Skill Ripjaws V Series
			Raytheon	30-JUN-17	60	Shipped	G.Skill Trident X
			Raytheon	30-JUN-17	60	Shipped	Asus X99-E-10G WS
			Raytheon	30-JUN-17	60	Shipped	Intel Xeon E5-2695 V4
			Raytheon	30-JUN-17	60	Shipped	Intel Xeon E5-2643 V2 (OEM/Tray)

      Notice that Order ID 60 has 7 items all indicating status of Shipped. Once I finish the migration, I will check the same order to make sure it moved successfully. Then I will change this order on the source database, setting the status from Shipped to Pending. This will demonstrate how Application Migration Service synchronizes any changes in the source database to the destination database.

Create Destination Virtual Private Cloud (VPC)

Before setting up Application Migration Service, I need to create a VPC in the destination region. This is where the replication servers and migrated instances will reside. Create a VPC with two subnets for the replication volumes and the EC2 instance containing the migrated database. If required, migration could be performed over private networks but for this example I am creating two public subnets:

  1. oracle-mgn-subnet-public1-us-east-1a to place replication server in.
  2. oracle-mgn-subnet-public2-us-east-1b to place the migrated destination server in.

To create the VPC, perform the following steps:

  1. Login to the AWS console
  2. Select the destination region
  3. From the services menu select VPC then choose Create VPC.
  4. On the VPC settings Select VPC and more
  5. In the Name tag auto-generation make sure Auto-generate option is selected and enter the tag oracle-mgn. In the IPv4 CIDR block enter the value 10.0.0.0/16
  6. Scroll down and verify that the Number of public subnets is 2. Set the Number of private subnets to 0, and VPC endpoints to None. Choose Create VPC.

Solution Steps

  1. Initialize Application Migration Service and configure replication settings.
  2. Add Source Server to Application Migration Service.
  3. Configure the launch settings and launch target test instance in the destination environment.
  4. Configure database on test instance.
  5. Mimic actual changes to the source database during migration and testing by altering the data. Validate the destination database configuration and conduct testing.
  6. Launch cutover instance.
  7. Finalize cutover.

Initialize Application Migration Service

Configure Application Migration Service in the destination region using the following steps:

  1. Login to the AWS console and select the destination region. Application Migration Service is available in AWS commercial and GovCloud regions. For this post I have selected the us-east-1 region.
  2. From the services menu select Migration and Transfer then choose AWS Application Migration Service.
  3. Choose Get started to initialize Application Migration Service on this region
  4. On the service initialization page, choose Set up service.
  5. This step will initialize Application Migration Service in this region and will display the Source servers pane.
  6. To configure the replication settings, expand Settings from the navigation pane then select Replication template. This will show you the replication template for the destination environment. Choose Edit.
  7. On the staging area subnet drop-down list, select the subnet where the replication servers will be launched. From the two public subnets created earlier, use oracle-mgn-subnet-public1-us-east-1a
  8. For the replication server instance type, select t3.small from the drop-down list.From a security perspective, the best practice is to have Application Migration Service automatically attach and monitor the default Application Migration Service security group that is created while initializing. This group allows inbound TCP Port 1500 for receiving the transferred replicated data. Selecting this default security group will be shown later in this post.
  9. Scroll down to the end of the page and choose Save template

Add Source Server to Application Migration Service

Deploy the Application Migration Service replication agent on the source server. An IAM user with programmatic access is required to perform the following steps as mentioned in the prerequisites. This user should also have the required policy attached to it. Please follow the standard procedure to create an IAM user with the required policy.

    1. To obtain the CLI commands to deploy the replication agent from the Application Migration Service page, choose Source servers from the navigation pane then choose add server
    2. Select the Linux operating system and on the replication preferences step, select replicate all disks from the drop-down list.
    3. For the IAM access key ID and secret access key, obtain the values from the created IAM user. Add to the corresponding boxes.
    4. Choose the copy button next to the download installer command and paste the results it in a text editor for later use.
    5. Choose the copy button for the installer command on step 6. Paste the results in a text editor for later use.
    6. To install Application Migration Service replication agents on the source server, run the CLI commands provided by the agent installation dialog. These commands will download and install the Application Migration Service agent. Replace the placeholders with the actual values for your access key id and secret access key below.
      Download installer:

      sudo wget -O ./aws-replication-installer-init https://aws-application-migration-service-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/aws-replication-installer-init

      Run the installer:

      sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init --region us-east-1 --aws-access-key-id <ACCESS_KEY_PLACEHOLDER> --aws-secret-access-key <SECRET_KEY_PLACEHOLDER> --no-prompt

      Each server with an installed replication agent continuously communicates with the Application Migration Service replication servers in the staging area subnet over TCP port 1500. It must continuously communicate with Application Migration Service over TCP port 443 as well. Make sure these ports are enabled on the server’s firewall settings and security groups.

    7. Navigate to Application Migration Service page and select the Source servers from the navigation page. Verify the source server is now listed and initializing.
    8. Select the source server name and scroll down to watch the replication progress bar. The amount of time required will depend on the size of the source disk.

      The replication initiation steps show successful progress. In case of issues, the steps will be shown in red and replication will stop until the issues are resolved. Common issues can be related to not enabling the required ports for replication on source servers (Ports 443, and 1500). For troubleshooting visit the Troubleshooting communication errors page.

      Once replication is complete, the replication progress will show initial replication finished. The lifecycle indicates Ready for testing.

Configure the Launch settings and launch test instance

  1. To configure the launch settings for the destination environment, choose the server name on the source servers list then choose the Launch settings tab.
  2. Scroll down to EC2 Launch Template and choose Modify
  3. A dialog box for confirmation is displayed. On the dialog box choose Modify.
  4. This will open the launch template on a new tab for editing.
  5. Scroll down to the Key pair section. Select a key pair under Key pair name if you have one already within this region (or create a new key pair) to be used to login to the destination database instance. In this case I use a key pair named ol8.pem
  6. On Network settings, select the oracle-mgn-subnet-public2-us-east-1b from the subnet drop-down list.
  7. On Firewall (security groups), choose the Select existing security group button then chose the default VPC security group from the list. Keep all other values at default and proceed.
  8. Application Migration Service will use the default version of the launch template. To make sure the changes are picked up by Application Migration Service, set the default version of the launch template to the latest version.
  9. Choose View launch templates and select the launch template created for application migration service.
  10. On the actions list select Set default version
  11. On the dialog box, select the latest version from the drop-down list and choose Set as default version

    Close the browser tab and return back to Application Migration Service browser tab.
  12. Next, launch a test EC2 instance. From the Application Migration Service page, choose  the Source servers on the navigation pane then select the server name link from the Source servers pane.
  13. Expand Test and cutover menu then select Launch Test Instance.
  14. On the dialog box choose Launch

    Application Migration Service creates an EC2 instance from the replicated volumes.
    Once finished, the new test server is up and running and the migration lifecycle indicates Test in Progress. This means the Application Migration Service is waiting for tests or scripts to be executed on the test instance.
  15. Check the security group that was configured in the launch template for the destination server. Make sure to enable port 22 for SSH from your local machine’s IP address, to be able to connect to the test server if needed. From the source drop-down list select My IP.

Test Instance Configuration

Check the destination test instance’s configuration and test the database. Login through SSH to the newly created test instance. Update the database configuration with the IP address of the machine, then connect to the Oracle database and query the data.

    1. To configure the newly migrated database, SSH to the test server using the CLI (replace with the test instance IP address) 
      ssh -i "ol8.pem" ec2-user@<TEST_INSTANCE_IP>
    2. Switch to the oracle user 
      $ sudo su - oracle
    3. Update Oracle network configuration with the correct local host names address on tnsnames.ora and listener.ora. Update the listener configuration with the IP addresses of the test instance host name as provided from the EC2 instance console 
      $ cd $ORACLE_HOME/network/admin
      $ vi tnsnames.ora

      $ vi listener.ora

    4. Add ORACLE_HOME, and ORACLE_SID and ORACLE_HOME/bin to the PATH environment variable. Set the environment variables in the installation owner user profile. 
      
$ export ORACLE_HOME=/opt/oracle/product/19c/dbhome_1
$ export PATH=$ORACLE_HOME/bin:$PATH
$ export ORACLE_SID=ORCLCDB
    5. Start the database (as it would be initially stopped after the migration). Alter the session to the container database, open the database, and start the database listener. 
      
#Start Database
$ sqlplus / as sysdba
SQL> startup
SQL> alter session set container=ORCLPDB1;
SQL> ALTER DATABASE OPEN;
SQL> exit
#Start database listener
		
      
$ lsnrctl start
    6. Connect to the newly created database 
      $ sqlplus testuser1/testuser1@//localhost:1521/ORCLPDB1
    7. Verify the newly created database, run the following query to retrieve the order data. The query returns the exact query results on the newly created database as compared to the original one. 
      
SELECT c.name, o.order_date, o.order_id, o.status, p.product_name
FROM customers c, orders o, order_items i, products p WHERE
o.customer_id = c.customer_id
AND o.order_id = i.order_id
AND i.order_id = o.order_id
AND p.product_id = i.product_id
AND c.customer_id = 1
AND o.order_id = 60
order by o.order_id asc;

      The query result shows the following orders for order_id 60:

       Name       order_date order_id status     product_name
Raytheon    30-JUN-17   60    Shipped   G.Skill Ripjaws 4 Series
Raytheon    30-JUN-17   60    Shipped     G.Skill Ripjaws V Series
Raytheon    30-JUN-17   60    Shipped     G.Skill Ripjaws V Series
Raytheon    30-JUN-17   60    Shipped     G.Skill Trident X
Raytheon    30-JUN-17   60    Shipped     Asus X99-E-10G WS
Raytheon    30-JUN-17   60    Shipped     Intel Xeon E5-2695 V4
Raytheon    30-JUN-17   60    Shipped     Intel Xeon E5-2643 V2 (OEM/Tray)

Mimic a change on the source database

In this step I make changes to the source database, then launch cutover to demonstrate the continuous replication performed by Application Migration Service. This shows the latest data being replicated from the source instance database to the migrated instance database.
Connect using SSH to the source database instance, log in to the database using SQL*Plus, and run the following steps to update the customer’s name.


SQL> UPDATE CUSTOMERS SET NAME = 'New User Name' where CUSTOMER_ID = 1;
SQL> SELECT c.name, o.order_date, o.order_id, o.status, p.product_name
FROM
customers c, orders o, order_items i, products p
WHERE
o.customer_id = c.customer_id
AND o.order_id = i.order_id
AND i.order_id = o.order_id
AND p.product_id = i.product_id
AND c.customer_id = 1
AND o.order_id = 60
order by o.order_id asc;

Notice the values of Customer name are now updated on source environment. The value will be replicated to replication server volumes as part of the continuous replication taking place.

 NAME ORDER_DATE ORDER_ID STATUS PRODUCT_NAME
New User Name	30-JUN-17	60	Shipped	G.Skill Ripjaws 4 Series
New User Name	30-JUN-17	60	Shipped	G.Skill Ripjaws V Series
New User Name	30-JUN-17	60	Shipped	G.Skill Ripjaws V Series
New User Name	30-JUN-17	60	Shipped	G.Skill Trident X
New User Name	30-JUN-17	60	Shipped	Asus X99-E-10G WS
New User Name	30-JUN-17	60	Shipped	Intel Xeon E5-2695 V4
New User Name	30-JUN-17	60	Shipped	Intel Xeon E5-2643 V2 (OEM/Tray)

Launch Cutover instances

In this step, launch the cutover instance with the latest replicated data (including the changes performed on the source database) and create the cutover instance.

First, mark the database as ready for cutover:

  1. Navigate to the Application Migration Service page
  2. Choose the Source servers from the navigation pane and select the server name to display the server details showing the lifecycle stage as Test in progress.
  3. Choose the Test and cutover menu and select Mark as Ready for cutover.

A dialog box is displayed to confirm marking the server as ready for cutover. Choose Continue.

Once the server is marked for cutover, launch the cutover instance. This step will terminate the current test instance and create the cutover instance.

From the Application Migration Service page, choose the source servers from the navigation pane then select the server name to display the server details. Choose the Test and cutover menu and select Launch Cutover Instances

A dialog box is displayed to confirm Launch cutover instance. Choose Launch.

Perform cutover instance configuration once the cutover instance is created:

  1. Login to the instance from your local machine using SSH, then connect to the database 
    
$ssh -i "ol8.pem" ec2-user@<CUTOVER_SERVER_IP_ADDRESS>
$sqlplus / as sysdba
  2. Switch to the oracle user, set the export variables, and connect as sysdba 
    
# Switch to the "oracle" user.
sudo su - oracle
# Configure your environment.
export ORACLE_HOME=/opt/oracle/product/19c/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export ORACLE_SID=ORCLCDB
  3. Edit Listener configuration with the newly assigned local DNS name. To update the listener configuration, first obtain the DNS value. Go to the EC2 instances page, select the instance and copy the Private IP DNS name from the Details tab.
  4. From the CLI of the cutover instance , change to the oracle home network admin directory. Edit the listener.ora and tnsnames.ora files to include the obtained DNS value 
    
cd $ORACLE_HOME/network/admin
vi listener.ora


    
vi tnsnames.ora

  5. Start the Oracle database. Connect using SQL*Plus to start the database. Set the container DB session to ORCLPDB1 [jrm3] to be able to connect to the pluggable database with the data tables. Open the database for use. 
    
#Start Database
sqlplus / as sysdba
SQL> startup
SQL> alter session set container=ORCLPDB1;
SQL> ALTER DATABASE OPEN;
SQL> exit
  6. Next, start the database listener to enable connection 
    $ lsnrctl start

  7. Connect to the destination test database using testuser1. 
    
sqlplus testuser1/testuser1@//localhost:1521/ORCLPDB1

    Query the database for details of the order with order_id = 60

    
SQL> SELECT c.name, o.order_date, o.order_id, o.status, p.product_name
FROM
customers c, orders o, order_items i, products p
WHERE
o.customer_id = c.customer_id
AND o.order_id = i.order_id
AND i.order_id = o.order_id
AND p.product_id = i.product_id
AND c.customer_id = 1
AND o.order_id = 60
order by o.order_id asc;

    Shows the following order

     NAME            ORDER_DATE ORDER_ID STATUS      PRODUCT_NAME
New User Name     30-JUN-17   60    Shipped     G.Skill Ripjaws 4 Series
New User Name     30-JUN-17   60    Shipped     G.Skill Ripjaws V Series
New User Name     30-JUN-17   60    Shipped     G.Skill Ripjaws V Series
New User Name     30-JUN-17   60    Shipped     G.Skill Trident X
New User Name     30-JUN-17   60    Shipped     Asus X99-E-10G WS
New User Name     30-JUN-17   60    Shipped     Intel Xeon E5-2695 V4
New User Name     30-JUN-17   60    Shipped     Intel Xeon E5-2643 V2 (OEM/Tray)

The new database returns the same query results as the source database at the time of migration. This includes any changes applied to the source database during testing. This demonstrates that the source database changes have successfully replicated to the cutover database.

Finalize Cutover

The last step is to finalize cutover. This action will stop the data replication between the source server and the replication volumes. Next it will remove the Application Migration Service agent from the source server and finally it will remove all resources used for the migration of the server, including the replication server and Amazon EBS volumes.

  1. From the Application Migration Service page, choose the Source servers from the navigation pane then select the server name to display the server details. Choose the Test and cutover menu and select Finalize cutover
  2. A dialog box appears for confirmation, choose Finalize
  3. Once cutover is done, the lifecycle shows Cutover Complete. This concludes the migration of the Oracle database from its source to AWS.

Cleaning up

Archive your source servers that have launched cutover instances to clean up your source servers. Marking the server as archived will remove its association with Application Migration Service. This step will not terminate the source server or its Amazon EBS volumes.

  1. From the Application Migration Service page, choose the Source servers from the navigation page then select the server name to display the server details. Choose the Actions menu and select Mark as archived
  2. A dialog box appears for confirmation, choose Archive

    Once archived, the console will list the server as an archived source server.
  3. To list archived servers, select Source servers from the navigation pane, then select the filter drop-down list and select Archived source servers

    The Archived source servers filter will list the source server as disconnected
  4. The last step is to delete the Amazon VPC and all its associated resources.

Conclusion

In this post, I demonstrated how to migrate an Oracle database to AWS using the Application Migration Service. It is for customers running enterprise workloads and provides a step-by-step guide for DBAs, architects, and managers to automate the migration process. This includes configuring Application Migration Service, installing the replication agent, configuring the launch settings, launching test instances, and finalizing cutover.

To learn more, visit the Application Migration Service page.

Mohamad Charaf

Mohamad Charaf is Senior Solutions Architect with the World-Wide Public Sector at AWS. With a migrations and modernization focus and a passion for guiding organizations to bridge the gap towards successful cloud migrations, he excels at providing solutions and approaches to simplify the path to migrations.