Что делать, если 1С:Документооборот не пускает в базу из-за бесконечных фоновых заданий после перемещения?

Рассмотрим ситуацию, которая часто ставит в тупик даже опытных системных администраторов и разработчиков. Представим: вы разворачиваете копию базы 1С:Документооборот 2.1 или переносите рабочую базу на новый сервер. При запуске система выдает стандартный запрос: «Информационная база перемещена или является копией». Если вы выбираете вариант «Это копия», всё работает прекрасно. Но стоит выбрать «База перемещена» (что необходимо для полноценной работы регламентных заданий и внешних интеграций), как система перестает пускать пользователей, а сервер начинает бесконечно крутить фоновые задания, создавая критические блокировки на уровне MS SQL Server.

В этой статье мы подробно разберем, почему это происходит, как связаны «Система взаимодействия» и зависшие транзакции со статусом AWAITING COMMAND, и какими методами можно вернуть базу в строй.

Выясняем причину: почему база блокируется

Проанализируем механику процесса. Когда мы нажимаем кнопку «База перемещена», платформа 1С инициирует ряд процедур по перерегистрации информационной базы. В 1С:Документооборот одной из самых «тяжелых» подсистем в этот момент является Система взаимодействия (обсуждения). Она пытается синхронизировать локальные данные с сервером взаимодействия.

Проблема часто кроется в сочетании конкретной версии платформы (например, 8.3.20.2184) и накопленных данных в очереди обсуждений. В журнале регистрации можно заметить бесконечные записи о выполнении фонового задания, которое обращается к регистру сведений Очередь обновления обсуждений. На уровне SQL-сервера это выглядит как незавершенная транзакция в статусе sleeping / AWAITING COMMAND. Это означает, что процесс 1С открыл транзакцию в базе данных, отправил запрос, но из-за внутреннего бага или ожидания ответа от внешнего сервиса (сервера обсуждений) «завис» и не закрыл транзакцию. В итоге системные таблицы блокируются, и новые пользователи не могут даже пройти аутентификацию (в логах это отображается как «Ошибка аутентификации с пустым пользователем»).

Шаг 1: Принудительное завершение зависших процессов через консоль 1С

Если обычное удаление сеансов через консоль администрирования не помогает, и процессы мгновенно порождают новые фоновые задания, применим метод «мягкой перезагрузки» рабочих процессов. Разберем этот алгоритм:

1. Откроем Консоль администрирования серверов 1С Предприятия.
2. Перейдем в свойства нашего кластера или конкретного рабочего сервера.
3. Установим параметр «Интервал перезапуска» в значение 300 секунд (5 минут). Это заставит систему пометить старые процессы как неактивные и постепенно перенести сеансы на новые.
4. Установим параметр «Выключенные процессы останавливать через» в значение 30 секунд. Это критически важно: так мы заставим операционную систему принудительно убить «зомби-процессы», которые держат транзакции в SQL.
5. После того как зависшие фоновые задания исчезнут, не забудьте вернуть параметры в исходное состояние (обычно это 0).

Шаг 2: Очистка очереди обсуждений и временное отключение системы взаимодействия

Поскольку виновником зацикливания является регистр Очередь обновления обсуждений, нам необходимо очистить его, чтобы фоновые задания перестали «спотыкаться» об одни и те же записи. Выполним следующие действия:

Зайдем в базу в режиме «Это копия» (в этом режиме система взаимодействия блокируется автоматически). Теперь нам нужно программно очистить регистр. Воспользуемся обработкой «Групповое изменение реквизитов» или напишем простой код:

Набор = РегистрыСведений.ОчередьОбновленияОбсуждений.СоздатьНаборЗаписей();
Набор.Записать(); // Записываем пустой набор, тем самым очищая регистр

Также рекомендуется временно полностью отключить систему взаимодействия, чтобы проверить стабильность системы без внешних вызовов. Это можно сделать через Функции для технического специалиста или программно:

Если СистемаВзаимодействия.Поддерживается() Тогда
    СистемаВзаимодействия.Отключить();
КонецЕсли;

Шаг 3: Работа с кэшем и системными таблицами SQL

Иногда очистки регистра недостаточно, так как информация о «битом» сеансе может застрять в серверном кэше или системных таблицах метаданных. Рассмотрим дополнительные меры:

• Очистка серверного кэша: Остановите службу 1C:Enterprise 8.3 Server Agent. Перейдите в папку srvinfo (обычно в C:\Program Files\1cv8\srvinfo) и удалите содержимое папок reg_1541 (кроме файлов конфигурации самого кластера).
• Анализ таблицы ConfigSave: В редких случаях в MS SQL транзакция блокирует таблицу ConfigSave. Проверьте её состояние и убедитесь, что в ней нет «застрявших» конфигураций, которые не были приняты.
• Настройка регламентных заданий: Проанализируйте, не совпадает ли время начала проблем с ночным обслуживанием баз в SQL. Если обслуживание (индексация, обновление статистик) пересекается с интенсивной работой фоновых заданий 1С, это может приводить к взаимным блокировкам (Deadlocks).

Шаг 4: Обновление платформы как радикальное решение

Как показывает практика эксплуатации версии 8.3.20.2184, она имеет внутренние несовершенства в механизме управления блокировками при работе с внешними компонентами. Если вышеописанные шаги помогают лишь временно, и проблема повторяется каждые несколько дней, проанализируем возможность перехода на более стабильную сборку.

Специалисты рекомендуют переходить на релизы ветки 8.3.21 или 8.3.22, где работа с сеансами и их принудительным завершением была существенно переработана. Если вы привязаны к ветке 8.3.20, попробуйте обновиться до последних патчей этой версии (например, 8.3.20.2257 и выше), где исправлены ошибки утечки памяти в фоновых заданиях.

Резюме и рекомендации

Подведем итог. Если ваш 1С:Документооборот «уходит в себя» после подтверждения перемещения базы:

1. Используйте «Интервал перезапуска» в консоли кластера, чтобы убить зависшие процессы 1С, которые держат SQL-транзакции.
2. Зайдите в режиме «Это копия» и очистите РегистрСведений.ОчередьОбновленияОбсуждений.
3. Отключите Систему взаимодействия, если она не используется критически или если сервер обсуждений нестабилен.
4. Проверьте, не запущено ли в этот момент Полнотекстовое индексирование — оно часто конфликтует с обновлением обсуждений.

Помните, что статус AWAITING COMMAND в SQL при наличии открытой транзакции — это всегда сигнал о том, что приложению (1С) не хватило логики для корректного выхода из операции. Тщательный мониторинг регистра обсуждений поможет вам избежать подобных «магических» проблем в будущем.