Иногда при администрировании серверов 1С возникает неприятная ситуация: в информационной базе «зависает» фоновое задание. Оно невидимо в стандартной консоли администрирования, но активно мешает выполнять важные операции, например, обновить конфигурацию. При попытке реструктуризации базы система сообщает об ошибке разделенного доступа и указывает на наличие активного фонового задания. Разберем по шагам, как можно решить эту проблему.
Проанализируем типичные симптомы:
Такое поведение обычно указывает на то, что рабочий процесс сервера 1С (rphost) некорректно завершил операцию, но продолжает удерживать соединение с СУБД. Это может быть вызвано ошибками в коде, бесконечным ожиданием ответа от внешнего ресурса без таймаута или «залипанием» транзакции на стороне SQL Server. Рассмотрим несколько методов борьбы с таким «фантомом», двигаясь от самых простых к более радикальным.
Самый простой и часто эффективный способ — перезапустить службу агента сервера 1С. Однако здесь есть важный нюанс: простая команда «Перезапустить» (Restart) иногда не помогает. Процесс может не успеть корректно завершиться. Поэтому действуем по более надежной схеме:
services.msc).Такой «жесткий» перезапуск принудительно обрывает все соединения и процессы, включая зависшее задание.
Если простой перезапуск не помог, проблема может быть в поврежденных файлах кэша сеансовых данных на сервере. В этом случае совмещаем перезапуск с очисткой кэша. Этот метод сбрасывает всю информацию об активных сеансах, не затрагивая данные в базе.
C:\Program Files\1cv8\srvinfo\reg_1541\. Внутри этого каталога будет папка с длинным буквенно-цифровым именем (GUID кластера), а в ней — папка snccntx.snccntx. Не удаляйте саму папку, только файлы внутри нее.После запуска служба пересоздаст необходимые файлы кэша, и «фантомный» сеанс должен исчезнуть.
Иногда соединение «зависает» именно на уровне СУБД. Сервер 1С может считать, что сеанс завершен, но SQL Server продолжает удерживать транзакцию или блокировку. В этом случае можно принудительно завершить сеанс, относящийся к нашей базе, напрямую из SQL Server Management Studio.
Для этого выполните следующий T-SQL скрипт. Будьте осторожны, так как он принудительно завершит все активные подключения к указанной базе данных, что приведет к аварийному завершению работы всех пользователей этой базы.
master.'ИмяБазыТут' на имя вашей проблемной базы данных:
USE [master];
GO
DECLARE @kill varchar(8000) = '';
SELECT @kill = @kill + 'kill ' + CONVERT(varchar(5), session_id) + ';'
FROM sys.dm_exec_sessions
WHERE database_id = db_id('ИмяБазыТут')
EXEC(@kill);
GO
Этот скрипт формирует и выполняет команду KILL для каждого идентификатора сессии (session_id), подключенной к указанной базе. После его выполнения все соединения будут разорваны, и вы сможете произвести обновление.
Это самый радикальный метод, который стоит применять, если ничего из вышеперечисленного не помогло. Он заключается в принудительном завершении процесса rphost.exe, который обслуживает зависшее задание, через Диспетчер задач Windows.
Важно: если у вас не настроена изоляция информационных баз по отдельным рабочим процессам (функциональность, требующая лицензии КОРП на современных платформах), то один процесс rphost может обслуживать сеансы нескольких баз и множества пользователей. Его завершение приведет к аварийному разрыву соединения у всех, кто работал через этот процесс.
Порядок действий:
rphost.exe.rphost.exe.После завершения процесса менеджер кластера (rmngr) автоматически перезапустит его, и пользователи смогут подключиться заново. Зависшее задание при этом будет уничтожено.
В заключение, отметим, что такие «фантомные» задания часто являются следствием ошибок в коде конфигурации (например, обращение к внешним ресурсам без установленного таймаута) или нестабильной работы платформы. После устранения последствий стоит попытаться выяснить причину с помощью технологического журнала (ТЖ), чтобы предотвратить повторение проблемы в будущем.