Cloud database enables administrators to scale up and down the resource usage according to the business requirements. Oracle 12c renders multi-tenancy to manage multiple pluggable databases within a multitenant container database. In an Exadata, at the compute nodes, the resource manager controls the resources among pluggable databases, and all this resource management is trickled down to the storage servers, where IORM controls the resources. This presentation lucidly explains as how a business can leverage the benefits of 12C multi-tenancy, DBRM, and IORM in an Exadata realm to have an ideal cloud based resource management.
We are a managed service AND a solution provider of elite database and System Administration skills in Oracle, MySQL and SQL Server
Cloud computing is a datacenter configuration and provisioning strategy. Cloud computing offers flexibility (the ability to move
resources around), reliability (continuous operation), and elasticity (the ability to increase or decrease
resources for a given application as needed)
Parallel_server-limit works with the parallel_server_target. Parallel_server_target is system wide parameter. PARALLEL_SERVERS_TARGET specifies the number of parallel server processes allowed to run parallel statements before statement queuing will be used. For example, if the PARALLEL_SERVERS_TARGET initialization parameter is set to 200 and the parallel_server_limit parameter for a PDB is set to 10%, then utilization limit for the PDB is 20 parallel execution servers (200 X .10).
MGMT_MTH: Resource allocation method for specifying how much CPU each consumer group or subplan gets. 'EMPHASIS', the default method, is for single-level or multilevel plans that use percentages to specify how CPU is distributed among consumer groups. 'RATIO' is for single-level plans that use ratios to specify how CPU is distributed.
There are two methods for CPU allocation. Default is āEmphasisā which deals in percentages for the levels, whereas other one is āRATIOā, which is for plans for only one level.
Specifies the consumer group to which a session is switched if switch criteria are met. If the group name is CANCEL_SQL, then the current call is canceled when switch criteria are met. If the group name is CANCEL_SQL, then the SWITCH_FOR_CALL parameter is always set to TRUE, overriding the user-specified setting.
If the group name is KILL_SESSION, then the session is killed when switch criteria are met.
If the group name is LOG_ONLY, then information about the session is recorded in real-time SQL monitoring, but no specific action is taken for the session.
If NULL, then the session is not switched and no additional logging is performed. The default is NULL. An error is returned if this parameter is set to NULL and any other switch parameter is set to non-NULL.
he following PL/SQL block creates a resource plan directive for the OLTP group that temporarily switches any session in that group to the LOW_GROUP consumer group if the session exceeds 100 logical I/O requests. The session is returned to its original group after the offending top call is complete.
First, the database sends IO requests to the Exadata storage cells. These requests are bundled in an iDB message and include metadata indicating their consumer group and optionally, resource category assigned to the IO request. The requests are sent to different CELLSRV IO queues, based on the order in which they were sent to the storage cell. The IO requests are then passed to from the CELLSRV IO queue to IORM; at which point any resource plans are also evaluated. IORM then evaluates the IO requests from each of the "input" consumer groups and databases, validates their priority against the configured resource plans, and schedules the IO into the cell disk queues.
To disable IORM, use the following CellCLI command to return IORM to the "basic" objective.Ā Note that "alter iormplan inactive" is deprecated in versions 11.2.3.2 and above because IORM is minimally always in "basic" mode.Ā Running "alter iormplan inactive" will result in the error message "IORMPLAN status cannot be set to inactive".
IORM only manages I/O for physical disks. I/O requests for objects in the flash cache or on flash-based
grid disks are not managed by IORM.
It ties up the CPU allocations to the IO allocations. You donāt assign anything at the IORM level at cell. You just activate the IORM plan at storage cell.
These metrics can be used to answer the following, common questions:
Which database or consumer group is utilizing the disk the most?Ā Use the disk utilization metrics to answer this question.Ā You can also use the disk IOPS metrics.Ā However, the total number of IOPS that can be sustained by the disk is extremely dependent on the ratio of reads vs writes, the location of the I/Os within the disk, and the ratio of small vs large I/Os.Ā Therefore, we recommend using the disk utilization metrics.
Am I getting good latencies for my OLTP database or consumer group?Ā The I/O latency, as seen by the database, is determined by the flash cache hit rate, the disk latency, and the IORM wait time.Ā OLTP I/Os are small, so you should focus on the disk latency for small reads and writes.Ā You can use IORM to improve the disk latency by giving high resource allocations to the OLTP databases and consumer groups.Ā If necessary, you can also use the "low latency" objective.Ā You can also decrease the IORM wait time byĀ giving high resource allocations to the critical databases and consumer groups.Ā
What is the flash cache hit rate for my database or consumer group?Ā For OLTP databases and consumer groups, you should expect the flash cache to be used for a significant number of I/Os.Ā Since the latency of flash cache I/Os is very low, the I/O response time, as seen by the database, can be optimized by improving the flash cache hit rate for critical workloads.
How much is I/O Resource Manager affecting my database or consumer group?Ā If IORM is enabled, then IORM may delay issuing an I/O when the disks are under heavy load or when a database or consumer group has reached its I/O utilization limit, if any.Ā IORM may also delay issuing large I/Os when it is optimizing for low latencies for OLTP workloads.Ā These delays are reflected in the "average queue time" metrics.Ā You can decrease the delays for critical databases and consumer groups by increasing their resource allocation.Ā
These metrics can be used to answer the following, common questions:
Which database or consumer group is utilizing the disk the most?Ā Use the disk utilization metrics to answer this question.Ā You can also use the disk IOPS metrics.Ā However, the total number of IOPS that can be sustained by the disk is extremely dependent on the ratio of reads vs writes, the location of the I/Os within the disk, and the ratio of small vs large I/Os.Ā Therefore, we recommend using the disk utilization metrics.
Am I getting good latencies for my OLTP database or consumer group?Ā The I/O latency, as seen by the database, is determined by the flash cache hit rate, the disk latency, and the IORM wait time.Ā OLTP I/Os are small, so you should focus on the disk latency for small reads and writes.Ā You can use IORM to improve the disk latency by giving high resource allocations to the OLTP databases and consumer groups.Ā If necessary, you can also use the "low latency" objective.Ā You can also decrease the IORM wait time byĀ giving high resource allocations to the critical databases and consumer groups.Ā
What is the flash cache hit rate for my database or consumer group?Ā For OLTP databases and consumer groups, you should expect the flash cache to be used for a significant number of I/Os.Ā Since the latency of flash cache I/Os is very low, the I/O response time, as seen by the database, can be optimized by improving the flash cache hit rate for critical workloads.
How much is I/O Resource Manager affecting my database or consumer group?Ā If IORM is enabled, then IORM may delay issuing an I/O when the disks are under heavy load or when a database or consumer group has reached its I/O utilization limit, if any.Ā IORM may also delay issuing large I/Os when it is optimizing for low latencies for OLTP workloads.Ā These delays are reflected in the "average queue time" metrics.Ā You can decrease the delays for critical databases and consumer groups by increasing their resource allocation.Ā
In most cases, a single-level I/O resource plan is sufficient. As they do with DBRM, multi-level IORM resource plans increase the complexity of measuring the effectiveness of your allocation scheme.