DBMS_JOB против DBMS_SCHEDULER

С других форумов:

Хотя dbms_job по-прежнему существует в версиях 10g и 11g, Oracle рекомендует использовать dbms_scheduler в версиях 10g и выше. Никаких новых функций в dbms_job не добавляется, и вы, скорее всего, быстро столкнетесь с его ограничениями.

dbms_scheduler является более надежным и полнофункциональным, чем dbms_job, и включает следующие функции, которых нет у dbms_job:

• регистрация выполнения заданий (история заданий)
• простой, но мощный синтаксис планирования (похожий, но более мощный, чем синтаксис cron)
• запуск заданий вне базы данных в операционной системе
• управление ресурсами между различными классами заданий
• использование аргументов задания, включая передачу объектов в хранимые процедуры
• модель безопасности на основе привилегий для рабочих мест
• именование заданий и комментарии в заданиях
• сохраненные, многократно используемые расписания

Функции в выпусках после 10g Release 1 включают:

• зависимости между рабочими единицами (10gR2 и выше)
• планирование на основе финансовых календарей и финансовых кварталов (10gR2 и выше)
• Задания на основе событий, которые запускаются при получении события (10gR2 и выше)
• запуск заданий на удаленных машинах (11gR1 и выше)
• уведомления по электронной почте об интересующих событиях вакансий (10gR2 и выше)
• запуск задания на основе поступления файла (10gR2 и выше)

Одно отличие, о котором следует помнить, заключается в том, что в отличие от DBMS_JOB, DBMS_SCHEDULER выполняет фиксацию, что делает его непригодным для некоторых целей. Это также довольно громоздко для более простых требований. Хотя DBMS_JOB больше не будет улучшаться, маловероятно, что она когда-либо будет прекращена, поскольку должны быть тысячи систем, которые используют ее и полагаются на то, как она работает, в том числе не выполняя неявную фиксацию транзакции, из которой она была вызвана.

См. эту тему "Спросите Тома" для большего.

Далее перечислены некоторые преимущества DBMS_SCHEDULER по сравнению с cron:

• Может сделать выполнение задания зависимым от завершения другого задания.

• Надежная балансировка ресурсов и гибкие функции планирования

• Может запускать задания на основе события базы данных

• Синтаксис DBMS_SCHEDULER работает одинаково независимо от операционной системы.

• Может запускать отчеты о состоянии с использованием словаря данных.

• При работе в кластерной среде не нужно беспокоиться о синхронизации нескольких таблиц cron для каждого узла в кластере.

Далее перечислены некоторые преимущества использования cron:

• Простота в использовании, простота, надежность и надежность

• Доступен практически во всех системах Linux/Unix; по большей части работает почти одинаково независимо от платформы Linux/Unix (да, есть небольшие отличия)

• Независимость от базы данных; работает независимо от базы данных и работает одинаково независимо от поставщика базы данных или версии базы данных

• Работает независимо от того, доступна база данных или нет

Я знаю, что это старая тема, но это кажется актуальным.

При обновлении до Oracle Database 19c произойдет преобразование заданий под капотом старого интерфейса DBMS_JOB. Не беспокойтесь – расслабьтесь!

Что просходит? И что это означает для ваших заданий в DBA_JOBS?

Прежде всего, вы не можете предотвратить или пропустить миграцию под контролем планировщика. Но и причин для этого тоже нет.

During the 19c upgrade for each job in DBMS_JOB a corresponding entry will be created with DBMS_SCHEDULER
The old DBMS_JOB interface still works. But using it will always create a corresponding entry in the scheduler
The check in preupgrade.jar is only checking for inconsistencies or any issues

Это означает следующее: вы по-прежнему можете использовать DBMS_JOB, но под прикрытием мы используем DBMS_SCHEDULER. Изменились внутренние процедуры. Ваши вызовы будут работать так же, но DBMS_JOB теперь является устаревшим интерфейсом для DBMS_SCHEDULER.

См.: DBMS_JOB — изменение поведения в Oracle 19c во время обновления