ALTER IORMPLAN

7.7.1.7 ALTER IORMPLAN

Purpose

The ALTER IORMPLAN command updates the I/O Resource Management (IORM) plan for the cell.

The ALTER IORMPLAN command clauses control the IORM objective and specify directives that control access to I/O resources.

Syntax

ALTER IORMPLAN [ objective = iorm_objective ]
      [ catplan = { ( directive [, directive] ... ) | "" } ]
      [ dbplan = { ( directive [, directive] ... ) | "" } ]
      [ clusterplan = { ( directive [, directive] ... ) | ""  } ]

Parameters

objective: Specifies the optimization mode for IORM. The valid objective values are:
- auto - Use this setting for IORM to determine the best mode based on active workloads and resource plans. IORM continuously and dynamically determines the optimization objective, based on the observed workloads and enabled resource plans. This is the recommended value for most use cases, and starting with Oracle Exadata System Software release 21.2.0, this is the default setting.
- high_throughput - Use this setting to optimize critical DSS workloads that require high throughput. This setting improves throughput at the cost of I/O latency.
- low_latency - Use this setting to optimize critical OLTP workloads that require extremely good disk latency. This setting provides the lowest possible latency at the cost of throughput by limiting disk utilization.
- balanced - Use this setting for a mixture of critical OLTP and DSS workloads. This setting balances low disk latency and high throughput. This setting limits disk utilization of large I/Os to a lesser extent than low_latency to achieve a balance between latency and throughput.
- basic: Use this setting to limit the maximum small I/O latency and otherwise disable I/O prioritization. This is the default setting in Oracle Exadata System Software release 20.1.0 and earlier.
catplan: Specifies the category plan, allowing you to allocate resources primarily by the category of the work being done. If no catplan directives are set, then every category has an equal share of the resources by default.

Note:

Starting with Oracle Exadata System Software release 25.1.0, the category plan is removed and no longer supported.

Starting with Oracle Exadata System Software release 21.2.0, the category plan is deprecated, and a warning message is issued when a category plan is specified.
dbplan: Specifies the interdatabase plan, allowing you to manage resource allocations among databases. If no dbplan directives are set, then every database has an equal share of the resources by default.
clusterplan: Specifies the cluster plan, allowing you to manage resource allocations among Oracle Grid Infrastructure clusters. If no clusterplan directives are set, then every cluster has an equal share of the resources by default.

Note:
The cluster plan is first introduced in Oracle Exadata System Software release 21.2.0.

Usage Notes

To fully enable any user-defined IORM plans (catplan, dbplan, or clusterplan), the IORM objective must be set to a value other than basic.
The cluster plan (clusterplan) uses ASM-scoped security for cluster identification. The value of the name attribute must match the asm field in the cellkey.ora file, which is part of the ASM-scoped security definition for the cluster.
Different user-defined IORM plans inter-operate as follows:
- The catplan and dbplan can be used in combination only if the dbplan does not contain any directives having type=profile.
  
  In this case, directives from both plans are applied to determine the share of resources.
- The catplan and clusterplan cannot be used in combination.
  
  You cannot set clusterplan directives when catplan directives exist. Likewise, you cannot set catplan directives when clusterplan directives exist.
- The clusterplan and dbplan can be used in combination only if the dbplan does not contain any allocation or level directives.
  
  In this case, directives from both plans are applied to determine the share of resources.
To remove the current directives and reset a catPlan, dbPlan, or clusterplan parameter, set the parameter to an empty string by using a pair of single or double quotation marks. The quotation marks must match. For example, "" is correct, but "' is incorrect.
Because of the command length and complexity, consider running ALTER IORMPLAN commands by using scripts.
IORM is configured individually on every storage server using the ALTER IORMPLAN command. To deliver consistent overall system performance, ensure every storage server in the storage cluster uses the same IORM configuration settings.

Example 7-39 Setting the IORMPLAN Objective

This example shows the ALTER IORMPLAN command being used to set the IORM optimization mode.

CellCLI> ALTER IORMPLAN objective=low_latency

CellCLI> ALTER IORMPLAN objective=auto

Example 7-40 Resetting IORMPLAN Plans

This example shows how to reset the IORMPLAN dbplan and catplan. The first command resets the dbplan and catplan using one command. The other commands reset the dbplan and catplan individually.

CellCLI> ALTER IORMPLAN dbplan="", catplan=""

CellCLI> ALTER IORMPLAN dbplan=""

CellCLI> ALTER IORMPLAN catplan=""

Parent topic: ALTER

7.7.1.7.1 Directives for a Category Plan

The directives for a category plan (catplan) use the following syntax:

( name=category_name , level=number, allocation=number )

Usage Notes

The name attribute must be the first attribute listed in each directive. Otherwise, the order of attributes is not important.
The category plan can have a maximum of 32 directives.
You cannot have multiple directives with the same category name.

See the following topics for details about the attributes (name, level, and allocation) that are defined in each catplan directive.

Parent topic: ALTER IORMPLAN

7.7.1.7.2 Directives for a Database Plan

The directives for a database plan (dbplan) use the following syntax:

( name={ db_name | profile_name }
  [, { share=number | level=number, allocation=number }]
  [, limit=number]
  [, flashcache={on|off}]
  [, xrmemcache={on|off}]
  [, pmemcache={on|off}]
  [, flashlog={on|off}]
  [, xrmemlog={on|off}]
  [, pmemlog={on|off}]
  [, flashcachelimit=number]
  [, flashcachemin=number]
  [, flashcachesize=number]
  [, xrmemcachelimit=number]
  [, xrmemcachemin=number]
  [, xrmemcachesize=number]
  [, pmemcachelimit=number]
  [, pmemcachemin=number]
  [, pmemcachesize=number]
  [, asmcluster=asm_cluster_name]
  [, type={database|profile}]
  [, role={primary|standby}] )

Usage Notes

The name attribute must be the first attribute listed in each directive. Otherwise, the order of attributes is not important.
The database plan cannot contain a mixture of resource allocation directives, with some using the share attribute and others using the level and allocation attributes. The resource allocation directives must all use the share attribute, or they must all use the level and allocation attributes.
If you use the share attribute to allocate I/O resources, then the database plan can have a maximum of 1024 directives. If you use the level and allocation attributes to allocate I/O resources, then the database plan can have a maximum of 32 directives.
Only one active directive is allowed for each database name and each profile name.

See the following topics for details about the attributes that can be defined in each dbplan directive.

Parent topic: ALTER IORMPLAN

7.7.1.7.3 Directives for a Cluster Plan

The directives for a cluster plan (clusterplan) use the following syntax:

( name=cluster_name [, share=number] [, limit=number] )

Usage Notes

The name attribute must be the first attribute listed in each directive. Otherwise, the order of attributes is not important.
The cluster plan can have a maximum of 1024 directives.
You cannot have multiple directives with the same cluster name.

See the following topics for details about the attributes that can be defined in each clusterplan directive.

Parent topic: ALTER IORMPLAN

7.7.1.7.4 name Attribute

Purpose

The name attribute identifies the entity that is the subject of the directive.

Syntax

ALTER IORMPLAN 
   catplan = (( name=category_name, ... ) ... )

ALTER IORMPLAN 
   dbplan = (( name={ db_name | profile_name }, ... ) ... )

ALTER IORMPLAN 
   clusterplan = (( name=cluster_name, ... ) ... )

Usage Notes

For directives in a category plan (catplan), the name attribute specifies the category name. Oracle Database manages intra-database resources using Database Resource Manager (DBRM). DBRM manages resources across consumer groups, and each consumer group is associated with a category. The catplan category name is associated with any DBRM category having the same name.
For directives in a database plan (dbplan), the name attribute usually identifies the database that is associated with the directive. However, when the directive includes type=profile, the name attribute specifies the profile name.

In directives that identify a database, the name value usually matches with the value of the DB_UNIQUE_NAME database parameter. The exception is where the directive uses the role attribute to manage an Oracle Data Guard configuration. For further details, see role Attribute.
For directives in a cluster plan (clusterplan), the name attribute identifies the Oracle Grid Infrastructure cluster that is associated with the directive.

The cluster plan (clusterplan) uses ASM-scoped security for cluster identification. The value of the name attribute must match the asm field in the cellkey.ora file, which is part of the ASM-scoped security definition for the cluster. If ASM-scoped security is not configured correctly, the cluster cannot be identified and associated with a directive in the cluster plan. In this case, even if it is named in the cluster plan, the cluster is treated the same as an unidentified cluster, receiving one share of IO resources by default.
The name attribute must be the first attribute in a directive.
The name attribute value cannot start with an underscore (_).
Each name must be followed by at least one other attribute, for example:
- (name=sales, share=8)
- (name=oltpdg, limit=80)
- (name=dwh, flashcachesize=50G)
There are two special name values:
- OTHER: names a special directive that defines the resource allocation for all other entities that are not specified in the plan. All entities that are not explicitly named in the plan share the resources associated with the OTHER directive.
  
  The OTHER directive is used in database plans and category plans that use allocation-based resource management; that is, resource allocation defined using the level and allocation attributes. Plans with allocation-based directives must also include an OTHER directive.
  
  In a database plan, the limit attribute can also be defined in the OTHER directive.
- DEFAULT: names a special directive that defines the resource allocation for each database that is not specified in a database plan. Every database that is not explicitly named in the plan receives the resources in the DEFAULT directive.
  
  The DEFAULT directive is available only in database plans that use share-based resource allocation; that is, resource allocation defined using the share attribute.

Example 7-41 Using the name Attribute in a Database Plan

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=db1, limit=50),                         -
                 (name=db2, limit=50),                         -
                 (name=OTHER, level=1, allocation=25))

Example 7-42 Setting a Database Plan with a DEFAULT Directive

This example shows how to use the DEFAULT directive to set the default share allocation for all databases except dev01 and dev02.

CellCLI> ALTER IORMPLAN                                             -
         dbplan=((name=dev01, share=1, limit=50, flashlog=off),     -
                 (name=dev02, share=1, limit=25, flashcache=off),   -
                 (name=DEFAULT, share=4))

Parent topic: ALTER IORMPLAN

7.7.1.7.5 share Attribute

Purpose

The share attribute controls share-based resource allocation, which specifies the relative priority for a database in a dbplan or a cluster in a clusterplan. A higher share value implies higher priority and more access to the I/O resources.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... share=number ... ) ... )

 ALTER IORMPLAN 
   clusterplan=(( name=cluster_name, ... share=number ... ) ... )

Usage Notes

share: Specifies the resource allocation share.

Valid values are 1 to 32, with 1 being the lowest share, and 32 being the highest share. The share value represents the relative importance of each entity. A higher share value implies higher priority and more access to resources. The sum of all share values in a plan cannot be greater than 32768.
Share-based resource allocation is the recommended method for a database plan (dbplan). For a cluster plan (clusterplan), share-based resource allocation is the only option.
In a database plan (dbplan) using share-based resource allocation, name=DEFAULT is used to define the default share for each database that is not explicitly specified in the dbplan.
Any cluster without an explicit share allocation is allocated one share by default. This includes any cluster not identified in the cluster plan (clusterplan).

Example 7-43 Setting a Database Plan Using the share Attribute

This example shows how to configure dbPlan using the share attribute.

CellCLI> ALTER IORMPLAN                                                 -
         dbplan=((name=sales01, share=4),                               -
                 (name=sales02, share=4),                               -
                 (name=fin01, share=3),                                 -
                 (name=fin02, share=2),                                 -
                 (name=dev01, share=1, limit=50, flashLog=off),         -
                 (name=dev02, share=1, limit=25, flashCache=off),       -
                 (name=DEFAULT, share=2))

Parent topic: ALTER IORMPLAN

7.7.1.7.6 allocation and level Attributes

Purpose

The level and allocation attributes control allocation-based resource management. You can use allocation-based resource management to control I/O distribution for a database in a dbplan or a workload category in a catplan.

Syntax

 ALTER IORMPLAN 
   catplan=(( name=category_name, level=number, allocation=number ) ... )

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... level=number, allocation=number ... ) ... )

Usage Notes

level: Specifies the allocation level.

Valid values are from 1 to 8. Resources are allocated to level 1 first, and then remaining resources are allocated to level 2, and so on.
allocation: Specifies the resource allocation as a percentage (0-100) within the level.

For each level, the sum of allocation values cannot exceed 100.
For allocation-based resource management, name=OTHER is used to define the resource allocation to share across all entities that are not specified in the IORM plan. Plans (dbplan or catplan) with allocation-based directives must also include a directive with name=OTHER.

Example 7-44 Using the level and allocation Attributes

These examples show the ALTER command with the level and allocation attributes.

CellCLI> ALTER IORMPLAN                                          -
        catplan=((name=administrative, level=1, allocation=80),  -
                 (name=interactive, level=2, allocation=90),     -
                 (name=batch, level=3, allocation=80),           -
                 (name=maintenance, level=4, allocation=50),     -
                 (name=other, level=4, allocation=50)),          -
        dbplan=((name=sales_prod, level=1, allocation=80),       -
                (name=finance_prod, level=1, allocation=20),     -
                (name=sales_dev, level=2, allocation=100),       -
                (name=sales_test, level=3, allocation=50),       -
                (name=other, level=3, allocation=50))

CellCLI> ALTER IORMPLAN                                         -
         catplan=((name=interactive, level=1, allocation=90),   -
                  (name=batch, level=2, allocation=80),         -
                  (name=maintenance, level=3, allocation=50),   -
                  (name=other, level=3, allocation=50))

Parent topic: ALTER IORMPLAN

7.7.1.7.7 limit Attribute

Purpose

The limit attribute specifies the maximum flash I/O utilization limit.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... limit=number ... ) ... )

 ALTER IORMPLAN 
   clusterplan=(( name=cluster_name, ... limit=number ... ) ... )

Usage Notes

limit: Specifies the maximum flash I/O utilization limit as a percentage of the available resources. The attribute applies only to I/O on flash devices, which includes flash-based grid disks and Exadata Smart Flash Cache.

Valid values are 1 to 100. If a limit is specified, then excess capacity is never used by the associated database or cluster. Consequently, it is possible for flash devices to run below full capacity when limits are specified.

Note:
Specifying low limit values can have a significant performance impact and is generally not advisable.
Resource management using limits is ideal for pay-for-performance use cases but should not be used to implement fairness. Instead, use the share attribute to ensure equitable distribution of I/O resources.

Example 7-45 Using the limit Attribute with a Database Plan

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=db1, limit=40),                         -
                 (name=db2, limit=40),                         -
                 (name=DEFAULT, limit=20))

Parent topic: ALTER IORMPLAN

7.7.1.7.8 flashcache Attribute

Purpose

The flashcache attribute controls use of Exadata Smart Flash Cache by a database. This ensures that cache space is reserved for mission-critical databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcache={on|off}  ... ) ... )

Usage Notes

By default, any database can use Exadata Smart Flash Cache unless it is affected by a directive that specifies flashcache=off.
flashcache=off is invalid in a directive that contains the flashcachemin, flashcachelimit, or flashcachesize attributes.

Example 7-46 Setting Flash Cache Use in a Database Plan

This example shows how to enable Flash Cache use in a database plan.

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=sales_prod, flashcache=on),             -
                 (name=sales_dev, flashcache=on),              -
                 (name=sales_test, flashcache=off),            -
                 (name=DEFAULT, flashcache=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.9 xrmemcache Attribute

Purpose

The xrmemcache attribute controls use of the Exadata RDMA Memory Cache (XRMEM cache) by a database. This ensures that cache space is reserved for mission-critical databases.

Syntax

ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcache={on|off}  ... ) ... )

Usage Notes

By default, any database can use the XRMEM cache unless it is affected by a directive that specifies xrmemcache=off.
xrmemcache=off is invalid in a directive that contains the xrmemcachemin, xrmemcachelimit, or xrmemcachesize attributes.
On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcache instead of xrmemcache in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcache.

Example 7-47 Setting XRMEM Cache Use in a Database Plan

This example shows how to enable XRMEM cache use in a database plan.

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=sales_prod, xrmemcache=on),             -
                 (name=sales_dev, xrmemcache=off),             -
                 (name=sales_test, xrmemcache=off),            -
                 (name=DEFAULT, xrmemcache=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.10 pmemcache Attribute

Purpose

The pmemcache attribute controls use of the persistent memory (PMEM) cache by a database. This ensures that cache space is reserved for mission-critical databases.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcache Attribute.

Syntax

ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcache={on|off}  ... ) ... )

Usage Notes

By default, any database can use the PMEM cache unless it is affected by a directive that specifies pmemcache=off.
pmemcache=off is invalid in a directive that contains the pmemcachemin, pmemcachelimit, or pmemcachesize attributes.

Example 7-48 Setting PMEM Cache Use in a Database Plan

This example shows how to enable PMEM cache use in a database plan.

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=sales_prod, pmemcache=on),             -
                 (name=sales_dev, pmemcache=off),             -
                 (name=sales_test, pmemcache=off),            -
                 (name=DEFAULT, pmemcache=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.11 flashlog Attribute

Purpose

The flashlog attribute controls use of Exadata Smart Flash Log by a database. This ensures that Exadata Smart Flash Log is reserved for mission-critical databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashlog={on|off}  ... ) ... )

Usage Notes

By default, any database can use Exadata Smart Flash Log unless it is affected by a directive that specifies flashlog=off.

Example 7-49 Setting Flash Log Use in a Database Plan

This example shows how to control Flash Log use in a database plan.

CellCLI> ALTER IORMPLAN                                                                       -
         dbplan=((name=oltp, level=1, allocation=80, flashcache=on, flashlog=on),             -
                 (name=dss, level=1, allocation=20, limit=50, flashcache=off, flashlog=off),  -
                 (name=OTHER, level=2, allocation=100),                                       -
                 (name=DEFAULT, flashcache=off, flashlog=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.12 xrmemlog Attribute

Purpose

The xrmemlog attribute controls use of the XRMEM log by a database. This ensures that commit acceleration is reserved for mission-critical databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemlog={on|off}  ... ) ... )

Usage Notes

By default, any database can use XRMEM log unless it is affected by a directive that specifies xrmemlog=off.
On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory commit accelerator, previously known as PMEM log, is now called XRMEM log.

For backward compatibility, on Exadata X8M and X9M systems, you can use pmemlog instead of xrmemlog in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemlog.

Example 7-50 Setting XRMEM Log Use in a Database Plan

This example shows how to control XRMEM Log use in a database plan.

CellCLI> ALTER IORMPLAN                                                                      -
         dbplan=((name=oltp, level=1, allocation=80, xrmemcache=on, xrmemlog=on),              -
                 (name=dss, level=1, allocation=20, limit=50, xrmemcache=off, xrmemlog=off),   -
                 (name=OTHER, level=2, allocation=100),                                      -
                 (name=DEFAULT, xrmemcache=off, xrmemlog=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.13 pmemlog Attribute

Purpose

The pmemlog attribute controls use of the persistent memory commit accelerator (PMEM log) by a database. This ensures that commit acceleration is reserved for mission-critical databases.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemlog Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemlog={on|off}  ... ) ... )

Usage Notes

By default, any database can use PMEM log unless it is affected by a directive that specifies pmemlog=off.

Example 7-51 Setting PMEM Log Use in a Database Plan

This example shows how to control PMEM Log use in a database plan.

CellCLI> ALTER IORMPLAN                                                                      -
         dbplan=((name=oltp, level=1, allocation=80, pmemcache=on, pmemlog=on),              -
                 (name=dss, level=1, allocation=20, limit=50, pmemcache=off, pmemlog=off),   -
                 (name=OTHER, level=2, allocation=100),                                      -
                 (name=DEFAULT, pmemcache=off, pmemlog=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.14 flashcachelimit Attribute

Purpose

The flashcachelimit attribute defines a soft limit for space usage in Exadata Smart Flash Cache. If the cache is not full, the limit can be exceeded.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcachelimit=number ... ) ... )

Usage Notes

You specify the value for flashcachelimit in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for flashcachelimit must be at least 4 MB.
The flashcachelimit and flashcachesize attributes cannot be specified in the same directive.
The value for flashcachelimit cannot be smaller than flashcachemin, if it is specified.

Example 7-52 Specifying Flash Cache Quotas in a Database Plan

This example shows how to configure flash cache quotas in a database plan.

CellCLI> ALTER IORMPLAN                                                          -
         dbplan=((name=prod, share=8, flashCacheMin=400M),                       -
                 (name=dev,  share=2, flashCacheMin=100M, flashCacheLimit=200M), -
                 (name=test, share=1, limit=40, flashCacheLimit=20M))

Parent topic: ALTER IORMPLAN

7.7.1.7.15 flashcachemin Attribute

Purpose

The flashcachemin attribute specifies a minimum guaranteed space allocation in Exadata Smart Flash Cache.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcachemin=number ... ) ... )

Usage Notes

You specify the value for flashcachemin in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for flashcachemin must be at least 4 MB.
In any plan, the sum of all flashcachemin values cannot exceed the size of Exadata Smart Flash Cache.
If flashcachelimit is specified, then the value for flashcachemin cannot exceed flashcachelimit.
If flashcachesize is specified, then the value for flashcachemin cannot exceed flashcachesize.

Parent topic: ALTER IORMPLAN

7.7.1.7.16 flashcachesize Attribute

Purpose

The flashcachesize attribute defines a hard limit for space usage in Exadata Smart Flash Cache. The limit cannot be exceeded, even if the cache is not full.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcachesize=number ... ) ... )

Usage Notes

You specify the value for flashcachesize in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for flashcachesize must be at least 4 MB.
The flashcachelimit and flashcachesize attributes cannot be specified in the same directive.
The value for flashcachesize cannot be smaller than flashcachemin, if it is specified.
In an IORM plan, if the size of Exadata Smart Flash Cache can accommodate all of the flashcachemin and flashcachesize allocations, then each flashcachesize definition represents a guaranteed space allocation.

However, starting with Oracle Exadata System Software release 19.2.0 you can use the flashcachesize attribute to over-provision space in Exadata Smart Flash Cache. Consequently, if the size of Exadata Smart Flash Cache cannot accommodate all of the flashcachemin and flashcachesize allocations, then only flashcachemin is guaranteed.

Parent topic: ALTER IORMPLAN

7.7.1.7.17 xrmemcachelimit Attribute

Purpose

The xrmemcachelimit attribute defines a soft limit for space usage in the Exadata RDMA Memory Cache (XRMEM cache). If the cache is not full, the limit can be exceeded.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcachelimit=number ... ) ... )

Usage Notes

You specify the value for xrmemcachelimit in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for xrmemcachelimit must be at least 4 MB.
The xrmemcachelimit and xrmemcachesize attributes cannot be specified in the same directive.
The value for xrmemcachelimit cannot be smaller than xrmemcachemin, if it is specified.
On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcachelimit instead of xrmemcachelimit in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcachelimit.

Parent topic: ALTER IORMPLAN

7.7.1.7.18 xrmemcachemin Attribute

Purpose

The xrmemcachemin attribute specifies a minimum guaranteed space allocation in the Exadata RDMA Memory Cache (XRMEM cache).

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcachemin=number ... ) ... )

Usage Notes

You specify the value for xrmemcachemin in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for xrmemcachemin must be at least 4 MB.
In any plan, the sum of all xrmemcachemin values cannot exceed the size of the XRMEM cache.
If xrmemcachelimit is specified, then the value for xrmemcachemin cannot exceed xrmemcachelimit.
If xrmemcachesize is specified, then the value for xrmemcachemin cannot exceed xrmemcachesize.
On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcachemin instead of xrmemcachemin in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcachemin.

Parent topic: ALTER IORMPLAN

7.7.1.7.19 xrmemcachesize Attribute

Purpose

The xrmemcachesize attribute defines a hard limit for space usage in the Exadata RDMA Memory Cache (XRMEM cache). The limit cannot be exceeded, even if the cache is not full.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcachesize=number ... ) ... )

Usage Notes

You specify the value for xrmemcachesize in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for xrmemcachesize must be at least 4 MB.
The xrmemcachelimit and xrmemcachesize attributes cannot be specified in the same directive.
The value for xrmemcachesize cannot be smaller than xrmemcachemin, if it is specified.
In an IORM plan, if the size of the XRMEM cache can accommodate all of the xrmemcachemin and xrmemcachesize allocations, then each xrmemcachesize definition represents a guaranteed space allocation.

However, you can use the xrmemcachesize attribute to over-provision space in the XRMEM cache. Consequently, if the XRMEM cache size cannot accommodate all of the xrmemcachemin and xrmemcachesize allocations, then only xrmemcachemin is guaranteed.
On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcachesize instead of xrmemcachesize in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcachesize.

Parent topic: ALTER IORMPLAN

7.7.1.7.20 pmemcachelimit Attribute

Purpose

The pmemcachelimit attribute defines a soft limit for space usage in the persistent memory (PMEM) cache. If the cache is not full, the limit can be exceeded.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcachelimit Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcachelimit=number ... ) ... )

Usage Notes

You specify the value for pmemcachelimit in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for pmemcachelimit must be at least 4 MB.
The pmemcachelimit and pmemcachesize attributes cannot be specified in the same directive.
The value for pmemcachelimit cannot be smaller than pmemcachemin, if it is specified.

Parent topic: ALTER IORMPLAN

7.7.1.7.21 pmemcachemin Attribute

Purpose

The pmemcachemin attribute specifies a minimum guaranteed space allocation in the persistent memory (PMEM) cache.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcachemin Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcachemin=number ... ) ... )

Usage Notes

You specify the value for pmemcachemin in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for pmemcachemin must be at least 4 MB.
In any plan, the sum of all pmemcachemin values cannot exceed the size of the PMEM cache.
If pmemcachelimit is specified, then the value for pmemcachemin cannot exceed pmemcachelimit.
If pmemcachesize is specified, then the value for pmemcachemin cannot exceed pmemcachesize.

Parent topic: ALTER IORMPLAN

7.7.1.7.22 pmemcachesize Attribute

Purpose

The pmemcachesize attribute defines a hard limit for space usage in the persistent memory (PMEM) cache. The limit cannot be exceeded, even if the cache is not full.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcachesize Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcachesize=number ... ) ... )

Usage Notes

You specify the value for pmemcachesize in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.
The value for pmemcachesize must be at least 4 MB.
The pmemcachelimit and pmemcachesize attributes cannot be specified in the same directive.
The value for pmemcachesize cannot be smaller than pmemcachemin, if it is specified.
In an IORM plan, if the size of the PMEM cache can accommodate all of the pmemcachemin and pmemcachesize allocations, then each pmemcachesize definition represents a guaranteed space allocation.

However, you can use the pmemcachesize attribute to over-provision space in the PMEM cache. Consequently, if the PMEM cache size cannot accommodate all of the pmemcachemin and pmemcachesize allocations, then only pmemcachemin is guaranteed.

Parent topic: ALTER IORMPLAN

7.7.1.7.23 asmcluster Attribute

Purpose

Starting with Oracle Exadata System Software release 19.1.0, you can use the asmcluster attribute to distinguish between databases with the same name running in different Oracle ASM clusters.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... asmcluster=asm_cluster_name ... ) ... )

Usage Notes

To use the asmcluster attribute, ASM-scoped security must be configured.
The value of the asmcluster attribute must match the asm field in the cellkey.ora file, which is part of the ASM-scoped security definition for the cluster.
You cannot use the asmcluster attribute in conjunction with allocation-based resource management (using the level and allocation attributes).

Example 7-53 Using the asmcluster Attribute

This example shows how to use the asmcluster attribute to distinguish between databases with the same name.

CellCLI> ALTER IORMPLAN                                                           -
         dbPlan=((name=prod1, share=4, flashcachemin=5G, asmcluster=cluster1),    -
                 (name=prod1, share=2, limit=80, asmcluster=cluster2),            -
                 (name=prod2, share=2, flashcachelimit=2G, asmcluster=cluster1),  -
                 (name=DEFAULT, share=1, flashcachelimit=1G))

Parent topic: ALTER IORMPLAN

7.7.1.7.24 role Attribute

Purpose

The role attribute enables you specify different plan directives based on the Oracle Data Guard database role. The directive for a database is applied only when the database is in the specified role. New directives are automatically applied by IORM when a database changes roles because of an Oracle Data Guard switchover or fail-over.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... role={primary|standby} ... ) ... )

Usage Notes

Directives using the role attribute must be defined in matched pairs, using the same name value. That is, for each directive that specifies role=primary, you must have a corresponding directive that specifies role=standby. Likewise, each standby directive must have a matching primary directive.
You must use the same name value to identify the database in both the primary directive and the standby directive. To achieve this, you can:
- Set the name attribute to the value of the DB_UNIQUE_NAME parameter in the standby database, and set the DB_NAME parameter in the primary database to the same value. This option allows you to define specific directives to manage multiple standby databases.
- Set the name attribute to the value of the DB_NAME database parameter, which will be the same in the primary and standby databases. This option is not recommended for cases supporting multiple standby databases because all of the cell metrics relating to the standby databases are aggregated under one name.
If the role attribute is not specified, then the directive applies regardless of the database role.
For allocation-based resource management (using the level and allocation attributes), the sum of the allocation values (including OTHER) cannot exceed 100 for every combination of level and role.
The role attribute cannot be specified in DEFAULT or OTHER directives.

Example 7-54 Using the role Attribute with Allocation-Based Resource Management

CellCLI> ALTER IORMPLAN                                                     -
         dbplan=((name=sales_prod, level=1, allocation=30, role=primary),   -
                 (name=sales_prod, level=1, allocation=20, role=standby),   -
                 (name=sales2, level=1, allocation=20),                     -
                 (name=other, level=3, allocation = 50))

Example 7-55 Using the role Attribute with Share-Based Resource Allocation

CellCLI> ALTER IORMPLAN                                               -
         dbplan=((name=salesprod, share=4, role=primary),             -
                 (name=salesprod, share=1, limit=50, role=standby),   -
                 (name=finance, share=4),                             -
                 (name=hr, share=2))

Parent topic: ALTER IORMPLAN

7.7.1.7.25 type Attribute

Purpose

The type attribute enables you to create a profile, or template, to ease management and configuration of resource plans in environments with many databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... type={database|profile} ... ) ... )

Usage Notes

type: Specifies the directive type. Valid values are database or profile:
- type=database: Specifies a directive that applies to a specific database. If type in not specified, then the directive defaults to the database type.
- type=profile: Specifies a directive that applies to a profile rather than a specific database. To associate a database with an IORM profile, you must set the database initialization parameter db_performance_profile to the value of the profile name. Databases that map to a profile inherit the settings specified in the profile.
  
  A profile directive can contain any attributes except level, allocation, asmcluster, and role.
  
  A profile name cannot be OTHER or DEFAULT.
The dbplan can contain a combination of profile and database directives.

Example 7-56 Creating a Profile

This example shows how to specify profiles as part of a database plan.

CellCLI> ALTER IORMPLAN                                -
         dbplan=((name=gold, share=10, type=profile),  -
                 (name=silver, share=5, type=profile), -
                 (name=bronze, share=1, type=profile))

Parent topic: ALTER IORMPLAN