Workload Management in Consolidated Oracle Database Environments RAO 25MAR13

Workload Management
In Consolidated Oracle Database Environments
. . . . . . . .
Surya Rao, Viren Parikh, Sathish Bala, Shailesh Mishra

GTS, Service Delivery, Data Management
In collaboration with the
IBM Oracle International Competency Center
March 25, 2013
Copyright IBM Corporation, 2013. All Rights Reserved.

All trademarks or registered trademarks mentioned herein are the property of their respective holders
Table of contents
Abstract..................................................................................................................................... 1
Introduction .............................................................................................................................. 2
Prerequisites............................................................................................................................. 4
1. Elements of Resource Manager .......................................................................................... 4
2. Evolution of the Oracle Database Resource Manager ....................................................... 7
2.1 DBRM enhancements in 9i ................................................................................................................ 7
2.2 DBRM enhancements in 10g............................................................................................................. 8
2.3 DBRM enhancements in 11g............................................................................................................. 9
3. What is Instance Caging .................................................................................................... 11
4. Resource Plans................................................................................................................... 14
4.1 Bottlenecks prevalent with OS Resource Allocation methods...................................... 14
4.2 Considerations for designing Resource Plans................................................................................. 14
4.3 Steps to setup resource management in a database ...................................................................... 15
4.4 Catering to mixed workloads using Resource Plans ....................................................................... 17
4.5 Managing multiple instances on a single server.............................................................................. 18
5. Consumer Groups .............................................................................................................. 19
5.1 Windows and Resource Plans........................................................................................................ 22
6. Resource Plan Directives................................................................................................... 23
6.1 CPU ................................................................................................................................................. 23
6.2 Degree of Parallelism Limit............................................................................................................. 23
6.3 Parallel Target Percentage ............................................................................................................. 23
6.4 Parallel Queue Timeout .................................................................................................................. 24
6.5 Active Session Pool with Queuing .................................................................................................. 24
6.6 Automatic Consumer Group Switching........................................................................................... 24
6.7 Canceling SQL and Terminating Sessions ..................................................................................... 24
6.8 Execution Time Limit........................................................................................................................ 24
6.9 Undo Pool ....................................................................................................................................... 25
6.10 Idle Time Limit............................................................................................................................... 25
7. Benchmarking the Resource Management Model ........................................................... 26
7.0 Objectives ....................................................................................................................................... 26
7.1 With NOARCHIVELOG ................................................................................................... 26
7.2 With ARCHIVELOG ........................................................................................................................ 27
7.3 Activate SOE_PLAN (Resource Plan) without Instance Caging .................................................... 28
Creating the SOE_PLAN Resource Plan ........................................................................ 28
Creating the SOE_PLAN directives for SOE_GROUP and OTHER_GROUPS ............. 29
7.4 Limiting the maximum CPU to 50% for the SOE_GROUP ............................................. 31
7.5 Combining Instance Caging with Resource Management limits .................................................... 35
7.5.1 Run time benchmark with 150 users ..................................................................... 35
7.5.2 RMLAB The Database view of CPU utilization and waiting sessions ................ 36
7.5.3 RMLAB2 The Database view of CPU utilization and waiting sessions .............. 36
IBM White paper title here

http://www.ibm.com/support/techdocs
Copyright 2013, IBM Corporation
7.5.4 OS CPU Stats OS level view of the run queue and idle CPU ....................... 36
7.5.5 RMLAB Throughput (TPM) benchmark.............................................................. 37
7.5.6 RMLAB2 Throughput (TPM) benchmark............................................................ 38
7.5.7 RMLAB DB Stats after stopping the RMLAB2 database. .................................. 38
7.5.8 OS CPU - after stopping the RMLAB2 database. ................................................. 39
7.5.9 TPS on RMLAB - after stopping the RMLAB2 database ...................................... 39
8. Benchmark Summary......................................................................................................... 41
9. Monitoring Resource Management ................................................................................... 44
9.1 Resource plan ........................................................................................................... 44
9.2 Resource consumer group ....................................................................................... 44
9.3 Resource plan directives ........................................................................................... 45
9.4 Privileges ................................................................................................................... 45
9.5 Default consumer group for users ............................................................................. 45
10. Known Issues and Troubleshooting ............................................................................... 47
Summary................................................................................................................................. 48
Resources............................................................................................................................... 49
About the authors................................................................................................................... 50
Trademarks and special notices ........................................................................................... 51

Copyright 2013, IBM Corporation
Abstract
The need for a database resource manager arose from the challenges faced,
specifically by database workload processing, when contending for limited
operating system resources, which are in-turn managed and governed at the
OS level. In other words, the Operating System is DB workload agnos-
tic, and this brings to the fore the challenge of how DB workloads will be
optimized to perform within Business SLAs (Service level Agreements) con-
tending for a set of OS resources over which they have no control over.
This paper is useful for aDBA and a DB architect. It explains how best we
can do workload management in a consolidated Oracle environment. Discuss
about database resource manager, instance caging feature of Oracle with
benchmark test results.

Copyright 2013, IBM Corporation 1
Introduction
Operating system schedulers are responsible for managing all the processes
running on a server. A server with four CPU cores can only execute four
processes at a time. The rest of the processes are ready for execution but
will be waiting on the server run queue. The workload on the server includes
all the processes on the CPU and on the run queue. Any process that is on
the CPU has to have its corresponding memory in the physical memory of
the server. In case of the server not having enough physical memory to load
the process memory then the OS will use swap space. Operating systems
usually use a proprietary scheduling algorithm to manage the processes.
Such sophisticated scheduling algorithms are important for the computer
systems to provide the applications with the desired throughput and re-
sponse time. Every operating system has its own operating system sched-
uler. Some of the most important implementations are Solaris resource
manager, Solaris Fair Share Scheduler, Completely Fair scheduler from
Linux.
Database resource manager, introduced in Oracle 8i, helps in workload man-

agement on database servers with an assortment of application and business
driven workloads. The resource manager helps to maintain healthy CPU
loads at all times. High CPU loads can expose the system to many issues like
OS vulnerabilities, database bugs, critical database processes starving for
CPU, database administrators unable to diagnose processes consuming
these resources and finally the disgruntled end users. Database resource
manager combined with instance caging can control CPU resources on data-
base systems with multiple instances.
It is also worth noting, that Oracle has made several architectural changes
to its Database Server model by allowing up to 250 User databases to run
within a single System Database or Container
Database resource managers typically help in the following areas of Re-

source Management.
Resource managers can guarantee at least a minimum amount of CPU

to certain users regardless of the load on the system or number of
users.
Resource managers can distribute CPU resources between different
kinds of workloads.

Resource managers can limit the degree of parallelism used by a group
of sessions.
Resource managers can prioritize the parallel operations on the
parallel operations queue.
Resource managers can limit the number of parallel servers a group of
sessions will use.
Resource managers can create an active session pool. An active
session pool is the maximum number of concurrent active sessions
within a group of users. Once the number of active sessions reaches a
set threshold then the remaining sessions are queued for execution.
Resource managers can manage runaway sessions by placing an
absolute limit on the percentage of CPU that a group can consume or
by terminating a session when it consumes more than the specified
CPU or IO.
Resource managers can prevent the execution of certain operations if
the optimizer estimates that the operation will consume more
resources than specified limit.
Resource managers can limit the amount of time that a session can be
idle and restricted only to blocking sessions.
Resource managers can switch between resource plans dynamically.
Note In general, Oracle does not recommend using Operating system Workload Managers in conjunc-
tion with the Oracle Database Resource Manager. For more information, please refer to
http://docs.oracle.com/cd/B28359_01/server.111/b28310/dbrm010.htm#i1010600

Prerequisites
Reader should have knowledge on database administration.

Reader should have knowledge on industry best practice for workload management in consoli-
dated oracle environment. Hence, reader can compare resource manager and instance caging
feature with other practices.
1. Elements of Resource Manager

The elements of the resource manager are described in the following table:
Element Description
Resource Consumer A set of sessions that are grouped together according to thei
Groups resource requirements. The resource manager allocates re
sources to consumer groups and not to individual sessions
The individual sessions are mapped to a consumer group us
ing the following session attributes - Service, module, action
oracle username, OS username, and program name.
Resource Plan Di- Resource plan directives are a set of resource limits for a par
rectives ticular consumer group. The resource plan and resource plan
directives are in a parent-child relationship. A set of direc
tives can target only one consumer group at a time.
Resource Plan Resource plan includes all the directives for different con
sumer groups. Only one resource plan can be active at
time.
Let us understand these three elements with an example.
We will create a simple resource plan called OLTP_DSS_DAYTIME_PLAN on a

database running multiple workloads (both OLTP and DSS) during core busi-
ness hours. The goal of the database administrator in such a scenario is to
ensure that no long running DSS type queries affect the OLTP users.
The DBA now creates a simple resource plan with plan directives restricting
CPU utilization for a particular consumer group. The DBA groups the data-
base users into two resource consumer groups namely OLTP and DSS. The
resource plan OLTP_DSS_DAYTIME_PLAN will have three resource plan di-
rectives one each for OLTP, DSS, and OTHER_GROUPS consumer groups
with a limit on CPU utilization.

2. Evolution of the Oracle Database Resource Man-
ager
Oracle Database Resource Manager (DBRM) was first introduced in Oracle 8i

(8.1.5). Since the initial release, the features have been constantly improved
upon. It is also worth mentioning that the DBRM is an integral part of Ora-
cle's Exadata offering where one is very likely to see the consolidation of
multiple databases into a single Exadata appliance. The topics covered in
this paper are equally applicable to Oracle databases running on the Exadata
appliance as well as on any other server/platform.
2.1 DBRM enhancements in 9i
The following new features were introduced in Oracle 9i.
Active Session Pool This provides FIFO mechanism with time-out

to carry out requests from different sessions. This helps to prevent any
performance bottleneck if there are too many active transactions.
Maximum Estimated Execution Time This feature was added to
prevent any long running operation to consume all system resource.
Automatic Consumer Group Switching For any active sessions,
Oracle8i allowed resource intensive transactions to be manually
switched between consumer groups to give them less priority. Oracle9i
improves on this to allow the session to be automatically switched
when it exceeds a specified threshold (SWITCH_GROUP, SWITCH_TIME).
UNDO_POOL This feature provide feature of using maximum quota
from UNDO space by any active transaction.
Resource Plan Directive Interactions This feature provides
resulting actions if a single resource consumer group associated with
multiple resource plan directive like following :-
The minimum parallel degree limit of the incoming values will be
used.
The sum of the incoming active session pools will be used.
The minimum incoming active session pool timeout will be used.
The smallest incoming switch time.
The value TRUE overrides FALSE for the switch estimate.
Resource manager chooses between multiple switch groups.
If a session is switched to a new consumer group it executes
regardless of the status of the active session pool in the new
group.

The most restrictive incoming maximum estimated execution
time is used.
Modified Views Oracle 9i becomes more interactive as some

columns were added to following views
V$SESSION and V$MYSESSIONS added with

CURRENT_QUEUE_DURATION showing number of seconds
session has been queued.
V$RSRC_CONSUMER_GROUP view added with QUEUE_LENGTH
and CURRENT_UNDO_CONSUMPTION columns which shows
current queue length and the UNDO consumption for the
consumer group.
DBA_RSRC_PLANS views added with QUEUEING_MTH column
indicates the queuing resource allocation method for the plan.
DBA_RESRC_PLAN_DIRECTIVES views added with
QUEUEING_P1, SWITCH_GROUP, SWITCH_TIME,
SWITCH_ESTIMATE, MAX_EST_EXEC_TIME and UNDO_POOL
columns.
2.2 DBRM enhancements in 10g
With lot of known issues and bugs in Oracle 9i, DBRM was further enhanced
with following new features in Oracle 10g.
Setting Consumer Group Switch Times Per Call For multi-tier

environments using connection pooling, Oracle 9i had limitation of
switch times to enable consumer groups to be switched if the
execution time reached a specified threshold. Oracle 10g DBRM have
new SWITCH_TIME_IN_CALL parameter of the
CREATE_PLAN_DIRECTIVE procedure solves this problem such that the
resource usage of one client does not affect future clients in the same
session. The default value this parameter is NULL, which represents
unlimited time.
CANCEL_SQL and KILL_SESSION With this new feature,

CREATE_PLAN_DIRECTIVE procedure can be used to automatically
cancel an SQL statement or kill the session if it exceeds its
SWITCH_TIME limit.
Setting Consumer Group Idle Timeouts With this new feature in

Oracle 10g, every minute PMON checks for sessions exceeding these

thresholds and kills those session who qualifies The MAX_IDLE_TIME
and MAX_IDLE_BLOCKER_TIME parameters defined in
CREATE_PLAN_DIRECTIVE procedure to release their resources.
Automatically Assigning Resource Consumer Groups to

Sessions This feature makes Oracle 10g DBRM more flexible by
mapping session attributes to consumer groups. This is done by adding
following two types of constants :- (These constants are used by the
SET_CONSUMER_GROUP_MAPPING procedure to define the consumer
group mappings.)
Login Attributes - oracle_user, service_name, client_os_user,

client_program, client_machine.
Runtime Attributes - module_name, module_name_action,
service_module, service_module_action
2.3 DBRM enhancements in 11g
With the release of 11g, DBRM was further enhanced with the following fea-
tures.
I/O Calibration With this feature asynchronous I/O can be

assessed by using procedure CALIBRATE_IO by performing I/O
intensive read-only workload.
Per Session I/O Limits Oracle 11g now capable of automatic

consumer group switching based on I/O thresholds apart from
consumer group switching based on single call or session time. The
SWITCH_IO_MEGABYTES and SWITCH_IO_REQS parameters are now
available for this purpose.
Resource Manager Statistics in AWR Historical data is available

now in new AWR views DBA_HIST_RSRC_PLAN and
DBA_HIST_RSRC_CONSUMER_GROUP and The
V$RSRCMGRMETRIC_HISTORY view displays one hours worth of
metrics taken from the V$RSRCMGRMETRIC view.
Built-In Resource Plans In order to give OLTP operations priority

over batch operations, oracle 11g came up with built-in resource plan
MIXED_WORKLOAD_PLAN. Calls assigned to the INTERACTIVE_GROUP

are automatically switched to the BATCH_GROUP if they exceed 60
seconds.
Instance Caging - Oracle 11gR2 came up with new feature called

Instance Caging which is discussed in details further in this
whitepaper.

3. What is Instance Caging
Server processing power is increasing day by day and most of the time serv-
ers are under-utilized or over-sized. Also managing multiple servers in-
creases administration cost. Hence, the IT Industry in general, and Data
Center management groups in particular, are looking for server consolidation
options. There are various options available in the market e.g. Hard Parti-
tions, O/S workload managers, Virtualization, Resource Managers and DB
(Oracle) Server Consolidation using Instance Caging.
Hard partitions basically refer to hardware partitions or processor sets.

Here, specific Processors are allocated to processor sets and each applica-
tion is associated with one or more processor sets. Hence, an application ac-
quires processors based on allocated processor sets. However, hard parti-
tions are not available in all operating systems and platforms
O/S Workload Manager allows Administrators to manage multiple types of

resources such as CPU and memory. O/S workload manager examples in-
clude the AIX workload manager, the HP-UX Workload Manager, and the So-
laris Resource Manager. However, O/S workload manager is not available in
all platforms. In addition, the OS workload managers are quite unaware of
workloads within a DBMS and hence quite inefficient when it comes to man-
aging database driven workloads. In other words, OS workload managers do
not differentiate (and hence cannot prioritize) between workloads in 2 data-
bases, say Database A and Database B, running on the same server. In ad-
dition, they cannot differentiate between, say an OLTP workload and a
BATCH workload within a given database.
In a Virtualized environment, one physical server runs multiple virtual serv-

ers and applications (and databases) run on virtual servers allocated to
them. It provides a good level of isolation and self-containment and is a very
widely used model for Server Consolidation.
Last but not the least, Oracle provides a resource manager and instance
caging feature which can prove very beneficial in Database Consolidated en-
vironments i.e. environments where multiple databases are consolidated
into a few servers with high processing power.
Key differences between the DBRM and Instance Caging

The Oracle DB Resource manager (DBRM)manages resources within a
database instance.
Instance caging limits CPU usage between Oracle database instances.
Both these features can be combined and used very effectively to guarantee
SLAs in a DB consolidated environment, as this paper explores and aims to
show
There are two approaches for instance caging.
Partitioning approach
In this approach, CPUs are assigned to databases and sum of assigned
CPUs are equal to or less than total CPUs in the server. This approach
can be considered for mission critical databases. Hence, one database
performance issue doesnt effects another database and provides pre-
dictable performance. Let us consider one server contains 4 CPUs and
4 databases are running in it and each CPU is allocated to each data-
base. So, each database consumes maximum one CPU (25% of the to-
tal CPUs) when other databases are idle.
Over provisioning approach

In this approach, CPUs are assigned to databases and sum of assigned CPUs are more
than number of CPUs in the server. This approach can be considered for non critical
databases. Here, it may be possible that one database performance can affect another
database performance. With this approach, most of time database will be benefitted of
low load on the server. Let us consider one server contains 4 CPUs and 4 databases are
running in it and two CPUs are allocated to each database. Hence, each database will
consume 2/(2+2+2+2)=25% of the CPU. If two databases are running, each database will
consume 2/(2+2)=50% of the CPU.
The main advantage of instance caging is that it does not require any new
software to be installed or licensed.
CPU_COUNT parameter is set to allocate number of CPUs to each database.

Using below query, CPU allocation to database can be viewed.
Select value from v$parameter where name=CPU_COUNT AND (isde-

fault = FALSE or ismodified !=FALSE);
The v$rsrcmgrmetric_history view shows CPU consumed time and CPU wait
time for each minute in past one hour for each consumer group.

Select to_char(begin_time,dd/mm/yyyy hh24:mi) , con-
sumer_group_name,cpu_consumed_time, cpu_wait_time from
v$rsrcmgrmetric_history order by begin_time;
The v$RSRC_CONSUMER_GROUP view shows CPU consumed time and CPU

wait time for each consumer group since CPU resource management was
enabled.
Select name,consumed_cpu_time, cpu_wait_time from

v$rsrc_consumer_group;

4. Resource Plans
4.1 Bottlenecks prevalent with OS Resource

Allocation methods
Database processes are ultimately spawned as OS processes and hence the

OS resource prioritization applied to them as well. Resource allocation deci-
sions are taken by operating system which may lead to the following bottle-
necks.
Excessive overhead When many server processes are running, context switching occurs
between oracle server processes, as well as, between Oracle and non-
Oracle processes
Insufficient schedule When a database server holds latches, the OS de-
schedules those database server processes
Equal resource allocation The OS allocates equal resources to all active processes. Due to this,
the database server is not able to prioritize tasks based on a
database priority
Inability to manage database Parallel execution and active sessions are not managed by the OS.
specific resources
To avoid the above problems, Oracle Resource Management and the Instance Caging features
can be employed.
4.2 Considerations for designing Resource Plans
The goal of designing a Resource plan is to achieve a balance between the available resources,
the known priority of tasks & processes and imposing limits on resource metrics which control
the amount of resources available to a database as a whole, and also govern how these available
resources are, in turn, distributed to the contending processes
With the help of a resource plan, CPU resources are allocated properly
based on known workloads. With this, one can achieve SLAs even if the

database server is excessively loaded or if the number of users is higher
than expected. Various CPU allocation ratios are defined proportionately
to the constituent consumer groups.
It is also possible to limit the degree of parallelism for operations such
that no single process can exhaust the available pool of parallel slave
processes.
It is also possible to create an active session pool which works on a
queuing mechanism. An active session pool is defined with a limit which
governs how many sessions for any consumer group can be active at any
given point of time. The rest of the sessions are, in effect, waiting for
their turn in being allocated CPU cycles.
One can also enable automatic switching of users from one consumer
group to another group based on certain triggering conditions. For
instance, if a consumer group can be configured to have its session
switched to another low resource consumer group if it has already
executed for a certain period of time.
An undo pool can be configured, with which the administrator can limit
the amount of undo generated by a group of users.
Idle time of sessions can also be configured after which they can be
forced to disconnect thus releasing any resources they are holding on to.
In addition, the administrator can also dynamically change the
resource plan (at the Database Level) without a restart of the database.
Changing a plan may be useful when the profile of the database's
workload vary. E.g. Weekdays, Weekends, Weeknights can be configured
with different methods of resource allocation.
Long running queries, can be automatically terminated, based on
specified predicates and this allows other sessions to continue processing
without any performance impact.
The above are the pre-dominant considerations taken into account when de-
signing resource management plans within the Oracle database.
4.3 Steps to setup resource management in a database
You can create a simple resource plan using create_simple_plan proce-

dure.
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'sam-
ple_plan',
CONSUMER_GROUP1 => 'group1', GROUP1_CPU => 60,
CONSUMER_GROUP2 => 'group2', GROUP2_CPU => 40);
END;

Executing the preceding statements creates the following plan
Consumer Group Level 1 Level 2 Level 3

SYS_GROUP 100% - -
group1 - 60% -
group2 - 40% -
OTHER_GROUPS - - 100%
To create complex plans, you have to follow a three-step process which con-
sists of creating, validating and then submitting a pending (work) area
Using below statement, a pending area is created.
EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
This procedure validates changes in resource manager plan.
EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA;
Once you verify plan, you can then submit the pending area.
EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA;
You can clear an existing pending area using the below procedure.
EXEC DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA;
You must call the CREATE_PENDING_AREA procedure before you can make
any change in plan.
You can create a resource plan using the create_plan procedure.
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN => 'Sample_plan',

COMMENT => 'Sample plan');
You can setup the consumer group such that it will be allowed to switch its
consumer group immediately using SWITCH_CONSUMMER_GROUP_FOR_SESS
procedure from lower resource group to higher resource group and
vice versa.

EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('10',
'12000', 'low_priorty');
You can switch all sessions of specific user using below procedure. Below ex-
ample move all CRM users to high group.
EXEC DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER
('CRM','high_group');
4.4 Catering to mixed workloads using Resource Plans
You can create mixed workload plan using resource plan. Below plan is
summarized in the following table:
CPU Re- Maximum

source Al- Active Ses- Estimated
location sion Pool Switching Execution Undo
Group % Parameters Parameters Time Pool
OLTP Level 1: Switch to -- Size:
60% group: OLAP 400K
Use esti-
mate: TRUE
OLAP Level 2: Pool size: 3 -- Time: 1200 --
100% Timeout:
300
OTHER_GROUP Level 3: -- -- -- --
S 100%
Below steps can be followed to create a resource plan called SIBLE_PLAN.

This step also creates two consumer groups (OLTP and OALP) and also as-
signs resource management directives to these groups to control their re-
source allocation.
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN => 'SIBLE_PLAN',
COMMENT => 'Resource plan for SIBLE Application'
);
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
CONSUMER_GROUP => 'OLTP',

COMMENT => 'Resource consumer group for SIBLE Application'
);
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
CONSUMER_GROUP => 'OLAP',
COMMENT => 'Resource consumer group for SIBLE Night jobs'
);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
PLAN => 'sible_plan',
GROUP_OR_SUBPLAN => 'OLTP',
COMMENT => 'OLTP jobs',
CPU_P1 => 60,
SWITCH_GROUP => 'OLAP',
SWITCH_ESTIMATE => TRUE,
UNDO_POOL => 400);
GROUP_OR_SUBPLAN => 'OLAP',
COMMENT => 'OLAP jobs', CPU_P2 => 100,
ACTIVE_SESS_POOL_P1 => 3, QUEUEING_P1 => 300,
MAX_EST_EXEC_TIME => 1200);
GROUP_OR_SUBPLAN => 'OTHER_GROUPS', COMMENT => 'mandatory',
CPU_P3 => 100);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
4.5 Managing multiple instances on a single server
To manage multiple instances on a single server, you can use the Instance
Caging feature. With this feature, you can limit the available CPU at each
Oracle database instance level. This feature does not permit the Oracle da-
tabase instance to use more CPU cores than what it is configured to use.
This is specified in the Database Configuration file

5. Consumer Groups
Resource consumer groups are a set of sessions grouped together according

to their resource usage profile & SLA (Service Level Agreement) require-
ments. The database automatically creates several predefined consumer
groups. In Oracle database 11gR2, there are 25 predefined consumer groups
with several of them identified as mandatory. The data dictionary view
DBA_RSRC_CONSUMER_GROUPS has the list of predefined resource con-
sumer groups. The column RESOURCE_CONSUMER_GROUP in v$session
identifies the resource consumer group that a particular session belongs to.
Various session attributes can be used to group a set of sessions into a con-
sumer group. The session attributes are as below:
Attribute Type Description

ORACLE_USER Login Oracle Database username
SERVICE_NAME Login The database service name used by
the client
CLIENT_OS_USER Login The OS user name of the client
CLIENT_PROGRAM Login The program name used to connect
to the database
CLIENT_MACHINE Login The machine name from where the
client is connected
CLIENT_ID Login The client identifier set by calling
dbms_session.set_identifier proce-
dure
MODULE_NAME Run- The module name set by calling
Time dbms_application_info. Set_module
procedure
MODULE_NAME_ACTION Run- The module/action combination set
Time by calling the dbms_application_info
procedure
SERVICE_MODULE Run- A combination of service name and
Time the module name
SER- Run- A combination of service name,
VICE_MODULE_ACTION Time module name and the action
ORACLE_FUNCTION Run- This is used during RMAN backup,
Time copy or Data pump operation.
For example, if you want to restrict some database users from running que-
ries using TOAD that are resource intensive then you can place those ses-
sions into a consumer group ADHOC_QUERIES by using the PL/SQL block
below:

Begin
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING (
attribute => DBMS_RESOURCE_MANAGER.CLIENT_PROGRAM,
value => toad.exe,
consumer_group => ADHOC_QUERIES
);
End;
/
After this PL/SQL block is executed whenever database user uses TOAD
software to login to the database, the session is automatically placed into
the ADHOC_QUERIES resource consumer group. Any time the session per-
forms a data pump operation then that session switches into a pre-defined
resource consumer group named ETL_GROUP. The value attribute accepts
wild-card characters similar to the SQL like operator.
Resource Consumer group mapping rules
As seen in the example above the database sessions and the consumer
groups are linked together using consumer group mapping rules. The ses-
sion and its consumer group can be identified using the data dictionary view
v$session.resource_consumer_group. Once a mapping rule is set up using
the DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING proce-
dure then the session is mapped into a consumer group either during login
or run-time. Oracle database has certain pre-defined mapping rules created
during the install.
Attribute Value Mapped Con- Comments

sumer Group
ORACLE_USER SYS SYS_GROUP Sessions connecting
as SYS USER auto-
matically maps into
SYS_GROUP
ORACLE_USER SYSTEM SYS_GROUP Sessions connecting
as SYSTEM USER
automatically maps
into SYS_GROUP
ORACLE_FUNCTION BACKUP BATCH_GROUP RMAN sessions doing
backup automatically
switch into
BATCH_GROUP dur-
ing backup operation

ORACLE_FUNCTION COPY BATCH_GROUP RMAN sessions doing
copy automatically
switch into
BATCH_GROUP dur-
ing copy operation
ORACLE_FUNCTION DATALOAD ETL_GROUP Any sessions doing
DATA_PUMP opera-
tion automatically
switches into
ETL_GROUP
For example, a database user named SCOTT logs into the database using
TOAD. This database user is mapped into the ADHOC_QUERIES consumer
group by default. The database user SCOTT knows that it is now off-peak
hours for the online users and can use more resources than what is assigned
to the ADHOC_QUERIES. The user SCOTT can now switch to a different con-
sumer group that the administrator has set up for him named AD-
HOC_QUERIES_OFFPEAK. He can switch into a different consumer group us-
ing the following PL/SQL procedure
DBMS_SESSION.SWITCH_CONSUMER_GROUP. This switch will be successful
provided the administrator has granted the user SCOTT permissions to
switch to this new consumer group.
Begin
DBMS_SESSION.SWITCH_CONSUMER_GROUP_FOR_USER (
user => SCOTT,
consumer_group => ADHOC_QUERIES_OFFPEAK
);
End;
/
This will switch the consumer group for all database sessions connected as
user SCOTT. The database user should have permissions to switch into a
new consumer group. When a session switches into a new consumer group,
the switch does not happen immediately but executes during the next data-
base call. The administrator must have granted the permissions directly or
through a role so the user can switch into the new consumer group.
Begin
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP (
grantee_name => SCOTT,
consumer_group => ADHOC_QUERIES_OFFPEAK,
grant_option => FALSE

);
End;
/
If the administrator grants permission to PUBLIC then any user can switch to
that particular consumer group. Any database user can switch to the pre-
defined consumer group OTHER_GROUPS as the grant is issued to PUBLIC.
5.1 Windows and Resource Plans
Scheduler Windows are pre-defined time ranges and they are intricately
linked with Resource Management in Oracle. Resource Plans can be created
to automatically become active when a window slides into the next one. This
allows the Administrator to ensure that workloads which change over a pe-
riod of time have appropriate resource plans defined as the Window
changes.
Scheduler Windows are linked with the Oracle Scheduler functionality and it
is possible to link Resource Plans with Scheduler windows which cause those
plans to be activated when the Window becomes operational.
This functionality allows the Administrator to define and automatically enable

appropriate resource plans for various times of the day in tune with the
changing workloads.
Scheduler window administration can be performed via command line APIs

or via the Oracle Enterprise Manager.

6. Resource Plan Directives
Resource plan directives specify how resources are allocated to resource

consumer groups or subplans. Each directive specifies the various resource
allocation methods. The types of resources managed by the resource man-
ager are described in the following section.
6.1 CPU
The following resource plan directives control CPU resource allocation
1. Management attributes
2. Maximum utilization limit
Management attributes, MGMT_Pn, where n can be a number between 1 and

8 is used to specify multiple levels of resource allocation. For example, con-
sider a database with a high-level resource plan named OLTP_USERS,
which uses 80% of CPU. Another resource consumer group or a sub-level re-
source plan can use the remaining 20% of CPU. If there is not enough load
from the database users using resource plan OLTP_USERS then the CPU
allocation is redistributed to another consumer group or the sub-plan.
In some cases, the lower priority consumer group can use up all the CPU
when there is low load from the higher priority consumer group. In such in-
stances, the maximum utilization attribute is helpful. The maximum utiliza-
tion attribute imposes an absolute upper limit on the CPU utilization for a re-
source consumer group.
6.2 Degree of Parallelism Limit
The PARALLEL_DEGREE_LIMIT_P1 attribute is used to limit the degree of

parallelism of one operation within a consumer group. This does not put an
absolute limit on the number of parallel processes that the sessions within a
consumer group can spawn.
6.3 Parallel Target Percentage

The PARALLEL_TARGET_PERCENTAGE directive attribute is used to limit the
number of parallel servers a resource consumer group can use. For example,
within a database the initialization parameter, PARALLEL_SERVERS_TARGET
is set to 32 then setting PARALLEL_TARGET_PERCENTAGE to 50% limits the
resource consumer group to use only 16 parallel servers. The rest of the
parallel processes are queued up for later execution.
6.4 Parallel Queue Timeout
The PARALLEL_QUEUE_TIMEOUT directive attribute specifies the maximum

time in seconds before the queued parallel processes times out.
6.5 Active Session Pool with Queuing
The maximum number of concurrently active sessions can be controlled by

defining an upper limit for the maximum active sessions.
6.6 Automatic Consumer Group Switching
When a resource plan is created, there are certain limits put on CPU, mem-
ory, and undo utilization. When such a threshold increases, one of the possi-
ble actions is to automatically switch the session to a different consumer
group with higher thresholds. This is possible to switch this session tempo-
rarily to higher consumer group until the SQL call is completed using this re-
source plan directive.
6.7 Canceling SQL and Terminating Sessions
This resource plan directive can be used to cancel long running SQL state-
ments when resource usage exceeds certain limits.
6.8 Execution Time Limit
This resource plan directive specifies the maximum execution time allowed
for an operation. If the database estimates that, a particular operation will
run longer then that operation is terminated with an error message.

6.9 Undo Pool
This resource plan directive controls the total amount of undo for uncommit-
ted transactions that can be generated by a resource consumer group.
6.10 Idle Time Limit
This resource plan directive can specify the amount of time that a session
can be idle, after which it is terminated. This allows the administrator to en-
sure that sessions connected for a long period of time and holding onto re-
sources that are needed by other sessions are terminated after a pre-
configured period of time.

7. Benchmarking the Resource Management Model
7.0 Objectives
The real test of resource management would be if by using it in a consoli-

dated DB Server consisting of more than one database, we can observe and
predict the impact of the following aspects of resource management on
workloads, ensuring that the CPU usage of any one of the databases does
not impact the other databases SLAs.
CPU_COUNT
MAX_UTILIZATION_LIMIT Resource Management directive
CPU allocation ratios to consumer groups
First of all, we run two tests to determine the TPM (Transactions per minute)
for the database in NOARCHIVELOG mode and in ARCHIVELOG mode. This
test is being done purely to determine if the rest of the tests can be done in
NOARCHIVELOG mode to ease the testing progress by eliminating the gen-
eration of archive logs in the test environment.
Then we run various benchmark scenarios documented in the individual sec-

tions measuring the Throughput per minute, OS Idle CPU and Average wait-
ing sessions as metrics for each scenario.
We use the Swingbench Oracle Load Generator to simulate the various

benchmarks. More information on this benchmarking tool can be obtained
from http://www.dominicgiles.com/swingbench.html
7.1 With NOARCHIVELOG
As can be seen below, the maximum TPM that could be achieved in this test
was 15764 TPM

7.2 With ARCHIVELOG
As can be seen below, the maximum TPM that could be achieved in this test
was 15650 TPM

All further tests will be done in NOARCHIVELOG mode as the TPM for both is
almost the same for our particular workload.
7.3 Activate SOE_PLAN (Resource Plan) without Instance Caging
Creating the SOE_PLAN Resource Plan
BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_consumer_group(
consumer_group=> 'SOE_GROUP',comment => 'Group for SOE Users');
dbms_resource_manager.submit_pending_area();
BEGIN
dbms_resource_manager_privs.grant_switch_consumer_group(
grantee_name=>'SOE',consumer_group=>'SOE_GROUP',grant_option=>FALSE
);
END;
END;
/

Creating the SOE_PLAN directives for SOE_GROUP and OTHER_GROUPS
BEGIN
--Create the SOE_PLAN
dbms_resource_manager.create_plan(
plan => 'SOE_PLAN',
comment=>'Planfor SOE_GROUP',
active_sess_pool_mth=>'ACTIVE_SESS_POOL_ABSOLUTE',
parallel_degree_limit_mth=>'PARALLEL_DEGREE_LIMIT_ABSOLUTE');
--Create the Plan Directives for the OTHER_GROUPS under the SOE_Plan
-- We have specified MGMT_P1 as 50 which means that not more than 50% of the CPU can
be
-- used by the sessions which are not part of SOE_GROUP
dbms_resource_manager.create_plan_directive(
plan => 'SOE_PLAN',
group_or_subplan => 'OTHER_GROUPS',
comment => 'Directives for Othergroups',
max_utilization_limit => null,
mgmt_p1 => 50, mgmt_p2 => null, mgmt_p3 => null, mgmt_p4 => null,
mgmt_p5 => null, mgmt_p6 => null, mgmt_p7 => null, mgmt_p8 => null ,
parallel_degree_limit_p1 => null ,
parallel_target_percentage => null ,
parallel_queue_timeout => null ,
switch_io_reqs => null,
switch_io_megabytes => null ,
active_sess_pool_p1 => null,
queueing_p1 => null,
switch_group => null,
switch_time => null,
switch_estimate => FALSE,
undo_pool => null ,
max_idle_time => null,
max_idle_blocker_time => null,
switch_for_call => null
);
--Create the Plan Directives for the SOE_GROUP under the SOE_Plan
-- We have specified MGMT_P1 as 50 which means that not more than 50% of the CPU can
be
-- used by the sessions which are part of SOE_GROUP
dbms_resource_manager.create_plan_directive(
plan => 'SOE_PLAN',
group_or_subplan => 'SOE_GROUP',
comment => 'Directives for SOE Group',
max_utilization_limit => null,
mgmt_p1 => 50, mgmt_p2 => null, mgmt_p3 => null, mgmt_p4 => null,
mgmt_p5 => null, mgmt_p6 => null, mgmt_p7 => null, mgmt_p8 => null ,
parallel_degree_limit_p1 => null ,
parallel_target_percentage => null ,
parallel_queue_timeout => null ,
switch_io_reqs => null,
switch_io_megabytes => null ,
active_sess_pool_p1 => null,
queueing_p1 => null,

switch_group => null,
switch_time => null,
switch_estimate => FALSE,
undo_pool => null ,
max_idle_time => null,
max_idle_blocker_time => null,
switch_for_call => null
);
END;
/
It is important to note with the above specification, that when the CPU is
saturated, the Oracle Resource Manager will ensure that not more than 50% of
the CPU is used by either the SOE_GROUP or the OTHER_GROUPs. However, if
spare CPU is available, either of these groups will be allowed to use more
than 50% of the CPU.
Enable the SOE User to switch to the SOE_GROUP
BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP
(
'SOE', 'SOE_GROUP', true
);
END;
/
Map the SOE user to the SOE_GROUP
execute DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
BEGIN
DBMS_RESOURCE_MANAGER.set_consumer_group_mapping (
attribute => DBMS_RESOURCE_MANAGER.oracle_user,
value => 'SOE',
consumer_group => 'SOE_GROUP');
END;
/
execute DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
Once the above steps are executed, we can view the Consumer group map-
ping from OEM which shows us that the SOE user now belongs to the
SOE_GROUP.

7.4 Limiting the maximum CPU to 50% for the SOE_GROUP
In this test scenario, we are going to limit the maximum CPU that the
SOE_GROUP can use to 50%
BEGIN
dbms_resource_manager.update_plan_directive(
plan => 'SOE_PLAN',
new_comment => null,
new_max_utilization_limit => 50
);
END;
/
This test is run without altering the CPU_COUNT but with resource plan
(SOE_PLAN) enabled with the MAX_UTILIZATION_LIMIT directive specified
to 50% for the SOE_GROUP
As can be seen from the benchmark window below, we were able to achieve
a maximum throughput of 15824 TPM and an average throughput of 13028
TPM

The below chart shows us the throughputs we were able to achieve for each
of the benchmarked transaction types i.e. Customer Registrations, Browse
Products, Order Products, Process Orders and Browse Orders.

We can also monitor how the resources are being managed within the data-
base using the below SQL script.
set lines 200 pages 999

alter session set nls_date_format=HH24:MI;
select
BEGIN_TIME,SEQUENCE#,CONSUMER_GROUP_NAME,
CPU_CONSUMED_TIME,CPU_WAIT_TIME,NUM_CPUS,
CPU_UTILIZATION_LIMIT,AVG_CPU_UTILIZATION
from v$rsrcmgrmetric_history;
The OTHER_GROUPS have a CPU_UTILIZATION_LIMIT of 100% but cur-

rently are using only around 0.1% of the CPU
The SOE_GROUP has a CPU_UTILIZATION_LIMIT of 50% and is currently us-

ing about 25 35% of the CPU on this server.

For this test, the number of CPUs available to the Oracle database are 4 and
the parameter resource_manager_cpu_allocation is set to 4 which means
that the Resource Manager has all 4 CPUs at its disposal to manage the Ora-
cle resources. Please note that the parameter resource_manager_cpu_allocation
has been deprecated and is only meant for backward compatibility
SQL> show parameter cpu
NAME TYPE VALUE

------------------------------------ ----------- ------------------------------
cpu_count integer 4
resource_manager_cpu_allocation integer 4

7.5 Combining Instance Caging with Resource Management limits
This is our culminating test scenario with 2 databases RMLAB and RMLAB2,
both running on the same server having 16CPU cores and 16GB of memory.
The below script allows us to set the maximum utilization limit to 25% of the
overall CPUs available to this DB. In addition, it allows us to specify that not
more than 50% of the maximum can be utilized by the SOE_GROUP of con-
sumers.
The same steps are run on both the databases thus imposing the same lim-
its on consumer groups connecting to both these databases (RMLAB and
RMLAB2)
BEGIN
dbms_resource_manager.update_plan_directive(
plan => 'SOE_PLAN',
new_comment => null,
new_max_utilization_limit => 25, new_mgmt_p1 => 50
);
END;
/
alter system set resource_manager_plan = 'SOE_PLAN' scope=BOTH;
7.5.1 Run time benchmark with 150 users
This shows the overall picture with respect to number of sessions waiting for
CPU. Also note that we have enabled instance caging by setting the value of
CPU_COUNT but we've chosen to specify the value of this parameter to the
maximum number of CPU cores available on this server. In other words, we
have enabled the instance caging algorithm but chosen to manage the work-

loads by forcing the Resource Management directive, Maximum Utilization
Limit, to 25%
7.5.2 RMLAB The Database view of CPU utilization and waiting sessions
For the RMLAB database, the average CPU used is hovering around 25%
which is the limit we forced. We can also see that the average number of
CPUs waiting for CPU cycles is around 67
7.5.3 RMLAB2 The Database view of CPU utilization and waiting sessions
Even for the RMLAB2 database, the average CPU used is hovering around
25% which is the limit we forced. We can see the average number of waiting
sessions are around 72.
7.5.4 OS CPU Stats OS level view of the run queue and idle CPU
The snapshot below shows the run queue and idle CPU available on the
Server when this benchmark was conducted

7.5.5 RMLAB Throughput (TPM) benchmark
The boxed area of the snapshot below shows the Throughput per minute
(TPM) benchmark for this test.

7.5.6 RMLAB2 Throughput (TPM) benchmark
The boxed area of the snapshot below shows the Throughput per minute
(TPM) benchmark for this test.
Now, we stop the RMLAB2 database to observe the effect of resource man-
agement within the surviving RMLAB database
We can see from the below Database view, that the average CPU utilization
is still around 25% but the number of waiting sessions have come down
from 67 to 49. This is due to the fact that the RMLAB2 consumer groups are
no longer competing for CPU on this server.
7.5.7 RMLAB DB Stats after stopping the RMLAB2 database.
Once the RMLAB2 is stopped we can see the that the Average waiting ses-
sions has dropped from around 72 to around 48 since more CPU is available
to RMLAB connections.

7.5.8 OS CPU - after stopping the RMLAB2 database.
The OS CPU idle time also, as expected, shows a significant increase in the
idle CPU available.
7.5.9 TPS on RMLAB - after stopping the RMLAB2 database
We can see that that throughput has increased from around 11,000 to
15,000

8. Benchmark Summary
The various tests done, their settings and observed readings are docu-
mented in the below table.
Note the TPM, OS CPU Idle and Sessions Waiting for CPU columns in the
above benchmark table. As the aim of this exercise is to ensure that we
have an optimal balance between these 3 measurements, we can see the
marked difference between these two sections
1. Both DB's running simultaneously WITHOUT Caging

1. Idle CPU 3%
2. Sessions Waiting for CPU 10

3. TPM 20913 & 19823
2. Both DB's running simultaneously WITH Caging
1. Idle CPU 37%
2. Sessions Waiting for CPU 65 and 62
3. TPM 12305, 11860
The above results show us that in the first scenario, we achieved a higher
TPM but at the cost of completely saturating the OS resources which means
that other concurrent workloads would suffer. In the second scenario, we
achieved a lesser TPM but ensuring that the OS resources are not compro-
mised. Workload Management and Optimization is all about balancing these
3 attributes and the Oracle Database Resource Managers provides Adminis-
trators with the tools to do so.

9. Monitoring Resource Management
Any database feature that the administrator uses needs monitoring to con-
firm if it is working as expected and if the feature requires any tuning ef-
forts. For such situations, the administrator turns to the data dictionary
views for assistance. For the database resource manager several dynamic
performance views exist in the data dictionary to monitor and tune this da-
tabase feature. The views provide information about currently active re-
source plans, historical activations of resource plans, and historical statistics
on resource consumption and CPU waits by both resource consumer group
and session. This section will discuss some of the important views in detail.
The following dynamic views allow the DBA to monitor and manage the re-
source management in the database.
V$RSRC_PLAN
V$RSRC_CONSUMER_GROUP
V$RSRC_SESSION_INFO
V$RSRC_PLAN_HISTORY
V$RSRC_CONS_GROUP_HISTORY
9.1 Resource plan
select plan, cpu_method, status from dba_rsrc_plans;
PLAN CPU_METHOD STATUS

-------------- ------------- --------------
SYSTEM_PLAN EMPHASIS ACTIVE
9.2 Resource consumer group
select consumer_group, cpu_method, status,mandatory

from dba_rsrc_consumer_groups;
CONSUMER_GROUP CPU_METHOD STATUS MAN

------------------------ -------------- ----------- ---
OTHER_GROUPS ROUND-ROBIN ACTIVE YES

DEFAULT_CONSUMER_GROUP ROUND-ROBIN ACTIVE YES
SYS_GROUP ROUND-ROBIN ACTIVE NO
LOW_GROUP ROUND-ROBIN ACTIVE NO
9.3 Resource plan directives
select plan, group_or_subplan, type,

cpu_p1, cpu_p2, cpu_p3, cpu_p4, status
from dba_rsrc_plan_directives
order by 8,1,2,3,4,5,6;
PLAN GROUP_OR_SUBPLAN TYPE CPU_P1 CPU_P2

CPU_P3 CPU_P4 STATUS
-------------- ----------------- -------------- ------- -------
------- ------- -------------
SYSTEM_PLAN LOW_GROUP CONSUMER_GROUP 0 0
100 0 ACTIVE
SYSTEM_PLAN OTHER_GROUPS CONSUMER_GROUP 0 100
0 0 ACTIVE
SYSTEM_PLAN SYS_GROUP CONSUMER_GROUP 100 0
0 0 ACTIVE
9.4 Privileges
select * from dba_rsrc_consumer_group_privs;
GRANTEE GRANTED_GROUP GRA INI

-------------- ------------------------------ --- ---
PUBLIC DEFAULT_CONSUMER_GROUP YES YES
PUBLIC LOW_GROUP NO NO
SYSTEM SYS_GROUP NO YES
9.5 Default consumer group for users
select username, initial_rsrc_consumer_group

from dba_users;
USERNAME INITIAL_RSRC_CONSUMER_GROUP
------------- ------------------------------
SYS SYS_GROUP
SYSTEM SYS_GROUP
SCOTT DEFAULT_CONSUMER_GROUP

For more information on these and other available views, please refer to the
Oracle documentation link below.
http://docs.oracle.com/cd/B28359_01/server.111/b28310/dbrm009.htm#A
DMIN11906
The below script allows us to see the CPU utilized, average running sessions
and average waiting sessions for each of the consumer groups in the data-
base
set lines 200 pages 999
alter session set nls_date_format='HH24:MI';
column CONSUMER_GROUP_NAME format a15
select BEGIN_TIME, CONSUMER_GROUP_NAME , CPU_CONSUMED_TIME,

CPU_WAIT_TIME, CPU_UTILIZATION_LIMIT, AVG_CPU_UTILIZATION,
AVG_RUNNING_SESSIONS,AVG_WAITING_SESSIONS
from v$rsrcmgrmetric_history
;

10. Known Issues and Troubleshooting
1. Recommended Patches for Resource Manager (CPU) [ID 1207483.1]
MOS note 1207483.1 recommends list of patches that the customer must
apply when using the database resource manager.
2. High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource

Manager Is Disabled.
MOS note 949033.1 describes this issue with a solution. The solution is to disable the usage
of the default resource plan during the weekday window.

Summary
As discussed, there are various options available for workload management
in consolidated environment. However when you consider database envi-
ronment consolidation, we have to consider resource management and in-
stance caging option. Added advantage is that there is no separate software
installation or licensed.
Please read resources section for further information.

Resources
Please refer to the below link for the Oracle Database Resource Manager
Reference.
http://docs.oracle.com/cd/B28359_01/server.111/b28310/dbrm011.htm#CHDFFJGJ
Please send an e-mail to the IBM Oracle International Competency Center at

ibmoracle@us.ibm.com or to the authors if there is any question about this topic.

About the authors
Surya Rao : Service Line Architect, Data Management Competency, GTS, Service Delivery
Viren Parikh : ISME, Data Management Competency, GTS, Service Delivery
Sathish Bala : SME, Data Management Competency, GTS, Service Delivery

Shailesh Mishra : SME, Data Management Competency, GTS, Service Delivery

Trademarks and special notices
Copyright. IBM Corporation 1994-2013. All rights reserved.
References in this document to IBM products or services do not imply that IBM intends to make them
available in every country.
IBM. the IBM logo, ibm.com, AIX, POWER, POWER6, POWER7, Systems Storage, Power Systems and
System x are trademarks or registered trademarks of International Business Machines Corporation in the
United States, other countries, or both:
UNIX is a registered trademark of The Open Group in the United States and other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
The information provided in this document is distributed AS IS without any warranty, either express or
implied.
The information in this document may include technical inaccuracies or typographical errors.
Information concerning non-IBM products was obtained from a supplier of these products, published an-
nouncement material, or other publicly available sources and does not constitute an endorsement of such
products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly avail-
able information, including vendor announcements and vendor worldwide homepages. IBM has not tested
these products and cannot confirm the accuracy of performance, capability, or any other claims related to
non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier
of those products.
All statements regarding IBM future direction and intent are subject to change or withdrawal without no-
tice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for
the full text of the specific Statement of Direction.
Some information addresses anticipated future capabilities. Such information is not intended as a defini-
tive statement of a commitment to specific levels of performance, function or delivery schedules with re-
spect to any future products. Such commitments are only made in IBM product announcements. The in-
formation is presented here to communicate IBM's current investment and development activities as a
good faith effort to help with our customers' future planning.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled
environment. The actual throughput or performance that any user will experience will vary depending
upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configura-
tion, the storage configuration, and the workload processed. Therefore, no assurance can be given that
an individual user will achieve throughput or performance improvements equivalent to the ratios stated
here.
Photographs shown are of engineering prototypes. Changes may be incorporated in production models.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in
any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part
of the materials for this IBM product and use of those Web sites is at your own risk.


Workload Management in Consolidated Oracle Database Environments RAO 25MAR13

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Workload Management in Consolidated Oracle Database Environments RAO 25MAR13

Загружено:

Авторское право:

Доступные форматы

Workload Management

In Consolidated Oracle Database Environments

Surya Rao, Viren Parikh, Sathish Bala, Shailesh Mishra

Copyright IBM Corporation, 2013. All Rights Reserved.

IBM White paper title here

IBM White paper title here

IBM White paper title here

Database resource manager, introduced in Oracle 8i, helps in workload man-

Database resource managers typically help in the following areas of Re-

Resource managers can guarantee at least a minimum amount of CPU

IBM White paper title here

IBM White paper title here

Reader should have knowledge on database administration.

1. Elements of Resource Manager

IBM White paper title here

Let us understand these three elements with an example.

We will create a simple resource plan called OLTP_DSS_DAYTIME_PLAN on a

IBM White paper title here

Oracle Database Resource Manager (DBRM) was first introduced in Oracle 8i

2.1 DBRM enhancements in 9i

The following new features were introduced in Oracle 9i.

Active Session Pool This provides FIFO mechanism with time-out

IBM White paper title here

Modified Views Oracle 9i becomes more interactive as some

V$SESSION and V$MYSESSIONS added with

2.2 DBRM enhancements in 10g

Setting Consumer Group Switch Times Per Call For multi-tier

CANCEL_SQL and KILL_SESSION With this new feature,

Setting Consumer Group Idle Timeouts With this new feature in

IBM White paper title here

Automatically Assigning Resource Consumer Groups to

Login Attributes - oracle_user, service_name, client_os_user,

2.3 DBRM enhancements in 11g

I/O Calibration With this feature asynchronous I/O can be

Per Session I/O Limits Oracle 11g now capable of automatic

Resource Manager Statistics in AWR Historical data is available

Built-In Resource Plans In order to give OLTP operations priority

IBM White paper title here

Instance Caging - Oracle 11gR2 came up with new feature called

IBM White paper title here

Hard partitions basically refer to hardware partitions or processor sets.

O/S Workload Manager allows Administrators to manage multiple types of

In a Virtualized environment, one physical server runs multiple virtual serv-

Key differences between the DBRM and Instance Caging

IBM White paper title here

There are two approaches for instance caging.

Over provisioning approach

CPU_COUNT parameter is set to allocate number of CPUs to each database.

Select value from v$parameter where name=CPU_COUNT AND (isde-

IBM White paper title here

The v$RSRC_CONSUMER_GROUP view shows CPU consumed time and CPU

Select name,consumed_cpu_time, cpu_wait_time from

IBM White paper title here

4.1 Bottlenecks prevalent with OS Resource

Database processes are ultimately spawned as OS processes and hence the

4.2 Considerations for designing Resource Plans

IBM White paper title here

4.3 Steps to setup resource management in a database

You can create a simple resource plan using create_simple_plan proce-

IBM White paper title here

Consumer Group Level 1 Level 2 Level 3

Using below statement, a pending area is created.

This procedure validates changes in resource manager plan.

You can create a resource plan using the create_plan procedure.