Scheduler windows in oracle
В статье рассматриваются некоторые свойства и примеры употребления планировщика заданий, появившегося в версии Oracle 10 на смену старому.
Введение
СУБД Oracle — большой и сложный механизм, требующий выполнения определенных плановых работ, таких как сбор статистики о хранимых объектах или сбор/чистка внутренней информации. Необходимость осуществлять плановый запуск работ могут испытывать и пользователи БД.
Первый механизм планового запуска появился в версии 7 для поддержки автоматических обновлений снимков (snapshots), как поначалу именовались нынешние материализованные виртуальные таблицы (materialized views). В версии 8 этот механизм был открыт для обычных пользователей через посредство некоторых параметров СУБД, таблиц словаря-справочника, а также пакета DBMS_JOB. Пакет DBMS_JOB позволял (и позволяет) запускать хранимую процедуру, или же неименованный блок PL/SQL в моменты времени, вычисляемые по указанной пользователем формуле.
К версии 10 такое устройство имевшегося планировщика заданий было сочтено слишком примитивным, и в ней появился новый планировщик, значительно более проработанный. Он использует следующие основные понятия:
- Schedule (расписание)
- Program (программа)
- Job (плановое задание = расписание + программа)
Кроме того, с ним связаны дополнительные, более специфичные понятия:
- Job class (класс заданий)
- Window и window group (ресурсное «окошко», интервал для автоматического включения ресурсного плана СУБД и группа окошек)
- Chain (цепочка заданий)
- Event schedule (возможность запустить задание по событию, зафиксированному по сообщению из очереди AQ)
В отличие от старого планировщика, в новом «программой» может быть не только блок PL/SQL, но и хранимая процедура на PL/SQL или на Java, внешняя процедура на С или даже команда ОС. Последнее означает, что Oracle отменяет необходимость использовать специфичные для разных платформ планировщики заданий ОС (cron, at) при построении БД-центричного приложения. Вдобавок, сам запуск заданий получил возможность учета текущей вычислительной обстановки в СУБД, а также желаемой приоритетности среди прочих заданий.
Как и в случае со старым планировщиком, новый, по сути, представляет собой элемент ядра СУБД, доступ пользователя к которому предоставляется посредством программной логики и элементов схемы БД. Именно, в распоряжении пользователя имеется следующее:
- таблицы словаря-справочника LIKE ‘%SCHEDULER_%’ (DBA_SCHEDULER_JOBS, DBA_SCHEDULER_JOB_LOG и прочие);
- несколько типов объектов хранения, как то:
- JOB
- SCHEDULE
- PROGRAM
- JOB CLASS,
ряд других;
- системные привилегии:
- CREATE SESSION
- CREATE JOB
- CREATE ANY JOB
- EXECUTE ANY PROGRAM
- EXECUTE ANY CLASS
- MANAGE SCHEDULER
- CREATE EXTERNAL JOB,
и объединяющая их роль SCHEDULERADMIN;
- объектные привилегии:
- EXECUTE
- ALTER
- ALL,
распространяющиеся на объекты типов JOB, SCHEDULE, PROGRAM и JOB CLASS;
- пакет DBMS_SCHEDULER.
Версия 11 дополнила планировщик возможностями:
- запуска «легковесных» заданий, делающей реальным их создание и удаление сотнями за секунду;
- запуска заданий на удаленных машинах посредством использования специального агента;
- запуска заданий только на основной БД физического горячего резерва или на страхующей БД логического резерва.
Некоторые ключевые моменты использования планировщика в Oracle 10 рассматриваются ниже на примерах.
Простой запуск задания
Простой запуск задания очень напоминает запуск с помощью процедуры SUBMIT из пакета DBMS_JOB. Однако, в отличие от SUBMIT, он возможен только при наличии привилегии CREATE JOB. В последующих примерах созданием заданий и управлением ими для простоты будет заниматься пользователь SCOTT, хотя в жизни разумно подумать об отдельном администраторе для этой цели. Выдадим пользователю SCOTT нужную привилегию:
Кроме системных привилегий, использование планировщика регулируется объектными привилегиями EXECUTE, ALTER и ALL, выдача которых применительно (GRANT . ON) к заданию, программе, расписанию или классу заданий позволяет работать с объектами БД типов JOB, PROGRAM, SCHEDULE и JOB CLASS соответственно, введенных в Oracle 10 вместе с новым планировщиком.
Ввиду того, что в дальнейшем предполагаются эксперименты с изменениями зарплаты сотрудников, будет удобно исходную зарплату сохранить:
Внутреннее задание для СУБД
Пример внутреннего задания в виде неименованного блока PL/SQL:
Обратите внимание:
- Обрамлять блок словами BEGIN и END не обязательно, так как код пакета DBMS_SCHEDULER это сделает самостоятельно (ради особой программной логики, добавляемой им к тексту пользователя).
- Задание запускается в этом же сеансе и сопровождается неявной выдачей COMMIT. В этом легко удостовериться: Зарплата SAL увеличится на 2. Проверить это в качестве упражнения.
Для хранимой процедуры задание формируется аналогично:
Обратите внимание, что нам не потребовалось удалять старое задание SIMPLE_JOB, так как при выбранных нами параметрах процедуры CREATE_JOB задания (и первое, и второе) прогонялись однократно, моментально и сразу же удалялись автоматически. Последнее как раз можно и отменить посредством не использованного в примере выше параметра AUTO_DROP.
В случае невозможности запустить задание СУБД, подобно тому, как это делалось для старого планировщика (пакет DBMS_JOB), будет делать повторные попытки, но только по несколько иной схеме: через секунду, затем через 10 секунд, затем через 100 и далее – всего 6 раз, если только до этого не наступит очередной плановый момент.
Внешнее задание (для ОС)
Совсем новым в планировщике Oracle 10 является возможность запускать плановые задания в ОС. Однако чтобы это было возможно, в ОС должна быть запущена программа extjob из ПО СУБД. На Windows она запускается службой OracleJobScheduler . Для того чтобы следующий пример проработал, службу необходимо запустить. Вдобавок потребуется выдать пользователю SCOTT еще одну привилегию.
Обратите внимание, что в Windows выдача команды ОС или же запуск командного файла напрямую (без вызова cmd.exe), не проходит.
В Unix аналогичное действие можно записать как ‘ls > /tmp/out. txt’.
Возможности запуска, наблюдения, вмешательства
Так же, как для пакета DBMS_JOB, в новом планировщике предусмотрено именно плановое, а не одноразовое исполнение задания. Добавим к последнему вызову параметр:
В результете корневой файл out.txt получим через 10 секунд после создания задания. Добавим еще параметр: В результате задание будет исполняться ежемесячно по воскресениям и последним субботам месяца. В отличие от DBMS_JOB, DBMS_SCHEDULER, в дополнение к возможности употребить выражение на PL/SQL, имеет для формулирования графика запуска еще и специальный язык. Он позволяет указывать частоту, интервал и уточнитель запуска задания. Примеры:
Для проверки правильности составления выражения можно воспользоваться специальной процедурой:
Полное описание языка приводится в документации по Oracle.
Если указать план запуска, задание появится в системе уже надолго. Удалить его при необходимости можно будет так:
Информацию об имеющихся заданиях пользователь SCOTT может посмотреть запросом:
Более подробную информацию SCOTT обнаружит в таблицах USER_SCHEDULER_%, а более общую – в обычной таблице USER_OBJECTS.
Скомпонованное задание
Более развитая возможность DBMS_SCHEDULER позволяет скомпоновать задание из независимых элементов: программы и расписания. Характерная особенность в том, что оба эти элемента самостоятельны; их можно комбинировать в разных заданиях и изменять, не внося изменений в определения заданий.
Создание программы
Простой пример создания программы:
Список сведений об имеющихся программах для планировщика имеется в таблицах DBA/ALL/USER_SCHEDULER_PROGRAMS.
Другими значениями параметра PROGRAM_TYPE могут быть ‘PLSQL_BLOCK’ и ‘EXECUTABLE’ (см. выше).
При наличии у процедуры параметров их количество потребуется указать особо:
Обратите внимание, что программа создана «отключенной». Дело в том, что указать фактические значения параметрам программе во «включенном» состоянии нельзя, так что последовательность действий будет следующая:
Создание расписания
Пример создания расписания:
В общем случае язык указания графика для расписания (параметр REPEAT_INTERVAL) допускает ссылаться на ранее созданные таким же образом расписания.
Список сведений об имеющихся расписаниях для планировщика имеется в таблицах DBA/ALL/USER_SCHEDULER_SCHEDULES.
Простой пример скомпонованного задания
Из самостоятельно существующих программы и расписания можно составить задание:
При наличии параметра пример может выглядеть так:
Обратите внимание, что в этом случае задание сначала создается выключенным, и только после указания значения параметра программе оно может включаться.
Создание и использование ресурсного окошка СУБД для задания
Очередной запуск внутреннего задания может прийтись на время активного использования ресурсов СУБД другими процессами. Это может замедлить выполнение планового задания, обесценить его выполнение и даже поставить его выполнение под угрозу. Справиться с этой проблемой призвано ресурсное окошко. Суть его состоит в одновременном с очередным запуском задания автоматическом переключении СУБД на работу по требуемому ресурсному плану (план поведения для распределителя ресурсов СУБД, resource manager). Сами ресурсные окошки (windows) принадлежат схеме SYS, но создавать их разрешено и другим пользователям при наличии соответствующей привилегии:
Ресурсный план построить несложно, но, чтобы не отвлекаться, воспользуемся встроенным в любую БД планом SYSTEM_PLAN (см. таблицу DBA_RSRC_PLANS). Тогда создание окошка может выглядеть так:
Теперь каждые три минуты на минуту будет включаться ресурсный план SYSTEM_PLAN. Это легко наблюдать, выдав несколько раз от имени SYS:
Если подгадать момент, когда значение OPERATION для окошка MY_JOB_WINDOW станет OPEN, от имени SYS можно будет удостовериться, что план включен:
Чтобы связать с этим периодически открывающимся ресурсным окошком задание, пользователю SCOTT достаточно указать его вместо расписания:
С этого момента можно наблюдать уменьшение зарплат сотрудников, осуществляемое каждые три минуты в условиях благоприятного ресурсного плана. В качестве варианта, в процедуре CREATE_WINDOW можно было сослаться и на какое-то существующее расписание.
Так как СУБД в каждый момент времени умеет работать только по одному ресурсному плану, окошки «не умеют» перекрываться, а могут только переопределять своим планом другой, ранее установленный и пришедшийся на то же время.
В качестве развития этой темы Oracle позволяет создавать именованный список существующих окошек и под маркой «группы» (window group) указывать его заданию значением параметра SCHEDULE_NAME, то есть там, где у нас было указано имя окошка.
Изменение свойств объектов планировщика
Хотя упомянутые JOB, SCHEDULE, PROGRAM, WINDOW и проч., причисляются к объектам хранения БД (и видны в таблицах DBA/ALL/USEROBJECTS), не только их создание и удаление, но и изменение свойств выполняются так, как было удобно разработчику: через API. Для всех перечисленных видов объектов существует довольно много поведенческих свойств, указанию которых нет места в процедурах LIKE ‘CREATE_%’. Устанавливать их следует явно единой для всех процедурой SET_ATTRIBUTE. Вот пример, как для задания MY_WINDOW_JOB (а) задать приоритет выполнения (по отношению к другим заданиям своего класса), если на одно время пришлось выполнение нескольких заданий одновременно, и (б) потребовать прекращения (процедурой STOP_JOB), если оно еще не выполнилось, а ресурсное окошко уже закрылось:
Полный список атрибутов и объектов, к которым они применимы, имеется в документации по Oracle.
Заключение
Помимо использованного выше общения с планировщиком Oracle 10 средствами PL/SQL и SQL, общаться с ним можно через графический интерфейс Oracle Enterprise Manager. По сути, OEM ничего нового не дает, так как в конечном итоге отсылает к СУБД те же команды на PL/SQL и SQL, но выполнение разовых действий через OEM часто администратору быстрее и понятнее. Для автоматизации работ, однако, лучше может подойти работа со сценариями запросов.
После проведенных опытов с планировщиком не забудьте освободить БД от ненужных объектов. Например:
Удаление прочих созданных ранее объектов и изъятие выданных пользователю SCOTT привилегий предлагается сделать самостоятельно в виде упражнения, воспользовавшись таблицами словаря-справочника и, при надобности, документацией. Можно также использовать OEM.
Oracle Scheduling Windows
Oracle Tips by Burleson Consulting
Windows define the times when resource plans are active. Since job classes point to resource consumer groups, and therefore resource plans, this mechanism allows control over the resources allocated to job classes and their associated jobs during specific time periods. A window can be assigned to the schedule_name parameter of a job instead of a schedule object.
Only one window can be active at any time, with one resource plan assigned to the window. The effects of resource plan switches are instantly visible to running jobs that are assigned to job classes.
A window can be created using the create_window procedure with a predefined or an inline schedule.
PROCEDURE create_window (
window_name IN VARCHAR2,
resource_plan IN VARCHAR2,
schedule_name IN VARCHAR2,
duration IN INTERVAL DAY TO SECOND,
window_priority IN VARCHAR2 DEFAULT ‘LOW’,
comments IN VARCHAR2 DEFAULT NULL)
PROCEDURE create_window (
window_name IN VARCHAR2,
resource_plan IN VARCHAR2,
start_date IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
repeat_interval IN VARCHAR2,
end_date IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
duration IN INTERVAL DAY TO SECOND,
window_priority IN VARCHAR2 DEFAULT ‘LOW’,
comments IN VARCHAR2 DEFAULT NULL)
The parameters associated with these procedures and their usage are as follows:
* window_name — A name that uniquely identifies the window.
* resource_plan — The resource plan associated with the window. When the window opens, the system switches to use the associated resource plan. When the window closes, the system switches back to the previous resource plan.
* schedule_name — The name of the schedule associated with the window. If this is specified, the start_date, repeat_interval and end_date must be NULL.
* start_date — The date when this window will take effect. This may be in the future if the window is to be setup in advance.
* repeat_interval — The definition of how often the window should open. A value of NULL indicates that the window should only open once.
* end_date — The date when this window will stop. This combined with the start_date parameter enables a window to be scheduled for a finite period of time.
* duration — The length of time in minutes the window should remain open.
* window_priority — The priority (LOW or HIGH) of the window. In the event of multiple windows opening at the same time, windows with a high priority take precedence over windows with a low priority, which is the default.
* comments — Free text allowing the user to record additional information.
The following code shows how the create_window procedures can be used:
BEGIN
— Window with a predefined schedule.
DBMS_SCHEDULER.create_window (
window_name => ‘test_window_1’,
resource_plan => NULL,
schedule_name => ‘TEST_HOURLY_SCHEDULE’,
duration => INTERVAL ’30’ MINUTE,
window_priority => ‘LOW’,
comments => ‘Window with a predefined schedule.’);
END;
/
BEGIN
— Window with an inline schedule.
DBMS_SCHEDULER.create_window (
window_name => ‘test_window_2’,
resource_plan => NULL,
start_date => SYSTIMESTAMP,
repeat_interval => ‘freq=hourly; byminute=0’,
end_date => NULL,
duration => INTERVAL ’30’ MINUTE,
window_priority => ‘LOW’,
comments => ‘Window with an inline schedule.’);
END;
/
The SYS user is the owner of all windows, so any schedules referenced by them must also be owned by SYS.
Figure 2.13 shows the Create Window screen in the OEM 10g DB Control.
Figure 2.13 ? OEM 10g DB Control: Create Window
Information about windows can be displayed using the dba_scheduler_windows view. The following script uses this view:
select
window_name,
resource_plan,
enabled,
active
from
dba_scheduler_windows
;
The output from the windows.sql script is displayed below.
WINDOW_NAME RESOURCE_PLAN ENABL ACTIV
—————————— ———————— —— ——
TEST_WINDOW_1 TRUE FALSE
TEST_WINDOW_2 TRUE FALSE
WEEKEND_WINDOW TRUE TRUE
WEEKNIGHT_WINDOW TRUE FALSE
4 rows selected.
Figure 2.14 shows the Scheduler Windows screen in the OEM 10g DB Control.
Figure 2.14 ? OEM 10g DB Control: Scheduler Windows
The server normally controls the opening and closing of windows, but they also can be opened and closed manually using the open_window and close_window procedures.
PROCEDURE open_window (
window_name IN VARCHAR2,
duration IN INTERVAL DAY TO SECOND,
force IN BOOLEAN DEFAULT FALSE)
PROCEDURE close_window (
window_name IN VARCHAR2)
The parameters associated with these procedures and their usage are as follows:
* window_name — A name that uniquely identifies the window.
* duration — The length of time, in minutes, the window should remain open.
* force — When set to FALSE, attempting to open a window when one is already open will result in an error unless the currently open window is the one that is attempting to open. In this case, the close time is set to the current system time plus the specified duration.
Closing a window causes all jobs associated with that window to be stopped.
The following example opens then closes test_window_2. Notice how the active window switches back to weekend_window when test_window_2 is closed.
BEGIN
— Open window.
DBMS_SCHEDULER.open_window (
window_name => ‘test_window_2’,
duration => INTERVAL ‘1’ MINUTE,
force => TRUE);
END;
/
SQL> @windows
WINDOW_NAME RESOURCE_PLAN ENABL ACTIV
—————————— ——————— —— ——
TEST_WINDOW_1 TRUE FALSE
TEST_WINDOW_2 TRUE TRUE
WEEKEND_WINDOW TRUE FALSE
WEEKNIGHT_WINDOW TRUE FALSE
4 rows selected.
BEGIN
— Close window.
DBMS_SCHEDULER.close_window (
window_name => ‘test_window_2’);
END;
/
WINDOW_NAME RESOURCE_PLAN ENABL ACTIV
—————————— ——————— —— ——
TEST_WINDOW_1 TRUE FALSE
TEST_WINDOW_2 TRUE FALSE
WEEKEND_WINDOW TRUE TRUE
WEEKNIGHT_WINDOW TRUE FALSE
4 rows selected.
Windows can be removed using the drop_window procedure.
PROCEDURE drop_window (
window_name IN VARCHAR2,
force IN BOOLEAN DEFAULT FALSE)
The parameters associated with this procedure and their usage are as follows:
* window_name — A single or comma separated list of window names. If a window group name is specified, all windows within that group will be dropped. In addition, all jobs that use the specified window or window group as a schedule will be disabled, although running jobs will complete normally.
* force — When set to FALSE, attempting to drop an open window will result in an error. When set to TRUE the open window is closed before it is dropped.
The following example drops the two test windows that were created earlier:
BEGIN
DBMS_SCHEDULER.drop_window (
window_name => ‘test_window_1,test_window_2’,
force => TRUE);
END;
/
The output from the windows.sql script confirms that the windows have been removed successfully.
WINDOW_NAME RESOURCE_PLAN ENABL ACTIV
———————— —————— —— ——
WEEKEND_WINDOW TRUE TRUE
WEEKNIGHT_WINDOW TRUE FALSE
2 rows selected.
The following section will show how to group related windows together using window groups.
 | This is an excerpt from the book «Oracle Job Scheduling» by Dr. Tim Hall. You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle job scheduling scripts. |
Burleson is the American Team
Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals. Feel free to ask questions on our Oracle forum .
Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.
Errata? Oracle technology is changing and we strive to update our BC Oracle support information. If you find an error or have a suggestion for improving our content, we would appreciate your feedback. Just e-mail:
and include the URL for the page.
