Как исправить ошибку «не удалось получить монопольный доступ, так как база данных используется» при восстановлении базы MS SQL?

При обслуживании и тестировании клиент-серверных баз 1С часто возникает задача развернуть резервную копию рабочей базы в существующую тестовую. Нередко в процессе восстановления через среду SQL Server Management Studio (SSMS) процесс останавливается с ошибкой: «не удалось получить монопольный доступ, так как база данных используется» (Exclusive access could not be obtained because the database is in use). При этом в консоли «Администрирование серверов 1С:Предприятия» список сеансов и соединений к этой информационной базе может быть абсолютно чистым.

Разберем детально, почему так происходит и какими способами можно гарантированно освободить базу для успешного наката бэкапа.

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

Проанализируем техническую сторону взаимодействия платформы 1С и СУБД MS SQL Server. Существует три основных источника скрытых блокировок:

1. Пул соединений кластера 1С (Connection Pooling). Рабочие процессы сервера 1С (rphost) удерживают физические TCP-соединения с MS SQL даже после того, как все пользователи вышли, а сеансы завершились. Пул соединений предназначен для оптимизации производительности, чтобы не тратить ресурсы на повторную авторизацию при новых запросах. С точки зрения MS SQL эти коннекты являются активными, что препятствует получению монопольного доступа.
2. Собственные сессии в среде SSMS. Если в SQL Server Management Studio открыта вкладка с редактором запросов, в контексте которой выбрана восстанавливаемая база (или ранее выполнялась команда USE test), среда сама удерживает монопольную блокировку. Также блокировать базу может развернутое дерево таблиц в обозревателе объектов (Object Explorer).
3. Фоновые службы и регламентные задания. К базе могут обращаться фоновые задания SQL Server Agent, службы резервного копирования сторонних вендоров, службы мониторинга или антивирусное ПО.

Способ 1. Использование встроенных параметров мастера восстановления SSMS

Если восстановление выполняется через графический интерфейс Management Studio, рассмотрим параметры, позволяющие сбросить коннекты автоматически:

1. В окне мастера «Восстановить базу данных» перейдем на вкладку «Параметры» (Options).
2. Установим флаг «Перезаписать существующую базу данных (WITH REPLACE)».
3. Обязательно установим флаг «Закрыть существующие соединения с целевой базой данных» (Close existing connections to destination database). Этот параметр переводит базу данных в однопользовательский режим перед накатом копии и принудительно обрывает пользовательские подключения.
4. Проверим состояние пункта «Создать резервную копию заключительного фрагмента журнала перед восстановлением» (Take tail-log backup before restore). Для тестовой базы этот флаг необходимо снять, так как попытка зафиксировать хвост журнала часто блокирует процедуру перезаписи.

Способ 2. Принудительный сброс соединений и накат бэкапа через T-SQL (рекомендуемый)

Посмотрим на более надежный и быстрый способ, исключающий необходимость вручную искать сессии через sp_who и сбрасывать их командой KILL. Переведем базу в монопольный режим одной командой с немедленным откатом незавершенных транзакций (WITH ROLLBACK IMMEDIATE).

Откроем новое окно запроса (убедившись, что контекстом выбрана база master) и выполним следующий сценарий:

USE master;
GO

-- Принудительно отключаем все процессы от базы test
ALTER DATABASE [test] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Выполняем восстановление с перезаписью файлов
RESTORE DATABASE [test] 
FROM DISK = 'C:\Backup\work_db.bak' 
WITH REPLACE, RECOVERY;
GO

-- Возвращаем многопользовательский режим
ALTER DATABASE [test] SET MULTI_USER;
GO

Конструкция ROLLBACK IMMEDIATE мгновенно разрывает открытые пулы соединений рабочих процессов 1С и любые зависшие сеансы, после чего процедура накатывания бэкапа проходит без ошибок монопольного доступа.

Способ 3. Завершение сессий через консоль и службу 1С

Разберем, как корректно разорвать соединения на стороне сервера приложений 1С, если нет возможности вмешиваться в скрипты СУБД:

1. В консоли «Администрирование серверов 1С:Предприятия» в свойствах информационной базы установим параметры Блокировка начала сеансов включена и Блокировка регламентных заданий включена.
2. Если пул соединений в процессах rphost продолжает удерживать порт, выполним перезапуск службы агента сервера 1С (1C:Enterprise Server Agent) через оснастку служб Windows. Перезапуск службы гарантированно освободит все удерживаемые таблицы и файлы СУБД.
3. Альтернативный вариант — временно удалить регистрацию информационной базы из кластера серверов 1С (без удаления самой базы на сервере баз данных), выполнить накат бэкапа в SQL Server и затем снова добавить базу в кластер 1С.

Важные действия после восстановления боевой базы в тестовую

Проанализируем сопутствующие настройки, о которых важно помнить после успешного восстановления:

1. Сопоставление пользователей СУБД (Orphaned Users). Если информационная база 1С подключается к MS SQL под отдельным пользователем базы данных, а не под учетной записью sa, после перезаписи идентификаторы безопасности (SID) разойдутся. Чтобы восстановить сопоставление пользователя с логином уровня сервера, выполним команду:
   Скопировать код

   
   USE [test];
   ALTER USER [db_user_1c] WITH LOGIN = [db_user_1c];
   

2. Безопасность первого запуска 1С. В развернутой копии сохраняются настройки обменов, рассылок, интеграций с банками и внешними сервисами. Перед запуском обязательно убедимся, что регламентные задания в консоли кластера 1С отключены, а при первом входе пользователей в режиме предприятия подтвердим статус «Это копия информационной базы» для автоматической блокировки работы с внешними ресурсами.