OCA/OCP Oracle Database 11g All-in-One Exam Guide 786 11. Set the initial consumer groups: SQL> exec dbms_resource_manager.set_initial_consumer_group- > ('CLERK','OLTP'); SQL> exec dbms_resource_manager.set_initial_consumer_group- > ('ACCT','DSS'); SQL> exec dbms_resource_manager.set_initial_consumer_group- > ('BATCH','BATCH'); SQL> exec dbms_resource_manager.set_initial_consumer_group- > ('MGR','OLTP'); 12. From the database home page, select the Server tab, and then the Plans link in the Resource Manager section, to see the default plans. 13. Click CREATE a new plan. Name it DAYTIME, and click the Activate This Plan check box. 14. Click MODIFY to reach the Select Groups/Subplans window. 15. Select the BATCH, DSS, OLTP, and SYS_GROUP groups and click MOVE, and then OK. 16. Select the Advanced radio button, and set the percentages for each level as in Figure 21-5. 17. Click the SHOW SQL button and study the procedure calls. Note in particular the final call to DBMS_RESOURCE_MANAGER.SWITCH_PLAN, which will activate the new plan. Click ENTER. 18. Click OK to complete the operation. 19. In a second SQL*Plus session, connect as user CLERK. 20. In the first session, confirm that CLERK’s effective consumer group is OLTP: SQL> select username,resource_consumer_group from v$session; 21. In the second session, connect as user MGR and run this code block to activate your membership of the DSS group: SQL> declare old_grp varchar2(30); 2 begin 3 dbms_session.switch_current_consumer_group('DSS',old_grp,TRUE); 4 end; 5 / 22. In the first session, repeat the query of Step 20 to confirm that MGR is in the DSS group. 23. In the first session, switch the MGR user over to the OLTP group. SQL> execute dbms_resource_manager.switch_consumer_group_for_user('MGR','BATCH'); 24. In the first session, repeat the query of Step 20 to confirm that MGR has been switched over to the BATCH group. Use of the Ratio CPU Method There is an alternative technique for allocating CPU resources. Rather than coding CPU usage as a percentage, you can specify ratios—and let Oracle work out the percentages. Chapter 21: The Resource Manager 787 PART III In the telesales example in the preceding section, the CPU resources at level 2 for the nighttime plan were OLTP 50% DSS 25% BATCH 25% If you decide to add a fourth group (call it WEB) and want to make it equal in priority to OLTP, and to double DSS and BATCH, you will have to change all the directives to achieve this: OLTP 33% WEB 33% DSS 17% BATCH 17% The ratio method lets you specify proportions. The absolute values have no significance. For example, the original ratios could have been OLTP 20 DSS 10 BATCH 10 and now, to add the WEB group with a priority equal to OLTP, you only have to add one new directive, WEB 20 and leave the others unchanged. The Active Session Pool Method It may be that investigation has shown that a certain number of jobs can be run concurrently by one group of users with no problems, but that if this number is exceeded, then other groups will have difficulties. For example, it might be that the telesales company has six management accountants, logging on with Oracle usernames in the DSS group. If one, two, or even three of them generate reports at the same time, everything is fine, but if four or more attempt to run reports concurrently, then the OLTP users begin to suffer. The active session pool method of the Resource Manager lets the DBA limit the number of statements that will run concurrently for one group, without restricting the actual number of logins. To continue the example, all six accountants can be connected, and if three of them submit reports, they will all run, but if a fourth submits a job, it will be queued until one of the other three finishes. The nighttime plan would remove all restrictions of this nature. An active session is defined as a session that is running a query, or a session that is in an uncommitted transaction. If parallel processing has been enabled, the individual parallel processors do not count against the session pool; rather, the entire parallel operation counts as one active session. By default, a session will be queued indefinitely, but if you wish, you can set a time limit. If a session from the pool does not become available within this limit, the statement is aborted and an error returned to the session that issued it. OCA/OCP Oracle Database 11g All-in-One Exam Guide 788 EXAM TIP A session that is not actually doing anything will still count against the active session pool for the group if it has made a change and not committed it. To enable the active session pool, either use the API directly or go through Database Control, as in Figure 21-6. In this example, when the daytime plan is active, BATCH users are limited to only one active session. If a second BATCH user issues any kind of SQL statement before the first has completed, it will be queued until the first statement has finished. DSS users are limited to three active sessions, but they are queued for only five minutes. If a session waits longer than that, an error will be returned. To monitor the effect of the active session pool, a column CURRENT_QUEUE_ DURATION in V$SESSION will show for every queued session the number of seconds it has been waiting. The view V$RSRC_CONSUMER_GROUP gives a global picture, showing how many sessions for each group are queued at any given moment. What if the active session pool were set to zero for all groups? The result would be that all sessions would hang. This is in fact a very useful capability, and it is used by the command ALTER SYSTEM QUIESCE RESTRICTED. Figure 21-6 Enabling active session pools Chapter 21: The Resource Manager 789 PART III This command activates the Resource Manager plan INTERNAL_QUIESCE, which sets the active session pool for all groups other than the SYS_GROUP to zero. The effect is that statements in progress will continue until they finish, but that no one (other than members of the SYS_GROUP) can issue any more statements. If they do, the session will hang. In effect, the database is frozen for all but the administrators. This can be invaluable to get a stable system for a moment of maintenance work. To cancel the quiesce, issue ALTER SYSTEM UNQUIESCE. TIP Quiesce is invaluable for DDL operations that require a very short exclusive object lock, such as an online index rebuild: quiesce the database, launch the operation, and then unquiesce. The rebuild operation will continue, and users may not have noticed that they were ever blocked. Limiting the Degree of Parallelism Parallel processing, both for SELECT statements and for DML, can greatly enhance the performance of individual statements, but the price you pay may be an impact on other users. To enable parallel processing, you must, as a minimum, • Create a pool of parallel execution servers, with the PARALLEL_MAX_SERVERS instance parameter. • Enable parallelism for each table, with the ALTER TABLE <table name> PARALLEL command. • Enable parallel DML for your session with ALTER SESSION ENABLE PARALLEL DML (parallel query will be enabled automatically for the session, if parallelism is set for the table). The problem is that once you enable parallel processing, you cannot stop anyone from using it. It may be that your management accountants have discovered that if they run a query with the degree of parallelism set to 50 (and you cannot control this—it is done by hints in the code they write), then the report generates faster. But do you really want one session to take 50 parallel execution servers from the pool? That may not leave enough for other work. Furthermore, the query may now run faster but cripple the performance of the rest of the database. The Resource Manager can control this, by setting a hard limit on the number of parallel processors that each session of any one group is allowed to use. In the daytime plan, for instance, you might limit the DSS and BATCH groups to no more than four per session, even if they ask for 50, and not permit OTHER_GROUPS sessions to use parallel processing at all. The nighttime plan could remove these restrictions. As with all Resource Manager limits, this can be set through the API or through Database Control, as Figure 21-7 illustrates. OCA/OCP Oracle Database 11g All-in-One Exam Guide 790 Controlling Jobs by Execution Time The problem of one large job killing performance for everyone else is well known in the database world. The Resource Manager solves this by providing a mechanism whereby large jobs can be completely eliminated from the system at certain times. In Figure 21-8, for the daytime plan, severe limits have been placed on the maximum execution time of statements submitted by all users except the SYS_GROUP. Any jobs submitted by the DSS or BATCH users will be canceled if they would not complete in one minute. An even more severe restriction is applied to the OLTP group. Because OLTP has been given a much higher priority at the CPU level, a large job submitted by an OLTP user would be much more serious than one submitted by other users (the OLTP sessions are meant to be used for running small, fast queries and transactions), so this setting will eliminate any job that would take more than ten seconds to complete. The tightest restriction is on OTHER_GROUPS sessions: if they submit a request that takes more than ten seconds, the session will be terminated. The nighttime plan would remove these restrictions, so that the long-running queries and batch jobs could go through when online performance is less important. Figure 21-7 Restricting parallelism Chapter 21: The Resource Manager 791 PART III Terminating Sessions by Idle Time Sessions that are not doing anything waste machine resources. Every session consists, on the server side, of a server process and a PGA. Even if the session is not executing a statement, the operating system must still bring it onto the CPU according to its round-robin time-slicing algorithm. This is known as a context switch. Every context switch forces the computer to do a lot of work as registers are loaded from main memory, the state of the session checked, and then the registers cleared again. If the PGA has been paged to disk, that too must be reloaded into main memory. The shared server mechanism, detailed in Chapter 4, will help to reduce idle processes, but it can’t do anything about the number of sessions. The UGAs (in the SGA, remember) will still be taking up memory, and Oracle still has to check the state of the session on a regular basis. The Resource Manager can disconnect sessions that are not working, according to two criteria. The first is simply based on idle time: how long is it since the session executed a statement? The second is more sophisticated: it not only checks how long since a session executed a statement, but also whether the session is holding any record or table locks that are blocking other sessions, which is a much more serious problem. Figure 21-8 Controlling execution times OCA/OCP Oracle Database 11g All-in-One Exam Guide 792 Remember from Chapter 8 that a record lock enqueue held by one session will cause another session that needs to lock the same row to hang indefinitely; this can cause the whole database to stop working if the problem escalates from session to session. It is possible for the DBA to detect this problem, identify the session that is holding the lock, and kill it—but this is a tricky procedure. By using the Resource Manager, you can configure automatic killing of any sessions that block other sessions for more than a certain length of time. An important point is that “idle time” is time that the server process has been idle, not time that the user process has been idle. For example, your management accountant might be using a spreadsheet as his user process: he will have downloaded some information to it, to work on locally before saving it back to the database. While this is going on, the server process is indeed idle, but the user could be working flat-out in the spreadsheet. He will not be pleased if, when tries to pass the information back, he finds that you have disconnected him and perhaps lost all his work in progress. In Figure 21-9, all groups except SYS_GROUPS have been given reasonable amounts of idle time before being disconnected, but much more aggressive settings if they are blocking other sessions. TIP It is also possible to disconnect sessions by using profiles assigned to named users, which you must enable with the instance parameter RESOURCE_ LIMITS. However, the Resource Manager is a better tool for this. Figure 21-9 Configuring idle time disconnection with Database Control Chapter 21: The Resource Manager 793 PART III Restricting Generation of Undo Data Management of undo data was covered in Chapter 8. All DML statements must generate undo data, and this data must be stored until the transaction has been committed or rolled back. Oracle has no choice about this; it is according to the rules of a relational database. If you have configured the UNDO_RETENTION instance parameter and set the RETENTION GUARANTEE attribute for your undo tablespace, then the undo data may well be kept for some considerable time after the transaction has committed. All your undo data will be written to a single undo tablespace, unless (against Oracle Corporation’s advice) you are using the outdated rollback segment method of undo management. This means that transactions from all users are sharing a common storage area. A potential problem is that one badly designed transaction could fill this storage area, the undo tablespace. Programmers should not design large, long-running transactions. In business terms, though, huge transactions may be necessary to preserve the integrity of the system. For example, an accounting suite’s nominal ledger cannot be partly in one accounting period, and partly in the next: this is an impossibility in accountancy. So the rollover from one period to the next could mean updating millions of rows in thousands of tables over many hours, and then committing. This will require a huge undo tablespace and will also cause record-locking problems as the big transaction blocks other work. The answer is to break up the one business transaction into many small database transactions programmatically. If this is a problem, go back to the developers; there is nothing you as DBA can do to fix it. As DBA, however, you can prevent large transactions by one group of users from filling up the undo tablespace. If your batch routines do not commit regularly, they will write a lot of undo data that cannot be overwritten. If too many of these batch jobs are run concurrently, the undo tablespace can fill up with active undo. This will cause all transactions to cease, and no more transactions can start, until one of them commits. The Resource Manager provides a mechanism whereby the undo tablespace can in effect be partitioned into areas reserved for different consumer groups. Your calculations on undo generated per second and your desired undo retention (as derived from the V$UNDOSTAT view, and your requirements for long running queries and the flashback query capability) might show that the undo tablespace should be, for example, 8GB. To be safe, you size it at 12GB. But to ensure that the small OLTP transactions will always have room for their undo data, you can limit the space used by the BATCH group to, say, 6GB during normal working hours by assigning an undo pool in a Resource Manager plan. To calculate the undo space necessary for individual transactions, you can query the view V$TRANSACTION while the transaction is in progress. The column USED_UBLK shows how much undo is being used by each active transaction. EXAM TIP The undo pool per group has nothing to do with tablespace quotas, which are assigned per user. You cannot even grant quotas on undo tablespaces. OCA/OCP Oracle Database 11g All-in-One Exam Guide 794 When the amount of active undo data generated by all sessions of a certain consumer group hits its pool limit (which you can set through Database Control, as shown in Figure 21-10), it will no longer be possible for members of that group to add more undo to current transactions or to start new transactions: they will hang until one transaction commits, thus freeing up space within the pool. Meanwhile, other groups can continue working in the remainder of the undo tablespace. This restricts the effect of generating too much undo to one group, rather than having it impact on all users. Automatic Consumer Group Switching In the discussion of consumer groups, you saw that one user can be a member of multiple groups, and that either the user or the system administrator can switch a user’s session from one consumer group to another. Why would one wish to do this? From the user’s point of view, they will presumably want to activate their membership in the group that has the highest priority at any given time. So if the daytime plan gives priority to OLTP and the nighttime plan gives priority to DSS, then if you are a member of both groups, you will switch between them as the different plans are activated. So whichever plan is enabled, you will always have the highest priority available to you. The DBA may wish to switch users’ sessions for a very different reason: to reduce the impact one session is having on others. This will mean identifying sessions that are causing problems and downgrading them, rather than upgrading them, which is what the typical user would like. It may well be that a job that kills the database if run Figure 21-10 Configuring undo pools with Database Control Chapter 21: The Resource Manager 795 PART III at normal priority can run without impacting other sessions if its priority is reduced. Of course, it will take longer to complete, but that may not be a problem (at least, not to everyone else). To do this manually would be extremely difficult, requiring continuous monitoring of sessions and workload. This is exactly what the Resource Manager can do. Automatic consumer group switching can switch a session permanently, or just for one call. The former technique might be acceptable in a client-server environment where each end user has a dedicated session, but the latter technique will be preferable in cases where a large number of users are connected to an application server that is funneling their application server sessions through a small number of shared database sessions. In this environment, each user will issue a series of commands through the application server, which may be picked up by any of the database sessions; there is not a persistent link between any one application server session and any one database session, so it becomes preferable to manage group switches at the call level. Automatic consumer group switching can be based on the amount of CPU time or the amount of I/O (measured in megabytes or I/O requests). If the threshold is time based, it is possible to switch the session before the call starts if the optimizer estimates that the call might exceed the threshold. TIP Enabling the switch-on-estimate capability places great faith in the accuracy of the optimizer’s estimate. This accuracy (or lack thereof) will be dependent on many factors, the accuracy of the object statistics in particular. Adaptive Consumer Group Mapping The default method for assigning sessions to consumer groups is through the Oracle username, as specified by the INITIAL_RSRC_CONSUMER_GROUP displayed in DBA_USERS. The initial group can be changed at any time, either manually or by the automatic consumer group switching capability based on the workload of the statements being executed. While this is useful if users have their own schema login, in many environments this is not good enough for one simple reason: in large systems, it is common for all users to connect to the same schema. Partly this is an administrative convenience (in an environment with hundreds or thousands of users, to manage security through the schema mechanism would be an impossible workload for the DBA) and for web applications it is an architectural limitation. In an application server environment, a large number of users will connect to the application server using the stateless HTTP web protocol; the application server will connect to the database with a relatively small number of persistent database sessions. The application server distributes the workload of requests from the users across the pool of database sessions, which are all connected as the same database user. In an environment where many users share one schema, the schema identity is not sufficient to distinguish between them and allocate them to appropriate resource manager consumer groups. For this reason, there are a number of other attributes of a session that can be used to map it (either permanently or temporarily) to a consumer group. . a session from the pool does not become available within this limit, the statement is aborted and an error returned to the session that issued it. OCA/ OCP Oracle Database 11g All-in-One Exam. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 786 11. Set the initial consumer groups: SQL> exec dbms_resource_manager.set_initial_consumer_group- > ('CLERK','OLTP'); SQL>. the PARALLEL_MAX_SERVERS instance parameter. • Enable parallelism for each table, with the ALTER TABLE <table name> PARALLEL command. • Enable parallel DML for your session with ALTER