Это один из самых частых вопросов, задаваемых планировщику. Здесь мы перечисляем некоторые распространенные проблемы и их решения.
1) job_queue_processes может быть слишком маленьким (это наиболее распространенная проблема) Значение job_queue_processes ограничивает общее количество заданий dbms_scheduler и dbms_job, которые могут выполняться в данный момент времени. Чтобы проверить, так ли это, проверьте текущее значение job_queue_processes с помощью SQL> выберите значение из параметра v$, где name='job_queue_processes'; Затем проверьте количество запущенных заданий SQL> выберите count() из dba_scheduler_running_jobs; SQL> выберите count() из dba_jobs_running;
Если это проблема, вы можете увеличить параметр, используя SQL> alter system set job_queue_processes=1000;
2) max_job_slave_processes может быть слишком низким. Если этот параметр не равен NULL, он ограничивает количество заданий dbms_scheduler, которые могут выполняться одновременно. Чтобы проверить, не в этом ли проблема, проверьте текущее значение с помощью SQL> выберите значение из dba_scheduler_global_attribute, где attribute_name='MAX_JOB_SLAVE_PROCESSES'; Затем проверьте количество запущенных заданий SQL> выберите count(*) из dba_scheduler_running_jobs;
Если это проблема, вы можете увеличить число или просто обнулить его, используя SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)
3) сессий может быть слишком мало. Этот параметр ограничивает количество сессий в любое время. Для каждого задания планировщика требуется 2 сеанса. Чтобы проверить, не в этом ли проблема, проверьте текущее значение с помощью SQL> выберите значение из параметра v$, где name='sessions'; Затем проверьте текущее количество сеансов с помощью SQL> select count(*) from v$session ;
Если числа слишком близки, вы можете увеличить максимальное значение, используя SQL> alter system set job_queue_processes=200;
4) Вы недавно применили патч для обновления часового пояса или обновили базу данных до версии с более новой информацией о часовом поясе? Если вы пропустили какие-либо шаги при обновлении информации о часовом поясе, задания могут не выполняться. Чтобы проверить, так ли это, попробуйте выполнить SQL> select * from sys.scheduler$_job; и SQL> выберите * из sys.scheduler$_window; и убедитесь, что они заканчиваются без ошибок.
Если он выдает предупреждение о часовом поясе, повторно примените обновление или исправление часового пояса, обязательно выполнив все шаги.
5) Работает ли база данных в ограниченном режиме? Если база данных работает в ограниченном режиме, никакие задания не будут выполняться (если только вы не используете 11g и не используете атрибут ALLOW_RUNS_IN_RESTRICTED_MODE). Чтобы проверить это, используйте SQL> выберите логины из v$instance ;
Если вход в систему ограничен, вы можете отключить ограниченный режим, используя SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6) Запланировано ли выполнение задания на экземпляре, который не работает?
Вы можете проверить это, увидев, установлен ли instance_id для задания (проверьте представление dba_scheduler_jobs), и если это так, вы должны проверить, работает ли этот экземпляр.
7) Запланировано ли выполнение задания в службе, которая еще не запущена ни в одном экземпляре?
Вы можете проверить это, проверив, на какой класс job_class указывает задание, а затем проверив, указывает ли этот класс на службу. Если это так, убедитесь, что служба запущена хотя бы на одном работающем экземпляре. Вы можете запустить службу на экземпляре, используя dbms_service.start_service.
8) Действует ли диспетчер ресурсов с ограничительным планом ресурсов?
Если действует ограничительный план ресурсов, для заданий планировщика может не быть выделено достаточно ресурсов, поэтому они могут не выполняться. Вы можете проверить, какой план ресурсов действует, выполнив
SQL> выберите имя из V$RSRC_PLAN ;
Если план не действует или действует план INTERNAL_PLAN, то диспетчер ресурсов не действует. Если менеджер ресурсов действует, вы можете отключить его, выполнив
SQL>изменить системный набор 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> select owner, job_name, 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> выберите * из dba_scheduler_windows;
Чтобы исправить это, вы можете либо увеличить лимиты, либо перенести окна обслуживания, чтобы они запускались в более удобное время.
Диагностика других проблем
Если ничего из этого не работает, вот еще несколько шагов, которые вы можете предпринять, чтобы попытаться выяснить, что происходит.
1) Проверьте, нет ли ошибок в журнале предупреждений. Если в базе данных возникли проблемы с выделением памяти, закончилось место на диске или произошли какие-либо другие катастрофические ошибки, вы должны решить их в первую очередь. Вы можете найти местоположение журнала предупреждений, используя SQL> выберите значение из параметра v$, где имя = 'background_dump_dest'; Журнал предупреждений будет находиться в этом каталоге с именем, начинающимся с «предупреждение».
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');
person
Nunyet de Can Calçada
schedule
09.10.2017
