Oracle позволяет присваивать заданиям приоритеты. Эта функциональность чрезвычайно важна для создания прочного и надежного механизма планирования.
Предположим, что в базе данных создан ряд заданий с разнообразными расписаниями. Всегда есть вероятность того, что некоторые задания будут перекрываться. В конце концов, в сутках всего 24 часа. Если два задания выполняются одновременно, они могут потреблять процессорное время и память с интенсивностью, не характерной для обычной работы базы данных. Потребление ресурсов (или, если точнее, конкуренция за ресурсы) может привести к тому, что оба задания будут замедляться (как и остальные приложения, работающие в системе). Как следует поступать в подобных ситуациях? Можно выделить заданию A все необходимые ему ресурсы и заставить задание B немного пострадать, пока A не завершится. Или наоборот, выделить больше ресурсов заданию B.
Приоритеты заданий планировщика Oracle управляются диспетчером ресурсов (Resource Manager), доступ к которому обеспечивает встроенный пакет базы данных DBMS_RESOURCE_MANAGER. Описание диспетчера ресурсов выходит за рамки нашего обсуждения: будем считать, что вы знакомы с его возможностями.
Давайте рассмотрим пример. Сначала определяем группу диспетчера ресурсов OLTP_GROUP для управления нагрузкой на базу данных при выполнении OLTP-операций.
Далее необходимо определить директивы по плану распределения ресурсов, которые указывают, какими образом ресурсы распределяются между различными группами внутри плана. Oracle поставляется с предопределенной группой OTHER_GROUP. В нашем случае мы создали вторую группу, OLTP_GROUP, которая будет объединять все OLTP-операции. Выделяем 80% мощности процессора на OLTP-операции, а оставшуюся часть отдаем OTHER_GROUP.
После того как ресурсные планы созданы, их можно использовать при определении заданий.
Существуют два разных способа использования ресурсных планов: с помощью классов заданий или с помощью окон планировщика. Следующий раздел будет посвящен классам заданий. Далее в разделе «Управление окнами» будет рассказано об использовании окон c DBMS_SCHEDULER (в том числе и об их использовании с ресурсными планами).
Класс заданий - это коллекция свойств. Создать класс заданий можно при помощи процедуры CREATE_JOB_CLASS пакета DBMS_SCHEDULER. Потом при создании задания можно указать имя уже созданного класса заданий в параметре job_class процедуры CREATE_JOB. Рассмотрим пример создания класса заданий планировщика, который связан с группой пользовательских ресурсов OLTP_GROUP.
Рассмотрим эти строки подробно.
|
|
Строка
|
Описание
|
3
|
Имя класса заданий.
|
4
|
|
5
|
Если выполнение задания протоколируется, то журнальные записи должны периодически удаляться, иначе журнал станет неуправляемо большим. Параметр log_history определяет, сколько дней журнальные записи должны храниться. Значение по умолчанию - 30 (дней). В нашем примере это значение увеличено до 45.
|
6
|
Класс заданий связан с группой ресурсов OLTP_GROUP, которая управляет выделением ресурсов и использованием заданий, определенных в данном классе заданий.
|
7
|
Комментарии для данного класса заданий.
|
После того как класс заданий создан, вы можете просмотреть его атрибуты (а также атрибуты определенных ранее классов заданий) в пред-
ставлении словаря данных DBA_SCHEDULER_JOB_CLASSES. Приведем запись из этого представления (отформатированную по вертикали для удобочитаемости):
При определении класса заданий можно также определить имя сервиса, под которым будут выполняться задания данного класса. Имя сервиса должно быть определено в базе данных. Например, если используется имя сервиса INTCALC_SRVC, то оно должно быть активировано следующим образом:
После этого можно определить класс заданий под таким именем сервиса, указав параметр service для процедуры CREATE_JOB_CLASS (см. строку, выделенную жирным шрифтом).
Имена сервисов удобны, когда необходимо управлять сеансом, связанным с сервисом, а не с экземпляром. Внутри экземпляра Oracle может быть определено несколько сервисов. При открытии сеанса возможно задание параметра SERVICE_NAME в файле TNSNAMES.ORA вместо использования SID в строке соединения. Если соединение устанавливается именно таким способом, то столбец SERVICE_NAME представления V$SES- SION отображает имя сервиса для сеанса. Если сервис в экземпляре отключен, сеансы не будут открыты даже при работающем экземпляре.
Сервисы полезны и для других целей. Например, если вы работаете с многоэкземплярной базой данных RAC, то можете захотеть определить сервис только в одном экземпляре базы данных, тем самым ограничив задание только одним конкретным экземпляром. При отключении экземпляра сеансы передаются другим «выжившим» экземплярам. Определение сервиса дает возможность указать, какому узлу следует передать сеансы при проблемах с исходным экземпляром базы данных. Сервис также можно использовать для управления ресурсными планами сеансов, которым сервис сопоставлен.
Так как сервис также управляет выделением ресурсов, нельзя задавать сразу два параметра: resource_consumer_plan и service. Следует выбрать какой-то один подход и задать соответствующий параметр.
Последним этапом будет создание задания, которое определяется как элемент созданного класса заданий. Создаем задание по сбору статистики оптимизатора.
Обратите внимание на выделенную строку: в ней единственное отличие от уже рассмотренных примеров. Параметр job_class установлен в значение OLTP_JOBS (созданный нами класс заданий). Задание COL- LECT_STATS наследует все свойства класса заданий OLTP_JOBS. Классу заданий была сопоставлена группа потребителей ресурсов OLTP_GROUP, поэтому все параметры управления ресурсами, определенные для этой группы ресурсов, будут применяться к заданию COLLECT_STATS.
| < Предыдущая | Следующая > |
|---|
