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

You probably have an alter Database Setting Single User or Admin mode that has a "WITH IMMEDIATE ROLLBACK" in it. That is what is kicking the users out. Take that clause out and it will wait for them to leave (but won't stop new ones from coming in also).

RE: Your Kill sProc: you might want to look at the "WITH IMMEDIATE ROLLBACK" option.

As for preventing new connects: What I've done in the past is to disable the Logins (Server Principal) of the application users, wait up to 10 minutes checking every minute to see if everyone is out. After that I do the ALTER DATABASE...WITH IMMEDIATE ROLLBACK and then onto whatever OPS function needs to be performed.

I've been fortunate in that the Logins were always single-use application user logins (i.e., SQL Logins for this purpose only) If you cannot do that, then the only other thing that I can think of at the moment would be to deny the CONNECT permission to the DB Users (database principal). and then REVOKE the DENY later on. I've never done it like this, but it should go something like:

DENY CONNECT TO SomeDBUserName;

Можно ли перенаправить отчеты на другое имя базы данных? Если да, вы можете создавать снимки базы данных DB2 и запускать отчеты из этих снимков. После каждого восстановления журнала вы создаете новый снимок и помечаете его где-нибудь как «текущий», и все новые отчеты начинают работать с этим снимком. При отправке нового журнала создается новый снимок, и новые отчеты сопоставляются с новым снимком, в то время как старые, работающие отчеты остаются в предыдущем снимке. Когда последний отчет создан со старым снимком и больше нет пользователей, ссылающихся на него, его можно удалить. Таким образом, ни один отчет никогда не прерывается за счет дополнительного хранилища: каждый новый журнал заставляет старый (е) снимок (ы) запускать «копирование при записи» затронутых страниц.

Я предполагаю, что ваше восстановление выполняется как задание. Тогда вам понадобится триггер входа в систему. Вот как вы создаете триггер входа в систему:

Триггеры входа в систему

Триггер входа в систему срабатывает при установлении сеанса. В этот момент возникает событие LOGON.

Жизненный цикл триггера входа в систему очень прост: пользователь подключается к серверу Sql, срабатывает триггер, открывается неявная транзакция, и все зависит от вас! Если по какой-либо причине вы хотите отклонить попытку входа в Sql Server, просто выполните инструкцию ROLLBACK, и все готово.

Вот пример триггера входа в систему:

USE master;
GO
CREATE LOGIN security_login WITH PASSWORD = 'P@ssw0rd'; 
GO
GRANT VIEW SERVER STATE TO security_login;
GO
CREATE TRIGGER connection_deny_trigger
ON ALL SERVER WITH EXECUTE AS 'security_login'
FOR LOGON
AS
BEGIN
<*Your conditional code goes here*>
    ROLLBACK;
END;

Вы можете определить свою работу, которую нужно выполнить это:

• Шаг 1: Включить триггер входа в систему

• Шаг 2: Проверить наличие открытого пользователя подключение к вашей БД отчетности в цикл до 0

   SELECT COUNT (*) из sysprocesses, где spid in (
  ВЫБЕРИТЕ session_id ИЗ sys.dm_exec_sessions, ГДЕ is_user_process = 1) И
  dbid = DB_ID ('База данных вашего отчета')
  

• Шаг 3. Установите для БД однопользовательский режим и восстановите ваши журналы

• Шаг 4. Сбросьте БД на многопользовательский режим и отключите триггер входа в систему

Радж

Требуется ли резервное копирование каждый час, или другой метод репликации будет соответствовать вашим потребностям лучше, чем настраиваемый вами процесс? Вы можете сделать доставку журналов, которую можно настроить на отправку каждый час, и SQL Server позаботится об этом изначально, блокируя пользователей на время восстановления журналов.

Я вижу вашу проблему и не думаю, что SQL Сервер имеет функции, которые вы ищете (блокирование новых подключений, позволяя завершить существующие подключения), но есть и другие обходные пути, которые предоставят вам те же функции репликации и могут лучше удовлетворить ваши бизнес-требования.