Задание СУБД Oracle не работает

Question

Я определил работу, которая будет выполняться со вторника по воскресенье каждые 5 минут. с 9:00 до 22:00

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'GET_INVOICES_JOB',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN LOPES.GET_INVOICES; END;',
repeat_interval =>'FREQ=MINUTELY; INTERVAL=5; BYHOUR=9,22; BYDAY=TUE,WED,THU,FRI,SAT,SUN', 
enabled => TRUE,
comments => 'GET_INVOICES');
END;
/

Но работа не работает, проверяя

SELECT *
FROM USER_SCHEDULER_JOB_RUN_DETAILS 
ORDER BY LOG_DATE DESC

Проверяя работу, кажется, все в порядке:

и запустив задание вручную, он выполняет процедуру, но только один раз, а не каждые 5 минут

Answer 1

Это один из самых распространенных вопросов планировщика. Здесь мы перечисляем некоторые распространенные проблемы и пути их решения.

1) job_queue_processes могут быть слишком низкими (это самая распространенная проблема). Значение job_queue_processes ограничивает общее количество заданий dbms_scheduler и dbms_job, которые могут выполняться в данный момент времени. Чтобы проверить, так ли это, проверьте текущее значение job_queue_processes с помощью SQL> выберите значение из параметра v$, где name='job_queue_processes'; Затем проверьте количество запущенных заданий SQL> select count () из dba_scheduler_running_jobs; SQL> select count () из dba_jobs_running;

Если это проблема, вы можете увеличить параметр, используя SQL> alter system set job_queue_processes = 1000;

2) max_job_slave_processes могут быть слишком низкими. Если этот параметр не равен NULL, то он ограничивает количество заданий dbms_scheduler, которые могут выполняться одновременно. Чтобы проверить, является ли это проблемой, проверьте текущее значение, используя SQL> select value из dba_scheduler_global_attribute, где attribute_name='MAX_JOB_SLAVE_PROCESSES'; Затем проверьте количество запущенных заданий SQL> select count(*) из dba_scheduler_running_jobs;

Если это проблема, вы можете увеличить число или просто обнулить его, используя SQL> exec dbms_scheduler.set_scheduler_attribute ('max_job_slave_processes', null)

3) количество сеансов может быть слишком низким. Этот параметр ограничивает количество сеансов в любое время. Каждое задание Планировщика требует 2 сеанса. Чтобы проверить, является ли это проблемой, проверьте текущее значение, используя SQL> select value из v$parameter, где name='session'; Затем проверьте текущее количество сеансов, используя SQL> select count(*) из v$session;

Если числа слишком близки, вы можете увеличить максимум, используя SQL> alter system set job_queue_processes = 200;

4) Вы недавно применили патч обновления часового пояса или обновили базу данных до версии с более новой информацией о часовом поясе? Если вы пропустили какие-либо шаги при обновлении информации о часовом поясе, задания могут не запускаться. Чтобы проверить, так ли это, попробуйте выполнить SQL> select * from sys.scheduler$_job; и SQL> select * from sys.scheduler$_window; и убедитесь, что они заканчиваются без ошибок.

Если выдается предупреждение о часовом поясе, повторно примените обновление или исправление часового пояса, следя за тем, чтобы выполнить все шаги.

5) База данных работает в ограниченном режиме? Если база данных работает в ограниченном режиме, то никакие задания не будут выполняться (если вы не используете 11g и не используете атрибут ALLOW_RUNS_IN_RESTRICTED_MODE). Чтобы проверить это, используйте SQL> select logins from v$instance;

Если вход в систему ограничен, вы можете отключить ограниченный режим, используя SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6) Запланировано ли выполнение задания на экземпляре, который не работает?

Вы можете проверить это, посмотрев, установлен ли instance_id для задания (проверьте представление dba_scheduler_jobs), и если это так, вы должны проверить, работает ли этот экземпляр.

7) Запланировано ли задание для службы, которая не была запущена ни в одном экземпляре?

Вы можете проверить это, проверив, на какой job_class указывает задание, а затем проверив, указывает ли этот класс на службу. Если это так, убедитесь, что служба запущена хотя бы на одном работающем экземпляре. Вы можете запустить службу в экземпляре, используя dbms_service.start_service.

8) Действует ли Resource Manager с ограничительным планом ресурсов?

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

SQL> выбрать имя из V$RSRC_PLAN;

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

SQL> изменить систему set resource_manager_plan = '';

9) Планировщик отключен? Это не поддерживаемое действие, но возможно, что кто-то сделал это в любом случае. Чтобы проверить это, выполните SQL> выберите значение из dba_scheduler_global_attribute, где attribute_name='SCHEDULER_DISABLED'

Если этот запрос возвращает TRUE, вы можете исправить это, используя SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');

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

1) Первое, что нужно проверить, это часовой пояс, в котором задание запланировано с помощью SQL> выбрать владельца, имя_объекта, next_run_date из dba_scheduler_jobs;

Если задания находятся в неправильном часовом поясе, они могут не запускаться в ожидаемое время. Если next_run_date использует абсолютное смещение часового пояса (например, +08:00) вместо именованного часового пояса (например, US/PACIFIC), тогда задания могут работать не так, как ожидается, если действует летнее время - они могут выполняться на час раньше или позже,

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

3) Одна из возможных причин, по которой может быть достигнуто одно из вышеуказанных ограничений, заключается в том, что могло появиться окно технического обслуживания. Окна обслуживания - это окна планировщика Oracle, принадлежащие группе окон с именем MAINTENANCE_WINDOW_GROUP. Во время запланированного периода обслуживания несколько задач обслуживания выполняются с использованием заданий. Это может привести к нарушению одного из перечисленных выше ограничений и задержке заданий пользователя. См. Руководство администратора для получения дополнительной информации об этом (глава 24).

Чтобы получить список окон обслуживания, используйте SQL> select * from dba_scheduler_wingroup_members;

Чтобы увидеть, когда запускаются окна, используйте SQL> select * from dba_scheduler_windows;

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

Диагностика других проблем

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

1) Проверьте, есть ли какие-либо ошибки в журнале предупреждений. Если в базе данных возникают проблемы с выделением памяти, или на ней не хватает места на диске, или возникли какие-либо другие катастрофические ошибки, сначала следует устранить их. Вы можете найти местоположение журнала предупреждений, используя SQL> select value из v$parameter, где name = 'background_dump_dest'; Журнал предупреждений будет находиться в этом каталоге с именем, начинающимся с "alert".

2) Проверьте, есть ли файл трассировки координатора заданий и, если он есть, проверьте, нет ли в нем ошибок. Если он существует, он будет расположен в каталоге background_dump_dest, который вы можете найти, как указано выше, и будет выглядеть примерно так: SID-cjq0_nnnn.trc . Если здесь есть какие-либо ошибки, они могут подсказать, почему задания не выполняются.

3) Если что-либо из вышеперечисленного указывает, что табличное пространство SYSAUX (где планировщик хранит свои таблицы журналов) заполнено, вы можете использовать процедуру dbms_scheduler.purge_log для очистки старых записей журнала.

4) Проверьте, открыто ли окно в данный момент. Если есть, вы можете попробовать закрыть его, чтобы посмотреть, поможет ли это.

SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where 
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');

5) попробуйте запустить простое однократное задание и посмотрите, работает ли оно

SQL>begin
dbms_scheduler.create_job (
job_name => 'test_job',
job_type => 'plsql_block',
job_action => 'null;',
enabled => true);
end;
/
SQL> -- wait a while
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB';

6) Если простое однократное задание не запускается, попробуйте перезапустить планировщик следующим образом.

SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE');
SQL> alter system set job_queue_processes=0;
SQL> exec dbms_ijob.set_enabled(FALSE);
SQL> 
SQL> alter system flush shared_pool;
SQL> alter system flush shared_pool;
SQL>
SQL> exec dbms_ijob.set_enabled(TRUE);
SQL> alter system set job_queue_processes=99;
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');

Answer 2

В многопользовательской среде контейнер также должен иметь правильное значение для job_queue_processes.