Основные понятия
По умолчанию менеджер ресурсов отключен и БД обрабатывает все сеансы одинаково.
Но можно настромть resource manager для управления рабочими нагрузками по разному,
настроив группы потребителей (consumer group) и планы ресурсов (resource plan).
consumer group - это набор сессий, которые управляются как единое целое.
Например можно определить consumer groups для каждого приложения
или для каждого типа рабочей нагрузки (OLTP, DSS итд).
resource plan - это директивы, указывающие как ресурсы CPU должны быть распределены
между группами потребителей (consumer group).
Все пользователи (кроме SYS и SYSTEM) по умолчанию относятся к группе:
DEFAULT_CONSUMER_GROUP
SET SQLFORMAT ANSICONSOLE
SET LINESIZE 32767
SET PAGESIZE 50000
select username,
initial_rsrc_consumer_group
from dba_users;
USERNAME INITIAL_RSRC_CONSUMER_GROUP
----------------------------------------------------
SYS SYS_GROUP
SYSTEM SYS_GROUP
XS$NULL DEFAULT_CONSUMER_GROUP
OJVMSYS DEFAULT_CONSUMER_GROUP
OUTLN DEFAULT_CONSUMER_GROUP
SYS$UMF DEFAULT_CONSUMER_GROUP
DBSNMP DEFAULT_CONSUMER_GROUP
APPQOSSYS DEFAULT_CONSUMER_GROUP
DBSFWUSER DEFAULT_CONSUMER_GROUP
GGSYS DEFAULT_CONSUMER_GROUP
ANONYMOUS DEFAULT_CONSUMER_GROUP
GSMADMIN_INTERNAL DEFAULT_CONSUMER_GROUP
XDB DEFAULT_CONSUMER_GROUP
WMSYS DEFAULT_CONSUMER_GROUP
GSMCATUSER DEFAULT_CONSUMER_GROUP
ANGOR DEFAULT_CONSUMER_GROUP
REMOTE_SCHEDULER_AGENT DEFAULT_CONSUMER_GROUP
SYSBACKUP DEFAULT_CONSUMER_GROUP
SYSRAC DEFAULT_CONSUMER_GROUP
AUDSYS DEFAULT_CONSUMER_GROUP
DIP DEFAULT_CONSUMER_GROUP
SYSKM DEFAULT_CONSUMER_GROUP
ORACLE_OCM DEFAULT_CONSUMER_GROUP
SYSDG DEFAULT_CONSUMER_GROUP
GSMUSER DEFAULT_CONSUMER_GROUP
25 rows selected.
Какие предустановленные группы имеются в БД:
SELECT consumer_group, status, comments
FROM dba_rsrc_consumer_groups;
CONSUMER_GROUP STATUS COMMENTS
---------------------------------------------------------------------------------------------------------------------------------------------
BATCH_GROUP Consumer group for batch operations
ORA$AUTOTASK Consumer group for autotask operations
INTERACTIVE_GROUP Consumer group for interactive, OLTP operations
OTHER_GROUPS Consumer group for users not included in any consumer group with a directive in the currently active plan
DEFAULT_CONSUMER_GROUP Consumer group for users not assigned to any consumer group
SYS_GROUP Consumer group for system administrators
LOW_GROUP Consumer group for low-priority sessions
ETL_GROUP Consumer group for ETL
DSS_GROUP Consumer group for DSS queries
DSS_CRITICAL_GROUP Consumer group for critical DSS queries
ORA$APPQOS_0 Consumer group for Application QOS
ORA$APPQOS_1 Consumer group for Application QOS
ORA$APPQOS_2 Consumer group for Application QOS
ORA$APPQOS_3 Consumer group for Application QOS
ORA$APPQOS_4 Consumer group for Application QOS
ORA$APPQOS_5 Consumer group for Application QOS
ORA$APPQOS_6 Consumer group for Application QOS
ORA$APPQOS_7 Consumer group for Application QOS
18 rows selected.
Все пользователи, при создании автоматически становятся членами группы
DEFAULT_CONSUMER_GROUP
Эту группу нельзя указывать в директивах плана ресурсов.
Для текущего активного плана ресурсов, все сеансы, которые не определены
в директивах этого плана считаются как "прочие" и относятся к предопределённой группе:
OTHER_GROUPS.
В группу OTHER_GROUPS нельзя включать пользователей, но в директивах плана её указывать нужно,
чтобы указать сколько ресурсов выделено прочим пользователям.
Все прочие пользователи могут быть членами других групп, не прописанных в директивах текущего
ресурсного плана, а также членами группы DEFAULT_CONSUMER_GROUP, так как эта группа
по определению не должна использоваться в директивах плана ресурсов.
ORA$AUTOTASK Эта определенная по умолчанию группа потребителей ресурсов используется для автоматически выполняемых задач, таких как генерация статистических данных. Приоритет таких задач, как сбор статистики, будет оставаться ниже приоритета задач, выполняемых в заданной по умолчанию группе потребителей.
Можно создать новую группу:
begin
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_consumer_group(
consumer_group => 'TEST_GROUP',
comment => 'TEST group.'
);
dbms_resource_manager.submit_pending_area();
end;
/
SELECT consumer_group, status, comments
FROM dba_rsrc_consumer_groups;
CONSUMER_GROUP STATUS COMMENTS
-----------------------------------------------------------------------------------------
BATCH_GROUP Consumer group for batch operations
ORA$AUTOTASK Consumer group for autotask operations
INTERACTIVE_GROUP Consumer group for interactive, OLTP operations
OTHER_GROUPS Consumer group for users not included in any consumer group with a directive in the currently active plan
DEFAULT_CONSUMER_GROUP Consumer group for users not assigned to any consumer group
SYS_GROUP Consumer group for system administrators
LOW_GROUP Consumer group for low-priority sessions
ETL_GROUP Consumer group for ETL
DSS_GROUP Consumer group for DSS queries
DSS_CRITICAL_GROUP Consumer group for critical DSS queries
ORA$APPQOS_0 Consumer group for Application QOS
ORA$APPQOS_1 Consumer group for Application QOS
ORA$APPQOS_2 Consumer group for Application QOS
ORA$APPQOS_3 Consumer group for Application QOS
ORA$APPQOS_4 Consumer group for Application QOS
ORA$APPQOS_5 Consumer group for Application QOS
ORA$APPQOS_6 Consumer group for Application QOS
ORA$APPQOS_7 Consumer group for Application QOS
TEST_GROUP TEST group.
19 rows selected.
И добавить в неё пользователя:
begin
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(
attribute => dbms_resource_manager.oracle_user,
value => 'angor',
consumer_group => 'TEST_GROUP'
);
dbms_resource_manager.submit_pending_area();
end;
/
select username,
initial_rsrc_consumer_group
from dba_users;
USERNAME INITIAL_RSRC_CONSUMER_GROUP
-----------------------------------------------------
SYS SYS_GROUP
SYSTEM SYS_GROUP
XS$NULL DEFAULT_CONSUMER_GROUP
OJVMSYS DEFAULT_CONSUMER_GROUP
OUTLN DEFAULT_CONSUMER_GROUP
SYS$UMF DEFAULT_CONSUMER_GROUP
DBSNMP DEFAULT_CONSUMER_GROUP
APPQOSSYS DEFAULT_CONSUMER_GROUP
DBSFWUSER DEFAULT_CONSUMER_GROUP
GGSYS DEFAULT_CONSUMER_GROUP
ANONYMOUS DEFAULT_CONSUMER_GROUP
GSMADMIN_INTERNAL DEFAULT_CONSUMER_GROUP
XDB DEFAULT_CONSUMER_GROUP
WMSYS DEFAULT_CONSUMER_GROUP
ANGOR TEST_GROUP
GSMCATUSER DEFAULT_CONSUMER_GROUP
REMOTE_SCHEDULER_AGENT DEFAULT_CONSUMER_GROUP
SYSBACKUP DEFAULT_CONSUMER_GROUP
SYSRAC DEFAULT_CONSUMER_GROUP
AUDSYS DEFAULT_CONSUMER_GROUP
DIP DEFAULT_CONSUMER_GROUP
SYSKM DEFAULT_CONSUMER_GROUP
ORACLE_OCM DEFAULT_CONSUMER_GROUP
SYSDG DEFAULT_CONSUMER_GROUP
GSMUSER DEFAULT_CONSUMER_GROUP
25 rows selected.
Автоматическое назначение группы потребителей ресурсов сеансу
Диспетчер ресурсов базы данных может автоматически назначать сеанс пользователя
в конкретную группу потребителей в соответствии с определенными атрибутами сеанса.
Достаточно отобразить атрибуты сеанса на различные группы потребителей,
и при регистрации пользователя подходящая группа потребителей будет присвоена
этому пользователю в соответствии с его атрибутами.
Возникший конфликт может быть разрешен путем назначения приоритетов отображениям
атрибутов сеанса на группы потребителей ресурсов.
Для сопоставления атрибутов сеансов и групп потребителей ресурсов
и определения приоритетов отображения служат две процедуры из пакета DBMS_RESOURCE_MANAGER:
SET_CONSUMER_GROUP_MAPPING
SET_CONSUMER_MAPPING_PRI
Существуют два различных типа атрибутов сеансов.
Первый набор охватывает атрибуты регистрации, которые помогают Database Resource Manager
определить первоначальную группу потребителей для пользователя.
Второй набор атрибутов сеансов состоит из атрибутов времени выполнения.
Ниже перечислены некоторые атрибуты сеанса, которые учитываются при отображении
сеанса пользователя на конкретную группу потребителей ресурсов:
Attribute (Type) Description
--------------------------------------------------------------------------------
ORACLE_USER (Login) The Oracle Database user name
SERVICE_NAME (Login) The service name used by the client to establish a connection
CLIENT_OS_USER (Login) The operating system user name of the client that is logging in
CLIENT_PROGRAM (Login) The name of the client program used to log into the server
CLIENT_MACHINE (Login) The name of the machine from which the client is making the connection
MODULE_NAME (Runtime) The module name in the application currently executing as set by the DBMS_APPLICATION_INFO.SET_MODULE procedure or the equivalent OCI attribute setting
MODULE_NAME_ACTION (Runtime) A combination of the current module and the action being performed as set by either of the following procedures
or their equivalent OCI attribute setting:
DBMS_APPLICATION_INFO.SET_MODULE
DBMS_APPLICATION_INFO.SET_ACTION
The attribute is specified as the module name followed by a period (.), followed by the action name (module_name.action_name).
SERVICE_MODULE (Runtime) A combination of service and module names in this form: service_name.module_name
SERVICE_MODULE_ACTION (Runtime) A combination of service name, module name, and action name, in this form: service_name.module_name.action_name
Отображение каждого из этих атрибутов сеанса на конкретную группу потребителей ресурсов
выполняется с помощью процедуры SET_CONSUMER_GROUP_MAPPING.
Иногда между двумя отображениями могут возникать конфликты и для их разрешения используется процедура:
DBMS_RESOURCE_MANAGER.set_consumer_group_mapping_pri (
explicit IN NUMBER,
oracle_user IN NUMBER,
service_name IN NUMBER,
client_os_user IN NUMBER,
client_program IN NUMBER,
client_machine IN NUMBER,
module_name IN NUMBER,
module_name_action IN NUMBER,
service_module IN NUMBER,
service_module_action IN NUMBER
)
Для разрешения конфликтов назначаются приоритеты.
Параметры сопоставляются с константами, за исключением параметра EXPLICIT, который представляет
явные вызовы для переключения групп потребителей с использованием процедур:
SWITCH_CURRENT_CONSUMER_GROUP
SWITCH_CONSUMER_GROUP_FOR_SESS
SWITCH_CONSUMER_GROUP_FOR_USER
Присвоенные приоритеты должны быть уникальными целыми числами от 1 до 10, где 1 обозначает наивысший приоритет.
BEGIN
DBMS_RESOURCE_MANAGER.set_consumer_group_mapping_pri (
explicit => 1,
oracle_user => 2,
service_name => 3,
client_os_user => 4,
client_program => 5,
client_machine => 6,
module_name => 7,
module_name_action => 8,
service_module => 9,
service_module_action => 10
);
END;
/
Используя приведенный выше пример, ORACLE_USER имеет более высокий приоритет, чем MODULE_NAME.
При изменении атрибута сеанса пользователь автоматически переводится в соответствующую группу потребителей ресурсов.
Можно, например завести сервис:
exec DBMS_SERVICE.CREATE_SERVICE('TSVC','TSVC');
exec DBMS_SERVICE.START_SERVICE('TSVC');
Создать группу ресурсов и включить сервис в эту группу:
BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP('TGRP','TGRP');
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(DBMS_RESOURCE_MANAGER.SERVICE_NAME,'TSVC','TGRP');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
SELECT P.ATTRIBUTE, P.PRIORITY, M.VALUE, M.CONSUMER_GROUP
FROM DBA_RSRC_GROUP_MAPPINGS M, DBA_RSRC_MAPPING_PRIORITY P
WHERE M.STATUS IS NULL
AND P.STATUS IS NULL
AND M.ATTRIBUTE(+) = P.ATTRIBUTE
ORDER BY 2,1,3,4;
ATTRIBUTE PRIORITY VALUE CONSUMER_GROUP
-----------------------------------------------------------
EXPLICIT 1
SERVICE_MODULE_ACTION 2
SERVICE_MODULE 3
MODULE_NAME_ACTION 4
MODULE_NAME 5
SERVICE_NAME 6 TSVC TGRP
ORACLE_USER 7 ANGOR TEST_GROUP
ORACLE_USER 7 SYS SYS_GROUP
ORACLE_USER 7 SYSTEM SYS_GROUP
CLIENT_PROGRAM 8
CLIENT_OS_USER 9
CLIENT_MACHINE 10
CLIENT_ID 11
13 rows selected.
Для RAC сервисы создаём так:
--Create a service for OLTP sessions
srvctl add service -d orcl -s DBRAC_OLTP -preferred orcl2 -available orcl1
srvctl start service -d orcl -s DBRAC_OLTP
--Create a service for BATCH sessions
srvctl add service -d orcl -s DBRAC_BATCH -preferred orcl2 -available orcl1
srvctl start service -d orcl -s DBRAC_BATCH
Просмотр ресурсных планов
Какие планы ресурсов существуют:
SELECT plan, comments FROM dba_rsrc_plans;
PLAN COMMENTS
------------------------------------
MIXED_WORKLOAD_PLAN Example plan for a mixed workload that prioritizes interactive operations over batch operations
DEFAULT_MAINTENANCE_PLAN Default plan for maintenance windows that prioritizes SYS_GROUP operations, leaving 5% for automated maintenance operations and 20% for other tasks.
DEFAULT_PLAN Default, basic, pre-defined plan that prioritizes SYS_GROUP operations and allocates minimal resources for automated maintenance and diagnostics operations.
INTERNAL_QUIESCE Plan for quiescing the database. This plan cannot be activated directly. To activate, use the quiesce command.
INTERNAL_PLAN Internally-used plan for disabling the resource manager.
APPQOS_PLAN Plan for Application QOS Management that provides a fixed set of allocations to the consumer groups that Application QOS uses to manage workload resource allocation.
ETL_CRITICAL_PLAN Example plan for DSS workloads that prioritizes ETL and critical DSS queries.
ORA$AUTOTASK_PLAN Plan for global maintenance in a consolidated database. This plan is for internal use only. It cannot be modified.
ORA$ROOT_PLAN Plan for administration tasks in the ROOT of a consolidated database. This plan is for internal use only. It cannot be modified.
ORA$QOS_PLAN Plan for QOS Management that provides a fixed set of allocations to the consumer groups that QOS uses to manage workload resource allocation.
DSS_PLAN Example plan for DSS workloads that prioritizes DSS queries over ETL.
11 rows selected.
ORA$AUTOTASK_SUB_PLAN Определенный по умолчанию подплан для задач автоматического обслуживания. Директива для этого подплана должна быть включена в каждый план верхнего уровня, чтобы можно было управлять ресурсами, используемыми задачами автоматического обслуживания.
ORA$AUTOTASK_HIGH_SUB_PLAN Определенный по умолчанию подплан для высокоприоритетных задач автоматического обслуживания. Обращение к этому подплану выполняется посредством ORA$AUTOTASK_SUB_PLAN и не должно выполняться непосредственно.
Активировать существующий ресурсный план можно так:
alter system set resource_manager_plan = 'MY_PLAN' scope=both;
Например, существует предопределённый план:
DEFAULT_PLAN
Активировав его:
alter system set resource_manager_plan = 'DEFAULT_PLAN' sid='*';
Мы получим следующие преимущества:
Фоновые процессы, например такие как PMON и LSM не будут нуждаться
в ресурсах процессора из-за чрезмерной нагрузки от foreground процессов.
SYS и SYSTEM запланированы с наивысшим приоритетом.
Время их отклика не будет зависеть от неуправляемого потребления ресурсов CPU обычными пользователями.
Из-под SYS всегда можно будет войти в систему и устранить проблемы с БД
Автоматизированные задачи обслуживания запланированы с наименьшим приоритетом,
значит они не будут конкурировать с другими сеансами за CPU.
Но, когда рабочая нагрузка БД низкая, то задачи обслуживания будут использовать
любые свободные для использования ресурсы CPU.
Отключить ресурсный менеджер можно так:
ALTER SYSTEM SET resource_manager_plan='';
По умолчанию параметр не установлен.
select name, value, display_value, default_value from v$parameter
where name = 'resource_manager_plan'
NAME VALUE DISPLAY_VALUE DEFAULT_VALUE
--------------------------------------------------------------
resource_manager_plan
Но активный план ресурсов сейчас такой:
select name, cpu_managed from v$rsrc_plan where is_top_plan = 'TRUE';
NAME CPU_MANAGED
--------------------------------------
INTERNAL_PLAN OFF
Через некоторое время активировался план ресурсов:
select name, cpu_managed from v$rsrc_plan where is_top_plan = 'TRUE';
NAME CPU_MANAGED
--------------------------------------
DEFAULT_MAINTENANCE_PLAN ON
Этот план был активирован одним из этих окон:
SELECT window_name, resource_plan, enabled, active
FROM dba_scheduler_windows;
WINDOW_NAME RESOURCE_PLAN ENABLED ACTIVE
----------------------------------------------------------------
MONDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE FALSE
TUESDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE FALSE
WEDNESDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE FALSE
THURSDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE TRUE
FRIDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE FALSE
SATURDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE FALSE
SUNDAY_WINDOW DEFAULT_MAINTENANCE_PLAN TRUE FALSE
WEEKNIGHT_WINDOW FALSE FALSE
WEEKEND_WINDOW FALSE FALSE
9 rows selected.
Как видим, с окнами связан план ресурсов:
DEFAULT_MAINTENANCE_PLAN
А когда окна открываются, то и активируются связанные с ними планы ресурсов.
Включены ли эти окна в группы?:
select * from DBA_SCHEDULER_WINGROUP_MEMBERS;
WINDOW_GROUP_NAME WINDOW_NAME
---------------------------------------------
MAINTENANCE_WINDOW_GROUP MONDAY_WINDOW
MAINTENANCE_WINDOW_GROUP TUESDAY_WINDOW
MAINTENANCE_WINDOW_GROUP WEDNESDAY_WINDOW
MAINTENANCE_WINDOW_GROUP THURSDAY_WINDOW
MAINTENANCE_WINDOW_GROUP FRIDAY_WINDOW
MAINTENANCE_WINDOW_GROUP SATURDAY_WINDOW
MAINTENANCE_WINDOW_GROUP SUNDAY_WINDOW
ORA$AT_WGRP_OS MONDAY_WINDOW
ORA$AT_WGRP_OS TUESDAY_WINDOW
ORA$AT_WGRP_OS WEDNESDAY_WINDOW
ORA$AT_WGRP_OS THURSDAY_WINDOW
ORA$AT_WGRP_OS FRIDAY_WINDOW
ORA$AT_WGRP_OS SATURDAY_WINDOW
ORA$AT_WGRP_OS SUNDAY_WINDOW
ORA$AT_WGRP_SA MONDAY_WINDOW
ORA$AT_WGRP_SA TUESDAY_WINDOW
ORA$AT_WGRP_SA WEDNESDAY_WINDOW
ORA$AT_WGRP_SA THURSDAY_WINDOW
ORA$AT_WGRP_SA FRIDAY_WINDOW
ORA$AT_WGRP_SA SATURDAY_WINDOW
ORA$AT_WGRP_SA SUNDAY_WINDOW
ORA$AT_WGRP_SQ MONDAY_WINDOW
ORA$AT_WGRP_SQ TUESDAY_WINDOW
ORA$AT_WGRP_SQ WEDNESDAY_WINDOW
ORA$AT_WGRP_SQ THURSDAY_WINDOW
ORA$AT_WGRP_SQ FRIDAY_WINDOW
ORA$AT_WGRP_SQ SATURDAY_WINDOW
ORA$AT_WGRP_SQ SUNDAY_WINDOW
28 rows selected.
Как видим, эти окна являются членами групп:
MAINTENANCE_WINDOW_GROUP
ORA$AT_WGRP_OS
ORA$AT_WGRP_SA
ORA$AT_WGRP_SQ
Смотрим когда будут открываться окна из этих групп:
select window_group_name,
enabled,
number_of_windows,
TO_CHAR(TO_TIMESTAMP_TZ(next_start_date, 'DD-MON-YY HH:MI:SS.FF AM TZH:TZM'), 'dd/mm/yyyy hh24:mi:ss') win_start_time,
comments
from dba_scheduler_window_groups;
WINDOW_GROUP_NAME ENABLED NUMBER_OF_WINDOWS WIN_START_TIME COMMENTS
-------------------------------------------------------------------------------------------------------------------------
MAINTENANCE_WINDOW_GROUP TRUE 7 05/07/2019 22:00:00 Window group for Automated Maintenance
ORA$AT_WGRP_OS TRUE 7 05/07/2019 22:00:00 auto optimizer stats collection
ORA$AT_WGRP_SA TRUE 7 05/07/2019 22:00:00 auto space advisor
ORA$AT_WGRP_SQ TRUE 7 05/07/2019 22:00:00 sql tuning advisor
Видим, что в каждой группе по 7 окон и очередные окна будут открываться в 22 часа.
Посмотрим расписание открытия этих окон:
select WINDOW_NAME,
RESOURCE_PLAN,
REPEAT_INTERVAL,
(extract (second from DURATION)
+ (extract (minute from DURATION)
+ (extract (hour from DURATION)
+ (extract (day from DURATION) * 24) ) * 60 ) * 60)/3600 DURATION_HOURS,
ENABLED
from DBA_SCHEDULER_WINDOWS
where WINDOW_NAME in (select WINDOW_NAME
from DBA_SCHEDULER_WINGROUP_MEMBERS
where WINDOW_GROUP_NAME='MAINTENANCE_WINDOW_GROUP');
WINDOW_NAME RESOURCE_PLAN REPEAT_INTERVAL DURATION_HOURS ENABLED
-------------------------------------------------------------------------------------------------------------------------------
WEDNESDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=WED;byhour=22;byminute=0; bysecond=0 4 TRUE
THURSDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=THU;byhour=22;byminute=0; bysecond=0 4 TRUE
SATURDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=SAT;byhour=6;byminute=0; bysecond=0 20 TRUE
SUNDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=SUN;byhour=6;byminute=0; bysecond=0 20 TRUE
FRIDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=FRI;byhour=22;byminute=0; bysecond=0 4 TRUE
MONDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0 4 TRUE
TUESDAY_WINDOW DEFAULT_MAINTENANCE_PLAN freq=daily;byday=TUE;byhour=22;byminute=0; bysecond=0 4 TRUE
7 rows selected.
Как видим, все окна в состоянии ENABLED=TRUE
Смотрим, какие клиенты используют данные auto task группы окон,
в качестве расписания для своего запуска:
select client_name,
consumer_group,
window_group,
status
from DBA_AUTOTASK_CLIENT;
CLIENT_NAME CONSUMER_GROUP WINDOW_GROUP STATUS
------------------------------------------------------------------------------
sql tuning advisor ORA$AUTOTASK ORA$AT_WGRP_SQ ENABLED
auto optimizer stats collection ORA$AUTOTASK ORA$AT_WGRP_OS ENABLED
auto space advisor ORA$AUTOTASK ORA$AT_WGRP_SA ENABLED
Также видим, что задачи будут выполняться в рамках consumer group: ORA$AUTOTASK
Смотрим какие автоматические задачи выполняют данные клиенты:
select client_name,
operation_name,
status
from DBA_AUTOTASK_OPERATION;
LIENT_NAME OPERATION_NAME STATUS
-----------------------------------------------------------------------
auto optimizer stats collection auto optimizer stats job ENABLED
auto space advisor auto space advisor job ENABLED
sql tuning advisor automatic sql tuning task ENABLED
Смотрим что все автоматические задачи готовы к выполнению:
Всё в статусе enabled
select window_name,
to_char (window_next_time, 'dd/mm/yyyy hh24:mi:ss') window_next_time,
window_active,
autotask_status,
optimizer_stats,
segment_advisor,
sql_tune_advisor
from DBA_AUTOTASK_WINDOW_CLIENTS;
WINDOW_NAME WINDOW_NEXT_TIME WINDOW_ACTIVE AUTOTASK_STATUS OPTIMIZER_STATS SEGMENT_ADVISOR SQL_TUNE_ADVISOR
--------------------------------------------------------------------------------------------------------------------------------
MONDAY_WINDOW 08/07/2019 22:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
TUESDAY_WINDOW 09/07/2019 22:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
WEDNESDAY_WINDOW 10/07/2019 22:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
THURSDAY_WINDOW 11/07/2019 22:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
FRIDAY_WINDOW 05/07/2019 22:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
SATURDAY_WINDOW 06/07/2019 06:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
SUNDAY_WINDOW 07/07/2019 06:00:00 FALSE ENABLED ENABLED ENABLED ENABLED
7 rows selected.
Смотрим статус последних выполнений данных задач:
select client_name,
task_name,
operation_name,
status,
last_try_result
from DBA_AUTOTASK_TASK;
CLIENT_NAME TASK_NAME OPERATION_NAME STATUS LAST_TRY_RESULT
-----------------------------------------------------------------------------------------------------------------
sql tuning advisor AUTO_SQL_TUNING_PROG automatic sql tuning task ENABLED SUCCEEDED
auto optimizer stats collection gather_stats_prog auto optimizer stats job ENABLED SUCCEEDED
auto space advisor auto_space_advisor_prog auto space advisor job ENABLED SUCCEEDED
Можно посмотреть, что окна действително открывались с определённой продолжительностью:
select window_name,
to_char (start_time, 'dd/mm/yyyy hh24:mi:ss') s_time,
(extract (second from DURATION)
+ (extract (minute from DURATION)
+ (extract (hour from DURATION)
+ (extract (day from DURATION) * 24) ) * 60 ) * 60)/3600 DURATION_HOURS
from DBA_AUTOTASK_SCHEDULE
order by start_time desc;
WINDOW_NAME S_TIME DURATION_HOURS
-------------------------------------------------------------
MONDAY_WINDOW 05/08/2019 22:00:00 4
SUNDAY_WINDOW 04/08/2019 06:00:00 20
SATURDAY_WINDOW 03/08/2019 06:00:00 20
FRIDAY_WINDOW 02/08/2019 22:00:00 4
THURSDAY_WINDOW 01/08/2019 22:00:00 4
WEDNESDAY_WINDOW 31/07/2019 22:00:00 4
TUESDAY_WINDOW 30/07/2019 22:00:00 4
MONDAY_WINDOW 29/07/2019 22:00:00 4
SUNDAY_WINDOW 28/07/2019 06:00:00 20
SATURDAY_WINDOW 27/07/2019 06:00:00 20
FRIDAY_WINDOW 26/07/2019 22:00:00 4
THURSDAY_WINDOW 25/07/2019 22:00:00 4
WEDNESDAY_WINDOW 24/07/2019 22:00:00 4
TUESDAY_WINDOW 23/07/2019 22:00:00 4
MONDAY_WINDOW 22/07/2019 22:00:00 4
SUNDAY_WINDOW 21/07/2019 06:00:00 20
SATURDAY_WINDOW 20/07/2019 06:00:00 20
FRIDAY_WINDOW 19/07/2019 22:00:00 4
THURSDAY_WINDOW 18/07/2019 22:00:00 4
WEDNESDAY_WINDOW 17/07/2019 22:00:00 4
Когда окна в последний раз открывались и закрывались:
select window_name,
to_char (window_start_time, 'dd/mm/yyyy hh24:mi:ss') win_start_time,
to_char (window_end_time, 'dd/mm/yyyy hh24:mi:ss') win_end_time
from DBA_AUTOTASK_WINDOW_HISTORY
order by window_start_time desc;
WINDOW_NAME WIN_START_TIME WIN_END_TIME
--------------------------------------------------------------
THURSDAY_WINDOW 04/07/2019 22:00:00 05/07/2019 02:00:00
WEDNESDAY_WINDOW 03/07/2019 22:00:00 04/07/2019 02:00:00
TUESDAY_WINDOW 02/07/2019 22:00:00 03/07/2019 02:00:00
MONDAY_WINDOW 01/07/2019 22:00:00 02/07/2019 02:00:00
SUNDAY_WINDOW 30/06/2019 06:00:00 01/07/2019 02:00:00
SATURDAY_WINDOW 29/06/2019 06:00:00 30/06/2019 02:00:00
FRIDAY_WINDOW 28/06/2019 22:00:00 29/06/2019 02:00:00
WEDNESDAY_WINDOW 26/06/2019 22:00:00 27/06/2019 02:00:00
MONDAY_WINDOW 24/06/2019 22:00:00 25/06/2019 02:00:00
SUNDAY_WINDOW 23/06/2019 06:00:00 24/06/2019 02:00:00
SATURDAY_WINDOW 22/06/2019 06:00:00 23/06/2019 02:00:00
FRIDAY_WINDOW 21/06/2019 22:00:00 22/06/2019 02:00:00
THURSDAY_WINDOW 20/06/2019 22:00:00 21/06/2019 02:00:00
WEDNESDAY_WINDOW 19/06/2019 22:00:00 20/06/2019 02:00:00
TUESDAY_WINDOW 18/06/2019 22:00:00 19/06/2019 02:00:00
15 rows selected.
Какие автоматические задачи запускались в конкретных окнах:
select client_name,
window_name,
to_char (window_start_time, 'dd/mm/yyyy hh24:mi:ss') win_start_time,
to_char ((extract (second from WINDOW_DURATION)
+ (extract (minute from WINDOW_DURATION)
+ (extract (hour from WINDOW_DURATION)
+ (extract (day from WINDOW_DURATION) * 24) ) * 60 ) * 60)/3600, '99990.9999') WIN_DURATION_HOURS,
to_char (window_end_time, 'dd/mm/yyyy hh24:mi:ss') win_end_time
from DBA_AUTOTASK_CLIENT_HISTORY
order by window_start_time desc;
CLIENT_NAME WINDOW_NAME WIN_START_TIME WIN_DURATION_HOURS WIN_END_TIME
-----------------------------------------------------------------------------------------------------------------------
auto optimizer stats collection THURSDAY_WINDOW 04/07/2019 22:00:00 4.0000 05/07/2019 02:00:00
auto space advisor THURSDAY_WINDOW 04/07/2019 22:00:00 4.0000 05/07/2019 02:00:00
sql tuning advisor THURSDAY_WINDOW 04/07/2019 22:00:00 4.0000 05/07/2019 02:00:00
auto optimizer stats collection WEDNESDAY_WINDOW 03/07/2019 22:00:00 4.0000 04/07/2019 02:00:00
auto space advisor WEDNESDAY_WINDOW 03/07/2019 22:00:00 4.0000 04/07/2019 02:00:00
sql tuning advisor WEDNESDAY_WINDOW 03/07/2019 22:00:00 4.0000 04/07/2019 02:00:00
auto optimizer stats collection TUESDAY_WINDOW 02/07/2019 22:00:00 4.0000 03/07/2019 02:00:00
auto space advisor TUESDAY_WINDOW 02/07/2019 22:00:00 4.0000 03/07/2019 02:00:00
sql tuning advisor TUESDAY_WINDOW 02/07/2019 22:00:00 4.0000 03/07/2019 02:00:00
auto optimizer stats collection MONDAY_WINDOW 01/07/2019 22:00:00 4.0000 02/07/2019 02:00:00
Сколько длились и как завершились задачи в конкретных окнах:
select client_name,
to_char (window_start_time, 'dd/mm/yyyy hh24:mi:ss') win_start_time,
to_char ((extract (second from WINDOW_DURATION)
+ (extract (minute from WINDOW_DURATION)
+ (extract (hour from WINDOW_DURATION)
+ (extract (day from WINDOW_DURATION) * 24) ) * 60 ) * 60)/3600, '99990.9999') WIN_DURATION_HOURS,
to_char (job_start_time, 'dd/mm/yyyy hh24:mi:ss') job_start_time,
to_char ((extract (second from JOB_DURATION)
+ (extract (minute from JOB_DURATION)
+ (extract (hour from JOB_DURATION)
+ (extract (day from JOB_DURATION) * 24) ) * 60 ) * 60)/3600, '99990.9999') JOB_DURATION_HOURS,
job_status,
job_error
from DBA_AUTOTASK_JOB_HISTORY
order by window_start_time desc;
CLIENT_NAME WIN_START_TIME WIN_DURATION_HOURS JOB_START_TIME JOB_DURATION_HOURS JOB_STATUS JOB_ERROR
-------------------------------------------------------------------------------------------------------------------------------------------------------
auto space advisor 04/07/2019 22:00:00 4.0000 04/07/2019 22:00:00 0.0011 SUCCEEDED 0
sql tuning advisor 04/07/2019 22:00:00 4.0000 04/07/2019 22:00:00 0.0489 SUCCEEDED 0
auto optimizer stats collection 04/07/2019 22:00:00 4.0000 04/07/2019 22:00:00 0.0625 SUCCEEDED 0
sql tuning advisor 03/07/2019 22:00:00 4.0000 03/07/2019 22:00:02 0.0681 SUCCEEDED 0
auto space advisor 03/07/2019 22:00:00 4.0000 03/07/2019 22:00:02 0.0011 SUCCEEDED 0
auto optimizer stats collection 03/07/2019 22:00:00 4.0000 03/07/2019 22:00:02 0.0797 SUCCEEDED 0
auto optimizer stats collection 02/07/2019 22:00:00 4.0000 02/07/2019 22:00:01 0.0817 SUCCEEDED 0
sql tuning advisor 02/07/2019 22:00:00 4.0000 02/07/2019 22:00:01 0.0583 SUCCEEDED 0
auto space advisor 02/07/2019 22:00:00 4.0000 02/07/2019 22:00:01 0.0025 SUCCEEDED 0
auto optimizer stats collection 01/07/2019 22:00:00 4.0000 01/07/2019 22:00:00 0.1286 SUCCEEDED 0
auto space advisor 01/07/2019 22:00:00 4.0000 01/07/2019 22:00:00 0.0019 SUCCEEDED 0
sql tuning advisor 01/07/2019 22:00:00 4.0000 01/07/2019 22:00:00 0.1606 SUCCEEDED 0
auto space advisor 30/06/2019 06:00:00 20.0000 30/06/2019 06:00:01 0.0011 SUCCEEDED 0
auto optimizer stats collection 30/06/2019 06:00:00 20.0000 30/06/2019 14:24:48 0.0069 SUCCEEDED 0
Директивы ресурсных планов:
select plan,
group_or_subplan,
mgmt_p1,
mgmt_p2,
mgmt_p3,
switch_group,
switch_for_call,
switch_time,
max_utilization_limit,
switch_time_in_call,
utilization_limit,
mandatory
FROM dba_rsrc_plan_directives
PLAN GROUP_OR_SUBPLAN MGMT_P1 MGMT_P2 MGMT_P3 SWITCH_GROUP SWITCH_FOR_CALL SWITCH_TIME MAX_UTILIZ_LIMIT SWITCH_TIME_IN_CALL UTILIZ_LIMIT MANDATORY
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
MIXED_WORKLOAD_PLAN SYS_GROUP 75 0 0 FALSE NO
MIXED_WORKLOAD_PLAN OTHER_GROUPS 2 0 0 FALSE NO
MIXED_WORKLOAD_PLAN INTERACTIVE_GROUP 20 0 0 BATCH_GROUP TRUE 60 60 NO
MIXED_WORKLOAD_PLAN BATCH_GROUP 2 0 0 FALSE NO
MIXED_WORKLOAD_PLAN ORA$AUTOTASK 1 0 0 FALSE 90 90 NO
DEFAULT_MAINTENANCE_PLAN SYS_GROUP 75 0 0 FALSE NO
DEFAULT_MAINTENANCE_PLAN OTHER_GROUPS 20 0 0 FALSE NO
DEFAULT_MAINTENANCE_PLAN ORA$AUTOTASK 5 0 0 FALSE 90 90 NO
DEFAULT_PLAN SYS_GROUP 90 0 0 FALSE NO
DEFAULT_PLAN OTHER_GROUPS 9 0 0 FALSE NO
DEFAULT_PLAN ORA$AUTOTASK 1 0 0 FALSE 90 90 NO
INTERNAL_QUIESCE SYS_GROUP 0 0 0 FALSE YES
INTERNAL_QUIESCE OTHER_GROUPS 0 0 0 FALSE YES
INTERNAL_PLAN SYS_GROUP 90 0 0 FALSE YES
INTERNAL_PLAN OTHER_GROUPS 9 0 0 FALSE YES
INTERNAL_PLAN ORA$AUTOTASK 1 0 0 FALSE 90 90 YES
DSS_PLAN SYS_GROUP 75 0 0 FALSE NO
DSS_PLAN DSS_CRITICAL_GROUP 18 0 0 FALSE NO
DSS_PLAN DSS_GROUP 3 0 0 FALSE NO
DSS_PLAN ETL_GROUP 1 0 0 FALSE NO
DSS_PLAN BATCH_GROUP 1 0 0 FALSE NO
DSS_PLAN ORA$AUTOTASK 1 0 0 FALSE 90 90 NO
DSS_PLAN OTHER_GROUPS 1 0 0 FALSE NO
ETL_CRITICAL_PLAN SYS_GROUP 75 0 0 FALSE NO
ETL_CRITICAL_PLAN DSS_CRITICAL_GROUP 8 0 0 FALSE NO
ETL_CRITICAL_PLAN DSS_GROUP 3 0 0 FALSE NO
ETL_CRITICAL_PLAN ETL_GROUP 8 0 0 FALSE NO
ETL_CRITICAL_PLAN BATCH_GROUP 3 0 0 FALSE NO
ETL_CRITICAL_PLAN ORA$AUTOTASK 1 0 0 FALSE 90 90 NO
ETL_CRITICAL_PLAN OTHER_GROUPS 2 0 0 FALSE NO
ORA$AUTOTASK_PLAN ORA$AUTOTASK 0 0 0 FALSE YES
ORA$ROOT_PLAN SYS_GROUP 75 0 0 FALSE YES
ORA$ROOT_PLAN OTHER_GROUPS 25 0 0 FALSE YES
ORA$QOS_PLAN SYS_GROUP 100 0 0 FALSE NO
ORA$QOS_PLAN ORA$APPQOS_0 57 0 0 FALSE NO
ORA$QOS_PLAN ORA$APPQOS_1 26 0 0 FALSE NO
ORA$QOS_PLAN ORA$APPQOS_2 12 0 0 FALSE NO
ORA$QOS_PLAN ORA$APPQOS_3 5 0 0 FALSE NO
ORA$QOS_PLAN OTHER_GROUPS 1 0 0 FALSE NO
ORA$QOS_PLAN ORA$AUTOTASK 1 0 0 FALSE NO
APPQOS_PLAN SYS_GROUP 75 0 0 FALSE NO
APPQOS_PLAN ORA$APPQOS_0 0 57 0 FALSE NO
APPQOS_PLAN ORA$APPQOS_1 0 26 0 FALSE NO
APPQOS_PLAN ORA$APPQOS_2 0 12 0 FALSE NO
APPQOS_PLAN ORA$APPQOS_3 0 5 0 FALSE NO
APPQOS_PLAN OTHER_GROUPS 0 0 80 FALSE NO
APPQOS_PLAN ORA$AUTOTASK 0 0 20 FALSE NO
47 rows selected.
Выдача привилегий:
Для администрирования диспетчера ресурсов у вас должна быть системная привилегия ADMINISTER_RESOURCE_MANAGER.
Эта привилегия (with the ADMIN option) предоставляется администраторам баз данных через роль DBA.
Для предоставления и отмены этого используются процедуры GRANT_SYSTEM_PRIVILEGE и
REVOKE_SYSTEM_PRIVILEGE пакета DBMS_RESOURCE_MANAGER_PRIVS.
begin
dbms_resource_manager_privs.grant_system_privilege(
grantee_name => 'DBADMIN',
admin_option => false);
end;
/
Проверка:
select * from dba_sys_privs where grantee='DBADMIN';
Отзыв привилегий:
begin
dbms_resource_manager_privs.revoke_system_privilege(
revokee_name => 'DBADMIN');
end;
/
Привилегии для автоматического переключения на ресурсную группу:
Чтобы назначить пользователей для групп потребителей ресурсов, отличных от стандартных,
пользователям должна быть предоставлена системная привилегия grant_switch_consumer_group, чтобы иметь возможность переключаться на эту группу потребителей.
Для предоставления и отмены этого используются процедуры GRANT_SWITCH_CONSUMER_GROUP и REVOKE_SWITCH_CONSUMER_GROUP пакета DBMS_RESOURCE_MANAGER_PRIVS.
Выдача привилегий:
begin
dbms_resource_manager_privs.grant_switch_consumer_group(
grantee_name => 'PUBLIC',
consumer_group => 'GROUP_NAME');
end;
/
Отзыв привилегий:
begin
dbms_resource_manager_privs.revoke_switch_consumer_group(
revokee_name => 'PUBLIC',
consumer_group => 'GROUP_NAME');
end;
/
Для активации Database Resource Manager , выполните:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = mydb_plan;
Для деактивации Database Resource Manager , выполните:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';
База данных может иметь несколько планов, но только один может быть активен в данный момент времени для каждого экземпляра.
Различные экземпляры RAC могут при необходимости активировать различные планы.
Создание простого плана ресурсов с использованием процедуры CREATE_SIMPLE_PLAN
Вы можете указать до восьми групп пользователей с этой процедурой. Единственный способ выделения ресурсов - это процессор.
В плане используется политика распределения ЦП EMPHASIS (по умолчанию),
и каждая группа потребителей использует политику планирования ROUND_ROBIN (также по умолчанию).
Следующий блок PL/SQL создает простой план ресурсов с двумя пользовательскими группами пользователей:
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN(SIMPLE_PLAN => 'mydb_plan',
CONSUMER_GROUP1 => 'MYGROUP1', GROUP1_PERCENT => 80,
CONSUMER_GROUP2 => 'MYGROUP2', GROUP2_PERCENT => 20);
END;
/
Executing the preceding statements creates the following plan:
Consumer Group Level 1 Level 2 Level 3
SYS_GROUP 100% - -
MYGROUP1 - 80% -
MYGROUP2 - 20% -
OTHER_GROUPS - - 100%
Каждая группа потребителей, указанная в плане, выделяет свой процент CPU на уровне 2.
Также неявно включены в план SYS_GROUP (группа, определяемая системой, которая является исходной группой потребителей для пользователей SYS и SYSTEM)
и OTHER_GROUPS.
Группе потребителей SYS_GROUP выделяется 100% CPU на уровне 1,
а OTHER_GROUPS выделяется 100% ЦП на уровне 3.
Список некоторых часто используемых параметров процедуры CREATE_PLAN_DIRECTIVE:
SWITCH_GROUP:
NULL, consumer_group_name, CANCEL_SQL, KILL_SESSION, LOG_ONLY.
Эти параметры определяют "что делать" или "куда переключаться"
SWITCH_TIME:
Определяет время на процессоре (не истекшее время), которое сеанс может выполнить до того,
как будет предпринято действие.
По умолчанию NULL, что означает UNLIMITED.
Как и в случае с другими директивами switch, если switch_for_call равен TRUE,
количество использованного процессорного времени накапливается с начала вызов.
В противном случае количество использованного процессорного времени накапливается на протяжении сеанса.
SWITCH_ESTIMATE:
Если TRUE, база данных оценивает время выполнения каждого вызова,
и если предполагаемое время выполнения превышает SWITCH_TIME,
сеанс переключается на SWITCH_GROUP до начала вызова. По умолчанию FALSE.
Оценка времени выполнения получается из оптимизатора. Точность оценки зависит от многих факторов,
особенно от качества статистики оптимизатора.
В целом, вы должны ожидать, что статистика будет не более точной, чем ± 10 минут.
SWITCH_IO_MEGABYTES:
Определяет количество операций ввода-вывода (в МБ), которое может выполнить сеанс до выполнения действия.
По умолчанию NULL, что означает UNLIMITED.
Как и в случае с другими директивами switch, если switch_for_call равен TRUE,
количество логических операций ввода-вывода накапливается с начала вызова.
В противном случае количество логических операций ввода-вывода накапливается на протяжении сеанса.
Действие определяется SWITCH_GROUP.
SWITCH_IO_REQS:
Задает количество запросов ввода-вывода, которые сеанс может выполнить до выполнения действия.
По умолчанию NULL, что означает UNLIMITED.
Как и в случае с другими директивами switch, если switch_for_call равен TRUE,
количество логических операций ввода-вывода накапливается с начала вызова.
В противном случае количество логических операций ввода-вывода накапливается на протяжении сеанса.
Действие определяется SWITCH_GROUP.
SWITCH_FOR_CALL:
Если TRUE, сеанс, который был автоматически переключен на другую группу потребителей
согласно (switch_time, switch_io_megabytes, switch_io_reqs, switch_io_logical или switch_elapsed_time),
возвращается в свою исходную группу потребителей, когда завершается вызов верхнего уровня.
По умолчанию FALSE, это означит что новая группа потребителей останется до завершения сеанса.
(Для WEB серверов сеансы сохраняем и ставим TRUE)
SWITCH_IO_LOGICAL:
Количество логических операций ввода-вывода, которые запустят действие, указанное switch_group.
Как и в случае с другими директивами switch, если switch_for_call равен TRUE,
количество логических операций ввода-вывода накапливается с начала вызова.
В противном случае количество логических операций ввода-вывода накапливается на протяжении сеанса.
SWITCH_ELAPSED_TIME:
Истёкшее время, которое запустит действие, указанное switch_group. Как и в других директивах switch,
если switch_for_call имеет значение TRUE, истекшее время накапливается с начала вызова.
В противном случае истекшее время накапливается для продолжительности сеанса.
Допустимые значения параметра SWITCH_GROUP описаны ниже:
NULL: автоматическое переключение групп потребителей не включено для этой директивы плана.
consumer_group_name: группа потребителей, к которой должен быть переключен сеанс/вызов, если достигнут порог.
CANCEL_SQL: если порог достигнут, текущий вызов отменяется, но сеанс не прерывается.
KILL_SESSION: если порог достигнут, текущий сеанс прерывается.
LOG_ONLY: если порог достигнут, событие регистрируется в SQL Monitor, но реально ничего не происходит с вызовом или сеансом.
Для всех параметров, связанных с переключателем, существует эквивалентный параметр NEW_ *
для изменения значений с помощью процедуры UPDATE_PLAN_DIRECTIVE.
V$SQL_MONITOR
Представление V$SQL_MONITOR включает четыре новых столбца менеджера ресурсов.
RM_LAST_ACTION: CANCEL_SQL, KILL_SESSION, LOG_ONLY, SWITCH TO < CG NAME >
RM_LAST_ACTION_REASON: SWITCH_CPU_TIME, SWITCH_IO_REQS, SWITCH_IO_MBS, SWITCH_ELAPSED_TIME, SWITCH_IO_LOGICAL
RM_LAST_ACTION_TIME: время последнего действия менеджера ресурсов.
RM_CONSUMER_GROUP: текущая группа потребителей.
Диспетчер ресурсов с базами данных контейнеров (CDB) и сменными базами данных (PDB)
В мультитеннентной среде менеджер ресурсов выполняет две отдельные задачи. На уровне CDB он контролирует ресурсы,
выделенные для каждой PDB, позволяя вам расставлять приоритеты для одних PDB над другими. На уровне PDB он контролирует ресурсы,
выделенные для каждого сеанса, подключенного к PDB, позволяя вам расставлять приоритеты для одних сеансов над другими
Создание комплексного плана ресурсов с использованием процедуры CREATE_PLAN
Сложный план ресурсов - это любой план ресурсов, который не создается с помощью процедуры CREATE_SIMPLE_PLAN.
Обратите внимание, что любой план ресурсов, созданный методом Simple Resource Plan с использованием CREATE_SIMPLE_PLAN,
также может быть создан методом комплексного ресурсного плана (this),
а также создание плана ресурсов с помощью этого метода дает большую гибкость и может иметь большую детализацию.
Когда ваша ситуация требует более сложного плана ресурсов,
вы должны создать план с его директивами и группами потребителей в промежуточной области,
называемой отложенной областью, а затем проверить план перед сохранением в словаре данных.
Вы можете создавать подпланы (план в планах) для более грамотного управления ресурсами.
Если потребительская группа не использует свой процент CPU, остаток переходит на следующий уровень,
и администратор может четко определить, что с ним делать. Можно указать до восьми уровней.
Ниже приведено общее руководство по выполнению плана менеджера баз данных:
1. Создайте планы ресурсов
2. Создание групп потребителей ресурсов
3. Создайте директивы плана ресурсов
4. Предоставить привилегии переключателя для групп пользователей ресурсов пользователям или ролям
5. Назначьте пользователей в группы пользователей ресурсов
6. Укажите план, который будет использоваться экземпляром
В дополнение к вышеуказанным шагам нам необходимо создать эти элементы в промежуточной области, называемой ожидающей областью,
поэтому приведенные ниже шаги относятся к области ожидания, которая может повторяться каждый раз для создания,
проверки и отправки этой ожидающей области.
1. Создание ожидающей области
2. Проверка области ожидания
3. Отправка ожидающей области
Следующий пример присваивает 80% ресурсов CPU сессиям в OLTP-группе и 10% для ADHOC и 10% для каждой группы BATCH.
предполагая, что мы создали 3 пользователей, ADHOC, BATCH и OLTP и назначили группу потребителей для каждого из них.
ЦП-ресурсы распределяются по всем группам потребителей по процентам, предоставленным каждой группе.
Указание нулевого процента для группы потребителей означает, что он не должен получать какие-либо ресурсы обработки на этом уровне,
учитывая потребление ЦП на 100%.
Это может заставить сеансы для этой группы потребителей долго ждать в перегруженной системе.
Это не означает, что пользователи, принадлежащие OTHER_GROUPS (с 0%), никогда не смогут запускаться,
но для полностью загруженной системы сеансы для OTHER_GROUPS должны ждать, пока остальные закончат работу.
Если это единственный активный сеанс, конечно, разрешено использовать все доступные ресурсы ЦП до 100%.
Но если другой сеанс запущен в другой группе, диспетчер ресурсов будет балансировать ресурсы ЦП в соответствии с директивами плана.
---Create pending area for plan, consumer group and directives
begin
dbms_resource_manager.create_pending_area();
end;
/
---1. Create resource plans
begin
dbms_resource_manager.create_plan(
plan => 'MYDB_PLAN',
comment => 'Resource plan/method for Single level sample');
end;
/
---2. Create resource consumer groups
begin
dbms_resource_manager.create_consumer_group(
consumer_group => 'OLTP_Group',
comment => 'Resource consumer group/method for online users sessions');
dbms_resource_manager.create_consumer_group(
consumer_group => 'BATCH_Group',
comment => 'Resource consumer group/method for users sessions who run batch jobs');
dbms_resource_manager.create_consumer_group(
consumer_group => 'ADHOC_Group',
comment => 'Resource consumer group/method for users sessions who execute Ad-Hoc Queries');
end;
/
---3. Create resource plan directives
begin
dbms_resource_manager.create_plan_directive(
plan => 'mydb_plan',
group_or_subplan => 'OLTP_Group',
comment => 'Online day users sessions at level 1',
cpu_p1 => 80,
parallel_degree_limit_p1 => 0);
dbms_resource_manager.create_plan_directive(
plan => 'mydb_plan',
group_or_subplan => 'BATCH_Group',
comment => 'batch day users sessions at level 1',
cpu_p1 => 10,
parallel_degree_limit_p1 => 10);
dbms_resource_manager.create_plan_directive(
plan => 'mydb_plan',
group_or_subplan => 'ADHOC_Group',
comment => 'ADHOC day users sessions at level 1',
cpu_p1 => 10,
parallel_degree_limit_p1 => 5);
dbms_resource_manager.create_plan_directive(
plan => 'mydb_plan',
group_or_subplan => 'OTHER_GROUPS',
comment => 'OTHER_GROUPS day users sessions at level 1',
cpu_p1 => 0,
parallel_degree_limit_p1 => 0);
end;
/
---Validate Pending area for plan, consumer group and directives
begin
dbms_resource_manager.validate_pending_area();
end;
/
---submit pending area for plan, consumer group and directives
begin
dbms_resource_manager.submit_pending_area();
end;
/
--- Затем мы должны предоставить привилегии, чтобы назначить группы пользователей пользователям:
--- Нам нужно снова создать ожидающую область, пока мы не представим ожидающую область
---Create pending area for privilages, roles and assign users
begin
dbms_resource_manager.create_pending_area();
end;
/
---4. Grant switch privilege for resource consumer groups to users or roles
begin
dbms_resource_manager_privs.grant_switch_consumer_group(
grantee_name => 'ADHOC',
consumer_group => 'ADHOC_Group',
grant_option => FALSE);
dbms_resource_manager_privs.grant_switch_consumer_group(
grantee_name => 'OLTP',
consumer_group => 'OLTP_Group',
grant_option => FALSE);
dbms_resource_manager_privs.grant_switch_consumer_group(
grantee_name => 'BATCH',
consumer_group => 'BATCH_Group',
grant_option => FALSE);
end;
/
---5. Assign users to resource consumer groups
begin
dbms_resource_manager.set_initial_consumer_group(
user => 'ADHOC',
consumer_group => 'ADHOC_Group');
dbms_resource_manager.set_initial_consumer_group(
user => 'OLTP',
consumer_group => 'OLTP_Group');
dbms_resource_manager.set_initial_consumer_group(
user => 'BATCH',
consumer_group => 'BATCH_Group');
end;
/
---Validate Pending area for privilages, roles and assign users
begin
dbms_resource_manager.validate_pending_area();
end;
/
---submit pending area for privilages, roles and assign users
begin
dbms_resource_manager.submit_pending_area();
end;
/
Specify a plan to be used by the instance
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = MYDB_PLAN;
===================================================================================
Проверка диспетчера ресурсов конфигурации и мониторинга
Мы можем использовать динамические представления производительности,
чтобы помочь нам отслеживать результаты нашего Oracle Database Resource Manager
Resource Plans:
select plan, cpu_method, status from dba_rsrc_plans order by 1;
PLAN CPU_METHOD STATUS
------------- ----------- ---------
MYDB_PLAN EMPHASIS ACTIVE
Resource Consumer Groups:
select consumer_group,cpu_method, status from dba_rsrc_consumer_groups order by 1;
CONSUMER_GROUP CPU_METHOD STATUS
------------------------------ ------------------------------ ------------------------------
ADHOC_GROUP ROUND-ROBIN ACTIVE
BATCH_GROUP ROUND-ROBIN ACTIVE
DEFAULT_CONSUMER_GROUP ROUND-ROBIN ACTIVE
OLTP_GROUP ROUND-ROBIN ACTIVE
OTHER_GROUPS ROUND-ROBIN ACTIVE
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 1,2,3,4,5,6;
PLAN GROUP_OR_SUBPLAN TYPE CPU_P1 CPU_P2 CPU_P3 CPU_P4 STATUS
---------------------- -------------------- -------------- ---------- ---------- ---------- ---------- -------
MYDB_PLAN ADHOC_GROUP CONSUMER_GROUP 10 0 0 0 ACTIVE
MYDB_PLAN BATCH_GROUP CONSUMER_GROUP 10 0 0 0 ACTIVE
MYDB_PLAN OLTP_GROUP CONSUMER_GROUP 80 0 0 0 ACTIVE
MYDB_PLAN OTHER_GROUPS CONSUMER_GROUP 0 0 0 0 ACTIVE
Resource consumer group privileges:
select * from dba_rsrc_consumer_group_privs;
GRANTEE GRANTED_GROUP GRA INI
------------------------------ ------------------------------ --- ---
BATCH BATCH_GROUP NO YES
OLTP OLTP_GROUP NO YES
PUBLIC DEFAULT_CONSUMER_GROUP YES YES
ADHOC ADHOC_GROUP NO YES
Эти пользователи имеют право переключаться на группу потребителей, отличную от стандартной.
Группы пользователей по умолчанию для пользователей:
select username, initial_rsrc_consumer_group from dba_users;
USERNAME INITIAL_RSRC_CONSUMER_GROUP
------------------------------ ------------------------------
SYS DEFAULT_CONSUMER_GROUP
SYSTEM DEFAULT_CONSUMER_GROUP
OLTP OLTP_GROUP
ADHOC ADHOC_GROUP
OUTLN DEFAULT_CONSUMER_GROUP
DBSNMP DEFAULT_CONSUMER_GROUP
BATCH BATCH_GROUP
Мониторинг использования ЦП и ожиданий по группам потребителей:
В этом примере сервер имеет 16 процессоров, что означает, что максимум 16 сеансов могут выполняться в любое время.
См. Примечание 1338988.1
select to_char(m.begin_time, 'HH:MI') time,
m.consumer_group_name,
m.cpu_consumed_time / 60000 avg_running_sessions,
m.cpu_wait_time / 60000 avg_waiting_sessions,
d.mgmt_p1*(select value from v$parameter where name = 'cpu_count')/100 allocation
from v$rsrcmgrmetric_history m,
dba_rsrc_plan_directives d,
v$rsrc_plan p
where m.consumer_group_name = d.group_or_subplan
and p.name = d.plan
order by m.begin_time, m.consumer_group_name;
TIME NAME AVG_RUNNING AVG_WAITING ALLOCATION
----- ------------------ ----------- ----------- ----------
13:34 ADHOC_GROUP 1.76 8.4 .8
13:34 BATCH_GROUP 2.88 .4 2.4
13:34 ETL_GROUP 0 0 2.4
13:34 INTERACTIVE_GROUP 10.4 6.8 5.6
13:34 OTHER_GROUPS .32 .08 .8
13:34 SYS_GROUP 0 0 4
==========================================================================================================
Очистка плана менеджера ресурсов
Чтобы удалить текущий план, сначала его нужно «отключить», или другой план должен быть выбран как текущий.
alter system set resource_manager_plan='';
---Create pending area for delete plan and consumer group
begin
dbms_resource_manager.create_pending_area();
end;
/
--Delete plan (assuming we have created 2 plans - MYDB_PLAN, ANY_OTHER_CREATED_PLAN)
begin
dbms_resource_manager.delete_plan(
plan => 'MYDB_PLAN');
dbms_resource_manager.delete_plan(
plan => 'ANY_OTHER_CREATED_PLAN');
end;
/
--Delete consumer group
begin
dbms_resource_manager.delete_consumer_group(
consumer_group => 'OLTP_GROUP');
dbms_resource_manager.delete_consumer_group(
consumer_group => 'BATCH_GROUP');
dbms_resource_manager.delete_consumer_group(
consumer_group => 'ADHOC_GROUP');
end;
/
---Validate Pending area for delete plan and consumer group
begin
dbms_resource_manager.validate_pending_area();
end;
/
---submit pending area for delete plan and consumer group
begin
dbms_resource_manager.submit_pending_area();
end;
/
--Clearing only the Pending Area, if you dont want to validate and submit
BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/
Ещё примеры:
BEGIN
DBMS_RESOURCE_MANAGER.clear_pending_area;
DBMS_RESOURCE_MANAGER.create_pending_area;
-- Do something
DBMS_RESOURCE_MANAGER.validate_pending_area;
DBMS_RESOURCE_MANAGER.submit_pending_area;
END;
/
CONN sys/password AS SYSDBA
BEGIN
DBMS_RESOURCE_MANAGER.clear_pending_area();
DBMS_RESOURCE_MANAGER.create_pending_area();
-- Create the consumer groups
DBMS_RESOURCE_MANAGER.create_consumer_group(
consumer_group => 'oltp_consumer_group',
comment => 'OLTP process consumer group.');
DBMS_RESOURCE_MANAGER.create_consumer_group(
consumer_group => 'batch_consumer_group',
comment => 'Batch process consumer group.');
DBMS_RESOURCE_MANAGER.validate_pending_area();
DBMS_RESOURCE_MANAGER.submit_pending_area();
END;
/
BEGIN
DBMS_RESOURCE_MANAGER.clear_pending_area();
DBMS_RESOURCE_MANAGER.create_pending_area();
-- Delete consumer groups.
DBMS_RESOURCE_MANAGER.delete_consumer_group (
consumer_group => 'oltp_consumer_group');
DBMS_RESOURCE_MANAGER.delete_consumer_group (
consumer_group => 'batch_consumer_group');
DBMS_RESOURCE_MANAGER.validate_pending_area();
DBMS_RESOURCE_MANAGER.submit_pending_area();
END;
/
BEGIN
DBMS_RESOURCE_MANAGER.clear_pending_area;
DBMS_RESOURCE_MANAGER.create_pending_area;
-- Create a new plan
DBMS_RESOURCE_MANAGER.create_plan(
plan => 'day_plan',
comment => 'Plan suitable for daytime processing.');
-- Assign consumer groups to plan and define priorities
DBMS_RESOURCE_MANAGER.create_plan_directive (
plan => 'day_plan',
group_or_subplan => 'oltp_consumer_group',
comment => 'Give OLTP processes higher priority - level 1',
cpu_p1 => 80,
switch_group => 'batch_consumer_group',
switch_time => 60);
DBMS_RESOURCE_MANAGER.create_plan_directive (
plan => 'day_plan',
group_or_subplan => 'batch_consumer_group',
comment => 'Give batch processes lower priority - level 2',
cpu_p2 => 100);
DBMS_RESOURCE_MANAGER.create_plan_directive (
plan => 'day_plan',
group_or_subplan => 'OTHER_GROUPS',
comment => 'all other users - level 3',
cpu_p3 => 100);
DBMS_RESOURCE_MANAGER.validate_pending_area;
DBMS_RESOURCE_MANAGER.submit_pending_area;
END;
/
BEGIN
DBMS_RESOURCE_MANAGER.clear_pending_area;
DBMS_RESOURCE_MANAGER.create_pending_area;
-- Create a new plan
DBMS_RESOURCE_MANAGER.create_plan(
plan => 'night_plan',
comment => 'Plan suitable for daytime processing.');
-- Assign consumer groups to plan and define priorities
DBMS_RESOURCE_MANAGER.create_plan_directive (
plan => 'night_plan',
group_or_subplan => 'batch_consumer_group',
comment => 'Give batch processes lower priority - level 2',
cpu_p1 => 80);
DBMS_RESOURCE_MANAGER.create_plan_directive (
plan => 'night_plan',
group_or_subplan => 'oltp_consumer_group',
comment => 'Give OLTP processes higher priority - level 1',
cpu_p2 => 100);
DBMS_RESOURCE_MANAGER.create_plan_directive(
plan => 'night_plan',
group_or_subplan => 'OTHER_GROUPS',
comment => 'all other users - level 3',
cpu_p3 => 100);
DBMS_RESOURCE_MANAGER.validate_pending_area;
DBMS_RESOURCE_MANAGER.submit_pending_area;
END;
/
Ещё примеры:
WEB сервер подключается к БД под одним пользователем:
TEST_USER
-- Создаём ресурсные группы:
-- TEST_HIGH_GROUP
-- TEST_MEDIUM_GROUP
-- TEST_LOW_GROUP
begin
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_consumer_group(
consumer_group => 'TEST_HIGH_GROUP',
comment => 'All TEST sessions start in this group.');
dbms_resource_manager.create_consumer_group(
consumer_group => 'TEST_MEDIUM_GROUP',
comment => 'TEST sessions are switched to this group after 10 seconds.');
dbms_resource_manager.create_consumer_group(
consumer_group => 'TEST_LOW_GROUP',
comment => 'Any sessions in this group have been executing for more than 120 seconds');
dbms_resource_manager.submit_pending_area();
end;
/
-- Дадим возможность пользователю TEST_USER
-- переключаться между группами:
-- TEST_HIGH_GROUP
-- TEST_MEDIUM_GROUP
-- TEST_LOW_GROUP
begin
dbms_resource_manager_privs.grant_switch_consumer_group (
grantee_name => 'TEST_USER',
consumer_group => 'TEST_HIGH_GROUP',
grant_option => FALSE );
dbms_resource_manager_privs.grant_switch_consumer_group (
grantee_name => 'TEST_USER',
consumer_group => 'TEST_MEDIUM_GROUP',
grant_option => FALSE );
dbms_resource_manager_privs.grant_switch_consumer_group (
grantee_name => 'TEST_USER',
consumer_group => 'TEST_LOW_GROUP',
grant_option => FALSE );
end;
/
begin
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
-- Создаём план ресурсов
dbms_resource_manager.create_plan( plan => 'TEST_PLAN', comment => 'TEST Plan');
-- Создаём директивы для нашего плана ресурсов
-- Сеанс, находясь в группах, получает ресурсы:
-- TEST_HIGH_GROUP 70% CPU
-- TEST_MEDIUM_GROUP 8 % CPU
-- TEST_LOW_GROUP 2 % CPU
-- Если вызов SQL выполняется более 10 секунд на CPU,
-- то переключаемся на группу TEST_MEDIUM_GROUP
dbms_resource_manager.create_plan_directive(
plan => 'TEST_PLAN',
group_or_subplan => 'TEST_HIGH_GROUP',
comment => 'All TEST sessions start in this group.',
mgmt_p1 => 70,
switch_group => 'TEST_MEDIUM_GROUP',
switch_time => 10,
switch_for_call => TRUE,
switch_estimate => FALSE );
-- Если вызов SQL выполняется более 120 секунд на CPU,
-- то переключаемся на группу TEST_LOW_GROUP
dbms_resource_manager.create_plan_directive(
plan => 'TEST_PLAN',
group_or_subplan => 'TEST_MEDIUM_GROUP',
comment => 'TEST sessions are switched to this group after 10 seconds.',
mgmt_p1 => 8,
switch_group => 'TEST_LOW_GROUP',
switch_time => 120,
switch_for_call => TRUE,
switch_estimate => FALSE );
-- Если вызов SQL выполняется более 1800 секунд на CPU,
-- то сеанс не будет прерван, но вызов SQL будет отменён
dbms_resource_manager.create_plan_directive(
plan=> 'TEST_PLAN',
group_or_subplan => 'TEST_LOW_GROUP',
comment => 'Any sessions in this group have been executing for more than 120 seconds',
mgmt_p1 => 2,
switch_group => 'CANCEL_SQL',
switch_time => 1800,
switch_for_call => TRUE,
switch_estimate => FALSE );
-- Создадим директивы для двух предопределённых групп
-- OTHER_GROUPS
-- ORA$AUTOTASK_SUB_PLAN
-- И выделим им по 10% ресурсов CPU
dbms_resource_manager.create_plan_directive(
plan=> 'TEST_PLAN',
group_or_subplan => 'OTHER_GROUPS',
comment => 'The mandatory group',
mgmt_p1 => 10
);
dbms_resource_manager.create_plan_directive(
plan=> 'TEST_PLAN',
group_or_subplan => 'ORA$AUTOTASK_SUB_PLAN',
comment => 'Sub plan for maintenance activity',
mgmt_p1 => 10
);
-- Установим группу TEST_HIGH_GROUP,
-- группой по умолчанию для пользователя TEST_USER
dbms_resource_manager.set_initial_consumer_group(
user => 'TEST_USER',
consumer_group => 'TEST_HIGH_GROUP');
dbms_resource_manager.submit_pending_area();
end;
/
-- Во время окон обслуживания активируется план DEFAULT_MAINTENANCE_PLAN
-- Мы хотим чтобы и во время окон обслуживания активировался наш план TEST_PLAN
begin
dbms_scheduler.set_attribute(
name => 'MONDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
dbms_scheduler.set_attribute(
name => 'TUESDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
dbms_scheduler.set_attribute(
name => 'WEDNESDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
dbms_scheduler.set_attribute(
name => 'THURSDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
dbms_scheduler.set_attribute(
name => 'FRIDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
dbms_scheduler.set_attribute(
name => 'SATURDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
dbms_scheduler.set_attribute(
name => 'SUNDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'TEST_PLAN'
);
end;
/
Активируем наш план TEST_PLAN на уровне экземпляра:
alter system set resource_manager_plan = 'TEST_PLAN' scope=both;
Представления:
select * from dba_rsrc_plans;
select * from dba_rsrc_plan_directives;
select * from dba_rsrc_consumer_groups;
select * from dba_rsrc_consumer_group_privs;
select * from dba_rsrc_mapping_priority;
select * from dba_rsrc_group_mappings;
select * from dba_rsrc_manager_system_privs;
select initial_rsrc_consumer_group from dba_users;
select resource_consumer_group, current_queue_duration from v$session;
select * from v$rsrc_plan;
select * from v$rsrc_consumer_group;
select * from dba_scheduler_wingroup_members;
select * from dba_scheduler_windows;
select * from dba_scheduler_window_groups;
select * from dba_autotask_client;
select * from dba_autotask_client_history;
select * from dba_autotask_job_history;
select * from DBA_AUTOTASK_CLIENT_JOB;
select * from dba_autotask_operation;
select * from dba_autotask_task;
select * from DBA_AUTOTASK_WINDOW_CLIENTS;
select * from DBA_AUTOTASK_WINDOW_HISTORY;
select * from DBA_AUTOTASK_SCHEDULE;
Комментариев нет:
Отправить комментарий