В практике администрирования серверных решений на базе 1С:Предприятие 8.3 иногда возникает критическая ситуация: регламентное задание, которое было удалено в Конфигураторе или отключено в консоли, продолжает самопроизвольно запускаться. Это приводит к дублированию рассылок, повторному формированию документов или избыточной нагрузке на сервер. В данной статье мы разберем причины возникновения таких «призрачных» заданий и рассмотрим пошаговые алгоритмы их полного устранения. Для выявления лишних операций в учёте, возникших из-за дублирования процессов, применяется программа для автоматической сверки бухгалтерских проводок между базами 1С.
Прежде чем переходить к радикальным мерам, давайте проанализируем ситуацию. Почему задание продолжает работать, если его нет в дереве метаданных? Чаще всего это происходит из-за аварийного завершения работы сервера 1С или СУБД (например, при нехватке оперативной памяти). В такие моменты нарушается целостность связи между метаданными (описанием задания в конфигурации) и физической записью в системных таблицах базы данных.
Рассмотрим основные факторы, способствующие возникновению ошибки:
rphost) кэшируют список заданий. Если кэш поврежден, процесс может инициировать запуск фонового задания по старому, уже несуществующему идентификатору.Стандартные консоли заданий часто фильтруют список, показывая только те объекты, которые связаны с текущими метаданными. Чтобы увидеть полную картину, воспользуемся программным методом. Проанализируем список всех заданий, зарегистрированных в информационной базе, включая те, у которых нет соответствия в Конфигураторе.
Для этого создадим внешнюю обработку и выполним следующий код:
Выборка = РегламентныеЗадания.ПолучитьРегламентныеЗадания();
Для Каждого Задание Из Выборка Цикл
Сообщить("Имя: " + Задание.Метаданные.Имя + " | ID: " + Задание.УникальныйИдентификатор);
// Если вы нашли лишнее задание, его можно удалить программно:
// Задание.Удалить();
КонецЦикла;
Использование метода РегламентныеЗадания.ПолучитьРегламентныеЗадания() позволяет выгрузить абсолютно все записи из системной таблицы _ScheduledJobs. Если в цикле вы обнаружите идентификатор задания, которое вы уже удалили в дереве метаданных, используйте метод Удалить(). Это самый безопасный способ очистки. Для управления фоновыми и регламентными заданиями без написания кода можно использовать обработку для работы с регламентными и фоновыми заданиями.
Если программный метод не выдает результатов, но процедура все равно выполняется, выясним, кто именно инициирует запуск. Проанализируем Журнал регистрации. Особое внимание уделим колонке «Фоновое задание». Даже если регламентное задание удалено, создаваемое им фоновое задание будет зафиксировано. По идентификатору фонового задания можно определить, какой рабочий процесс его породил.
Также стоит проверить сторонние источники вызовов. Рассмотрим вероятность того, что процедура вызывается не внутренним планировщиком, а внешним соединением:
Если отладчик не останавливается на точках останова (даже при включенной отладке на сервере и остановке по ошибке), это верный признак того, что процесс выполняется в специфическом окружении. Разберем, как настроить Технологический журнал (ТЖ) для отслеживания вызовов.
Создайте файл logcfg.xml в папке настроек conf сервера 1С. Включите сбор событий фоновых заданий JOB и обращений к базе данных SDBL. Это позволит точно зафиксировать момент старта процесса, его UUID и текст запроса к SQL-таблице заданий. Проанализируем полученные логи: там будет указан конкретный номер рабочего процесса rphost, который «помнит» старое задание.
Если программные методы не помогли, перейдем к радикальным мерам очистки. Этот этап требует остановки службы сервера 1С:Предприятие. В ходе таких технических работ применяется инструмент для автоматического архивирования, обновления и тестирования баз 1С.
Очистка серверного кэша:
1C:Enterprise 8.3 Server Agent.srvinfo (обычно это C:\Program Files\1cv8\srvinfo).snacc и reg_1541. Также удалите временные файлы кэша.Работа с таблицами базы данных на уровне SQL:
Разберем ситуацию, когда запись «зависла» непосредственно в таблице СУБД. В 1С регламентные задания хранятся в таблице с префиксом _ScheduledJobs. Внимание! Прямое редактирование таблиц SQL не поддерживается фирмой «1С» и может привести к потере данных. Выполняйте эти действия только после создания резервной копии!
Выясним причину дублирования: если в таблице _ScheduledJobs присутствуют записи, не имеющие аналогов в таблице метаданных Config, их необходимо вычистить. После ручного удаления записей из SQL-таблицы обязательно выполните Тестирование и исправление (ТИИ) в режиме Конфигуратора с включенными опциями «Проверка логической целостности» и «Очистка пустых значений».
Рассмотрим еще один лайфхак, помогающий при рассинхронизации. Если процедура все равно вызывается, попробуйте изменить ее сигнатуру (имя или количество параметров) в Конфигураторе и выполнить полное (не динамическое!) обновление базы данных. Платформа будет вынуждена обновить связи в таблице Config. После этого «призрачное» задание, пытаясь вызвать старую процедуру, завершится с ошибкой, которая наконец-то отобразится в Журнале регистрации, и вы сможете окончательно идентифицировать источник проблемы.
Подводя итог, отметим, что наиболее эффективным методом является комбинация программного удаления через РегламентныеЗадания.ПолучитьРегламентныеЗадания() и полной очистки серверного кэша с перезагрузкой службы. Это гарантированно убирает фантомные процессы и восстанавливает нормальную работу планировщика заданий.