DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Владелец расписания

Еще один важный столбец представления DBA_SCHEDULER_JOBS - это SCHEDULE_OWNER. В нашем примере он содержит значение ARUP, имя пользователя, который создал расписание. Наличие этого столбца отражает важный факт: расписание не обязательно должно быть создано пользователем, фактически запускающим задание, оно может быть определено другим пользователем. Однако имейте в виду, что пользователь, создающий расписание, должен иметь системную привилегию CREATE JOB. Расписание создается средствами пакета DBMS_SCHEDULER, поэтому пользователь также должен обладать привилегией EXECUTE на пакет.
Предположим, что я создаю специального пользователя SCHED_MANAGER для управления всеми расписаниями базы данных. Такой подход упрощает управление расписаниями и позволяет контролировать их из одной точки. Как уже говорилось, пользователю должны быть выданы привилегии CREATE JOB, EXECUTE ON DBMS_SCHEDULER.
Код создания задания теперь будет выглядеть следующим образом:

Обратите внимание на изменение строки 6. Теперь параметр schedu- le_name содержит значение SCHED_MANAGER.opt_stat_coll_sched, указывающее на владельца расписания. В предыдущих примерах мы не вклю-
чали в название расписания префикс (если префикс не указан, то по умолчанию считается, что расписание принадлежит пользователю, создающему задание).
После того как расписание создано некоторым пользователем, использовать его может произвольный другой пользователь. Не существует средств детального контроля доступа, которые обеспечивали бы управление доступом к определенному расписанию. Помните об этом при создании расписаний.
Управление именованными программами
Мы изучили два основных компонента планировщика: задание и расписание. Третьим базовым элементом является программа: тот код, который будет выполняться по расписанию. Вы уже научились вызывать программы разных типов, теперь можно попробовать (и это вполне оправданно) поместить все планируемые процессы (в хранимых процедурах, анонимных блоках PL/SQL или исполняемых файлах) под контроль планировщика. Однако тут возникает одна сложность. В соответствии с предложенным ранее описанием синтаксической конструкции вам необходимо передать полный путь к исполняемому файлу (или к PL/SQL-блоку или хранимой процедуре) в параметр job_action процедуры CREATE_JOB. Если этот путь длинный (а именно так зачастую и бывает), то вводить его полностью не слишком удобно. А если, к тому же, приходится вводить его неоднократно, то увеличивается вероятность ошибок при вызове планировщика.
К счастью, DBMS_SCHEDULER позволяет определять именованные программы, что значительно упрощает ссылку на выполняемую программу. Именованная программа, по сути, - синоним кода, который фактически выполняется. Вместо того чтобы вызывать реальный сегмент кода, вы ссылаетесь на программу по имени. Теперь, если когда-нибудь нужно будет изменить задание так, чтобы оно запускало другую программу, вам не придется изменять определение задания. Необходимо заменить исполняемый модуль внутри программы, и задание будет работать, как надо.
 









jAntivirus