Не удалось получить монопольный доступ к базе SQL: что делат

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

Чаще всего это происходит при восстановлении базы из бэкапа, изменении важных параметров базы, переводе базы в другой режим или обслуживании 1С-базы на SQL Server

Содержание

Что означает монопольный доступ
Быстрая диагностика подключений
Безопасный порядок действий
Когда нельзя использовать ROLLBACK IMMEDIATE без подготовки
Если база сразу снова занята
Мини-практика
Частые ошибки
Что почитать дальше по SQL

Что означает монопольный доступ

Монопольный доступ означает, что SQL Server должен временно остаться единственным, кто работает с базой. Если к базе подключены пользователи, приложение, сервис 1С, сайт, агентская задача или окно SSMS, операция может быть заблокирована

Самый частый сценарий:

RESTORE DATABASE sales_db
FROM DISK = 'D:\backup\sales_db.bak'
WITH REPLACE;

SQL Server пытается восстановить базу, но видит, что кто-то еще подключен к sales_db

Быстрая диагностика подключений

Посмотреть активные подключения к базе можно так:

SELECT
    session_id,
    login_name,
    host_name,
    program_name,
    status
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID('sales_db');

Если database_id в этом запросе не показывает ожидаемые строки, можно посмотреть запросы через sys.dm_exec_requests:

SELECT
    r.session_id,
    s.login_name,
    s.host_name,
    s.program_name,
    r.status,
    r.command
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s
    ON r.session_id = s.session_id
WHERE r.database_id = DB_ID('sales_db');

Так можно понять, кто держит базу: пользователь, приложение, 1С, SQL Agent или ваше же окно SSMS

Безопасный порядок действий

Сначала предупредите пользователей и остановите приложение, которое работает с базой. Если это 1С, завершите сеансы и остановите фоновые задания, если они мешают обслуживанию

Затем переведите базу в режим одного пользователя:

ALTER DATABASE sales_db
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;

После этого выполните нужную операцию, например восстановление:

RESTORE DATABASE sales_db
FROM DISK = 'D:\backup\sales_db.bak'
WITH REPLACE;

Когда операция закончится, верните базу в обычный режим:

ALTER DATABASE sales_db
SET MULTI_USER;

Важно не забыть последний шаг. Иначе пользователи не смогут нормально подключаться к базе

Когда нельзя использовать ROLLBACK IMMEDIATE без подготовки

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

Перед применением проверьте, что:

есть актуальная резервная копия
пользователи предупреждены
бизнес-процесс остановлен
вы понимаете, какую базу переводите в SINGLE_USER
после операции вы вернете MULTI_USER

Для рабочей базы лучше делать это в технологическое окно

Если база сразу снова занята

Иногда после SINGLE_USER базу успевает занять не ваш скрипт, а другое приложение или Object Explorer в SSMS. Поэтому перед восстановлением лучше переключиться на master

USE master;
GO

ALTER DATABASE sales_db
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

RESTORE DATABASE sales_db
FROM DISK = 'D:\backup\sales_db.bak'
WITH REPLACE;
GO

ALTER DATABASE sales_db
SET MULTI_USER;
GO

Если вы оставались внутри восстанавливаемой базы, собственное подключение тоже могло мешать операции

Мини-практика

На учебной базе откройте два окна SSMS. В первом выполните простой запрос к базе и оставьте окно открытым. Во втором попробуйте перевести базу в SINGLE_USER

Так вы увидите, что даже обычное подключение может мешать операции обслуживания