What Solutions Does the Resource Manager Provide for Workload Management?

When database resource allocation decisions are left to the operating system, you may encounter the following problems with workload management:

• Excessive overhead

  Excessive overhead results from operating system context switching between Oracle Database server processes when the number of server processes is high.

• Inefficient scheduling

  The operating system deschedules database servers while they hold latches, which is inefficient.

• Inappropriate allocation of resources

  The operating system distributes resources equally among all active processes and cannot prioritize one task over another.

• Inability to manage database-specific resources, such as parallel execution servers and active sessions

The Resource Manager helps to overcome these problems by allowing the database more control over how hardware resources are allocated. In an environment with multiple concurrent user sessions that run jobs with differing priorities, all sessions should not be treated equally. The Resource Manager enables you to classify sessions into groups based on session attributes, and to then allocate resources to those groups in a way that optimizes hardware utilization for your application environment.

With the Resource Manager, you can:

• Guarantee certain sessions a minimum amount of CPU regardless of the load on the system and the number of users.

• Distribute available CPU by allocating percentages of CPU time to different users and applications. In a data warehouse, a higher percentage can be given to ROLAP (relational online analytical processing) applications than to batch jobs.

• Limit the degree of parallelism of any operation performed by members of a group of users.

• Manage the order of parallel statements in the parallel statement queue. Parallel statements from a critical application can be enqueued ahead of parallel statements from a low priority group of users.

• Limit the number of parallel servers that a group of users can use. This ensures that all the available parallel servers are not allocated to only one group of users.

• Create an active session pool. An active session pool consists of a specified maximum number of user sessions allowed to be concurrently active within a group of users. Additional sessions beyond the maximum are queued for execution, but you can specify a timeout period, after which queued jobs will terminate. The active session pool limits the total number of sessions actively competing for resources, thereby enabling active sessions to make faster progress.

• Manage runaway sessions or calls in the following ways:

  • By placing an absolute limit on the percentage of CPU that a group can consume

  • By detecting when a session or call consumes more than a specified amount of CPU or I/O, and then automatically either terminating the session or call, or switching it to a consumer group that is allocated a small amount of CPU, which would in effect mitigate the impact of the runaway session or call

• Prevent the execution of operations that the optimizer estimates will run for a longer time than a specified limit.

• Limit the amount of time that a session can be idle. This can be further defined to mean only sessions that are blocking other sessions.

• Allow a database to use different resource plans, based on changing workload requirements. You can dynamically change the resource plan, for example, from a daytime resource plan to a nighttime resource plan, without having to shut down and restart the instance. You can also schedule a resource plan change with Oracle Scheduler. 

转载于:https://www.cnblogs.com/gispf/p/3770761.html