I/O Resource Management and Instance Caging - Oracle Exadata Recipes: A Problem-Solution Approach - page 504

Figure 17-1. IORM architecture

The process flow for I/O requests with IORM can be described as follows:

1. Each I/O request submitted by a database sends an iDB message to each storage cell.

The iDB message includes the list of extents required to satisfy the operation as well as
several pieces of metadata, including the database name associated with the request, the
consumer group name (or “other” if DBRM is not in place), the resource and the resource
category (or ”other” if categories are not assigned to consumer groups).

2. The I/O request is placed on an I/O queue, managed by cell services. Each cell disk

maintain an I/O queue for each database and each consumer group per database.

3. IORM intercepts the I/O requests from the I/O queues before placing them on a disk

queue. If the disk queue(s) is full, IORM will evaluate the IORM plan rules for each
incoming I/O request and place the I/O request in the proper, prioritized order on the
disk queue.

4. I/Os on the disk queues are processed in a FIFO basis; at this point, IORM would have

already executed its logic to properly prioritize I/O requests.

Without IORM, I/Os are serviced on each cell disk based on a first-in-first-out (FIFO) algorithm; whichever
request is issued first gets priority, then the second request, followed by the third, and so on. When an IORM plan is
enabled, it evaluates the rules configured in the IORM plan and prioritizes disk I/Os accordingly by placing them in
the proper slot on the disk queue.