Oracle не запускаются джобы
Обновлено: 06.07.2024
В какой то момент времени перестали запускаться job-ы. Т.е. просто висит
некоторое количество просроченных job-ов. Hе broken. Количество failures 0.
Если сделать любой job-е run, то она выполняется без проблем. Если создать
новую job-у, то тоже не запускается по расписанию.
Hе совсем понятна причина. Точнее совсем не понятна. Поглядел: select * from
v$bgprocess; Увидел что два процесса - CJQ0 и QMN0 имеют в поле Error
значение 448. Почитал описание ORA-448. Hаписано, смотрите трейсы. В трейсах
пусто.
Попробовал перезапустить координатор job-ов, изменил параметр
job_queue_processes на 0 и обратно на 2. В alert*.log появилась надпись:
Restarting dead background process CJQ0
CJQ0 started with pid=70
. однако job-ы все равно не запускаются. Делать рестарт серверу
нежелательно.
Привет всем.
В какой то момент времени перестали запускаться job-ы. Т.е. просто висит
некоторое количество просроченных job-ов. Hе broken. Количество failures
Post by Andrew V. Fionik
Если сделать любой job-е run, то она выполняется без проблем. Если создать
новую job-у, то тоже не запускается по расписанию.
Hе совсем понятна причина. Точнее совсем не понятна. Поглядел: select *
Post by Andrew V. Fionik
v$bgprocess; Увидел что два процесса - CJQ0 и QMN0 имеют в поле Error
значение 448. Почитал описание ORA-448. Hаписано, смотрите трейсы. В
Post by Andrew V. Fionik
пусто.
Попробовал перезапустить координатор job-ов, изменил параметр
Restarting dead background process CJQ0
CJQ0 started with pid=70
. однако job-ы все равно не запускаются. Делать рестарт серверу
нежелательно.
А очереди у вас часом не используются ? У нас было нечто похожее с
очередями. Залипали очереди и есть подозрение, что и джобы за них цеплялись
тоже. Лечили ребутом. Вообще то можно отстреливать было только один процесс
(сейчас не вспомню название но не CJQ).
Это один из наиболее часто задаваемых вопросов Планировщику. Здесь мы перечисляем некоторые из распространенных проблем и способы их решения.
1) job_queue_processes может быть слишком низким (это наиболее распространенная проблема) Значение job_queue_processes ограничивает общее количество dbms_scheduler и задания dbms_job, которые могут выполняться в заданное время. Чтобы проверить, так ли это, проверьте текущее значение job_queue_processes с SQL> выберите значение из параметра v $, где name = 'job_queue_processes'; Затем проверьте количество запущенных заданий. SQL> выберите количество () из dba_scheduler_running_jobs; SQL> выберите количество () из 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> выберите количество (*) из dba_scheduler_running_jobs;
Если это проблема, вы можете увеличить число или просто обнулить его, используя SQL> exec dbms_scheduler.set_scheduler_attribute ('max_job_slave_processes', null)
3) количество сеансов может быть слишком низким. Этот параметр ограничивает количество сеансов в любое время. Для каждого задания планировщика требуется 2 сеанса. Чтобы проверить, является ли это проблемой, проверьте текущее значение с помощью SQL> выберите значение из параметра v $, где name = 'sessions'; Затем проверьте текущее количество сеансов с помощью SQL> выберите 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'
Причины опоздания с вакансиями
1) Первое, что нужно проверить, - это часовой пояс, в котором задание запланировано с помощью SQL> выберите владельца, имя_задания, дату_следующего_пуска из dba_scheduler_jobs;
Если задания находятся в неправильном часовом поясе, они могут не выполняться в ожидаемое время. Если next_run_date использует абсолютное смещение часового пояса (например, +08: 00) вместо именованного часового пояса (например, US / PACIFIC), тогда задания могут выполняться не так, как ожидалось, если действует летнее время - они могут выполняться на час раньше или позже. .
2) Может случиться так, что в то время, когда задание было запланировано для запуска, одно из нескольких указанных выше ограничений могло быть временно достигнуто, что привело к задержке задания. Убедитесь, что указанные выше пределы достаточно высоки, и, если возможно, проверьте их во время задержки задания.
3) Одна из возможных причин, по которой может быть превышен один из вышеуказанных пределов, заключается в том, что, возможно, вступил в силу интервал обслуживания. Окна обслуживания - это окна планировщика Oracle, которые принадлежат группе окон с именем MAINTENANCE_WINDOW_GROUP. Во время планового окна обслуживания несколько задач обслуживания запускаются с помощью заданий. Это может привести к срабатыванию одного из перечисленных выше ограничений и задержке пользовательских заданий. Дополнительную информацию об этом см. В руководстве администратора (глава 24).
Чтобы получить список окон обслуживания, используйте SQL> выберите * from dba_scheduler_wingroup_members;
Чтобы увидеть, когда запускаются окна, используйте SQL> выберите * from dba_scheduler_windows;
Диагностика других проблем
Если ничего из этого не сработает, вот еще несколько шагов, которые вы можете предпринять, чтобы попытаться выяснить, что происходит.
1) Проверьте, нет ли ошибок в журнале предупреждений. Если у базы данных возникли проблемы с выделением памяти, закончилось место на диске или возникли другие катастрофические ошибки, вы должны сначала устранить их. Вы можете найти местоположение журнала предупреждений, используя SQL> выберите значение из параметра v $, где name = 'background_dump_dest'; Журнал предупреждений будет находиться в этом каталоге с именем, начинающимся с "предупреждения".
2) Проверьте, есть ли файл трассировки координатора заданий, и если он есть, проверьте, содержит ли он какие-либо ошибки. Если он существует, он будет расположен в каталоге 'background_dump_dest', который вы можете найти, как указано выше, и будет выглядеть примерно как SID-cjq0_nnnn.trc. Если здесь есть какие-либо ошибки, они могут намекнуть, почему задания не выполняются.
3) Если любое из вышеперечисленных указывает, что табличное пространство SYSAUX (где планировщик хранит свои таблицы журналирования) заполнено, вы можете использовать процедуру dbms_scheduler.purge_log для очистки старых записей журнала.
4) Посмотрите, открыто ли в данный момент окно. Если есть, вы можете попробовать закрыть его, чтобы посмотреть, поможет ли это.
5) попробуйте запустить простое однократное задание и посмотрите, работает ли оно
6) Если простое однократное задание не запускается, вы можете попробовать перезапустить планировщик следующим образом.
В многопользовательской среде контейнер также должен иметь правильное значение для job_queue_processes.
Мне нужно его стартовать так, что бы дата не сбилась, то бишь если в нем прописана next_date завтра, а я делаю broken = false, то он не стартанул сразу же.
Я просто что-то так и не нагуглил инфы. Как остановить job есть инфа, и как стартануть job есть инфа, но так, что бы он сразу и отработал, а так как мне нужно, видимо не там гуглю.
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Запуск студией и запуск самой виндой. Разница работы программы
Итак, проблема такова: есть проект, который замечательно работает при нажатии F5 в студии. При.
Запуск в батнике - команды на запуск файла (из консоли с правами администратора)
Добрый день, форумчане. Помогите решить вопрос. Существует файл, которого нужно часто запускать.
Автоматический запуск/запуск с клавиатуры или ПК живет своей жизнью =)
Всем привет и с наступающим! У меня такая беда, которая случилась где-то месяца 2 назад: .
Запуск сначала одного видео, потом по событию - запуск второго видео
У меня при заходе на сайт, весь сайт немного затемняется и делается не активным (ни ссылку ни.
Потом остановить, сделать нечто и снова стартануть. Только непонятно, зачем останавливать, если следующий старт будет только завтра? Может и не надо вовсе делать broken=true ?
Ведь в дате прописан не только день, но и часы с минутами и секундами
Добавлено через 5 минут
К тому же, если сделано broken=true, насколько я знаю, дата автоматически меняется на 4000 год, так что полезной информации Вы, скорее всего, не извлечете
Добавлено через 4 минуты
А вот LAST_DATE, время последнего выполнения, Вы извлечь, скорее всего, сможете. То есть, Вам придется к LAST_DATE как-то применить функцию INTERVAL и самому получить новую дату старта
Были случаи когда я мог делитнуть джоба и вьюха сразу удалялась, сейчас нельзя джобу удалять удалить вьюхи, которые на основе его выполнения заполняются Как view могут чем-то заполняться (если это конечно не matview)? Тогда совершенно непонятно, зачем перезапускать job, который все равно снова повиснет, да еще и в строго определенный момент времени. Тогда совершенно непонятно, зачем перезапускать job, который все равно снова повиснет
job рассылает уведомления, рассылка цепляет данные из нескольких баз, в том числе вью, которая формируется на основе данных из нерабочей базы.
мне нужно удалить эту вью. удалить нормально не могу потому, что при этом зависает моя сессия.
когда пытался понять, почему она виснет в аналогичной ситуации, я просто снес другой джоб и вью удалилась моментально. в данном случае я снести джоб не могу потому, что перестанут идти абсолютно все уведомления.
идея была такова, остановить джоб, удалить вью, которая формируется с нерабочей базы, запустить джоб.
если бы вью удалялась без проблем, я бы джоб не останавливал.
, затем грохнуть сессию задания, если оно выполняется, грохнуть само задание, чтобы больше не стартовало, грохнуть все объекты которые хочется, и перезапустить задание по сохраненным в таблице параметрам?
Только еще хочу напомнить, что удаление объектов в базе может привести к тому, что какие-то другие объекты станут инвалидными, и что-нибудь может посыпаться в самый неподходящий момент
Добавлено через 17 минут
Я тоже, вслед за
По-моему, объект нельзя дропнуть тогда, он когда как-то используется в сесииях (необязательно активных). Есть системные вьюхи, позволяющие найти объекты, удерживаемые сессиями. В некоторых случаях мы убивали все сессии, работающие с объектом, если возникала необходимость срочно его видоизменить, например. Может здесь тоже можно сделать что-то подобное, ну или, хотя бы проанализировать, кто и что держит Как view могут чем-то заполняться (если это конечно не matview)? начинаю склоняться к мысли, что речь идет о материализованных представлениях.
После того, как остановили ту базу стоит задача из мат.вью сделать вью, с таким же названием на своей базе, понятное дело, что сначала нужно дропнуть мат.вью. Как только я это делаю, зависает моя сессия и все, кроме как кильнуть ее, больше нечем заниматься.
По опыту знаю, что как только прекращает свое действие джоб, вью дропает на раз два. Но если раньше я просто сносил джоб по ненадобности, то тут я такого сделать не мог.
Все что мне нужно, это остановить джоб, как вы уже сказали "дата автоматически меняется на 4000 год", по этому что бы корректно восстановить время его запуска, мне нужно было знать, можно ли как то проделать сие действия, не сбивая next_date
Только еще хочу напомнить, что удаление объектов в базе может привести к тому, что какие-то другие объекты станут инвалидными, и что-нибудь может посыпаться в самый неподходящий моментП.С. Я так понимаю, что так, как я хочу сделать нельзя. Тобишь, нужно или в функции делать лог запуска, или мигрировать в sheduler. Значит займусь первым вариантом
В externaljob.ora прописан юзер oracle с группой oinstall.
В .bash_profile юзера oracle прописаны все перменные:
Сделал примитивный bash-скрипт с редиректом текущих системных переменных в отдельный текстовый файл. Если запустить из консоли, то все переменные на месте. При запуске через external job юзер остается oracle, но нет переменных.
Как решить проблему?
Oracle вызывает executuble, указанный в external job. напрямую, т.е. без оболочки и в пустом окружении. Из комментария топикастера:
Заменил sqlplus на софтлинк скрипта, который устанавливает переменные и запускает уже настоящий sqlplus. Такой костыль не хочется оставлять, хочется красивого решения.
Это собственно и есть правильное решение.
Или можно создать универсальную задачу запускающую оболочку с чтением логин скриптов, а затем в ней запускать желаемую программу (или даже built-in, function и т.д.):
/env.out вывод полного окружение пользователя в режиме не интерактивного логина.
Ещё один пример запуска и просмотр вывода на стандртный поток ошибок:
В главе 28.3.1.2.1 About External Jobs, кроме всего прочего, описано, как установить пользователя и группу, с которыми будет запущена задача.
Читайте также: