Proving the Performance of Oracle Exadata-Based Workloads on AWS

By Tom Monk, Director, Cloud Product Management – Navisite

Navisite

According to Oracle, 86% of the Fortune Global 100 run their Oracle databases on Exadata. Organizations the world over rely on the Exadata database platform to operate and manage Oracle databases, simplify data management, and ensure performance-intensive systems are running as expected.

While Exadata workloads perform well on premises, organizations are increasingly looking to achieve the scalability, flexibility, and cost benefits of Amazon Web Services (AWS).

The problem is the complexity of Exadata workloads; IT teams often struggle to chart a migration path forward, causing delays and preventing them from fully realizing the benefits of digital transformation.

In this post, I will explain the process for testing the performance of Exadata workloads once they have been migrated to AWS using Oracle Real Application Testing (RAT). Performance is a key metric for measuring the suitability of a cloud platform; this process outlines how customers can accurately test and measure that key metric.

Navisite has been helping customers migrate Oracle enterprise applications and databases to AWS since 2013. Throughout that time, we’ve attained a number of AWS Partner achievements: Navisite is an AWS Premier Consulting Partner and member of the AWS Managed Service Provider (MSP) and Well-Architected Partner Programs.

Navisite is also an AWS Oracle Competency Partner specializing in helping customers architect, deploy, and manage Oracle-based workloads running on the AWS Cloud.

Concerns with Exadata Performance

One of the chief concerns holding IT teams back from moving forward with their Exadata migration plans is performance. Exadata workloads are business-critical and tied to core revenue-generating processes, which means anything other than reliable high performance on AWS is unacceptable.

When customers look to migrate an Exadata-based workload, a common question they ask is, “Will my workload perform as well on AWS as it does today?”

Often, customers don’t just want reassurance, they want to see the platform demonstrate it can support their requirements. This presents a problem: customers don’t want to migrate before they know their workloads will perform well, but the only way to do so is to migrate the workload.

The other challenge is that performance testing is notoriously difficult. Replicating a production-level database load on a migrated database without directing huge numbers of users away from their day jobs is time-consuming.

There are also numerous technical challenges associated with facilitating the activities of users while safely providing production-equivalent integrations and data feeds.

The key to mitigating these concerns is proving Exadata workloads will perform as expected on AWS.

At Navisite, a modern managed cloud service provider, we have moved hundreds of mission-critical Oracle workloads to AWS and have developed a proven methodology to guide customers through the process.

One of the most important elements in our methodology is the proof of concept (PoC). We work with customers to establish the reasons for their concerns and structure some non-functional requirements to work towards. These inform what needs to be tested in the PoC and how success can be measured.

RAT Validation Before Migration

A standard proof of concept involves migrating a non-production environment to AWS, so the customer can test their workloads ahead of time.

However, for mission-critical workloads like Exadata, we use a more rigorous PoC tool from Oracle called Real Application Testing (RAT), which stress tests specific workloads for performance, capacity, speed, and other criteria.

RAT testing allows us to replay a recording of a database’s workload against a copy of that database. So, the customer records a key business process or busy period from a production database, and then takes a copy of that database and makes a change to the infrastructure or software. The customer can then replay the captured activity to see if the change has impacted the performance.

In short, RAT enables us to test a specific Exadata-based workload on AWS against real-world demands to determine if it meets specific technical and user experience requirements. If it doesn’t, the results are helpful in identifying how the process can be modified to ensure success.

5-Step Process for RAT Testing on Amazon RDS

This section of the post outlines a step-by-step roadmap for executing a RAT against a copy of an on-premises Oracle database that has been migrated to Amazon Relational Database Service (Amazon RDS).

Figure 1 – Real Application Testing (RAT) process flow.

Step 1: Record a representative workload on the on-premises production environment, making a record of the System Change Number (SCN) at the start of the recording. Once the recording is complete, copy a backup of the database, the Automatic Workload Repository (AWR) data and the RAT data to an Amazon Simple Storage Service (Amazon S3) bucket.

Step 2: Create a self-managed database running on Amazon Elastic Compute Cloud (Amazon EC2) to restore the database. Roll the database forward to the SCN captured in step one. Use Oracle DataPump to copy the entire database from EC2 into an Amazon RDS for Oracle instance.

Step 3: Deploy RAT load generators and copy the RAT data to each load generator and the RDS instance.

Step 4: Execute the replay from the Amazon RDS for Oracle database. Once the replay is complete, analyze the AWR data outputs and the Amazon CloudWatch metrics.

Step 5: Once the previous run has been analyzed, roll the database back to before the replay and make any performance changes required before executing the replay again.

Putting the Results into Action

The technical process of executing the RAT method is one half of the process; the other half is analyzing the results and leveraging the findings for performance tuning and optimization.

At Navisite, we have a methodical process for analyzing RAT data, making changes to improve performance and repeating test executions. Additionally, following RAT testing we deliver our conclusions in a detailed final report that includes:

• RAT findings.
• Recommended architecture, infrastructure requirements, and total cost of ownership (TCO).
• Estimated migration cost.
• Project plan, with recommendations and strategies for successfully moving Exadata workloads to Amazon RDS.

Conclusion

With the Real Application Testing (RAT) process, analysis and a final detailed report, customers benefit from pre-migration assurance that their Exadata workloads will perform as expected on AWS.

Navisite’s cloud experts have years of experience moving Exadata workloads to AWS. Our team has the skills, resources, and capabilities customers need to confidently migrate to AWS and ensure the performance of Exadata workloads in this new environment can be maintained and continually improved.

To learn more about Navisite’s methodology for migrating Exadata workloads to AWS, read the eBook: The Final Mile: Migrating Exadata Workloads to AWS, or contact us today.

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.

.

Navisite – AWS Partner Spotlight

Navisite is an AWS Premier Consulting Partner and MSP that helps customers migrate enterprise applications and databases to maximize the full power of AWS.

Contact Navisite | Partner Overview

*Already worked with Navisite? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.