Resource requirements for the target platform
We recommend that you size the target database environment on AWS based on the source Exadata utilization, not configuration. Many customers purchase Exadata systems with additional capacity to accommodate anticipated growth for the next three to five years. Typically, when Exadata workloads are migrated to AWS, fewer resources are deployed compared to the configuration of the source Exadata system, so it's misleading to use that original configuration to predict AWS resources.
To estimate the resources required in the target instance, you can use the tools that are discussed in the previous section, such as AWR, database views, OEM, and CellCLI. On AWS, you can scale resources up or down more easily compared with the source Exadata platform. The following sections discuss best practices for estimating resources such as CPU, memory, and IOPS for the target platform. Additionally, AWS account teams and database specialists who have extensive experience in assisting customers with their Exadata migrations can help you size your target environment. AWS has internal tools that the AWS account team can use to estimate the resources required and right-size your target environment on AWS.
CPU and memory requirements
When you migrate your Exadata workloads to an Oracle database deployment option on AWS, such as Amazon RDS for Oracle, you shouldn't base the compute layer resources (CPU and memory) only on the utilization statistics from Exadata database servers. The workload also benefits from Exadata-specific features such as Smart Scan and storage indexes, which offload processing to the storage cells and use the resources of the storage servers. Therefore, you should provision the compute layer in the target instance with additional CPU and memory resources based on your usage of Exadata-specific features and the degree of workload optimization that might be possible during the migration.
It's difficult to accurately estimate the additional CPU resources required. Use the discovery results as a starting point for sizing the target environment. For a rough calculation, consider including one additional vCPU for every 500 MBps of Smart Scan workloads to the total vCPUs required for the compute layer.
Another approach is to consider the CPU utilization on the storage servers. You could add about 20 percent of the total used CPUs on storage servers to the total vCPUs required for the compute layer as a starting point. You can adjust this percentage based on your use of Exadata features, as determined by tools such as AWR and CellCLI. For example, for low usage, you can add 10 percent for low usage, 20 percent for medium usage, and 40 percent for high usage. If you utilize a total number of 20 CPU threads across all storage servers and Exadata feature usage is observed as medium, you might consider 4 additional vCPUs to compensate for missing Exadata features in the target environment.
After these initial estimates, you should also conduct performance testing on the target environment to determine whether you need to scale the resources allocated. Performance testing could also reveal further workload optimization opportunities that can reduce the resources required.
You might have to increase memory allocation to the Oracle instance to improve the cache hit ratio and reduce the I/O footprint. Your source Exadata platform might not have sufficient memory for large SGA allocations, especially in a consolidated scenario. This might not cause performance issues in Exadata, because I/O operations are generally fast. We recommend that you start with an instance that supports the following memory allocation:
Target memory required = larger of (8 GB per vCPUs required, two times the SGA+PGA allocation in the source) SGA+PGA allocation = ~80% of available memory on the instance
During performance testing, you can use Oracle features such as buffer pool advisory, SGA target advisory, and PGA memory advisory to fine-tune the SGA and PGA allocation to meet your workload's requirements.
The Amazon EC2 or Amazon RDS instance must have adequate CPU, memory, and I/O resources to handle
the anticipated database workload. We recommend that you use a current generation instance
class to host your workload on AWS. Current generation instance types, such as instances
that are built on the Nitro
System, support hardware virtual machines (HVMs). To take advantage of enhanced
networking and increased security, you can use Amazon Machine Images (AMIs) for HVMs.
Amazon RDS for Oracle currently supports up to 128 vCPU and 3,904 GBs of memory. See DB
instance classes in the Amazon RDS documentation for information about hardware
specifications of instance classes available for Amazon RDS for Oracle See Amazon EC2 instance types
I/O requirements
Using AWR reports to estimate resource requirements requires familiarity with workload patterns for peak, off-peak, and average load timings. To estimate IOPS requirements for your workload based on an AWR report collected during peak periods, follow these steps:
-
Review the AWR report to identify physical read I/O requests, physical write I/O requests, physical read total bytes, and physical write total bytes.
These metrics take the benefits of Exadata-specific features such as storage indexes into account, so they indicate actual IOPS and throughput values that you can use to size the storage I/O layer of your target AWS environment.
-
In the I/O profile section of the AWR report, review the physical read requests optimized and physical write requests optimized values to determine if Smart Scan and other Exadata features related to I/O—such as I/O saved by storage indexes, columnar cache, or Smart Flash Cache—are used. If you see optimized requests in the AWR I/O profile, review system statistics to obtain the details of Smart Scan and storage index metrics such as cell physical I/O bytes eligible for predicate offload, cell physical I/O interconnect bytes returned by Smart Scan, and cell physical I/O bytes saved by storage index.
Although these metrics aren't directly used to size the target environment, they are useful for understanding how much I/O is saved by Exadata-specific features and tuning techniques to optimize the workload.
Total IOPS required for the workload = physical read IO requests + physical write IO requests Total throughput = physical read bytes + physical write bytes
The AWR statistics physical read I/O requests, physical write I/O requests, physical read bytes, and physical write bytes reflect the workload's I/O activities, excluding the I/O contributed by non-application components such as RMAN backup and other utilities such as expdp or sqlldr. In those cases, you can consider the AWR statistics physical read total I/O requests, physical write total I/O requests, physical read total bytes, and physical write total bytes to estimate IOPs and throughput requirements.
Databases that run on Exadata typically produce hundreds of thousands of IOPS and very high throughput (over 50 Gbps) because of the factors discussed in earlier sections. However, in most cases, tuning techniques and workload optimization reduce the I/O footprint of the workload drastically.
If I/O requirements are very high, be aware of Amazon EC2 and Amazon RDS limitations. For high Amazon EBS volume throughput, consider using Amazon EC2 instance classes such as x2iedn, x2idn, and r5b, which support up to 260,000 IOPS with a throughput of 10,000 MBps. See Amazon EBS-optimized instances in the Amazon EC2 documentation to review the maximum IOPS and throughput supported by various instances. For Amazon RDS for Oracle, the rb5 instance class supports up to 256,000 IOPS with a throughput of 4,000 MBps. See DB instance classes to review Amazon EBS-optimized instances available for Amazon RDS for Oracle.
You should also understand how IOPS and throughput are measured in the case of different
EBS volumes that are available for the target environment. In some cases, Amazon EBS splits or
merges I/O operations to maximize the throughput. To learn more, see I/O
characteristics and monitoring in the Amazon EC2 documentation and How do I optimize
the performance of my Amazon EBS Provisioned IOPS volumes?
