Strategies for Successful Oracle Database Migration with VMware Cloud on AWS

By Masayuki Toyoda, Sr. Partner Solutions Architect – AWS
By Michitoshi Yoshida, Sr. Partner Solutions Architect – AWS

Customers are seeking an effective way to enhance their existing data center infrastructure and migrate workloads to the cloud. Organizations running Oracle Database on vSphere environments are also looking for migration paths for the database and the best path for them.

VMware Cloud on AWS enables customers to deploy VMware’s software-defined data center (SDDC) and consume vSphere workloads on Amazon Web Services (AWS) global infrastructure as a managed service. It enables customers to extend their on-premises data centers and easily migrate workloads without converting machine image formats or undergoing a re-platforming process.

In this post, we’ll explore database migration paths to AWS from on-premises vSphere environments and the benefit of integrating VMware Cloud on AWS with AWS Cloud Databases. We will also discuss how each migration path helps customers streamline operations, reduce costs, and improve overall business agility.

Database Migration Paths

AWS defined 7 Strategies for Migrating Applications to the Cloud, also known as the “7 R’s.” There are four paths (we call them the “4 R’s” in this post) to AWS when considering Oracle Database migration from on-premises vSphere environments.

Figure 1 – Database migration paths to AWS (4 R’s).

Relocate

Relocate is used to migrate entire virtual machines (VMs), including database VMs, to the VMware Cloud on AWS SDDC.

This path is the easiest way to migrate the Oracle Database without impacting ongoing operations or rewriting the application. It’s a good starting point if you have a number of databases that need to be migrated in a limited time frame.

Review VMware Cloud on AWS host types for the latest available deployment options and resource usage of your database VMs to determine the optimal configuration. Customers should also review your Oracle license agreement to determine the number of licenses required to complete the migration.

Rehost

Rehost is a similar approach to relocate, as customers experience minimal change to convert database VMs into Amazon Elastic Compute Cloud (Amazon EC2) instances, while other workloads migrate to the VMware Cloud on AWS SDDC.

Amazon EC2 provides compute instances sized to fit the needs of your Oracle workload, and you can use your existing Oracle Database license (BYOL) to run Oracle Database on EC2. To understand the number of licenses required to run your databases on Amazon EC2, see Oracle’s policy for licensing Oracle software in the cloud. Note that this information must not be used as guidance for licensing purchases or compliance; it’s for educational purposes only, and customers should consult their own Oracle license agreement for details.

Replatform

Replatform is used to migrate database VMs to Amazon Relational Database Service (Amazon RDS) for Oracle, while other workloads migrate to the VMware Cloud on AWS SDDC. Amazon RDS helps customers reduce the complexity of supporting critical transactional applications by making it easy to set up, operate, and scale a relational database in the cloud.

Amazon RDS automates time-consuming administrative tasks such as hardware provisioning, database setup, patching, and backups while providing cost-efficient and scalable capacity. It frees you to focus on your applications to give them the performance, high availability, security, and compatibility they need.

RDS is available on several database instance types—optimized for memory, performance, or I/O—and provides six familiar database engines, including Oracle Database. You can bring your Oracle Database license to Amazon RDS, which also provides the License Included (LI) model for Standard Edition Two (SE2) and allows you to pay for compute capacity by the hour. Therefore, your database instance runs with no long-term commitments.

Refactor

Refactor is used to re-architect workloads, change the database engine from Oracle Database, and then move to Amazon RDS, Amazon Aurora, or Amazon Redshift. It involves modifying the application code to use a different database engine, such as PostgreSQL or MySQL, and then migrating the data to the new engine. You can migrate all other workloads to the VMware Cloud on AWS SDDC.

Although this strategy requires significant effort and resources, it’s considered the most future-proof migration approach. Amazon Aurora is a relational database service that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. While fully compatible with MySQL and PostgreSQL, Aurora is designed to deliver higher throughput and lower latency compared to their standard installations, with a lower total cost of ownership (TCO).

Integrate with AWS Managed Database Services

VMware Cloud on AWS customers can seamlessly integrate their SDDCs with native AWS services. During an SDDC onboarding process, customers can establish high-bandwidth and low-latency connectivity to a designated virtual private cloud (VPC), which is often referred to as the connected VPC. This connectivity is established using cross-account elastic network interface (ENI) between the NSX Edge appliance in the VMware-managed shadow account and a subnet within the connected VPC in the customer-managed account.

Data transfer between the SDDC and connected VPC will not incur any egress costs as long as the SDDC and destined native services reside in the same AWS Availability Zone (AZ). Figure 2 shows data from the VMs in the SDDC going over the NSX Edge and ENI to access native AWS services in the connected VPC.

Figure 2 – Integrate VMware Cloud on AWS with native AWS services.

Customer Concerns and Workarounds for Database Migrations

Customers may be concerned about potential performance degradation and meeting availability requirements when migrating from the Oracle Database on the vSphere environment to Amazon RDS. Following are things to check and consider when addressing these concerns.

Performance

When considering migrations to Oracle Database on Amazon EC2 or RDS, remember the underlying database mechanism is the same as on vSphere environments, even when running on AWS. You need to know how exactly your database is running.

Generate Automatic Workload Repository (AWR) or Statspack reports for the Oracle Database in action to help size your instances based on the following criteria:

DB time and top 5 wait events
vCPU (DB time)
Memory usage; cache hit ratio
I/O bandwidth usage; IOPS

Determining the number of CPU cores and amount of memory used in the workload is vital to optimizing cost and performance, not the cores or the RAMs installed on the servers. AWS offers a variety of instance types that are optimized for different use cases; select the best instance type and storage based on the above sizing result.

Suppose you plan to migrate to Oracle Database on EC2; choose the best instance type that 1) fits the existing license, 2) supports Amazon Elastic Block Store (Amazon EBS) optimized instance type, and 3) is equipped with a large memory capacity.

Availability

For customers using Oracle Real Application Clusters (RAC) in an on-premise vSphere environment, availability may be a concerning factor when planning the migration. It’s important to determine and confirm the level of recovery time objective (RTO) and recovery point objective (RPO) required to make the right investment for the necessary level of availability. The table below shows an example of the RTO for each database migration path.

Figure 3 – RTO comparison for each option.

Figure 3 shows that choosing one of the database migration paths to AWS can reduce the time to recover from data corruption or data center failure. You can optimize costs and achieve the desired level of availability by selecting a migration path that meets your requirements.

Migrating Databases to AWS

When you have identified databases for migration, you’ll go through the phases of discovery, design, convert, migration, operation, and optimization.

Discovery: This phase involves determining whether the database migration is feasible, through discussion and proof of concept (PoC). You need to assess whether the migration is technically possible, meets business requirements, and is cost effective.
Design: In this phase, you design the migration methodology and the post-migration environment. This includes selecting the appropriate database engine, configuring the network infrastructure, and determining the security requirements.
Convert: This involves extracting and rewriting SQL, and then performing unit, integration, and comprehensive performance tests. This ensures the migrated database performs as expected and any potential issues are identified and addressed before the migration.
Migration: During this phase, you perform migration tests, data migration, and cut over to the new environment.
Operation: This includes monitoring the database, performing backups, and addressing any issues that arise to ensure the migrated databases run smoothly after the cut over.
Optimization: You perform continuous operational improvements, such as capacity review and cost optimization. This phase ensures the migrated database continues to perform well and is optimized for cost effectiveness.

In the discovery phase, the primary goal is to gather and analyze information on the current environment, choose the destination engine/platform, and determine the migration method. The target database migration path depends on your requirements, and the figure below can help you decide.

Figure 4 – Selection chart of database migration path.

Migrating from Oracle Database to Amazon Aurora can significantly reduce the TCO, but consider three factors when changing the database engine.

First, adapting your application to the new engine may be costly due to differences in architecture and features. AWS Schema Conversion Tool can help assess the impact of engine changes and automate parts of the conversion process. Refer to the Oracle-to-Aurora migration playbook for a step-by-step guide to the migration process, commonly seen application incompatibilities, and their workarounds.

Second, consider additional costs for modifying database-specific functionalities integrated with your application, which may affect migration costs. Lastly, evaluate whether migrating to Amazon Aurora addresses your business challenges. While Aurora offers benefits, alternative solutions like data warehouses or NoSQL databases might better suit your needs.

When migrating an Oracle Database to Amazon RDS, “knockout conditions” refer to unsupported database features or configurations in Amazon RDS for Oracle, which can prevent successful migration. Figure 5 illustrates typical knockout conditions for Amazon RDS for Oracle migrations.

Figure 5 – Knockout conditions for migrations to Amazon RDS for Oracle.

Leveraging Amazon RDS Custom for Oracle can overcome some of the knockout conditions such as full access to OS, database vault requirement, and backup using RMAN while reaping the benefits of a managed database environment. Amazon RDS Custom for Oracle enables certain custom configurations and features not supported by RDS, making the migration process smoother and some of the knockout conditions manageable.

If you encounter knockout conditions that Amazon RDS Custom for Oracle can’t solve, consider migrating to EC2 or VMware Cloud on AWS.

Data Migration Approach

Once you have identified the target environment for migration, the next action is to decide how to migrate the data from the current production Oracle Database. AWS provides various services and features to simplify this process, including AWS Database Migration Service (AWS DMS), which allows secure migration of your database and analytics workloads to AWS with minimal downtime.

It’s important to note that when the database engine remains the same between source and destination, use of native tools such as Oracle Data Pump can be a simpler option, assuming some downtime is acceptable. This approach can provide an efficient and reliable way to transfer data without the need for complex data transformation processes.

Regardless of the chosen method, it’s vital to identify the approach most suited to your application, considering the volume of data being transferred and amount of downtime allowed during the migration. You can take advantage of the Database Freedom program, a unique program designed to assist customers in migrating to AWS through technical advice, migration support, and financial assistance.

AWS can help assess your application, recommend a migration path, and help you execute the migration through our network of Database Freedom partners, AWS Professional Services, and Amazon Database Migration Accelerator.

Summary

In this post, we took a closer look at Oracle Database migration paths to AWS from on-premise vSphere environments. AWS offers a variety of choices for database migration, and you can choose the best option based on your requirements.

VMware Cloud on AWS provides high-bandwidth and low-latency connectivity with native AWS services, so you can seamlessly connect your VMs on SDDC to AWS managed database services.

Migration to Amazon Aurora helps you reduce the license costs associated with Oracle Database, while migration to Amazon RDS for Oracle offers a faster track to the cloud with minimal application changes. Both managed database services can free you from time-consuming, undifferentiated administration tasks.

Finally, one of the key benefits of moving your database to AWS is that once the migration is complete to any of the options above, you can leverage your data and bring more value to your business, using native analytics and machine learning services AWS offers.

Please refer to this AWS blog post to learn more about data warehousing and business intelligence for VMware Cloud on AWS, which provides a walkthrough on how to drive insights out of databases running in VMware Cloud on AWS using Amazon Redshift and Amazon QuickSight.

To learn more, we recommend you review these additional resources:

AWS Partner Network (APN) Blog