Чрезвычайное время ожидания при переводе базы данных SQL Server в автономный режим

Question

Я пытаюсь выполнить автономное обслуживание (восстановление базы данных dev из оперативного резервного копирования) в моей базе данных dev, но команда «Отключить» через SQL Server Management Studio выполняет крайне медленно - на порядка 30 минут плюс сейчас. Я почти сошел с ума и не могу найти в Интернете никаких ссылок на то, что может быть причиной проблемы со скоростью, или как ее исправить.

Некоторые сайты предполагают, что открытые соединения с базой данных вызывают это замедление, но единственное приложение, которое использует эту базу данных, - это экземпляр IIS моей машины разработчика, и служба остановлена ​​- больше нет открытых соединений.

Что может быть причиной этого замедления и что я могу сделать, чтобы ускорить его?

Answer 1

После некоторого дополнительного поиска (новые условия поиска, основанные на ответе gbn и комментарии u07ch на ответ KMike), я нашел это, которое успешно завершилось за 2 секунды:

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(Update)

Если по-прежнему возникает ошибка со следующей ошибкой, вы можете исправить ее, вдохновленную этим сообщением в блоге :

Ошибка ALTER DATABASE, поскольку не удалось установить блокировку для базы данных 'dbname'. Повторите попытку позже.

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

EXEC sp_who2

И используйте то, что SPID вы найдете в следующей команде:

KILL <SPID>

Затем снова введите команду ALTER DATABASE. Теперь он должен работать.

Answer 2

Скорее всего, есть соединение с БД откуда-то (редкий пример: асинхронное обновление статистики )

Чтобы найти соединения, используйте sys.sysprocesses

USE master
SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID('MyDB')

Для принудительного отключения, используйте ОТКЛОНИТЬ НЕМЕДЛЕННО

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Answer 3

Есть ли у вас открытые окна SQL Server Management Studio, подключенные к этой БД?

Переведите его в однопользовательский режим и повторите попытку.

Answer 4

В моем случае, после того, как я так долго ждал его завершения, у меня не хватило терпения и я просто закрыл студию управления. Перед выходом показывало сообщение об успешном завершении, дБ не в сети. Файлы были доступны для переименования.

Answer 5

выполнить хранимую процедуру sp_who2

Это позволит вам увидеть, есть ли какие-либо блокирующие блокировки. Убить их следует исправить.

Answer 6

В SSMS: щелкните правой кнопкой мыши значок сервера SQL, Activity Monitor. Открытые процессы. Найти обработанный связанный. Щелкните правой кнопкой мыши по процессу, Kill.

Answer 7

каждый раз, когда вы сталкиваетесь с подобными вещами, вы всегда должны думать о своем журнале транзакций. Alter db statment с немедленным откатом указывает, что это так. Проверьте это: http://msdn.microsoft.com/en-us/library/ms189085.aspx

Поддерживайте контрольные точки и т. Д. Вы должны решить, стоит ли сохранять транзакции в вашем журнале или нет, а затем выбрать режим для запуска вашей базы данных соответственно. На самом деле нет причин для того, чтобы вам пришлось ждать, но также нет причин для потери данных - вы можете иметь и то и другое.

Answer 8

В моем случае я просмотрел некоторые таблицы в БД до выполнения этого действия. Моя учетная запись удерживала активное соединение с этой БД в SSMS. После того как я отключился от сервера в SSMS (оставив открытым диалоговое окно «Перевести базу данных в автономный режим»), операция прошла успешно.

Answer 9

Закрытие экземпляра SSMS (SQL Service Manager), из которого был сделан запрос, решил проблему для меня .....

Answer 10

Чтобы обойти это, я остановил веб-сайт, который был подключен к БД в IIS, и сразу же «замороженная» панель «Отключить БД в автономном режиме» стала разблокированной.