Resource manager: When the database resource allocation decisions are left to the operating systems, we can encounter

excessive overhead that results from the operating system context switching between the oracle server processes when the number of server processes is high and the operating system can deschedule the database servers while they hold latches, which is very inefficient. Also the OS distributes the resources equally among all the active processes and cannot prioritize one task over the another. Also OS cannot control the number of parallel servers that can allocated or the number of active session at the database level. With the help of the resource manager, we can overcome these problems by allowing database more control over how the hardware is being allocated. In an environment with multiple concurrent user sessions that run jobs with different priorities, all sessions should not be treated equally. The resource manager enables us to classify sessions into groups based on session attributes, and to then allocate resources to these groups in a way that optimizes the hardware utilization for our application environment. With the resource manager we can do the following tasks. 1. Guarantee that a certain session get minimum amount of CPU regardless of the load of the server and the number of users. 2. Distribute available CPU by allocating percentages of CPU time to different users and application. 3. Limit the degree of parallelism of any operation performed by members of the group of users. 4. Manage the order of parallel statements in the parallel statement queue. Parallel statements from the critical application can be enqueued ahead of parallel statements from a lower priority group of users. 5. Create an active server pool. An active sever pool consist of specified number of user sessions allowed to be concurrently active within a group of users. Additional sessions beyond the maximum are queued for execution, but we can specified the timeout period, after which the queued jobs will terminate. The active session pool limits the total number of sessions actively competing for resources, thereby enabling the active sessions to make the faster progress. 6. We can place an absolute limit on the percentage of the 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 a session or call, or switching it to the consumer group that is allocated smaller amount of CPU. 7. Prevent the execution of the operations that the optimizer estimates will run for a longer period of time. 8. Limit the amount of time that a session can be idle. This can be further defined to mean only session that are blocking other sessions. Allow a database to use different resource plans, based on changing workload requirements, we can dynamically change the resource plan. Elements of resource manager: The following are the various elements of the resource manager. Resource consumer group: A group of sessions that are grouped together based on resource requirements. The resource manager allocates resources to consumer groups, not to individual sessions. A resource consumer group is a collection of user sessions that are grouped together based on their processing needs. When a session is created, it is automatically mapped to the consumer group on mapping rules that we set up. As a DBA, we can manually switch a session to a different consumer group. Similarly an application can run the PL/SQL procedure that switches its session to a particular consumer group. Because the resource manager allocates the resources only to consumer groups, when a sessions becomes a member of the consumer group. Its resource allocation is determined by the allocation for the consumer group. There are three special consumer groups that are always present in the data dictionary. They cannot be deleted or modified. They are as followS: 1. SYS_GROUP: this is the initial consumer group for all sessions created by the user accounts SYS or SYSTEM. This initial consumer group can be overridden by the SESSION to CONSUMER GROUP mapping rules. 2. OTHER_GROUPS:This consumer group contains all sessions that have not been assigned to a consumer group. Every resource plan must contain a directory to OTHER_GROUPS.

Resource Plan: A container for directives that specifies how the resources are allocated to resource consumer groups. We specify how the database allocates resources by activating a specific resource plan. In addition to the resource plans that are predefined for each oracle database, we can create any number of resource plans. Only one resource plan is active at a time. When a resource plan is active, each of its child resource plan directives controls resource allocation for a different consumer group. Each plan must include a directive that allocates the resources to the consumer groups named OTHER_GROUPS.OTHER_GROUPS that applies to all the sessions that belong to the consumer group that is part of the current active plan. Resource plan directives: Associates a resource consumer group with a particular plan and specifies how the resources are to be allocated to the resource consumer group. The resource manager allocates resources to the consumer groups according to a set of resource plan directives that belong to the currently active resource consumer plan. There is parent child relationship between a resource plan and its resource plan directives. Each directive refers once consumer group, and no two directives for the current active plan can reference the same consumer group. A directive have several ways in which it can limit the resource allocation for a consumer group. The following example shows a simple resource plan to limit the amount of CPU. SUB Plans: Instead of referencing a consumer group, a resource plan directive can reference other resource plans. In this case, the plan is referred to as a subplan. The subplan itself has directives that allocate the resources to consumer groups and other subplans. The resource allocation scheme then will look like a top resource plan, dividing the resources among consumer groups and subplans. Each subplan allocates its portion of the total resource allocation among its consumer groups and subplans. We can create a resource subplan in the same way that we create a resource plan. To create a plan that is used only as a subplan, we can use the SUB_PLAN argument in the package procedure DBMS_RESOURCE_MANAGER.CREATE_PLAN. Remember that in any top level we can reference only one subplan. A subplan is not required to have a directive to OTHER_GROUPS and cannot be set as a resource plan. The following example shows the user sub plans. Remember it is possible to have a subplan or consumer group to have multiple parents. We can use the DBMS_RESOURCE_MANAGER procedure to create and limit these elements. The elements are stored in tables in the data dictionary. We can view the information about them with the data dictionary views. We should have the system privilege ADMINISTER_RESOURCE_MANAGER to administer the resource manager. This privilege is granted to the database administrators through the DBA role. If we have this system privilege, we can execute all of the procedures in the DBMS_RESOURCE_MANAGER PL/SQL package. We can grant an user to administer the resource manager by granting the GRANT_SYSTEM_PRIVILEGE or REVOKE_SYSTEM_PRIVILEGE using the DBMS_RESOURE_MANAGER_PRIVS PL/SQL package. Using the following procedure we can grant the GRANT_SYSTEM_PRIVILEGE to the user HR. BEGIN DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE( GRANTEE_NAME => 'HR', PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER', ADMIN_OPTION => FALSE);

END; / Overview of assigning sessions to the resource consumer groups: Before we can enable the resource manager, we must specify how user sessions are assigned to the resource consumer groups. We can do this by creating the mapping riles that will enable the resource manager to automatically assign each session to a consumer group upon session startup, based upon the session attributes, after a session is assigned to the initial consumer group and is running, we can call a procedure to manually switch a session to a different consumer group. We would typically do this if the session is using excessive resources and must be moved to a consumer group that is more limited in its resource allocation. We can grant the SWITCH privilege to the users and to applications so that they can switch their sessions from one consumer group to another. The database can automatically switch a session from one consumer to other (typically lower priority) consumer group, when there are changes in the session attributes or when a session exceeds designated consumption limits. By creating a session to consumer group mapping rules, we can specify the initial consumer group for a session based on session attributes and enable the resource manager to dynamically switch when a running session to another consumer group based on changing session attributes. The mapping rules are based on the session attributes such as the user name, the service that the session used to connect to database and the name of the client program. To resolve the conflicts among the mapping rules, the resource manager orders the rules by priority. For example there is mapping rules that says the SCOTT user should be placed in MED_PRIORITY and another saying user connected using SALES services start in HIGH_PRIORITY, mapping rules will resolve this conflict. There are two types of session attributes upon which the mapping rules are based, login attrbutes and run time attributes. The login attributes are meaningful only at session login time. When a resource manager determines the initial consumer group of the session. Run time attributes apply any time during and after the session login. We can reassign a session to another consumer group by changing any of its run time attributes. We can use the SET_CONSUMER_GROUP_MAPPING or SET_CONSUMER_GROUP_MAPPING_PRI procedures to configure the automatic assignment of the sessions to the consumer groups. We must use a pending area for these procedures. A session is automatically switched to a consumer group through mapping rules at a distinct point in time when the session first logs in, and if the session attribute is changed dynamically to a new value, then the mapping rules are reevaluated and the session is dynamically changed to another consumer group. Each database comes with a set of predefined consumer mapping rules like SYS_GROUP, OTHER_GROUPS.OTHER_GROUPS. Session performing the data load with the data pump or sessions performing backup or copy operations with RMAN are automatically mapped to predefined consumer groups. We can use the DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING procedure to modify or delete any of these predefined mapping rules. We can use SET_CONSUMER_GROUP_MAPPING procedure to map a session attribute/value pair to the consumer group. This procedure takes in the following parameters. ATTRIBUTE, VALUE and CONSUMER_GROUP. An ATTRIBUTE can be any of the following: ATTRIBUTE can be one of the following: Attribute ORACLE_USER SERVICE_NAME CLIENT_OS_USER CLIENT_PROGRAM CLIENT_MACHINE CLIENT_ID Type Description Login The Oracle Database user name Login The database service name used by the client to establish a connection Login The operating system user name of the client that is logging in Login The name of the client program used to log in to the server Login The name of the computer from which the client is making the connection Login The client identifier for the session The client identifier session attribute the DBMS_SESSION.SET_IDENTIFIERprocedure. is set by

MODULE_NAME

Run- The module name in the currently running application as set by

Attribute

Type Description time theDBMS_APPLICATION_INFO.SET_MODULE procedure equivalent OCI attribute setting or the

MODULE_NAME_ACTION

Run- A combination of the current module and the action being time performed as set by either of the following procedures or their equivalent OCI attribute setting: DBMS_APPLICATION_INFO.SET_MODULE DBMS_APPLICATION_INFO.SET_ACTION The attribute is specified as the module name followed by a period (.), followed by the action name (module_name.action_name). Run- A combination of service and time form: service_name.module_name module names in this

SERVICE_MODULE

SERVICE_MODULE_ACTION Run- A combination of service name, module name, and action name, in time this form:service_name.module_name.action_name ORACLE_FUNCTION Run- An RMAN or Data Pump operation. Valid values time are DATALOAD, BACKUP, and COPY. There are predefined mappings for each of these values. If your session is performing any of these functions, it is automatically mapped to a predefined consumer group. See Table 27-6 for details.

The following PL/SQL block causes the user SCOTT to map the DEV_GROUP consumer group every time he logs in. BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (DBMS_RESOURCE_MANAGER.ORACLE_USER, 'SCOTT', 'DEV_GROUP'); END; / Remember that we must first creating a pending area before running SET_CONSUMER_GROUP_MAPPING procedure. We can use wildcards for VALUES in most of the ATTRIBUTE section in the SET_CONSUMER_GROUP_MAPPING procedure. We can use the wildcards for all attributes except ORACLE_USER, SERVICE_MODULE and SERVICE_MODULE_ACTION. To specify these attribute we can use the semantics as the SQL LIKE operator with % _ or \. We can modify the consumer group mapping rule, using the SET_CONSUMER_GROUP_MAPPING procedure against a desired attribute/value pair, specifying a new consumer group. To delete a rule, run the SET_CONSUMER_GROUP_MAPPING against the desired attribute/value pair and specify a null consumer group. Creating Mapping rule Priorities: To resolve a conflicting mapping rile, we can establish a priority ordering of the session attributes from most import to least important. We can use the SET_CONSUMER_GROUP_MAPPING_PRI procedure to set the priority of each attribute from 1 to 12 (1 being the most import and 12 being the least). The following is an example of setting the priorities. BEGIN DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRI( EXPLICIT => 1, SERVICE_MODULE_ACTION => 2, SERVICE_MODULE => 3, MODULE_NAME_ACTION => 4, MODULE_NAME => 5, SERVICE_NAME => 6, ORACLE_USER => 7, CLIENT_PROGRAM => 8, CLIENT_OS_USER => 9, CLIENT_MACHINE => 10, CLIENT_ID => 11, ORACLE_FUNCTION => 12);

END; / SET_CONSUMER_GROUP_MAPPING_PRI requires that we include the pseudo-attribute EXPLICIT as an argument. It must be set to 1. It indicates that the explicit consumer group have the highest priority. We can switch the consumer groups with the following procedures.

DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER If the user is part of multiple consumer groups, then the user is assigned to the group whose attribute has the highest priority. We can use the DBMS_RESOURCE_MANAGER package to change the resource consumer group of the running sessions. Both of these procedures also change the consumer group of any parallel execution server session associated with the coordinator session. The changes made by these procedures pertain to current session only, they are not persistent. They do not change the initial consumer groups for the users. Instead of killing a session of the user with excessive CPU, we can change that users consumer group to one that is allocated fewer resources. The SWITCH_CONSUMER_GROUP_FOR_SESS procedure can be used to move a session to a specified consumer group. In affect this procedure can raise or lower the priority of the session. BEGIN DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345', 'HIGH_PRIORITY'); END; / The SWTICH_CONSUMER_GROUP_FOR_USER procedure change the resource consumer group for all session pertaining to a specified user name. The following PL/SQL procedure can be used for that purpose. BEGIN DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('HR', 'LOW_GROUP'); END; / We can grant a user the SWTICH privilege so that he can switch his current consumer group using the SWITCH_CURRENT_CONSUMER_GROUP procedure in the DBMS_SESSION package. A user can run this procedure from an SQL*Plus or an application call. This change is dynamic. The SWITCH_CURRENT_CONSUMER_GROUP procedure enables the users to switch to only those consumer groups for which they have the switch privilege. The parameters for this procedures are as follows Parameter NEW_CONSUMER_GROUP OLD_CONSUMER_GROUP Description The consumer group to which the user is switching. Returns the name of the consumer group from which the user switched. Can be used to switch back later. INITIAL_GROUP_ON_ERROR Controls behavior if a switching error occurs. If TRUE, in the event of an error, the user is switched to the initial consumer group. If FALSE, raises an error. The following procedure shows how the switching can be done. SET serveroutput on DECLARE old_group varchar2(30); BEGIN DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('BATCH_GROUP', old_group, FALSE); DBMS_OUTPUT.PUT_LINE('OLD GROUP = ' || old_group); END; /

DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS

The resource manager also works in the environments where a generic database user name is used to log on to an application. The DBMS_SESSION package can be called to switch the consumer group assignment of a session at the session start up or as it particular modules are called. Specifying automatic resource consumer group switching: We can configure the resource manager to automatically switch a session to another consumer group when a certain condition is met. Automatic switching occur when the session attribute changes, causing a new mapping rule to take effect or when a session exceeds the CPU or I/O resource consumption limits set by its consumer group. When the session attribute changes when it is running, then the session to consumer group mapping rules are reevaluated. If the new rule takes effect, then the session might be moved to the different consumer group. Specifying automatic switching by setting resource limits: This section describes managing runaway sessions or calls that use the CPU or I/O resources beyond a specified limit. A runaway session is a SQL query, while runaway call is a PL/SQL call. When we create a resource plan directive for a consumer group, we can specify limits for the CPU and I/O resource consumption for sessions in that group. We can then specify the action that is to be taken if any single call within the session exceeds one of these limits. The possible actions can be session to be dynamically switched to a designated consumer group or a session being killed or the sessions current SQL statement is aborted. The following are the resource plan directive attributes that are involved in this type of automatic session switching.

SWITCH_FOR_CALL Switches occur for sessions that are running and consuming resources, not waiting for user input or waiting for CPU cycles. After a session is switched, it continues in the target consumer group until it becomes idle, at which point it switches back to its original consumer group. If the SWITCH_FOR_CALL is set to TRUE then the resource manager does not wait until the session is idle to return to its original resource consumer group. Instead, the session is returned when the current top level call completes. A top level call in PL/SQL is an entire PL/SQL block treated as a call. A top level call in SQL is an individual SQL statement. The resource manager views a session as idle if the certain amount of time passes between calls. This time interval is not configurable. SWITCH_FOR_CALL is useful for three tier applications where the middle tier server is using session pooling. A switched session is allowed to continue running even if the active session pool for the new group is full. Under these conditions, a consumer group can have more sessions running than specified by its active session pool. The following are the examples of how this is done. The following PL/SQL block creates a resource plan directive for the OLTP group that switches any session in that group to the LOW_GROUP consumer group if a call in the sessions exceeds 5 seconds of CPU time. This example prevents unexpectedly long queries from consuming too many resources. The switched-to consumer group is typically one with lower resource allocations. BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( PLAN => 'DAYTIME', GROUP_OR_SUBPLAN => 'OLTP', COMMENT => 'OLTP group', MGMT_P1 => 75, SWITCH_GROUP => 'LOW_GROUP', SWITCH_TIME => 5); END; /

SWITCH_GROUP SWITCH_TIME SWITCH_ESTIMATE SWITCH_IO_MEGABYTES SWITCH_IO_REQS

The following PL/SQL block creates a resource plan directive for the OLTP group that temporarily switches any session in that group to the LOW_GROUPconsumer group if the session exceeds 10,000 I/O requests or exceeds 2,500 Megabytes of data transferred. The session is returned to its original group after the offending top call is complete. BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( PLAN => 'DAYTIME', GROUP_OR_SUBPLAN => 'OLTP', COMMENT => 'OLTP group', MGMT_P1 => 75, SWITCH_GROUP => 'LOW_GROUP', SWITCH_IO_REQS => 10000, SWITCH_IO_MEGABYTES => 2500, SWITCH_FOR_CALL => TRUE); END; / The following PL/SQL block creates a resource plan directive for the OLTP group that kills (terminates) any session that exceeds 60 seconds of CPU time. This example prevents runaway queries from consuming too many resources. BEGIN DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE ( PLAN => 'DAYTIME', GROUP_OR_SUBPLAN => 'OLTP', COMMENT => 'OLTP group', MGMT_P1 => 75, SWITCH_GROUP => 'KILL_SESSION', SWITCH_TIME => 60); END; / Granting or Revoking the switch privilege: Using the DBMS_RESOURCE_MANAgER_PRIVS Pl/SQL package, we can grant or revoke the system privilege to the user, role or PUBLIC. The switch privilege enables a user or application to switch a session to a specified resource consumer group. It also enables the database to automatically switch a session to a consumer group specified in the session to consumer group mapping rule or specified in the SWITCH_GROUP parameter of the resource plan directive. The following are the procedures that can be used. Procedure GRANT_SWITCH_CONSUMER_GROUP Description Grants permission to a user, role, or PUBLIC to switch to a specified resource consumer group. REVOKE_SWITCH_CONSUMER_GROUP Revokes permission for a user, role, or PUBLIC to switch to a specified resource consumer group. OTHER_GROUPS has the switch privileges granted to PUBLIC. Therefore, all users are automatically the switch privilege for this consumer group. Granting the switch role: The following example grants the user SCOTT the privilege to switch to consumer group OLTP. BEGIN DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP ( GRANTEE_NAME => 'SCOTT',

CONSUMER_GROUP => 'OLTP', GRANT_OPTION => TRUE); END; / If we grant the permission to a role to switch to a particular resource consumer group, then any user who is granted that role and has enabled that role can switch his session to that consumer group. IF we grant the PUBLIC the permission to switch to a particular consumer group, then any user can switch to that group. If the GRANT_OPTION is set to TRUE, then users granted switch privilege for the consumer group can also grant switch privilege for that consumer group to others. Revoking Switch Privileges: The following procedure can be used to revoke the switch privileges from the SCOTT. BEGIN DBMS_RESOURCE_MANAGER_PRIVS.REVOKE_SWITCH_CONSUMER_GROUP ( REVOKEE_NAME => 'SCOTT', CONSUMER_GROUP => 'OLTP'); END; / If we revoke a user switch privilege to a particular consumer group, any subsequent attempts by that user to switch to switch to that consumer group, either manually or automatically will fail. The user session will then be automatically assigned to OTHER_GROUPS. If we revoke from a role the switch privilege to the consumer group, any users who had the switch privilege for the consumer group only through that role are no longer able to switch to that consumer group. If we revoke switch privileges to the consumer group from PUBLIC, any users other than those who are explicitly assigned switch privileges either directly or through a role are no longer able to switch to that consumer group.