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

15. > \(name=other,level=3,allocation=100\)\)"
16. cm01cel01: IORMPLAN successfully altered
17. cm01cel02: IORMPLAN successfully altered
18. cm01cel03: IORMPLAN successfully altered
19. [oracle@cm01dbm01 iorm]$ dcli -g ./cell_group "cellcli -e alter iormplan active"
20. cm01cel01: IORMPLAN successfully altered
21. cm01cel02: IORMPLAN successfully altered
22. cm01cel03: IORMPLAN successfully altered
23. [oracle@cm01dbm01 iorm]$

• In line 1, we are disabling any current IORM plan. This is not required, but it is something we

prefer to do in order to avoid confusion should the new IORM plan have any errors.

• In line 5, we are using

dcli to launch cellcli on each storage cell.
In line 6, we are specifying

•

auto as our plan objective; we will discuss this in more detail in the
How It Works section of this recipe.

• Lines 7 through 11 contain our Interdatabase IORM plan objectives. Here, we assign a specific

I/O utilization target for four different databases, each at level 1, as well as a 100% utilization
at level 2.

• Lines 12 through 15 contain our Category IOR plan objectives. Here we are assigning 100%

for CAT_HIGH at level 1, 80% and 20% for CAT_MEDIUM and CAT_LOW at level 2, and all other
categories 100% at level 3.

• Line 19 enables our IORM Plan.

How It Works
Although it is common for Exadata DMAs to refer to any implementation of iormplan as “IORM,” Oracle defines an
IORM plan as a combination of Category IORM and Interdatabase IORM plans. IORM plans are created by using the
alter iormplan command to implement both a Category Plan ( catplan ) and Interdatabase Plan ( dbplan ). In short:

• An IORM plan is a combination of a Category plan and an Interdatabase plan.

• A Category plan specifies resource allocations per classification, or category, of resource

consumer groups. Categories with the same names are assigned to consumer groups
across multiple Exadata databases, and IORM sees these as requests that have the same I/O
characteristics from a prioritization perspective.

• Categories are assigned to consumer groups and consumer groups are created as part of a

DBRM or Intradatabase plan within a database.

• An Interdatabase plan specifies I/O resource allocations on a per database level.

If you are reading the recipes in this chapter sequentially, you may have noticed that, thus far, we have not
described how IORM actually “works.” Here, we will attempt to provide a concise explanation of how IORM functions,
when it is engaged, the order in which IORM rules are evaluated, and the information needed to understand the
“math” of IORM.
We have stated in several recipes in this chapter that IORM is only engaged “when I/O is saturated on the storage
cells.” More accurately speaking, IORM kicks in when there are “full” disk I/O queues (and when IORM is enabled, of
course). Figure 17-1 provides a graphical representation of how IORM works.