Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

I/O Resource Management - AWS Prescriptive Guidance

I/O Resource Management

I/O Resource Management (IORM) is an Exadata feature that manages how multiple workloads and databases share the I/O resources of an Exadata system. IORM complements the Oracle Database Resource Manager (DBRM) to provide necessary isolation for different workloads in a consolidated environment. Whenever I/O requests start to saturate the I/O capacity of storage cell servers, IORM schedules and prioritizes incoming I/O requests based on the resource plans you configured.

You can collect IORM metrics from Exadata storage cells by using the script metric_iorm.pl as discussed in My Oracle Support (MOS) Note 337265.1, Tool for Gathering I/O Resource Manager Metrics: metric_iorm.pl (requires an Oracle account). These metrics can be useful for organizing workloads that run in a consolidated environment in Exadata when you migrate the workloads to the target platform on AWS.

Migrating to AWS

In the AWS Cloud, we recommend that you host different workloads on separate instances. This approach provides more flexibility in maintaining the databases according to the resource, performance, and SLA requirements of individual applications instead of consolidating them into a single instance. The following practices can be useful when you migrate such workloads to AWS:

  • Identify interdependencies among databases and classify the workloads that must be migrated to the same instance on the target platform. These databases might have unresolvable cross-schema references or low-latency database link connectivity.

  • Based on the statistics you collected by using the metric_iorm.pl script, identify databases and workloads that initiate and benefit from IORM. Use this information to determine the databases that can be consolidated or migrated to independent instances. Choose appropriate storage types and instance classes to avoid I/O saturation.

  • If the target platform is Oracle Database, consider using Oracle Database Resource Manager (DBRM) to prioritize or throttle resources such as CPU, PGA, and parallelism for multiple workloads that are consolidated in the same instance as multiple pluggable databases or schemas.

  • Consider implementing caching solutions such as Amazon ElastiCache and Amazon RDS for Oracle read replicas to serve read-only workloads. These solutions reduce the I/O footprint on the primary instance.

  • For workloads that don't have a dependency on Oracle Database, Amazon Aurora provides a distributed and decoupled architecture that provides high I/O throughput. You can meet the demands of a heavy, I/O-intensive workload by designing an Aurora cluster with an appropriate number of reader instances and by using features such as Amazon Aurora global databases.

PrivacySite termsCookie preferences
© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved.