Не обновляется статус BatchJob после завершения

[samolalex]

Коллеги, добрый день.

В АХ2009 последние несколько дней наблюдаю странную ситуацию - в пакетных заданиях статус Batch переходит в "Завершено", а статус "BatchJob" зависает на неопределнное время в "Выполнение".

Особенности ситуации:
1. В БД при этом нет блокировок
2. Ситуация касается не отдельных пакетных заданий, а всех
3. Ситуация возникает время от времени - день работает нормально -> зависание -> далее снова какое-то время работает нормально и так далее. Закономерности четкой нет.
4. Если обновить статус пакетного задания точечно в "Отмена", а затем в "Ожидание", то он снова нормально стартует и продолжает нормально работать неопределенное время
5. Ситуация может разрешиться сама собой - т.е. пакеты снова массово переходят в статус "Ожидание" и далее по кругу.
6. На BatchJob в свойствах таблицы убрал кэширование

Сталкивался ли кто-нибудь с подобным?
Если да, то как решили данную ситуацию?
На что следует обратить внимание при решении ситуации, "куда смотреть"?

Спасибо.

[Logger]

Предлагаю пересоздать индексы.
А дальше внимательно курить методы класса batchrun, переводящие статусы.

[Logger]

Повспоминать, что могло в бд поменяться при смене сервера.
Версия винды. Какие то обновления sql?

[trud]

Статус завершается вроде бы отдельным обработчиком. Может у вас просто не хватает потоков(они все заняты чем-то).
Можно попробовать увеличить "Максимальное число потоков в пакетном задании" в конфигурации сервера

[Raven Melancholic]

Александр, стоит посмотреть нет ли ожидания работы SP_GETAPPLOCK (у нас, точнее теперь у вас, он логируется).
Там же где пакетные задачи есть запрос об ожиданиях разрешения на запуск. Большие ли там ожидания для процесса, в имени которого есть FinishedJobs?

[samolalex]

Алексей, спасибо. Проверил по логу интервалы времени возникновения зависаний.
Ожиданий работы SP_GETAPPLOCK в это время нет.

[Raven Melancholic]

Тогда, возможно, стоит помониторить как работает метод класса

BatchRun::serverProcessFinishedJobs

То есть, записывать в какой-либо лог в отдельной транзакции момент, когда выполнение проходит дальше, чем проверка:

Цитата:

if(!shouldProcess)
return;

Соответственно, если проходим дальше примерно раз в минуту-другую, то проблемы где-то далее, а вот если не проходим, то попробовать логировать места, в которых идет работа в начале метода с batchGlobal в тех местах, в которых в итоге не устанавливается shouldProcess = true, то есть в двух catch и сделать ветку else для проверки LastProcFinishedJobs с записью в этот лог.
Возможно, стоит в лог писать данные о значении thisDate и batchGlobal.LastProcFinishedJobs.
Поятно, что логирование работы с bacthGlobal имеет смысл делать, если будет понятно, что дело в срабатывании if(!shouldProcess).
PS: в любом случае, метод вызывается часто, поэтому записей в логе будет много, нужно будет чистить его время от времени.

[ice321i]

Может у вас появились пакетные задания с BatchConstraint? Попробуйте удалить записи из этой таблицы в момент закипания статуса пакетов.

[Товарищ ♂uatr]

Добрый день.
Была аналогичная проблема. Поскольку BatchGlobal обновляется в отдельной транзакции - он всегда содержит данные, "якобы" метод уже обновил всю необходимую информацию. Хотя на самом деле выполнение кода "оборвалось" на какой-либо вставке записей в таблицы истории.

[Pokersky09]

У меня бывало, что:
1) Если при работе пакетного задания запустить пересборку цила, то пакетник зависал (навсегда). Связано это с тем что сервисы отключаются при этом, и уже нормально не подхватывается пакет после такого.
Спасало только полная очистка всех строк пакетника (таблица вроде Batch), либо обновление статуса вручную (джобом).

2) Бывает что когда одновременно много потоков (один или несколько пакетников работает), и в каждом потоке есть большой инфолог (который пакуется в batch поле таблицы), то возникали блокировки на уровне SQL, так как по факту могут быть большие объемы данных, и SQL физически не успевал все делать. Но этот способ легко ловить обычным sp_whoisactive на sql.

P.s. Возможно у вас что-то иное, делюсь своими кейсами.