Настройка Oracle: производительность через диспетчер ресурсов базы данных

Илья Дергунов

Илья Дергунов

Автор статьи. ИТ-специалист с 20 летним стажем, автор большого количества публикаций на профильную тематику (разработка ПО, администрирование, новостные заметки). Подробнее.

Database Resource Manager - настройка производительности базы данных OracleПредположим, что перед нами стоит задача управления производственной базой данных Oracle, в которой присутствуют перечисленные ниже проблемы.

  • Пакетные задания отнимают большинство доступных ресурсов, что негативно сказывается на других, более критичных задачах, которые должны выполняться в это же время.
  • Избыточные нагрузки в часы максимальной нагрузки приводят к недопустимо длительному выполнению критичных процессов.
  • Существуют запланированные большие задания, для которых невозможно предсказать время их запуска.
  • Некоторые пользователи используют избыточное время ЦП, вынуждая резко прерывать их сеансы.
  • Некоторые пользователи используют очень высокую степень параллелизма своих операций, что негативно сказывается на производительности системы в целом.
  • Невозможно управлять активными сеансами.
  • Необходимо установить приоритеты задач в соответствии с определенной схемой, но это невозможно сделать с помощью ресурсов операционной системы.

Как видите, все эти проблемы проистекают из неспособности администратора БД эффективно распределять и настраивать ограниченные ресурсы между конкурирующими операциями, что ведет к неправильному распределению ресурсов и очень длительным интервалам отклика для важных заданий. Средством решения этой задачи является Oracle Resource Manager. Он позволяет создавать планы распределения ресурсов, которые указывают, как ресурсы должны предоставляться различным группам потребителей. Пользователей можно группировать, исходя из их потребностей в ресурсах, а Database Resource Manager может выделять заранее установленные объемы ресурсов этим группам. Ценные ресурсы ЦП можно распределять, выделяя определенный процент времени ЦП различным пользователям. Это позволяет легко устанавливать приоритеты пользователей и задач. Сетевые пользователи с более высоким приоритетом будут обслуживаться быстрее, а пакетные задания с более низким приоритетом могут выполняться дольше.

Используя Database Resource Manager (диспетчер ресурсов базы данных), можно настроить, чтобы важные группы пользователей (формально называемые группами потребителей ресурсов (resource consumer groups) всегда получали гарантированно достаточный объем ресурсов для решения своих задач.

Database Resource Manager также позволяет ограничивать интервал времени, в течение которого сеанс пользователя может оставаться бездействующим, и автоматически прерывать долго выполняющиеся SQL-операторы и сеансы пользователей. С помощью Database Resource Manager можно устанавливать начальные приоритеты регистрации для различных групп потребителей. Концепция пула активных сеансов позволяет также указывать максимальное количество одновременно активных сеансов группы потребителей — Database Resource Manager будет автоматически помещать в очередь все последующие запросы до тех пор, пока текущие сеансы не будут завершены. Администратор БД может также автоматически переводить пользователей из одной группы в другую на основании заранее установленного критерия использования ресурсов и ограничивать объем пространства отмены, который может использовать группа потребления ресурсов. Следующие четыре элемента — это неотъемлемые составляющие Database Resource Manager.

  • Группа потребителей ресурсов. Группа потребителей ресурсов служит для группирования похожих пользователей в соответствии с их потребностями в ресурсах.
  • План ресурсов. План ресурсов определяет выделение ресурсов группам потребителей. Каждый план ресурсов состоит из набора групп потребителей ресурсов, принадлежащих данному плану, и инструкций по распределению ресурсов между этими группами. Например, план ресурсов может определять распределение ресурсов ЦП между тремя группами потребителей так, чтобы первая группа получала 60% времени ЦП, а остальные две группы — 20%. План ресурсов может также содержать подпланы, которые позволяют более точно распределять ресурсы между группами потребителей.
  • Метод распределения ресурсов. Метод распределения ресурсов определяет конкретный метод, используемый для распределения таких ресурсов, как время ЦП. Доступны следующие методы распределения ресурсов базы данных.
    • Метод ЦП. Oracle использует несколько уровней выделения времени ЦП для установления приоритетов и распределения времени ЦП между конкурирующими сеансами пользователей.
    • Время бездействия. Можно указать, чтобы сеанс пользователя прерывался по истечении указанного периода бездействия. Можно также указать, чтобы прерывались только те бездействующие сеансы, которые блокируют другие сеансы.
    • Предельное время выполнения. Использованием ресурсов можно управлять, устанавливая максимальное время выполнения операций.
    • Пул отмены. Устанавливая директиву пула отмены, можно ограничивать общее количество операций отмены, которые могут быть сгенерированы группой потребителей ресурсов.
    • Пул активных сеансов. Можно установить максимальное допустимое количество активных сеансов внутри любой группы потребителей ресурсов. Все сеансы, выходящие за пределы установленного ограничения, помещаются в очередь для выполнения сразу после освобождения текущих активных сеансов.
    • Автоматическое переключение между группами потребителей. Используя этот метод, можно указать, чтобы сеанс пользователя автоматически переводился в другую группу, если он выполняется дольше указанного периода времени (в секундах). Группа, в которую должен быть переведен сеанс, называется группой перевода, а временной предел — временем перевода. Сеанс может быть возвращен в исходную группу потребителей после завершения главного вызова, который определяется как весь блок PL/SQL или отдельный SQL-оператор.
    • Отмена SQL-запросов и прерывание сеансов. Используя CANCEL_SQL или KILL_SESSION в качестве группы перевода, долго выполняющиеся SQL-операторы или даже целые сеансы можно направлять на отмену или прерывание.
    • Предел степени параллелизма. Этот метод можно использовать для указания предела степени параллелизма операций.
  • Директива плана ресурсов. Директива плана ресурсов связывает план ресурсов с конкретной группой потребителей ресурсов.

 Данные элементы позволяют настроить Oracle на оптимальное распределение ресурсов между пользователями (потребителями) и обеспечить требуемый уровень производительности.

 

Использование диспетчера ресурсов базы данных

Управление Database Resource Manager осуществляется за счет выполнения процедур из предоставляемого Oracle пакета DBMS_RESOURCE_MANAGER. Этот пакет позволяет создавать планы ресурсов для различных групп потребителей и присваивать планы группам. Администратор БД изначально обладает полномочиями на выполнение любой процедуры из пакета DBMS_RESOURCE_MANAGER, но любым другим пользователям, у которых возникает потребность в применении Database Resource Manager, придется для этого предоставить специальные системные полномочия ADMINISTER_RESOURCE_MANAGER, как показано в следующем примере: 

SQL> EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE -
(GRANTEE_NAME => 'scott', PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER');

Пакет DBMS_RESOURCE_MANAGER содержит несколько процедур, но мы уделим внимание нескольким наиболее важным, которые позволят использовать пакет для управления распределением ресурсов между пользователями базы данных.


На заметку! Следующее описание Database Resource Manager призвано ознакомить читателей с различными действиями по созданию планов ресурсов и их претворению в действие. Мастер Resource Plan Wizard (Мастер плана ресурсов) — несомненно, наилучший способ быстрого создания планов ресурсов базы данных, а также выполнения различных действий, связанных с созданием и поддержанием планов.


Чтобы приступить к использованию Database Resource Manager, понадобится выполнить следующие действия.

  1. Создайте область ожидания. Она представляет собой рабочую область, в которой будут создаваться и проверяться группы потребителей ресурсов, планы ресурсов и директивы планов.
  2. Создайте группу потребителей ресурсов. Она объединяет пользователей, которые будут получать один и тот же объем ресурсов.
  3. Создайте план ресурсов. Это коллекция директив, которые указывают, как Oracle должен выделять ресурсы группам потребителей.
  4. Создайте директиву плана. Она связывает группы потребителей ресурсов с планами ресурсов и распределяет ресурсы между группами потребителей.
  5. Проверьте правильность области ожидания. Этот процесс проверяет группу потребителей ресурсов, план ресурсов и директиву.
  6. Зафиксируйте область ожидания. В результате группа потребителей ресурсов, план ресурсов и директивы плана будут созданы и станут активными.

Как только все эти действия будут выполнены, пользователей можно включать в группы потребителей ресурсов, и они будут получать ресурсы, присвоенные данной группе.

 

Создание области ожидания

Прежде чем Database Resource Manager можно будет использовать для распределения ресурсов, изменения старого плана или создание нового, необходимо создать так называемую область ожидания (pending area), предназначенную для проверки правильности изменений перед их реализацией. Область ожидания служит рабочей областью для внесения изменений. Все созданные планы ресурсов будут храниться в словаре данных, а область ожидания служит промежуточной областью, в которой выполняется работа с планами ресурсов перед их реализацией. Область ожидания создается следующим образом: 

SQL> EXECUTE dbms_resource_manager.create_pending_area;
PL/SQL procedure successfully completed.
SQL>

В случае ошибок, допущенных при создании различных компонентов Database Resource Manager, область ожидания можно также очистить с помощью следующей процедуры:

SQL> EXECUTE dbms_resource_manager.clear_pending_area;
PL/SQL procedure successfully completed.
SQL>

Создание групп потребителей ресурсов

Как только область ожидания станет активной, в ней можно создать группы потребителей ресурсов, в которые будут включаться пользователи. Поначалу пользователей можно включить в одну группу, а затем, при необходимости, перевести в другую. Для создания группы потребителей ресурсов используют три параметра: имя группы потребителей (CONSUMER_GROUP), комментарий (COMMENT) и метод распределения ресурсов ЦП между активными сеансами группы потребителей ресурсов (CPU_MTH). При определении параметра CPU_MTH можно выбирать один из двух методов: метод RUN_TO_COMPLETION планирует сеансы, которые займут большую часть времени, перед другими, менее продолжительными сеансами, и применяемый по умолчанию метод ROUND_ROBIN, который использует систему циклического планирования.

Пример, приведенный в листинге ниже, демонстрирует создание в базе данных трех групп потребителей: national, regional и local. Обратите внимание, что параметр CPU_MTH не применяется, поскольку планируется использовать выбранный по умолчанию метод ROUND_ROBIN.


 

SQL> EXECUTE dbms_resource_manager.create_consumer_group -
> (consumer_group => 'local', comment => 'local councils');
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager.create_consumer_group -
> (consumer_group => 'regional', comment => 'regional councils');
PL/SQL procedure successfully completed.
SQL>
SQL> EXECUTE dbms_resource_manager.create_consumer_group -
> (consumer_group => 'national', comment => 'national office');
PL/SQL procedure successfully completed.
SQL>

 

Выяснение групп, существующих в базе данных

Для просмотра информации о группах, существующих в базе данных (перед проверкой и фиксацией области ожидания), можно запросить представление DBA_RSRC_CONSUMER_GROUPS, как показано в листинге ниже.


 

SQL> SELECT consumer_group, status
2* FROM dba_rsrc_consumer_groups;
CONSUMER_GROUP                                        STATUS
------------------------------------------------ -----------
AUTO_TASK_CONSUMER_GROUP                             PENDING
DEFAULT_CONSUMER_GROUP                               PENDING
SYS_GROUP                                            PENDING
OTHER_GROUPS                                         PENDING
LOW_GROUP                                             ACTIVE
AUTO_TASK_CONSUMER_GROUP                              ACTIVE
DEFAULT_CONSUMER_GROUP                                ACTIVE
SYS_GROUP                                             ACTIVE
LOW_GROUP                                            PENDING
OTHER_GROUPS                                          ACTIVE
LOCAL                                                PENDING
REGIONAL                                             PENDING
NATIONAL                                             PENDING
13 rows selected.
SQL>

В предыдущем разделе статьи были созданы три новых группы — national, regional и local, — но листинг выше отображает восемь различных групп потребителей. Этот же запрос, выполненный перед созданием трех новых групп в области ожидания, отобразил бы следующую информацию:

 

SQL> SELECT consumer_group,status
2 FROM dba_rsrc_consumer_groups;
CONSUMER_GROUP STATUS
-------------------------- -------
ORA$AUTOTASK_URGENT_GROUP
BATCH_GROUP
ORA$DIAGNOSTICS
ORA$AUTOTASK_HEALTH_GROUP
ORA$AUTOTASK_SQL_GROUP
ORA$AUTOTASK_SPACE_GROUP
ORA$AUTOTASK_STATS_GROUP
ORA$AUTOTASK_MEDIUM_GROUP
INTERACTIVE_GROUP
OTHER_GROUPS
DEFAULT_CONSUMER_GROUP
SYS_GROUP
LOW_GROUP
AUTO_TASK_CONSUMER_GROUP
14 rows selected.
SQL>

Шесть групп потребителей ресурсов, отображенные в приведенном выводе — это группы, определенные по умолчанию, которые существуют в каждой базе данных Oracle.

  • OTHER_GROUPS. В действительности группой не является, поскольку ей нельзя назначать пользователей. Когда план ресурсов активен, OTHER_GROUPS играет роль категории “прочие” для всех сеансов, не относящихся к данному активному плану ресурсов.
  • DEFAULT_CONSUMER_GROUP. Если пользователи не назначены ни одной группе, они по умолчанию станут членами группы, определенной по умолчанию.
  • SYS_GROUP и LOW_GROUP. Эти группы являются частью определенного по умолчанию плана, названного system_plan, который существует в каждой базе данных.
  • BATCH_GROUP. Эта определенная по умолчанию группа предназначена для использования с пакетными операциями.
  • AUTO_TASK_CONSUMER_GROUP. Эта определенная по умолчанию группа потребителей ресурсов используется для автоматически выполняемых задач, таких как генерация статистических сведений. Приоритет таких задач, как сбор статистических сведений, будет оставаться ниже приоритета задач, выполняемых в заданной по умолчанию группе потребителей. Как видно из вывода следующего запроса, Oracle предлагает семь определенных по умолчанию планов ресурсов для каждой базы данных:
SQL> 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.
                           Пример плана для смешанной рабочей нагрузки, который
                           устанавливает для интерактивных операций более высокий
                           приоритет, чем для пакетных операций.
ORA$AUTOTASK_SUB_PLAN      Default sub-plan for automated maintenance tasks.
                           A directive to this sub-plan should be included in
                           every top-level plan to manage the resources consumed
                           by the automated maintenance tasks.
                           Определенный по умолчанию подплан для задач
                           автоматического обслуживания. Директива для этого
                           подплана должна быть включена в каждый план верхнего
                           уровня, чтобы можно было управлять ресурсами,
                           используемыми задачами автоматического обслуживания.
ORA$AUTOTASK_HIGH_SUB_PLAN Default sub-plan for high-priority, automated maintenance
                           tasks. This sub-plan is referenced by ORA$AUTOTASK_SUB_
                           PLAN and should not be referenced directly.
                           Определенный по умолчанию подплан для высокоприоритетных
                           задач автоматического обслуживания. Обращение к этому
                           подплану выполняется посредством ORA$AUTOTASK_SUB_PLAN
                           и не должно выполняться непосредственно.
INTERNAL_PLAN              Internally-used plan for disabling the resource manager.
                           Внутренне используемый план для отключения диспетчера
                           ресурсов.
DEFAULT_PLAN               Default, basic, pre-defined plan that
                           prioritizes SYS_GROUP operations and
                           allocates minimal resources for automated
                           maintenance and diagnostics operations.
                           Заданный по умолчанию, базовый, заранее определенный план,
                           который устанавливает более высокий приоритет для операций
                           группы SYS_GROUP и выделяет минимальный объем ресурсов для
                           операций автоматического обслуживания и диагностики. 
INTERNAL_QUIESCE           Plan for quiescing the database. This plan
                           cannot be activated directly. To activate, use
                           the quiesce command.
                           План для "замораживания" базы данных. Этот план не
                           может быть активизирован непосредственно. Для его
                           активации необходимо использовать команду quiesce.
DEFAULT_MAINTENANCE_PLAN   Default plan for maintenance windows that
                           prioritizes SYS_GROUP operations and allocates
                           the remaining 5% to diagnostic operations and 25%
                           to automated maintenance operations.
                           Определенный по умолчанию план для окон обслуживания,
                           который устанавливает наиболее высокий приоритет
                           для операций SYS_GROUP и выделяет оставшиеся
                           5% диагностическим операциям и 25% операциям
                           автоматического обслуживания.
7 rows selected.
SQL>

Если запросить представление DBA_RSRC_CONSUMER_GROUPS после проверки области ожидания, вывод отобразит пять групп, определенных по умолчанию, и три только что созданные группы. В листинге 12.4 видно, что состояние (STATUS) трех новых, только что созданных групп изменилось с PENDING (ожидающая) на ACTIVE (активная).


 

SQL> SELECT consumer_group, status
FROM dba_rsrc_consumer_groups;
CONSUMER_GROUP                                STATUS
--------------------------------------------  --------
AUTO_TASK_CONSUMER_GROUP                      ACTIVE
DEFAULT_CONSUMER_GROUP                        ACTIVE
SYS_GROUP                                     ACTIVE
OTHER_GROUPS                                  ACTIVE
LOW_GROUP                                     ACTIVE
LOCAL                                         ACTIVE
REGIONAL                                      ACTIVE
NATIONAL                                      ACTIVE
8 rows selected.
SQL>

 

Создание планов ресурсов

План ресурсов содержит директивы, которые управляют распределением ресурсов между различными группами потребителей. Планы ресурсов позволяют устанавливать ограничения на ресурсы, указывая предельные значения в четырех переменных: ЦП, количестве активных сеансов, степени параллелизма и порядке, в котором будут выполняться сеансы, помещенные в очередь. Ниже подробно рассматриваются пять параметров, которые управляют этими ресурсами.

  • CPU_MTH. Этот метод выделения ресурсов служит для указания способа распределения ресурсов ЦП между группами потребителей ресурсов. Метод, применяемый по умолчанию, носит название EMPHASIS и использует процентные значения для распределения ресурсов ЦП между различными группами. Альтернативный метод, RATIO, использует для этой цели дробные коэффициенты.
  • ACTIVE_SESS_POOL_MTH. Этот параметр определяет предельное количество активных сеансов в группе потребителей ресурсов. Единственный доступный метод —ACTIVE_SESS_POOL_ABSOLUTE, который определен по умолчанию.
  • PARALLEL_DEGREE_LIMIT_MTH. Этот параметр определяет степень параллелизма, используемую конкретной операцией. Единственная доступная опция —PARALLEL_DEGREE_LIMIT_ABSOLUTE (которая используется по умолчанию).
  • SUB_PLAN. Если значение этого параметра — TRUE, план нельзя использовать в качестве плана высшего уровня (только в качестве подплана). Значение, установленное по умолчанию — FALSE.
  • QUEUEING_MTH. Этот параметр определяет порядок, в котором будут выполняться сеансы, помещенные в очередь. В настоящее время доступна только опция FIFO_TIMEOUT, устанавливаемая по умолчанию.

Можно также создавать подпланы (планы внутри других планов), которые позволяют точнее распределять ресурсы между различными пользователями. Создайте план ресурсов, снова обратившись к пакету DBMS_RESOURCE_MANAGER:

SQL> DBMS_RESOURCE_MANAGER.CREATE_PLAN
(PLAN => 'membership_plan',
CPU_MTH -> 'RATIO',
COMMENT => 'New Membership Recruitment');
PL/SQL procedure successfully completed.
SQL>

 

Создание директив плана

Теперь вы располагаете планом ресурсов, но план все еще не содержит никаких ограничений ресурсов. Чтобы присвоить ресурсы различным группам потребителей ресурсов в базе данных, потребуется создать директиву плана ресурсов. Ресурсы можно распределять по следующим критериям.

  • ЦП. Используя метод распределения ресурсов ЦП, ресурсы можно распределять между группами потребителей или подпланами. Для установки приоритета использования ЦП можно задавать несколько уровней выделения ресурсов ЦП. Например, можно было бы указать, чтобы уровень 2 получал ресурсы ЦП только при наличии каких-либо ресурсов после обеспечения ими уровня 1.
  • Сеансы. Максимальным количеством активных сеансов, открытых в любой момент времени можно управлять с использованием параметра ACTIVE_SESSION_POOL. Можно также разрешить прерывание длительных SQL-запросов и сеансов пользователей.
  • Степень параллелизма. Можно установить предел степени параллелизма во время любой операции.
  • Автоматическое переключение между группами потребителей. Можно указать, что при определенных условиях база данных будет переводить сеансы в другую группу потребителей.
  • Использование отмены. Можно устанавливать ограничения количества операций отмены, которые может генерировать группа потребителей ресурсов. База данных автоматически прерывает SQL-операторы, которые вызывают превышение предела операций отмены, генерируемых группой потребителей. Это помешает новым членам группы потребителей выдавать операторы DML.
  • Предел времени бездействия. Директива ресурса предельной продолжительности бездействия, устанавливаемая с помощью параметра MAX_IDLE_TIME, помогает управлять использованием ресурса в занятой базе данных. Этот параметр можно применять для установки максимальной длительности бездействия одиночного сеанса. Кроме того, устанавливая параметр MAX_IDLE_BLOCKER_TIME, можно так-же ограничивать время, в течение которого сеанс пользователя может блокировать другой сеанс.
  • Перевод сеанса. Параметр SWITCH_GROUP можно использовать для указания группы потребителей, в которую сеанс может быть переведен при выполнении конкретного критерия перевода. Существуют две группы перевода: CANCEL_SQL и KILL_SESSION. Назначение сеанса в первую группу приведет к отмене текущего вызова, а назначение во вторую — к прерыванию сеанса. Параметр SWITCH_GROUP может также указывать значения следующих параметров, связанных с переводом.
  • SWITCH_IO_MEGABYTES. Этот параметр указывает объем данных ввода-вывода в мегабайтах, которые сеанс может передать, прежде чем база данных предпримет какое-либо действие.
  • SWITCH_IO_REQS. Этот параметр указывает количество запросов ввода-вывода, которые сеанс может выполнить, прежде чем база данных предпримет какое-либо действие.
  • SWITCH_FOR_CALL. Если значение этого параметра установлено равным TRUE, база данных возвращает переведенный в другую группу сеанс в исходную группу по завершении вызова высшего уровня.

Следующий пример демонстрирует ограничение сеанса в плане ресурсов максимальным временем бездействия, равным 600 секунд, и максимальным временем бездействия, равным всего 300 секунд, если сеанс начинает блокировать другой сеанс:

SQL> EXECUTE dbms_resource_manager.create_plan_directive -
(plan => 'prod_plan',
group_or_subplan => 'dss_group',
comment => 'Limit idle time',
max_idle_time => 900,
max_idle_blocker_time => 300); 

В приведенном примере, когда время бездействия сеанса превысит 900 секунд (или 300 секунд, если сеанс блокирует другой сеанс), фоновый процесс PMON автоматически прервет “провинившийся” сеанс.

Создание директивы плана с применением метода ЦП показано в листинге 12.5. На первом уровне директива плана присваивает 70% доступного времени ЦП группе local, а остальные 30% — группе regional. На втором уровне она выделяет 100% времени ЦП группе national. Обратите внимание, что в этом примере использован применяемый по умолчанию метод emphasis (акцентированный) выделения ресурсов ЦП, который распределяет эти ресурсы в процентах. Существует также альтернативный метод выделения, ratio (отношение), который распределяет ресурсы ЦП в виде дробных значений.


 

SQL> EXECUTE dbms_resource_manager.create_plan -
directive (plan => 'membership_plan', -
GROUP_OR_SUBPLAN => 'local', COMMENT => 'LOCAL GROUP',-
CPU_P1 => 70);
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager.create_plan -
directive (plan => 'membership_plan', -
GROUP_OR_SUBPLAN => 'REGIONAL', COMMENT => 'regional group',-
CPU_P1 => 30);
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager.create_plan
directive (plan => 'membership_plan', -
GROUP_OR_SUBPLAN => 'national', comment => 'national group',-
CPU_P2 => 100);
PL/SQL procedure successfully completed.
SQL>


Совет. Если директива ресурсов для группы OTHER_GROUPS отсутствует, а директива плана определена для основного плана или плана высшего уровня, Oracle не позволит использовать директивы для других групп в группе OTHER_GROUPS.


 

Проверка области ожидания

После того как группы потребителей ресурсов, планы ресурсов и директивы планов созданы, можно приступить к проверке правильности выполненных изменений. Это выполняется следующим образом:

SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
PL/SQL procedure successfully completed.

 

Фиксация области ожидания

Фиксация области ожидания в действительности приводит к созданию и активизации всех необходимых элементов, вроде группы потребителей ресурсов, плана ресурсов и директив плана. Фиксация области ожидания выполняется следующим образом: 

SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
PL/SQL procedure successfully completed.

Запрос, показанный в листинге ниже, можно использовать для выяснения директив плана, действующих в данный момент для различных групп.


 

SQL> SELECT plan,group_or_subplan,cpu_p1,cpu_p2,cpu_p3, status
2* FROM dba_rsrc_plan_directives;
PLAN               GROUP          CPU_P1    CPU_P2   CPU_P3   STATUS
----------------   ------------   ------   -------   ------   ------
SYSTEM_PLAN        SYS_GROUP         100         0        0   ACTIVE
SYSTEM_PLAN        OTHER_GROUPS        0       100        0   ACTIVE
SYSTEM_PLAN        LOW_GROUP           0         0      100   ACTIVE
INTERNAL_QUIESCE   SYS_GROUP           0         0        0   ACTIVE
INTERNAL_QUIESCE   OTHER_GROUPS        0         0        0   ACTIVE
INTERNAL_PLAN      OTHER_GROUPS        0         0        0   ACTIVE
MEMBERSHIP_PLAN    REGIONAL           30         0        0   ACTIVE
MEMBERSHIP_PLAN    NATIONAL            0       100        0   ACTIVE
MEMBERSHIP_PLAN    OTHER_GROUPS        0         0      100   ACTIVE
MEMBERSHIP_PLAN    LOCAL              70         0        0   ACTIVE
10 rows selected.
SQL>

 

Назначение пользователей в группы потребителей

После того как группы потребителей ресурсов созданы, а область ожидания проверена, отдельных пользователей можно назначить в созданные группы потребителей. Предположим, что трех пользователей — local_user, regional_user и national_user — нужно следующим образом назначить в три группы ресурсов: local_user в группу потребителей local, regional_user — в группу regional, а national_user — в группу national.

Помните, что все три пользователя уже являются членами группы, определенной по умолчанию — default_consumer_group. Поэтому, прежде чем их можно будет действительно перевести в новые группы, вначале им нужно предоставить полномочия на смену своих групп. В листинге ниже демонстрируется использование пакета DBMS_RESOURCE_MANAGER для назначения и смены групп потребителей.


Совет. Если выдать пользователю PUBLIC полномочия на смену групп, эти полномочия не придется индивидуально предоставлять всем пользователям в группе. При наличии большого количества пользователей в каждой группе такой подход рациональнее.



 

SQL> EXECUTE dbms_resource_manager_privs.grant_switch_
consumer_group ('local_user','local', true);
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager.set_
initial_consumer_group ('local_user','local');
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager_privs.grant_
switch_consumer_group('regional_user','regional', true);
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager.set_initial_
consumer_group ('regional_user','regional');
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager_privs.grant_
switch_consumer_group('national_user','national',true);
PL/SQL procedure successfully completed.
SQL> EXECUTE dbms_resource_manager.set_
initial_consumer_group ('national_user','national');
PL/SQL procedure successfully completed.
SQL>

Удостовериться в том, что три пользователя назначены в соответствующие группы потребителей, можно с помощью запроса, показанного в листинге ниже.


 

SQL> SELECT username, initial_rsrc_consumer_group
2 FROM dba_users;
USERNAME           INITIAL_RSRC_CONSUMER_GROUP
----------------   ---------------------------
SYS                SYS_GROUP
SYSTEM             SYS_GROUP
SALAPATI           DEFAULT_CONSUMER_GROUP
NATIONAL_USER      NATIONAL
REGIONAL_USER      REGIONAL
LOCAL_USER         LOCAL
6 rows selected.
SQL>

Обратите внимание, что привилегированные пользователи SYS и SYSTEM по умолчанию являются членами группы SYS_GROUP. Пользователь salapati — член группы DEFAULT_CONSUMER_GROUP, в которую автоматически назначаются все пользователи базы данных при их создании. Как видите, три новых пользователя local_user, regional_user и national_user корректно назначены в соответствующие группы LOCAL, REGIONAL и NATIONAL.

 

Автоматическое назначение группы потребителей ресурсов сеансу

Диспетчер ресурсов базы данных может автоматически назначать сеанс пользователя в конкретную группу потребителей в соответствии с определенными атрибутами сеанса. Достаточно отобразить атрибуты сеанса на различные группы потребителей, и при регистрации пользователя подходящая группа потребителей будет присвоена этому пользователю в соответствии с его атрибутами. Возникший конфликт может быть разрешен путем назначения приоритетов отображениям атрибутов сеанса на группы потребителей ресурсов.

Для сопоставления атрибутов сеансов и групп потребителей ресурсов и определения приоритетов отображения служат две процедуры из пакета DBMS_RESOURCE_MANAGERSET_CONSUMER_GROUP_MAPPING и SET_CONSUMER_MAPPING_PRI. Существуют два различных типа атрибутов сеансов. Первый набор охватывает атрибуты регистрации, которые помогают Database Resource Manager определить первоначальную группу потребителей для пользователя. Второй набор атрибутов сеансов состоит из атрибутов времени выполнения.

Ниже перечислены некоторые атрибуты сеанса, которые учитываются при отображении сеанса пользователя на конкретную группу потребителей ресурсов: 

ORACLE_USER
SERVICE_NAME
CLIENT_OS_USER
CLIENT_PROGRAM
CLIENT_MACHINE
MODULE_NAME

Отображение каждого из этих атрибутов сеанса на конкретную группу потребителей ресурсов выполняется с помощью процедуры SET_CONSUMER_GROUP_MAPPING. В следующем примере пользователь hr отображается на группу HUMAN_RESOURCES_GROUP во время выполнения: 

SQL> EXECUTE DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.ORACLE_USER, 'HR', 'HUMAN_RESOURCES_GROUP');

По завершении регистрации изменение атрибутов сеанса пользователя ведет к изменению группы потребителей ресурсов на основе отображения между атрибутами сеанса и группами ресурсов.

Иногда между двумя отображениями могут возникать конфликты и для их разрешения используют процедуру SET_CONSUMER_MAPPING_PRI, с помощью которой назначаются приоритеты различным атрибутам сеансов в диапазоне от 1 до 10, причем значение 1 соответствует наименьшему по важности, а 10 — наибольшему по важности приоритету. Например: 

SQL> EXECUTE DBMS_RESOURCE_MANAGER. SET_CONSUMER_GROUP_MAPPING_PRI (
EXPLICIT => 1, CLIENT_MACHINE => 2, MODULE_NAME => 3, ORACLE_USER => 4,
SERVICE_NAME => 5, CLIENT_OS_USER => 6, CLIENT_PROGRAM => 7,
MODULE_NAME_ACTION => 8, SERVICE_MODULE=>9, SERVICE_MODULE_ACTION=>10);

При изменении атрибута сеанса пользователь автоматически переводится в соответствующую группу потребителей ресурсов.

 

Реализация ограничений ресурсов ЦП и ввода-вывода, установленных для отдельного сеанса

База данных может также автоматически переключать сеансы в соответствии с использованием ресурсов ЦП и ввода-вывода, тем самым позволяя реализовать ограничения ресурсов ЦП и ввода-вывода, установленные для отдельного сеанса. Например, если пользователь отнимает слишком много ресурсов ЦП, вместо того чтобы прервать сеанс пользователя, база данных автоматически переведет его в другую группу ресурсов, обладающую меньшим объемом выделенных ей ресурсов ЦП.

Когда сеанс превышает пределы выделенных ему ресурсов, база данных может выполнять одно из следующих действий:

  • переводить сеанс в группу ресурсов с меньшим выделенным объемом ресурсов;
  • прерывать сеанс;
  • отменять SQL-оператор, выдавший обращение к базе данных.

При создании плана следует указать значения для сеанса в таких параметрах, как SWITCH_IO_MEGABYTES, SWITCH_GROUP и SWITCH_TIME. Рассмотрим несколько примеров, которые демонстрируют установку автоматического переключения сеансов для смены групп потребителей ресурсов в зависимости от использования ресурсов сеансом.

Следующий пример демонстрирует способ указания перевода сеанса в группу с более низким приоритетом, если сеанс превышает указанный предел использования ЦП: 

SQL> BEGIN
dbms_resource_manager.create_plan_directive (
plan => 'peaktime',
group_or_subplan => 'oltp',
mgmt_p1 => 75,
switch_group => 'low_Group',
switch_time => 10
switch_for_call => true);
END;

Когда сеанс превышает установленный предел использования ЦП, он автоматически переводится в группу потребителей ресурсов LOW_GROUP, являющуюся группой потребителей ресурсов с более низким приоритетом. Поскольку был указан параметр SWITCH_FOR_CALL, по завершении вызова, требующего большого объема ресурсов, база данных переводит сеанс в его исходную группу потребителей ресурсов.

Следующий пример демонстрирует способ указания прерывания сеанса, если он превышает указанный предел использования ЦП: 

SQL> BEGIN
dbms_resource_manager.create_plan_directive (
plan => 'peaktime',
group_or_subplan => 'oltp',
mgmt_p1 => 75,
switch_group => 'kill_session',
switch_time => 60);
END;

Приведенный код указывает, что база данных должна прервать сеанс (SWITCH_GROUP => 'kill_session'), когда продолжительность использования ЦП сеансом превышает 60 секунд.

 

Активизация диспетчера ресурсов базы данных

Само по себе создание нового плана и директив плана и фиксация области ожидания не означает, что Oracle будет автоматически реализовывать планы ресурсов. Необходимо явно активизировать Database Resource Manager — либо указав параметр инициализации RESOURCE_MANAGER_PLAN в файле init.ora, либо воспользовавшись командой ALTER SYSTEM, как показано ниже в примере: 

SQL> ALTER SYSTEM SET resource_manager_plan=MEMBERSHIP_PLAN;
System altered.
SQL> SELECT * FROM v$rsrc_plan;
NAME
----------------------------------------
MEMBERSHIP_PLAN
SQL>

Для отключения Database Resource Manager служит следующая команда:

SQL> ALTER SYSTEM SET resource_manager_plan='';
System altered.
SQL> SELECT * FROM v$rsrc_plan;
no rows selected
SQL> 

В любой момент можно запросить представление V$RSRC_CONSUMER_GROUP для просмотра использования ресурсов группами потребителей:

SQL> SELECT name,active_sessions,cpu_wait_time, consumed_cpu_time,
current_undo_consumption
FROM v$rsrc_consumer_group;
NAME          ACTIVE    CPU_  CONSUMED_  CURRENT
              SESSIONS  WAIT  CPU_TIME   UNDO_CONS
------------- --------- ----- ---------  ----------
REGIONAL          0       0       0          0
NATIONAL          0       0       0          0
OTHER_GROUPS      1       0      74          0
LOCAL             0       0   18017          0
SQL>

 

Представления словаря данных

Следующие представления словаря данных помогают управлять диспетчером Database Resource Manager.

  • Представление V$SESSION отображает, в какие группы потребителей ресурсов сеансы назначены в текущий момент.
  • Представление DBA_RSRC_CONSUMER_GROUP_PRIVS отображает все группы потребителей ресурсов, присвоенные пользователям или ролям.
  • Представление DBA_RSRC_PLANS отображает все планы ресурсов в базе данных.
  • Представление V$RSRC_PLAN отображает все активные в текущий момент планы ресурсов.

 

Использование OEM для управления диспетчером ресурсов базы данных

Теперь, когда вы завершили чреватую ошибками, трудоемкую работу по созданию и активизации планов ресурсов, вспомните, что применение Oracle Enterprise Manager (OEM) для управления диспетчером Database Resource Manager — значительно более легкий подход. Ниже приведено краткое описание использования OEM для администрирования Database Resource Manager.

 

Использование страницы Resource Monitors

Страницу Resource Monitors (Монитор ресурсов) можно использовать для отображения текущего состояния активного плана ресурсов. На ней можно просматривать статистические сведения об активном в текущий момент плане, выбирать план из списка и активизировать его. Таблица Consumer Group Statistics (Статистические данные о группах потребителей) содержит ряд статистических сведений о группах потребителей, являющихся частью текущего плана ресурсов.


Совет. При активизации плана на странице Resource Monitors необходимо закрыть страницу, а затем снова выбрать вкладку Resource Monitors, чтобы обновить страницу.


 

Создание, редактирование и удаление планов ресурсов

Управление списком планов ресурсов можно осуществлять посредством страницы свойств Resource Plans (Планы ресурсов). Как вы уже знаете, планы ресурсов можно использовать для распределения ресурсов между группами потребителей. Страница свойств Resource Plans позволяет создавать, удалять и изменять настройки плана ресурсов.

Для управления планом ресурсов перейдите на страницу Database Control Home PageAdministrationConsumer Groups (Домашняя страница управления базой данных => Администрирование =>Группы потребителей). В раскрывающемся списке Object Type (Тип объекта) выберите элемент Resource Plans (Планы ресурсов). Откроется страница Resource Plans, содержащая список всех текущих планов ресурсов. Теперь можно либо создать новый план ресурсов, либо выбрать план из списка.

 

Управление группами потребителей ресурсов

Управление группами потребителей ресурсов можно осуществлять посредством страницы свойств Resource Consumer Groups (Группы потребителей ресурсов). Эту страницу свойств можно использовать для создания, удаления и изменения настроек группы потребителей ресурсов.

Для управления группой потребителей ресурсов перейдите на страницу Database Control Home Page => Administration => Consumer Groups (Домашняя страница управления базой данных => Администрирование => Группы потребителей). В раскрывающемся списке Object Type (Тип объекта) выберите элемент Resource Consumer Groups (Группы потребителей ресурсов). Откроется страница Resource Consumer Groups, отображающая все группы потребителей ресурсов, которые существуют в текущей базе данных. На этой странице можно создавать, редактировать и удалять группы потребителей ресурсов.

 

Вас заинтересует / Intresting for you:

Создание БД Oracle 12c с макси...
Создание БД Oracle 12c с макси... 2941 просмотров Андрей Васенин Mon, 20 Aug 2018, 13:43:20
Настройка памяти базы данных O...
Настройка памяти базы данных O... 10116 просмотров Stas Belkov Sat, 07 Jul 2018, 15:44:14
Мониторинг Oracle через метрик...
Мониторинг Oracle через метрик... 3314 просмотров sepia Tue, 21 Nov 2017, 13:18:05
Нужно ли менять настройки базы...
Нужно ли менять настройки базы... 4645 просмотров Tue, 21 Nov 2017, 13:31:33
Войдите чтобы комментировать