Пакет DBMS JOB

Пакет DBMS JOB позволяет запланировать однократное или регулярное выполнение заданий в базе данных. Задание представляет собой хранимую процедуру, аноним-н1й блок PL/SQL или внешнюю процедуру на языке С или Java. Эти задания выполняются серверными процессами в фоновом режиме. Задания можно выполнять регулярно (в 2 часа ночи каждые сутки) или однократно (выполнить задание сразу после фиксации транзакции и удалить его из очереди). Если вы знакомы с утилитами cron или at в ОС UNIX или Windows, то особенности использования пакета DBMS JOB вам уже понятны. Задания выполняются в той же среде (пользователь, набор символов и т.п.), из которой они посланы на выполнение (но роли не действуют). Задания выполняются аналогично процедурам с правами создателя, т.е. роли для них не учитываются. Это можно продемонстрировать на следующем примере (процедуры, использованные в этом примере, позже будут рассмотрены подробно):

tkyte@TKYTE816> create table t (msg varchar2(20) , cnt int) ; Table created.

tkyte@TKYTE816>insert into t select from SQL*PLUS, count(*) from session roles;

1 row created.

tkyte@TKYTE816> variable n number

tkyte@TKYTE816> exec dbms job.submit(:n,insert into t select from job , count(*) from session roles;) ;

PL/SQL procedure successfully completed.

tkyte@TKYTE816> print n

1594 Приложение

tkyte@TKYTE816> exec dbms job.run(:n); PL/SQL procedure successfully completed tkyte@TKYTE816> select * from t; MSG CNT

from SQL*PLUS 10

from job 0

Как видите, в среде SQL*Plus имеется 10 действующих ролей, а в среде выполнения задания - ни одной. Поскольку пользователи в качестве задания обычно вызывают хранимую процедуру, это не имеет значения, потому что при выполнении хранимой процедуры роли все равно не учитываются. Проблема возникает только при попытке выполнить процедуру, доступную через роль. Такая процедура не сработает, поскольку в заданиях роли не действуют.

Часто пользователи спрашивают, как лучше всего скрыть имя пользователя/пароль, связанные с пакетным заданием (например, для периодического анализа таблиц), по-с1лаемым с помощью утилиты cron или ее аналогов в среде Windows NT/2000. Их беспокоит, что пароль хранится в файле (и это правильно) или явно представлен в результатах выполнения команды ps в среде UNIX и т.п. Я всегда рекомендую вообще не использовать средства ОС для планирования заданий в базе данных, а вместо этого написать хранимую процедуру, выполняющую необходимые действия, и запланировать ее выполнение с помощью средств пакета DBMS JOB. При этом ни имя пользователя, ни пароль нигде не хранится, и задание выполнится только в том случае, когда доступна база данных. Если сервер базы данных не будет работать в соответствующий момент, задание, естественно, не выполнится, поскольку именно сервер базы данных и отвечает за выполнение задания.

Часто спрашивают также: как ускорить выполнение? Необходимо выполнить продолжительное действие, а пользователь не хочет ждать. Причем иногда ускорить выполнение действия нельзя. Например, я уже многие годы посылаю сообщения электронной почты с сервера базы данных. Я использовал для этого различные механизмы: каналы базы данных, пакет UTL HTTP, внешние процедуры и средства языка Java. Все они работали примерно с одинаковой скоростью, но всегда - медленно. Иногда завершения работы по протоколу SMTP приходится ждать достаточно долго. Слишком долго в случае моего приложения, для которого ожидания более четверти секунды вообще недопустимы. Посылка сообщения по протоколу SMTP может иногда потребовать 2-3 секунды. Ускорить этот процесс нельзя, но можно создать видимость его более быстрого выполнения. Вместо отправки сообщения при нажатии пользователем соответствующей кнопки в приложении должно посыпаться на выполнение задание, которое будет отправлять сообщение сразу после фиксации транзакции. При этом возникает два побочных эффекта. Во-первых, действие выполняется как бы быстрее, а во-вторых, отправка сообщения становится частью транзакции. Одно из свойств пакета DBMS JOB состоит в том, что задание попадает в очередь только после фиксации транзакции. При откате транзакции задание удаляется из очереди и не выполняется. С помощью пакета

Пакет DBMS JOB 1595

DBMS JOB мы не только создаем видимость более быстрой работы приложения, но и делаем его более надежным. Больше не будет пос1латься уведомление по электронной почте из триггера при изменении строки, если это изменение затем б1ло отменено. Либо строка изменяется, и отправляется сообщение; либо строка не изменяется, и сообщение не отправляется.

Так что пакет DBMS JOB имеет широкую сферу применения. Он может включить выполнение действий, выходящих за рамки транзакций (таких как отправка сообщений по электронной почте или создание таблицы при вставке строки в другую таблицу) в транзакции. Он позволяет создать видимость более быстрого выполнения действий, особенно, если продолжительные действия не должны выдавать пользователю результатов. Пакет позволяет планировать и автоматизировать многие задачи, для решения которых обычно создавались сценарии вне базы данных. Это, безусловно, очень полезный пакет.

Для корректной работы пакета DBMS JOB необходимо выполнить небольшую настройку сервера. Надо установить два параметра инициализации.

job queue interval. Задает периодичность (в секундах) проверки очередей и поиска заданий, готовых к выполнению. Если задание должно выполняться раз в 30 секунд, но параметр job queue interval имеет (стандартное) значение 60, это задание не будет выполняться раз в 30 секунд - в лучшем случае, раз в 60 секунд.

job queue processes. Задает количество фоновых процессов для выполнения заданий. Значением может быть целое число от 0 (по умолчанию) до 36. Это значение можно менять без перезапуска сервера с помощью оператора ALTER SYSTEM SET JOB QUEUE PROCESSES=<nn>. Если оставить стандартное значение 0, задания из очереди автоматически никогда выполняться не будут. Процессы обработки очередей заданий можно увидеть в среде ОС UNIX - они получают имена ora snpN $ORACLE SID, где N - число (0, 1, 2, ...,job queue processes-l). В среде Windows очереди заданий обрабатываются потоками операционной системы, увидеть которые с помощью стандартных средств нельзя.

Многие системы работают со значением параметра job queue interval, равным 60 (другими словами, проверяют очереди раз в минуту), и значением параметра job queue processes, равным 1 (выполняют одновременно не более одного задания). При интенсивном использовании заданий или возможностей, для реализации которых используются задания (в частности, репликация и поддержка материализованных представлений используют очереди заданий), может потребоваться добавление дополнительных процессов и увеличение значения параметра инициализации job queue processes.

После настройки и автоматического запуска очередей заданий можно начинать их использование. Основная процедура пакета DBMS JOB - процедура SUBMIT. Она имеет следующий интерфейс:

PROGEDURE SUBMIT

Argument Name Type In/Out Default?

JOB BINARY INTEGER OUT

WHAT VARGHAR2 IN

NEXT DATE DATE IN DEFAULT

INTERVAL VARGHAR2 IN DEFAULT