Часто в работе администратора 1С:Предприятие возникает ситуация, когда при попытке обновления конфигурации или выгрузки базы в файл .dt система выдает критическую ошибку «ошибка разделенного доступа к базе данных». При этом стандартные инструменты, такие как консоль администрирования серверов 1С или перезапуск службы агента, не приносят ожидаемого результата — «фантомные» фоновые задания продолжают отображаться в списке активных сеансов.
Давайте разберем по шагам, почему это происходит и как эффективно очистить сервер от таких зависших подключений.
Когда вы видите в консоли кластера сеансы, которые физически не могут существовать (например, служба сервера 1С была полностью остановлена, а соединение с SQL разорвано), это означает, что информация о них сохранена во временных файлах сервера. Эти данные описывают состояние активных пользователей и фоновых заданий в кэше сервера srvinfo.
Если процесс сервера 1С (rphost.exe) завершился аварийно, файлы сеансовых данных не успели удалиться корректно. При последующем запуске службы сервер 1С считывает эти «битые» файлы и считает, что сеанс по-прежнему активен, блокируя монопольный доступ к базе.
Прежде чем приступать к глубокой очистке, необходимо убедиться, что сервер не использует файлы сеансов. Выполним следующие действия:
services.msc).rphost.exe. Иногда бывает, что служба остановлена, но процесс «подвис» в памяти и продолжает держать файлы открытыми.Это самый важный этап решения. Сервер 1С хранит информацию о сеансах в специальных папках, именуемых snccntx. Чтобы найти нужную папку:
C:\Program Files\1cv8\srvinfo\reg_1541\ (путь может отличаться в зависимости от вашего порта кластера).snccntx.snccntx хранятся файлы, описывающие текущие соединения. Удалите содержимое этой папки (или саму папку, сервер создаст ее заново при следующем запуске).Важное примечание: Будьте внимательны! Удаление всей папки srvinfo приведет к потере настроек всех баз данных в консоли кластера, поэтому удаляйте файлы только внутри папки snccntx.
Если после очистки кэша сеансы все еще «видны» в консоли, необходимо проверить, нет ли «потерянных» соединений на стороне SQL Server. Хотя 1С и SQL работают по разным протоколам, иногда сеанс в 1С может удерживать блокировку в таблицах базы данных (например, в таблице _Config или v8users).
Попросите администратора БД проверить текущие подключения к базе 1С. Если вы обнаружили зависшие процессы SQL, которые ссылаются на базу, можно принудительно завершить их командой KILL (будьте крайне осторожны при выполнении этого действия!).
После проведения очистки кэша сеансовых данных запустите службу сервера 1С заново. Теперь консоль администрирования должна показывать пустой список активных сеансов для данной базы.
Чтобы минимизировать подобные риски в будущем, рекомендуем:
srvinfo в реальном времени — это частая причина блокировок файлов.Теперь ваша база данных должна быть свободна от «фантомных» сеансов, и вы сможете беспрепятственно выполнить обновление или выгрузку в .dt.