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 numbe
Trang 111 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
Trang 2In 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
Trang 3EXAM 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
Trang 4This 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
Trang 5Controlling 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
Trang 6Terminating 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
Trang 7Remember 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
Trang 8Restricting 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
Trang 9When 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
Trang 10at 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