OCA/OCP Oracle Database 11g All-in-One Exam Guide 776 In the telesales example, the two hundred data entry clerks could be in a group called OLTP, and the half-dozen management accountants could be in a group called DSS. Some users could be in both groups; depending on what work they are doing, they will activate the appropriate group membership. Other groups might be BATCH, to be given top priority for month-end processing, and LOW for people who happen to have accounts on the system but are of no great significance. There are fourteen groups created by default when a database is created: • SYS_GROUP This is a group intended for the database administrators. By default, only the SYS and SYSTEM users are in this group. • DEFAULT_CONSUMER_GROUP This is a group for all users that have not been specifically assigned to any other group. By default, all sessions other than SYS and SYSTEM are in this group, and this membership is active when they first create a session. • OTHER_GROUPS This is a group that all users are members of, used as a catch-all for any sessions that are in groups not listed in the active Resource Manager plan. • LOW_GROUP This group is intended for low-priority sessions. • BATCH_GROUP, INTERACTIVE_GROUP These are preconfigured groups intended for sessions doing certain types of work. • The AUTOTASK groups There are seven groups associated with the automatic tasks, such as gathering statistics and running advisors. These are intended to prevent the auto-tasks from impacting adversely on end-user sessions. • ORA$DIAGNOSTICS A group for running diagnostic tasks. To view the groups in your database, query the views DBA_RSRC_CONSUMER_ GROUPS and DBA_USERS. The latter shows the initial consumer group set for each session at connect time (see Figure 21-1). Resource Manager Plans A Resource Manager plan is of a certain type. The most basic (and most common) type of plan is one that allocates CPU resources, but there are other resource allocation methods. Many plans can exist within the database, but only one plan is active at any one time. This plan applies to the whole instance: all sessions are controlled by it. The resources that can be controlled by a plan are • Total CPU usage for all sessions in a group • Degree of parallelism available to each session in a group • Number of active sessions permitted per group • Volume of undo space permitted per group • Time before terminating idle sessions • Maximum length of execution time for a call in a session, which can also trigger the switch of a session into another group Chapter 21: The Resource Manager 777 PART III In the telesales example, there could be three plans based on CPU usage. A daytime plan would give top priority to the OLTP group. At times of peak activity, with the system working to full capacity, it is possible that the sessions of users in other groups would hang. At night, a different plan would be activated that would guarantee that the DSS jobs would run, though perhaps still not with the priority of the OLTP group. A month-end plan would give 100 percent of resources to the BATCH group. A plan consists of a number of directives. Each directive assigns resources to a particular group at a particular priority level. Seven plans are configured at database creation time: • The INTERNAL_PLAN is not for normal use—it disables the Resource Manager. • The DEFAULT_PLAN has four directives (see Figure 21-2). The first states that at priority level 1, the highest priority, the session connected to the SYS_GROUP consumer group can take 100 percent of CPU resources. At level 2, OTHER_ GROUPS can have 90 percent, the ORA$DIAGNOSTICS can have 5 percent, and a subplan can have the remaining 5 percent. This plan ensures that if SYS or SYSTEM needs to do something, it will get whatever resources it needs to do it. Any resources it does not need will “trickle down” to the groups at level 2. Figure 21-1 Resource Manager consumer groups OCA/OCP Oracle Database 11g All-in-One Exam Guide 778 • The ORA$AUTOTASK_SUB_PLAN (see Figure 21-2) assigns the priorities between tasks considered to be of urgent, high, or medium importance. • The ORA$AUTOTASK_HIGH_SUB_PLAN further divides resources for automatic jobs. • The DEFAULT_MAINTENANCE_PLAN raises the proportion of resources available to maintenance tasks to 25 percent. • The INTERNAL_QUIESCE plan has a particular purpose covered at the end of the chapter: it will freeze all sessions except those of the SYS_GROUP members. • The MIXED_WORKLOAD_PLAN (shown in Figure 21-3) gives top priority to the SYS_GROUP, then the INTERACTIVE_GROUP, and then the BATCH_GROUP. To enable a plan, set the RESOURCE_MANAGER_PLAN instance parameter. This can be set automatically by the Scheduler (described in Chapter 22), manually with an ALTER SYSTEM command, or programmatically with the DBMS_RESOURCE_ MANAGER.SWITCH_PLAN procedure. Following creation of a database with DBCA, the Scheduler will be configured to activate the DEFAULT_PLAN during normal working hours, and the DEFAULT_MAINTENANCE_PLAN at night and weekends. It is assumed that these plans will be appropriate for most sites: they give the DBA staff top priority, followed by users, and restrict the resources that can be taken by maintenance jobs. EXAM TIP The instance parameter RESOURCE_LIMITS has nothing to do with the Resource Manager. It pertains to the older method of controlling resources, through database profiles. Resource Manager Configuration Tools There is a PL/SQL API that can be used to administer the Resource Manager; as well as a Database Control interface. The API consists of two packages: DBMS_RESOURCE_ Figure 21-2 The directives of the DEFAULT_PLAN and ORA$AUTOTASK_SUB_PLAN plans Chapter 21: The Resource Manager 779 PART III MANAGER_PRIVS and DBMS_RESOURCE_MANAGER. DBMS_RESOURCE_MANAGER_ PRIVS is used to put users into consumer groups and also to grant the system privilege necessary to administer the Resource Manager (see Figure 21-4). Figure 21-3 The MIXED_WORKLOAD_PLAN, shown in Database Control Figure 21-4 The DBMS_RESOURCE_MANAGER_PRIVS package OCA/OCP Oracle Database 11g All-in-One Exam Guide 780 To give user JOHN the capability of administering the Resource Manager, with the ability to pass on the privilege to other users: SQL> execute dbms_resource_manager_privs.grant_system_privilege(- grantee_name=>'JOHN',admin_option=>true); This procedure call will grant the system privilege ADMINISTER RESOURCE MANAGER. You can see this grant by querying the DBA_SYS_PRIVS view. EXAM TIP The ADMINISTER RESOURCE MANAGER system privilege can be granted and revoked only with the DBMS_RESOURCE_MANAGER_PRIVS package, not with the usual GRANT and REVOKE commands. To add a user to a group, use a call such as this: SQL> exec dbms_resource_manager_privs.grant_switch_consumer_group(- grantee_name=>'ROOPESH',consumer_group=>'OLTP',grant_option=>false); This call will add ROOPESH to the group OLTP, but without giving him the ability to add other users to the group. If ROOPESH is now a member of several groups, you should nominate one as his default group. This requires a procedure in a different package: exec dbms_resource_manager.set_initial_consumer_group(- user=>'ROOPESH',consumer_group=>'OLTP'); DBMS_RESOURCE_MANAGER is used to create consumer groups, plans, and directives. It is also used to create the “pending area.” Before any work can be done with Resource Manager objects, you must create a pending area. This is an area of memory in the SGA, used for storing the objects while they are being configured. A plan may consist of many directives, and each directive is created independently; it would therefore be possible to create a totally impossible plan: one that might, for example, allocate 500 percent of CPU. The pending area is provided to prevent this possibility: the plan is created in the pending area, and then when complete it is validated to check that it does make sense. Only then does the plan get saved to the data dictionary. To reach the Database Control interface to the Resource Manager, from the database home page take the Server tab, and then follow the links in the Resource Manager section. To configure the Resource Manager with the APIs is an extremely laborious process, and in virtually all circumstances Database Control will be a far superior method. At all stages in the Database Control windows there will be a SHOW SQL button: this will show all the API calls, including those that create and validate the pending area. TIP When using Database Control, keep copies of the API calls revealed by the SHOW SQL button. These will let you recreate (and possibly debug) the Resource Manager environment as necessary. Chapter 21: The Resource Manager 781 PART III Managing Users and Consumer Groups A pending area is needed to create consumer groups, but not to put users into groups. If you use Database Control, the pending area will be managed for you; if you use the API directly, you must explicitly create it. Database Control does itself use the API, but the GUI front end makes it much simpler to use and has validations that should make it impossible to create a logically inconsistent Resource Manager environment. At connect time, a session will pick up the initial consumer group assigned to that user. If the user is a member of multiple consumer groups, the session can be switched to a different consumer group later on. This can be done either manually or by using more advanced techniques automatically according to the work that the session is doing. Any user can switch their active consumer group to any of the groups of which they are a member by using the SWITCH_CURRENT_CONSUMER_GROUP procedure in the DBMS_SESSION package. Alternatively, a user with the privilege to administer the Resource Manager can switch another session over, by using one of two procedures in the DBMS_RESOURCE_MANAGER package. The SWITCH_CONSUMER_GROUP_ FOR_USER procedure will switch all sessions logged on with a particular user name, or SWITCH_CONSUMER_GROUP_FOR_SESS will switch one particular session, identified by SID and SERIAL#: SQL> exec dbms_resource_manager.switch_consumer_group_for_sess(- session_id=>209,session_serial=>10223,consumer_group=>'OLTP'); EXAM TIP The DBMS_RESOURCE_MANAGER_PRIVS package includes the procedure to put someone in a group, but it is procedures in DBMS_SESSION and DBMS_RESOURCE_MANAGER that can change a user’s active consumer group. Resource Manager Plans A plan consists of a set of directives that divide resources among consumer groups. There are several principles that can be used to control this: • CPU method • Number of active sessions • Degree of parallelism • Operation execution time • Idle time • Volume of undo data It is also possible to enable automatic consumer group switching by combining operation execution time with CPU usage: a session that initiates a long-running job that will impact adversely on other users can be downgraded to a lower priority. The CPU method is known as an “emphasis” method, because the effect will vary depending on system activity. The other methods are “absolute” methods, meaning that you define a hard limit, which is always enforced exactly as written. OCA/OCP Oracle Database 11g All-in-One Exam Guide 782 CPU Method Continuing the telesales example, the daytime plan would give maximum resources to the OLTP group. All other sessions will hang, if the OLTP users really do need the whole machine. The only exception is the SYS_GROUP. You should always give the SYS_GROUP priority over anything else: if you, the DBA, need to do something on the production system (such as rebuilding a broken index, or doing a restore and recover), then you should be able to do it as fast as possible. The plan could look like this: Priority Level Group CPU % 1 SYS_GROUP 100 2 OLTP 100 3 DSS BATCH 50 50 4 OTHER_GROUPS 100 There are eight possible priority levels; this plan uses four of them. All CPU resources not used at one level trickle down to the next level. When this plan is active, the SYS_ GROUP at level 1 can, if necessary, take over the whole machine; all other sessions will hang. But this shouldn’t happen; in normal running, no CPU cycles will be taken by the SYS_GROUP, so the whole machine will be available at level 2, where the OLTP users can use it all. Any CPU resources they do not need drop down to level 3, where they are divided 50/50 between the DSS and the BATCH sessions. If, after they have taken what they need, there is still some capacity left, it will be available to members of other groups. It is possible, at times when the OLTP users are working nonstop and CPU usage has hit 100 percent, that the DSS and BATCH sessions will hang. EXAM TIP The total CPU allocated at each level cannot exceed 100 percent. If it does, the pending area will fail to validate and the plan will not be saved to the data dictionary. It is possible to have a plan that allocates less than 100 percent at a level, but there is little purpose in doing this. The nighttime plan will have different settings: Priority Level Group CPU % 1 SYS_GROUP 100 2OLTP DSS BATCH 50 25 25 3 OTHER_GROUPS 100 As with the daytime plan, if the SYS_GROUP needs to do something, it will get top priority. But at level 2, the DSS and BATCH users are guaranteed processing time. They still do not have as high a priority as the OLTP group, but their sessions will not hang. The month-end plan might change this further: Chapter 21: The Resource Manager 783 PART III Priority Level Group CPU % 1 SYS_GROUP 100 2 BATCH 100 3 DSS OLTP 50 50 4 OTHER_GROUPS 100 When this plan is active, the BATCH jobs will take priority over everyone else, taking the whole machine if necessary. This would be advisable if the month-end processing actually means that the system is not usable, so it is vital to get it done as fast as possible. TIP If the CPU is not running at 100 percent usage, then these plans will have no effect. They have an impact only if the CPU capacity cannot satisfy the demands upon it. A variation on the CPU method is that the “group” can itself be a plan. It is possible by this method to set up a hierarchy, where a top-level plan allocates resources between two or more subplans. These subplans can then allocate resources among consumer groups. A case where this might be applicable would be an application service provider. Perhaps you have installed an application such as an accounting suite, and you lease time on it to several customers. Each customer will have its own groups of users. Your top-level plan will divide resources between subplans for each customer, perhaps according to the amount it is paying for access to the service. Then within that division, the customers can each allocate resources among their consumer groups. The DEFAULT_PLAN uses this method to assign resources to the various automatic tasks. EXAM TIP Every plan must include a directive for the group OTHER_ GROUPS; otherwise, the validation will fail and you cannot save the plan from the pending area to the data dictionary. To create a plan such as the daytime plan just described requires a series of procedure calls through the API. The first step is to create the pending area: SQL> exec dbms_resource_manager.create_pending_area; You then create the plan: SQL> exec dbms_resource_manager.create_plan(- plan=>'DAYTIME',comment=>'plan for normal working hours'); and the directives within it: SQL> exec dbms_resource_manager.create_plan_directive(- plan=>'DAYTIME',group_or_subplan=>'SYS_GROUP',cpu_p1=>100,- comment=>'give sys_group users top priority'); SQL> exec dbms_resource_manager.create_plan_directive(- plan=>'DAYTIME',group_or_subplan=>'OLTP',cpu_p2=>100,- OCA/OCP Oracle Database 11g All-in-One Exam Guide 784 comment=>'give oltp users next priority'); SQL> exec dbms_resource_manager.create_plan_directive(- plan=>'DAYTIME',group_or_subplan=>'DSS',cpu_p3=>50,- comment=>'dss users have half at level 3'); SQL> exec dbms_resource_manager.create_plan_directive(- plan=>'DAYTIME',group_or_subplan=>'BATCH',cpu_p3=>50,- comment=>'batch users have half at level 3'); SQL> exec dbms_resource_manager.create_plan_directive(- plan=>'DAYTIME',group_or_subplan=>'OTHER_GROUPS',cpu_p4=>100,- comment=>'if there is anything left, the others can have it'); Finally, validate the pending area and (if the validation returns successfully) save the plan to the data dictionary: SQL> exec dbms_resource_manager.validate_pending_area; SQL> exec dbms_resource_manager.submit_pending_area; To activate the plan, SQL> alter system set resource_manager_plan=daytime; This plan will be displayed in Database Control as in Figure 21-5. TIP The DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE procedure has the arguments CPU_Pn, where n ranges from 1 to 8. These are in fact deprecated: you should use the alternative MGMT_Pn arguments instead. But Database Control still generates code that refers to the old CPU_Pn arguments. Figure 21-5 The daytime plan, using the CPU method Chapter 21: The Resource Manager 785 PART III Exercise 21-1: Manage Users and Plans Create some users and consumer groups, view the configuration, and test the consumer group switching for a user who is a member of multiple groups. 1. Connect to your database as user SYSTEM using SQL*Plus. 2. Create some users and grant them the CONNECT role: SQL> grant connect to clerk identified by clerk; SQL> grant connect to acct identified by acct; SQL> grant connect to batch identified by batch; SQL> grant connect to mgr identified by mgr; 3. Connect to your database as user SYSTEM using Database Control. 4. From the database home page, take the Server tab, and then the Consumer Groups link in the Resource Manager section, to see the default groups. 5. Click CREATE to reach the Create Resource Consumer Group window. 6. Enter OLTP for the consumer group name, and group for telesales clerks as the description. Click ADD to display a listing of all users in the database. 7. Check the selection boxes for users CLERK and MGR, and click SELECT to return to the Create Resource Consumer Group window. 8. Click SHOW SQL, and study the output. Note the use of the pending area. Click ENTER to return to the Create Resource Consumer Group window. 9. Click OK to create the group, and assign the users to it. 10. Create two more groups, with users as follows: Group DSS, members ACCT and MGR Group BATCH, members BATCH and MGR From your SQL*Plus session check the groups and the memberships, with a query such as that shown in the illustration. . OCA/ OCP Oracle Database 11g All-in-One Exam Guide 776 In the telesales example, the two hundred data entry clerks could be in a group called OLTP, and the half-dozen management accountants. MIXED_WORKLOAD_PLAN, shown in Database Control Figure 21-4 The DBMS_RESOURCE_MANAGER_PRIVS package OCA/ OCP Oracle Database 11g All-in-One Exam Guide 780 To give user JOHN the capability of administering. define a hard limit, which is always enforced exactly as written. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 782 CPU Method Continuing the telesales example, the daytime plan would give maximum