Thinking of Migrating an Oracle Database Workload from Exadata to AWS RDS? Have you considered all the implications?

In this blog we offer some points you may want to consider prior to choosing to undertake such a migration.

These include:

1. Nature and criticality of your Oracle Database workload
2. Manual effort required to tune and maintain your environment
3. Cost

Requirements of your Workload – Performance, Scalability, Reliability, and Availability

The first major consideration should be the nature and criticality of your database workload. RDS only provides a single node database engine without the horizontal scalability, reliability, and availability enabled by Oracle Real Application Clusters (Oracle RAC). Will such a limited service be able to meet your requirements in those areas? Exadata not only runs Oracle RAC, but is purpose-built to run Oracle Database, with unique capabilities like Smart Scan, Storage Indexes, Remote Direct Memory Access (RDMA) and many more combined in an intelligent data architecture that make it uniquely well-suited to run Oracle Database with performance that can’t be matched on any other platform, including RDS.

Cloud users can get all these Exadata advantages with Exadata Database Service and Autonomous Database running in the Oracle Cloud (OCI), Azure, Google Cloud, and even AWS. That’s right, applications running in AWS can get all the benefits of Exadata by running it local to their applications. They get better performance and availability than is possible with RDS, in AWS. And further, your AWS consumption commitments apply to Oracle Database@AWS.

That all sounds great, you may say, but what if my workload isn’t big enough to warrant a dedicated Exadata environment? We recently introduced a unique new intelligent data architecture, Exascale, and a new infrastructure option for Exadata Database Service based upon it, Exadata Database Service on Exascale Infrastructure. The Exascale architecture makes it possible for multiple tenants to share both database compute and the intelligent storage tier provided by Exadata. This eliminates the need for dedicated infrastructure and makes it possible for the new service to offer Exadata performance, reliability, availability, and security at a much lower entry point, effectively combining the best aspects of Exadata and cloud. This service is available today in OCI and will be expanded in the near future to our Multicloud partnerships with Azure and Google Cloud, though it is not yet on the announced roadmap for AWS.

For workloads that don’t need Exadata level performance, capacity, or other capabilities, Oracle Cloud offers Base Database Service, which runs in Virtual Machines (VMs) on non-Exadata, commodity infrastructure – just as RDS for Oracle does in AWS. Customers willing to run their applications in OCI have even more options like earlier access to new database releases, longer support life for older database releases with free extended support, and more flexible licensing with a license included service for Enterprise Edition and database options – none of which are available with RDS. If you ever need to do so, you can easily scale up to RAC, or even Exadata.

What about those of you who have a requirement for your Oracle Database to run in AWS? Even then, if your workload doesn’t currently need Exadata performance, capacity, or other capabilities – if you were able to not only meet, but exceed those requirements in case your workload should ever grow, and do so with less effort and at lower expense, wouldn’t you want to do so? More on that to come…

Manual Effort Required

Last month the AWS Database Blog published a post titled Migrating Oracle Databases from Exadata to Amazon RDS for Oracle: Addressing Performance Considerations. In this blog the authors provide some great examples that illustrate a few of the ways in which the workloads they examine benefit from Exadata capabilities like Smart Scan query offload to the intelligent storage tier, which reduces the work that must be performed in the database compute tier and significantly decreases the amount of data that must be moved during query processing. After all, the fastest I/O possible is the one you eliminate the need to do in the first place! The authors also provide good examples of analyzing Automatic Workload Repository (AWR) reports and identifying and tuning individual SQL IDs or adapting the RDS environment in which they would run. All this work is done to try to compensate for the absence of Exadata enhancements like Smart Scan and Storage Indexes to the extent to which it’s possible to do so.

One of the great features of Oracle Database is that it provides a variety of tools and mechanisms through which tuning needs can be identified and addressed. But an even greater innovation is the ability for the system to manage itself and obviate the need for all that human effort. Many of the steps described in the AWS blog are correctly identified as ones that would need to be applied not only to each database, but in many cases to individual SQL statements within the workloads. The level of effort entailed is significant, and expensive in terms of the time that must be expended by someone who has the necessary expertise to perform the analysis and tuning required.

An example that’s referenced is the fact that indexes might have been dropped when a workload was originally moved to Exadata and could potentially be reinstated. Where this is the case it’s usually because doing so resulted in improved performance by getting previous human attempts at optimization out of the way and letting Exadata do the optimizing more effectively. It’s 2025 now, and we have capabilities like Autonomous Database, which runs on Exadata infrastructure and goes even further in terms of self-management and tuning. Why dedicate so much time and energy to tuning your database environment when it could be doing the work for you – especially now since Exadata and the Oracle Database services that run on it are available through our Multicloud partnerships in all the major clouds – not only OCI, but also AWS, Azure, and Google Cloud as well?

RDS Cost: Over 3 Times More Expensive Than Exadata in AWS

Another approach to mitigating performance concerns in RDS for Oracle that’s referenced is to use an instance store residing on local Non-Volatile Memory Express (NVMe) flash storage to store temporary tables and/or utilize memory-optimized compute instances. As the blog states, having more RAM available does enable you to have a larger System Global Area (SGA) and therefore a larger buffer cache. While it’s undeniably true that having the data you need to retrieve already sitting in cache (whether in RAM or Flash) vs. stored on disk results in faster retrieval, this is essentially the old legacy approach of throwing hardware at a performance problem, which has historically rarely proven to be the most cost-effective solution.

To see if that holds true in this case, let’s look at a pricing comparison with RDS for Oracle running on an db.x2iedn.32xlarge instance, the example cited in the AWS blog, which is both memory-optimized and supports RDS for Oracle instance store. For Oracle Enterprise Edition with Bring Your Own License (BYOL) on this instance type the AWS Pricing Calculator shows a monthly cost (exclusive of storage) of $54,939.40. We’ll also configure IO2 Block Express storage, again as cited, with the maximum 256K IOPS supported. Note that this is significantly fewer IOPS than are available on even a single Exadata storage server (where, as we’ve already seen, the software enhancements eliminate the need to perform many of those I/O operations in the first place), but it’s the highest performance you can get with RDS. We’ll also specify 64 TB of storage, again the maximum supported by RDS for Oracle. Plugging this into the AWS Pricing Calculator yields monthly storage costs of an additional $33,792. It’s important to note that $25,600 of this cost goes to Provisioned IOPS charges. For comparison, there are no charges for IOPS on any Exadata-based cloud service. There are literally millions of IOPS available, all at no additional charge. When we add the compute and storage costs, you get a total monthly price of $88,731.80.

Let’s compare that cost to Exadata Database Service on Dedicated Infrastructure, which is currently in Limited Availability in the US-East-1 Northern Virginia AWS Region as part of the Oracle Database@AWS partnership, and will be expanding to General Availability and additional regions later this year. If we price the minimum configuration on the newly introduced Exadata X11M you get 2 Exadata Database servers with 190 available cores each (a total of ~6X the compute power of the db.x2iedn.32xlarge AWS instance, configured as a 2-node Oracle RAC cluster with all the advantages that entails in terms of scalability, reliability, and availability). You also get 3 Exadata Storage Servers with 192 additional cores available to offload SQL processing to the storage tier and 240TB of usable triple-mirrored data storage (compared to a maximum capacity of 64TB of data on AWS RDS for Oracle). Further, this is dedicated infrastructure which isn’t subject to the potential noisy neighbor problems that can happen in a shared VM architecture. If you price based on utilizing compute capacity equivalent to that of the db.x2iedn.32xlarge instance and BYOL licensing the monthly price comes to only $26,170.35 – less than 1/3 the cost!

If you price based on utilizing the full capacity of the X11M as configured (presumably for additional workloads), it still only totals $102,061.92 – more than 6X the compute capacity for 1.15X the cost. Consolidation of multiple workloads onto Exadata is one of the most effective approaches to achieve optimal utilization of all those resources and capabilities that Exadata makes available, and, as you can see from these numbers, can be much more cost-effective than dedicating separate RDS instances to each individual workload.

Summary

As we’ve shown above, while it’s certainly possible to go through a labor intensive, iterative process of manual steps to tune your Oracle database workloads in order to perform the best they possibly could on AWS RDS, and to configure options in RDS to get the best performance available from the platform, doing so can require significant effort and cost and is still extremely unlikely to achieve performance comparable to what’s available on Exadata – without all the work. When you also consider that Exadata and the Autonomous and Exadata Database Services it supports are now available in AWS, it’s difficult to see why anyone would choose to pay more, do more work, and still get less performance by migrating their Oracle Database workloads from Exadata to RDS.

For more information

• Blog: Comparing Oracle, Microsoft, Google and Amazon clouds for business-critical Oracle databases
• Blog: Exadata in the Cloud is Your Future – What Are You Waiting For?