Здравствуйте, все.
Прошу откликнуться тех, кто может пролить свет на некоторые вопросы.
Есть базы с job'ами, которые иногда не срабатывают. Настроены эти job'ы на запуск 1 раз в сутки (INTERVAL — SYSDATE+1). Если попытка обновления таблицы прошла неудачно, то через некоторое время (не через сутки, а через 1,2,3...6 часов или минут) job попытается запуститься снова (NEXT_DATE). После 15 неудачных попыток (или ошибок FAILURES) job автоматом отключается (Disabled). В связи с этим возникают вопросы:
1) Как уменьшить (ЭТО!) количество попыток в сутки
2) Как увеличить допустимое количество FAILURES (чтобы сделать больше 15)
Заранее спасибо.

Здравствуйте, stanislove, Вы писали:

S>Есть базы с job'ами, которые иногда не срабатывают. Настроены эти job'ы на запуск 1 раз в сутки (INTERVAL — SYSDATE+1). Если попытка обновления таблицы прошла неудачно, то через некоторое время (не через сутки, а через 1,2,3...6 часов или минут) job попытается запуститься снова (NEXT_DATE). После 15 неудачных попыток (или ошибок FAILURES) job автоматом отключается (Disabled). В связи с этим возникают вопросы:
S>1) Как уменьшить (ЭТО!) количество попыток в сутки
S>2) Как увеличить допустимое количество FAILURES (чтобы сделать больше 15)

http://www.jlcomp.demon.co.uk/faq/dbms_job.html

7# Errors / Broken jobs

If a job fails, an entry is written to the alert log and a user trace file is created. Since we are all monitoring our alert log anyway (aren't we?!), monitoring job failure is relatively straightforward. The job is retried in 1 minute (if your execution interval was originally set to being greater than 1 minute), and then Oracle uses an binary exponential backoff algorithm until such stage as the backoff interval exceeds the original job submission interval.

If a job fails 16 times in succession, then it gets marked as BROKEN and it will no longer execution automatically. Whilst 16 times may sound fine, if your schedule is every 10 seconds, then all you need is 160 seconds worth of problems and your job is dead. Some options that can be used to avoid jobs getting into this state are:

* A second job that looks every 'n' minutes for jobs marked as broken with 16 failures, and tries to re-run them. (If a broken job can be run successfully, then it is no longer considered broken).
* Build your own binary exponential backoff routine into the job processing itself. When the job fails, double the execution interval using DBMS_JOB.CHANGE and then raise the error. In this way, you are giving the job more time to rectify itself.

если кто задвинет чего полезного — тоже буду признателен.
вопрос состоит в том, как поправить уже существующее, или как переделать плохо работающее? по второму поводу можно поговорить. во

Здравствуйте, stanislove, Вы писали:

S>1) Как уменьшить (ЭТО!) количество попыток в сутки
S>2) Как увеличить допустимое количество FAILURES (чтобы сделать больше 15)

http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/jobq.htm#7860

If a job returns an error while Oracle is attempting to execute it, Oracle tries to execute it again. The first attempt is made after one minute, the second attempt after two minutes, the third after four minutes, and so on, with the interval doubling between each attempt. If the job fails 16 times, Oracle automatically marks the job as broken and no longer tries to execute it. However, between attempts, you have the opportunity to correct the problem that is preventing the job from running. This will not disturb the retry cycle, and Oracle will eventually attempt to run the job again.

http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/jobq.htm#1135

When you submit a job it is considered not broken.
There are two ways a job can break:
* Oracle has failed to successfully execute the job after 16 attempts.

http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/jobq.htm#1175

If a problem has caused a job to fail 16 times, Oracle marks the job as broken.

интересно. узнал много нового.
p.s. переходите на DBMS_SCHEDULER. bo