Using Resource Manager To Detect and Kill Idle Sessions
Using Resource Manager To Detect and Kill Idle Sessions
Using Resource Manager To Detect and Kill Idle Sessions
1)
In this Document
Purpose
Scope
Details
Monitoring
Support
References
APPLIES TO:
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version
N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Information in this document applies to any platform.
***Checked for relevance on 21-Jul-2017***
PURPOSE
Sessions that are idle for long periods of time cause problems because they hold
onto valuable resources such as PGA
memory that may be needed by other workloads. Idle sessions are even more
problematic when the session is processing
a query that returns a large number of rows and partway through, the session
becomes idle, waiting for the client to issue
a call to fetch the next set of rows. Such a wait can be extremely long if the
application has timed out or the application is
waiting for a user input to fetch the next set of rows. In this case, the session
is likely to be holding many resources,
including locks, PGA memory, temp space, and undo space. If the query is using
parallel execution, then the session will
also be holding onto parallel servers, each of which may also be holding onto more
locks, PGA memory, etc.
This scenario is often seen with ad-hoc query tools like SQL Developer and Toad.
For a DBA, the only solution is to detect
these idle sessions and kill them. This article describes how to use Resource
Manager to do this automatically.
SCOPE
DETAILS
Resource Manager provides different features for workload management, including the
ability to automatically detect and
kill idle session. An idle session is defined to be a user (not background) session
whose wait class is “Idle”. Using a
Resource Plan, you can configure the maximum number of seconds that a session can
be idle before being killed.
Using the resource plan below, any session that is idle for more than 300 seconds
will be automatically killed.
begin
dbms_resource_manager.create_pending_area;
dbms_resource_manager.create_plan(
plan => 'idle_mgmt_plan',
comment => 'Detects and kills idle sessions');
dbms_resource_manager.create_plan_directive(
plan => 'idle_mgmt_plan',
group_or_subplan => 'other_groups',
max_idle_time => 300,
comment => 'Limits idle time for all sessions to 300 seconds');
dbms_resource_manager.submit_pending_area;
end;
/
alter system set resource_manager_plan = idle_mgmt_plan;
In this example, all sessions are controlled with the same idle time limit. For
more flexibility, you could create multiple
consumer groups and specify a unique idle time limit for each consumer group. For
example, in a resource plan with SYS,
OLTP, BATCH, and ADHOC consumer groups, BATCH could be limited to 300 seconds of
idle time while ADHOC is limited
to 100 seconds.
You can also configure a maximum idle time for sessions that is only enforced if
the session is blocking another session by
using the directive MAX_IDLE_BLOCKER_TIME. MAX_IDLE_BLOCKER_TIME defines the
maximum time a session
assigned to this consumer group can be idle while holding resources that another
session needs according to Hang
Manager. Its default value is NULL, which represents unlimited time. In the
resource plan below, sessions are killed if they
are idle for more than 60 seconds and blocking another session by setting
MAX_IDLE_BLOCKER_TIME to 60. In addition,
sessions are killed if they are idle for more than 300 seconds by setting
MAX_IDLE_TIME to 300.
begin
dbms_resource_manager.create_pending_area;
dbms_resource_manager.create_plan(
plan => 'idle_mgmt_plan2',
comment => 'Detects and kills idle sessions');
dbms_resource_manager.create_plan_directive(
plan => 'idle_mgmt_plan2',
group_or_subplan => 'other_groups',
max_idle_blocker_time => 60,
max_idle_time => 300,
comment => 'Limits idle time for blocking sessions to 60 seconds and to 300 seconds
otherwise');
dbms_resource_manager.submit_pending_area;
end;
/
alter system set resource_manager_plan = idle_mgmt_plan2;
Monitoring
This query shows the current resource plan:
select name from v$rsrc_plan;
This query shows the idle time thresholds for each consumer group:
select d.group_or_subplan, d.max_idle_time, d.max_idle_blocker_time from
dba_rsrc_plan_directives
d, v$rsrc_plan p where d.plan = p.name and (d.max_idle_time is not null or
d.max_idle_blocker_time
is not null) and d.status is null;
Recommended Bug Description Releases
Bug 9523768
IDLE SESSIONS AREN’T ACTUALLY
KILLED IMMEDIATELY
For 11.2.0.1, 11.2.0.1 Exadata BP 1 to
5
Request patch.
Enable the following event:
event="10720 trace name context
forever, level 4096" # Kill idle sessions
immediately
For 11.2.0.2, 11.2.0.3, 11.2.0.1
Exadata BP 6+
Enable the following event:
event="10720 trace name context
forever, level 4096" # Kill idle sessions
immediately
11.2.0.1 - 11.2.0.3
Bug 13837378 ALTER SYSTEM KILL SESSION
IMMEDIATE DOES NOT KILL QC
SESSIONS
Since an "immediate" kill is used to kill
idle sessions, the feature requires this
bug fix in order to work on parallel
queries.
11.2.0.1 - 12.1.0.1
Bug 8891495 NON-IDLE SESSIONS ARE KILLED
In some intermittent timing windows,
a non-idle session is mistaken for an
idle session and is killed.
11.2.0.1 only
This query shows the number of idle sessions that have been killed thus far.
select name, idle_sessions_killed, idle_blkr_sessions_killed from
v$rsrc_consumer_group;
Support
We recommend that this feature be used with RDBMS 11.2.0.1 or higher. See the table
below for recommended bug
fixes. Recommended bug fixes for prior releases are not listed.
For more information on Resource Manager, see the Primary MOS note Document
1339769.1.