How to Migrate Oracle Workloads to VMware Cloud on AWS

By Jayaraman VelloreSampathkumar, Sr. Partner Solutions Architect at AWS

VMware Cloud on AWS is becoming a preferred choice to run Oracle workloads on Amazon Web Services (AWS).

Some Oracle workloads, like Oracle Real Application Cluster (RAC) or WebLogic application clusters, have specific networking and storage requirements, which can be met with VMware Cloud on AWS.

After you decide on an architecture, you should consider how to migrate your Oracle workloads to AWS.

This post details the various considerations and migration options users have for Oracle workloads. I will examine in-depth how to migrate an Oracle database from an on-premises environment to AWS using AWS Database Migration Service (AWS DMS).

VMware is an AWS Partner Network (APN) Advanced Technology Partner. VMware Cloud on AWS delivers a highly scalable, secure, and innovative service that allows organizations to seamlessly migrate and extend their on-premises VMware vSphere-based environments to the AWS Cloud running on next-generation Amazon Elastic Compute Cloud (Amazon EC2) bare metal infrastructure.

Migration Planning

Organizations have many options when migrating Oracle workloads from an on-premises environment to VMware Cloud on AWS. When selecting a migration path, you should consider:

Whether your workload is production or non-production.
The type of workload (databases, applications, containers).
SLA requirements (can it be offline for few hours?).
Network bandwidth between your on-premises environment and the VMware Cloud on AWS Region.

Beyond the technical aspects, consider the technical skill set of your migration personnel. Oracle DBAs are familiar with Oracle migration methods like Oracle Recovery Manager (RMAN) backup/restore, Oracle Data Guard, or Oracle GoldenGate. VMware personnel may be familiar with VMware HCX and vMotion for migrations.

I recommend categorizing the application based on how critical it is to the business. The different buckets have different approaches and require different skills. For example, a critical production database may require the care and security provided by Oracle Data Guard. But for the hundreds of dev/test databases and applications that are less critical in nature, a mass migration using HCX is faster and less costly.

Network Connectivity

Network connectivity between your on-premises data center and VMware Cloud on AWS plays a key role in migration. For more information, see the APN Blog post, Simplifying Network Connectivity with VMware Cloud on AWS and AWS Direct Connect.

Many Oracle customers hope to retain the same IP address in VMware Cloud on AWS. This is called a Layer 2 extension for VMware Cloud on AWS, and this option works only if the Oracle database or application is already in VMware on-premises. For more information, see the documentation.

Migration Options

Let’s review some of the migration options available for Oracle workloads. Some of these are only appropriate if the Oracle workload is already running on VMware on-premises, while others can work even if you’re not already using VMware locally.

VMware HCX

VMware HCX provides live migration technologies to VMware Cloud on AWS, without the need to retrofit your on-premises VMware infrastructure. It also supports migration from vSphere 5.0+.

HCX has four methods of migration: HCX Bulk Migration, HCX vMotion, HCX Cold Migration, and HCX Replication-Assisted vMotion. The following table helps you choose the right HCX migration methodology for your needs.

Figure 1 – How to choose the right VMware HCX migration methodology for your needs.

For a more in-depth look, see the APN Blog post, Migrating Workloads to VMware Cloud on AWS with Hybrid Cloud Extension (HCX).

Oracle Technologies

There are multiple options when using Oracle technologies to move to VMware Cloud on AWS.

For example, you can use Oracle RMAN backups to restore the databases in VMware Cloud on AWS. The AWS Storage Gateway file interface can run on the local VMware infrastructure and presents an NFS storage that can be mounted on an Oracle database server.

You can back up the database using Oracle RMAN, and write the RMAN backup set to the NFS storage, which is then copied to the designated Amazon Simple Storage Service (Amazon S3) bucket in the linked AWS account. You can copy the backup set from the S3 bucket to virtual machines (VMs) in VMware Cloud on AWS. Or you can choose to mount the S3 bucket as an NFS mount on VMware Cloud VMs using Storage Gateway.

Alternate Oracle technologies, such as Oracle Data Guard, Oracle Active Data Guard, or Oracle GoldenGate, can be used to replicate the on-premises database to the target database in VMware Cloud on AWS.

You can also consider AWS Direct Connect, depending on the amount of redo log generated in the source Oracle database. Oracle workloads based on the filesystem, such as Oracle WebLogic, can be replicated using traditional file syncing tools such as rsync.

AWS Database Migration Service

AWS DMS supports homogeneous migrations such as Oracle to Oracle, as well as heterogeneous migrations between different database engines such as Oracle to Amazon Aurora. With AWS DMS, you can perform one-time migrations as well as continuous replication of data from source to target.

AWS DMS is a platform-agnostic migration service. Oracle customers can use AWS DMS to migrate data from non-x86 platforms like Solaris, HP-UX, or even non-Oracle RAC databases to Oracle RAC databases.

Oracle RAC can be implemented on VMware Cloud on AWS, which supports multi-cast and shared storage requirements of Oracle RAC. We have published a reference architecture for Oracle RAC on VMware Cloud on AWS. For a step-by-step implementation guide, see the documentation.

Migrating Workloads with AWS DMS

The following diagram uses linked AWS accounts to run an AWS DMS instance.

Figure 2 – AWS DMS database migration architecture.

The steps to implement the migration architecture are as follows:

Provision the AWS DMS instance.
Create endpoints for source and target databases.
Create and start AWS DMS tasks.
Monitor the migration.

Provisioning the AWS DMS Instance

VMware Cloud on AWS creates cloud elastic network interfaces in a specific subnet in the linked AWS account. To provide low latency and high performance, you should provision your AWS DMS instance in the same subnet as the cloud network interface.

Your AWS DMS instance subnet also needs connectivity to the on-premises data center network where the source Oracle database exists. Depending upon the volume of data to be transferred, the connection could be a VPN-based connection or AWS Direct Connect.

AWS DMS offers a variety of instances for migration, but compute-optimized instances (C4) and memory-optimized instances (R4) are suitable for large production-class migration.

General purpose (T2) AWS DMS instances are useful in testing the initial connection and development instance migration. For large database migrations, I recommend AWS DMS 3.1.1 or higher, as it contains support for parallel full unload of tables and partitions for Oracle databases. The AWS DMS release notes contain detailed notes on features and updates.

As shown in Figure 3, on the AWS DMS instance creation screen you can choose the DMS instance class, DMS engine version (we recommend choosing the latest engine version), and Amazon EBS storage allocated to the instance.

Figure 3 – Screenshot of AWS DMS instance creation.

Log files and cached transactions consume allocated storage. For cached transactions, storage is used only when the cached transactions must be written to disk. Cached transactions from the source database are written when it takes time to load large tables in the target database.

The default storage is usually sufficient, but the allocated storage may be consumed when there are large tables and a rate of row change in the source table. Monitor the storage-related metrics and scale up the storage when required.

Creating Endpoints for Source and Target Databases

You can create endpoints for source and target databases. AWS DMS supports Oracle databases versions 10.2 through 12.2.

AWS DMS supports change data capture (CDC) to perform continuous replication. It can use Oracle LogMiner to read through the redo log files and archived log files. AWS DMS with Oracle Binary Reader can support full load replications, but does not support ongoing replication.

AWS DMS supports Oracle ASM for transaction log access, but the extra connection attribute in DMS must include your ASM username and ASM server address.

useLogMinerReader=N;asm_user=<asm_username>;asm_server=<first_RAC_server_ip_address>:<port_number>/+ASM

AWS DMS can use a separate Oracle user account in its source database to support replication. For a complete list of user account privileges and other replication considerations, see the documentation.

Creating and Starting AWS DMS Tasks

An AWS DMS task is where all the work happens. You can specify tables and schemas, and provide filtering conditions. Multiple AWS DMS tasks are usually created to facilitate parallel load of independent schemas within the database.

As you can see in Figure 4, you can name the AWS DMS task using Task Identifier, and choose the replication instance you previously created. You can also select the source and target database endpoints, and select the type of AWS DMS migration task.

Figure 4 – Screenshot of AWS DMS task creation.

You can set up a task to do a one-time migration of data from source to target. You can also create an ongoing replication task to provide continuous replication between the source and target. To read ongoing changes for Oracle databases, AWS DMS uses either the Oracle LogMiner API or Binary Reader (bfile API).

AWS DMS reads ongoing changes from the online or archived redo logs based on the system change number (SCN). There are two types of ongoing replication tasks:

Full load and CDC: Task migrates existing data and then updates the target based on the changes from the source data.
CDC only: Task migrates ongoing changes after you have data on the target database. The initial target database could have been created using Oracle RMAN backup and restore or the export/import utility. It’s important to know the last SCN of the backup.

To have the tasks start immediately, choose Start Task on Create. Or, you can start the task from the Action menu on the Database Migration Tasks page.

You can validate the number of rows inserted in target tables by choosing Enable Validation. A row count is performed on each target table and compared to the source table. However, this setting can be time-consuming and might affect the overall migration time.

Monitoring the Migration

You can monitor the progress of your task by checking on the task status and by monitoring the tasks control table dmslogs.awsdms_apply_exceptions. For a full list of control tables and their columns, see the documentation.

You can also monitor the progress of your tasks using Amazon CloudWatch. By using the console, AWS Command Line Interface (CLI), or AWS DMS API, you can monitor the task progress and the resources and network connectivity used.

As shown in Figure 5, you can monitor various migration task metrics to gain better insight into the performance of the AWS DMS migration task.

Figure 5 – AWS DMS migration task metrics console page.

Other Technologies

There are other technologies you could consider for Oracle migration. AWS Marketplace lists software solutions that can be easily deployed on AWS. You can connect these third-party software deployments to your on-premises over AWS Direct Connect or a virtual private network (VPN) solution and move data to VMware Cloud on AWS.

Conclusion

To migrate Oracle workloads to VMware Cloud on AWS, there are a number of migration methods to choose from based on your needs and existing system.

For online migrations, VMware technologies like vMotion and HCX help you migrate VM workloads from on-premises VMware clusters to VMware Cloud on AWS.

AWS DMS helps you to migrate and/or replicate Oracle databases to VMware Cloud on AWS with minimal downtime. It supports Oracle RAC workloads and can migrate across platforms such as HP-UX, IBM-AIX, and Solaris SPARC. You may also use native Oracle technologies, such as Oracle DataGuard or Oracle GoldenGate, to migrate workloads to AWS.

Cold migration or offline migration of Oracle workloads is also possible using Oracle RMAN, AWS Snowball, AWS Storage Gateway, or VMware HCX.

For additional information on VMware Cloud on AWS, please visit our website. If you’re interested in discussing your Oracle workloads on VMware Cloud on AWS, reach out to us at aws-vmware-cloud@amazon.com.