In the Exadata world, I/O Calibration is the process of "benchmarking" your storage grid to determine its maximum performance limits. Think of it as a stress test that tells the Oracle Database exactly how many IOPS (Input/Output Operations Per Second) and how much MBPS (Megabytes Per Second) the underlying storage can actually handle.

While I/O calibration exists in standard Oracle databases, it is foundational to Exadata because it powers the "brain" of the storage grid: IORM (I/O Resource Management).

1. Why do we calibrate?

The primary goal is to provide the Oracle Optimizer and IORM with a reality check. Without calibration:

• The Optimizer might guess incorrectly about how "expensive" a disk scan is versus an index lookup.

• IORM wouldn't know the "ceiling" of the storage cells. To fairly distribute I/O among multiple databases, the software first needs to know the total capacity it is trying to divide.

2. How it Works: The Stress Test

When you run the calibration, the database issues a series of asynchronous I/O requests across all storage cells. It specifically measures two metrics:

1. Small Random I/O: Measures IOPS and Latency. This simulates OLTP workloads (finding a single row).

2. Large Sequential I/O: Measures Throughput (MBPS). This simulates Data Warehouse workloads (scanning a massive table).

3. The Exadata Difference

On a standard SAN, I/O calibration can be "fooled" by external caches or shared noisy neighbors. On Exadata, the process is highly optimized:

• It communicates directly with the Cellsrv process on the storage servers.

• It identifies the performance of the Smart Flash Cache versus the Hard Disks.

• It populates the CALIBRATION_TIME and MAX_IOPS columns in the V$DATABAS_PROPERTIES table.

4. How to Run It

Calibration is usually performed during initial setup or after a hardware upgrade (like adding a new storage cell). You run it via the DBMS_RESOURCE_MANAGER package:

SET SERVEROUTPUT ON
DECLARE
  lat  INTEGER;
  iops INTEGER;
  mbps INTEGER;
BEGIN
  -- num_physical_disks: The total number of disks in your grid
  -- max_latency: The maximum acceptable latency (usually 10ms)
  DBMS_RESOURCE_MANAGER.CALIBRATE_IO (12, 10, iops, mbps, lat);
  
  DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
  DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
  DBMS_OUTPUT.PUT_LINE ('max_mbps = ' || mbps);
END;
/

5. Viewing the Results

Once finished, the database stores these metrics permanently. You can check them at any time with this query:

SELECT max_iops, max_mbps, max_pmbps, latency 
FROM v$io_calibration_status;

• MAX_IOPS: Total random 8K read requests per second.

• MAX_MBPS: Total sequential I/O throughput.

• MAX_PMBPS: Large I/O throughput for the entire physical storage (including non-Oracle files).

Important Tips

• Run it on a "Quiet" System: Do not run calibration while production jobs are running. It is a stress test; it will consume all available I/O bandwidth and potentially slow down users.

• ASM Influence: Ensure your ASM diskgroups are mounted and healthy before starting, as calibration happens through the ASM layers.

• Required for IORM: If you see OBJECTIVE = 'AUTO' in your IORM settings, but haven't run calibration, IORM may not be able to effectively throttle low-priority workloads.

Summary

I/O Calibration is the "Speedometer Calibration" for your Exadata. It ensures that the software's expectations match the hardware's reality, allowing the Optimizer to make smarter decisions and IORM to enforce fair-share policies effectively.