Проблема задвоения выполнения регламентных заданий в 1С — это сложная коллизия, с которой часто сталкиваются администраторы после аварийного завершения работы сервера, сбоев дисковой подсистемы или некорректного восстановления базы данных из бэкапа. Ситуация выглядит следующим образом: в консоли администрирования задание отображается в единственном экземпляре, однако в «Журнале регистрации» или по результатам работы кода видно, что задание запускается дважды (иногда с разницей в минуту, иногда параллельно). Рассмотрим подробно, почему это происходит и как это исправить.
Прежде чем приступать к радикальным мерам, нам необходимо проанализировать ситуацию и убедиться, что мы имеем дело именно с программным сбоем планировщика, а не с человеческим фактором. Проанализируем «Журнал регистрации». Нам нужно обратить внимание на следующие колонки:
rphost. Если задания выполняются в разных процессах, это может указывать на наличие «зависших» процессов в памяти сервера.Разберем основные способы решения проблемы, начиная от самых простых и заканчивая глубокой очисткой системы.
Как показывает практика и опыт участников обсуждения, самым эффективным и быстрым способом является банальный перезапуск службы 1С:Предприятия. Это связано с тем, что планировщик заданий является частью процесса rmngr (менеджер кластера) и при определенных сбоях его внутренние таблицы в оперативной памяти могут рассинхронизироваться с данными в базе SQL.
Выполним следующие шаги:
1C:Enterprise 8.3 Server Agent через оснастку services.msc.rphost, rmngr и ragent завершены.Если простой перезапуск не помог, проанализируем состояние серверного кэша. Сервер 1С хранит служебную информацию о кластере в каталоге srvinfo (по умолчанию это путь C:\Program Files\1cv8\srvinfo). При некорректном восстановлении файлов базы (например, простым копированием файлов БД обратно на диск после сбоя) данные в файлах .lst и папках с GUID баз могут содержать неактуальные сведения о сеансах и заданиях.
Важно: Перед выполнением этих действий создайте резервную копию папки srvinfo!
Рассмотрим порядок действий по очистке:
reg_1541 внутри srvinfo.snacc и другие временные файлы внутри каталога базы.Рассмотрим ситуацию, когда записи в системных таблицах планировщика внутри SQL-базы конфликтуют с реестром кластера. Поможет метод переподключения базы:
Этот метод заставляет менеджер кластера заново прочитать все метаданные и объекты РегламентныеЗадания из таблицы _Config и пересоздать записи в очередях планировщика.
Для баз большого объема (как в примере — 300 Гб) этот метод трудозатратен, но он гарантирует устранение логических несоответствий на уровне таблиц 1С. При выгрузке в файл .dt система не переносит временные таблицы и мусорные записи из очередей заданий. После загрузки в чистую базу данных структура будет максимально «стерильной».
Проанализируем техническую сторону: в базе данных за регламентные задания отвечают таблицы _ScheduledJobs (сами задания) и _JobQueue (очередь выполнения). При восстановлении базы из бэкапа средствами SQL (или копированием файлов) планировщик может считать, что задание «зависло», и инициировать повторный запуск.
Выясним причину, связанную с версией платформы. В версиях 8.3.11.3034 и соседних релизах наблюдались ошибки планировщика, когда при изменении расписания создавался новый внутренний поток исполнения, а старый не завершался корректно. Если вы используете эту версию, рекомендуется:
Для программной проверки уникальности запущенных заданий можно использовать следующий код, который выведет список всех регламентных заданий и их уникальные идентификаторы:
ВыборкаЗаданий = РегламентныеЗадания.ПолучитьРегламентныеЗадания();
Для Каждого Задание Из ВыборкаЗаданий Цикл
Сообщить("Задание: " + Задание.Метаданные.Имя + " | ID: " + Задание.УникальныйИдентификатор);
Сообщить("Состояние: " + Задание.Состояние + " | Использование: " + Задание.Использование);
КонецЦикла;
Если вы видите, что в списке присутствуют дубли одного и того же метаданного с разными УникальныйИдентификатор, которых нет в консоли, значит, в базе данных присутствуют «битые» ссылки, и поможет только программное удаление лишних объектов через метод Задание.Удалить() или выполнение тестирования и исправления ИБ.
Подводя итог, в большинстве случаев для решения проблемы достаточно полной остановки всех процессов 1С и перезапуска службы. Если это не помогает — приступайте к пересозданию базы в консоли кластера и очистке серверных кэшей.