1.2.19.2 Intra-Vault Resource Management Using Exascale Resource Profiles

Intra-vault resource management defines how resources are shared by the various Oracle databases and block store volumes that use a vault. Within Exascale, intra-vault resource management is governed by resource profiles.

By default, every Exascale client (Oracle database or block store volume) has access to all of the resources in their associated vault. Furthermore, I/O resources are shared equally when the system is under load.

To enable more granular I/O resource management, you can associate each Exascale client with a resource profile. You can define any number of resource profiles, but you can only associate an Exascale client with one resource profile at a time.

Each resource profile contains the following resource limits and settings:

• I/O Bandwidth (IOPS) — For each Exascale media type (HC and EF), you can define a limit value and a share value. While I/O bandwidth utilization is less than the vault capacity, the limit controls each client. However, when I/O bandwidth utilization reaches capacity, resource allocation across all clients is further governed by the share values.

  The limit value specifies the absolute limit of I/O bandwidth available to each client associated with the resource profile. The value represents a fraction out of 10000. For example, a value of 1 represents a limit of 1/10000 (0.01%), 5000 represents 5000/10000 (50%), 10000 represents 10000/10000 (100%, or effectively unlimited), and so on. If not specified, the default limit value is 10000 (effectively unlimited).

  The share value defines the proportional share of I/O bandwidth available to each client associated with the resource profile. Each client’s share is relative to all other client shares. A higher share value implies higher priority. For example, consider a system with 2 clients, where client A has a share value of 2 and client B has a share value of 1. In this case, when I/O bandwidth utilization reaches capacity, client A gets 2/3 (66.67%) of the I/O bandwidth, which is twice as much as client B (1/3, or 33.33%). Now, consider adding client C with a share value of 7. After the addition of client C, when I/O bandwidth utilization reaches capacity, client A gets 2/10 (20%) of the I/O bandwidth, which is still twice as much as client B (1/10, or 10%), but client C gets 7/10 (70%) of the I/O bandwidth. The range of valid values is 1-100. If not specified, the default share value is 1.

• Flash Cache and Exadata RDMA Memory (XRMEM) Cache — For each type of cache, you can enable or disable use of the cache by clients associated with the resource profile. Then, for each enabled cache type, you can specify a minimum and maximum usage value in the range of 0 to 10000.

  The minimum value guarantees a portion of the cache for each client associated with the resource profile. Nominally, the value represents a fraction out of 10000. For example, a value of 1 represents a limit of 1/10000 (0.01%), 5000 represents 5000/10000 (50%), 10000 represents 10000/10000 (100%, or effectively unlimited), and so on. However, if the sum of all minimum values exceeds 10000 across all clients and resource profiles, then all values are scaled down proportionally to ensure that minimum guarantees can be honored. If not specified, the default minimum value is 0 (no guaranteed minimum).

  The maximum value specifies the absolute limit of cache space available to each client associated with the resource profile. The value represents a fraction out of 10000. For example, a value of 1 represents a limit of 1/10000 (0.01%), 5000 represents 5000/10000 (50%), 10000 represents 10000/10000 (100%, or effectively unlimited), and so on. If not specified, the default value is 10000 (effectively unlimited).

• Flash Log — You can enable or disable use of the flash log accelerator for clients associated with the resource profile. If not specified, the default setting enables the use of flash log.

You can also create a system-reserved resource profile named $UNASSIGNED. All Exascale clients not explicitly associated with a resource profile are automatically governed by the $UNASSIGNED profile. The $UNASSIGNED resource profile contains only two modifiable attributes, which specify the maximum fraction (out of 10000) of flash cache space and XRMEM cache space assigned to the profile. All other attributes of the $UNASSIGNED resource profile use the previously described default values.

All Exascale clients governed by the $UNASSIGNED profile share the specified cache resources. The behavior differs from regular resource profiles, where each application of the resource profile defines the resource allocation for one associated client.

If you do not create the $UNASSIGNED resource profile, all unassigned Exascale clients share any unassigned flash cache space and XRMEM cache space. If there is no unassigned space to share, the system automatically reserves 5% of the cache space for unassigned Exascale clients.

Resource over-provisioning across multiple clients and resource profiles is allowed. For over-provisioned resources, the system automatically adjusts the resource shares to maintain the relative proportions for each client.

For example, consider a system with the following resource profiles:

• GOLD resource profile:

  • EF IOPS: share=11, limit=5100
  • HC IOPS: share=40, limit=5200
  • Flash Cache: enabled=TRUE, minimum=500, maximum=1000
  • XRMEM Cache: enabled=TRUE, minimum=400, maximum=800
  • Flash Log: enabled=TRUE

• SILVER resource profile:

  • EF IOPS: share=6, limit=2500
  • HC IOPS: share=20, limit=2500
  • Flash Cache: enabled=TRUE, minimum=300, maximum=600
  • XRMEM Cache: enabled=TRUE, minimum=200, maximum=400
  • Flash Log: enabled=TRUE

• BRONZE resource profile:

  • EF IOPS: share=3, limit=900
  • HC IOPS: share=10, limit=1500
  • Flash Cache: enabled=TRUE, minimum=200, maximum=500
  • XRMEM Cache: enabled=TRUE, minimum=100, maximum=200
  • Flash Log: enabled=FALSE

• $UNASSIGNED resource profile:

  • Flash Cache: maximum=1000
  • XRMEM Cache: maximum=500

Also, imagine that the system hosts 8 databases, which are associated with the resource profiles as follows:

• DB1 and DB2 are associated with the GOLD resource profile.
• DB3 is associated with the SILVER resource profile.
• DB4 and DB5 are associated with the BRONZE resource profile.
• DB6, DB7, and DB8 are not explicitly associated with any resource profile. Therefore, they are implicitly associated with the $UNASSIGNED resource profile.

Now consider how the resource profiles are used to manage a specific resource, such as I/O bandwidth on high capacity storage media (HC IOPS):

• While the resource utilization is less than 100% of the vault capacity, each database is capped using the limit value. For example:

  • DB1: 5200 (52%)
  • DB2: 5200 (52%)
  • DB3: 2500 (25%)
  • DB4: 1500 (15%)
  • DB5: 1500 (15%)
  • DB6: 10000 (100%, default value, effectively unlimited)
  • DB7: 10000 (100%, default value, effectively unlimited)
  • DB8: 10000 (100%, default value, effectively unlimited)

  If the limits keep utilization to less than 100% of the vault capacity, then no further intervention is required.

• While the resource utilization is 100%, the resource is allocated proportionally using the share value. For example:

  • DB1: 40
  • DB2: 40
  • DB3: 20
  • DB4: 10
  • DB5: 10
  • DB6: 1 (default value)
  • DB7: 1 (default value)
  • DB8: 1 (default value)

  In this example, the sum of the shares is 123, resulting in the following resource allocations:

  • DB1: 40/123 (35.52%)
  • DB2: 40/123 (35.52%)
  • DB3: 20/123 (16.26%)
  • DB4: 10/123 (8.13%)
  • DB5: 10/123 (8.13%)
  • DB6: 1/123 (0.81%)
  • DB7: 1/123 (0.81%)
  • DB8: 1/123 (0.81%)