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

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

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

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

Ответ 1

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

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(Обновление)

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

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

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

EXEC sp_who2

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

KILL <SPID>

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

Ответ 2

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

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

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

Чтобы принудительно отключить, используйте ROLLBACK IMMEDIATE

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

Чтобы обойти это, я остановил сайт, который был подключен к db в IIS, и сразу же "замороженная" панель "db offline" стала незамеренной.

Ответ 9

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

Ответ 10

Кроме того, закройте все окна запросов, которые могут быть открыты, которые подключены к соответствующей базе данных;)

Ответ 11

В SSMS установите базу данных только для чтения, а затем обратно. Соединения будут закрыты, что освобождает блокировки.

В моем случае был веб-сайт с открытыми подключениями к базе данных. Этот метод был достаточно простым:

Щелкните правой кнопкой мыши базу данных → Свойства → Параметры
Установите Database Read-Only в True
Нажмите "Да" в диалоговом предупреждении, что SQL Server закроет все подключения к базе данных.
Повторно откройте параметры и отключите функцию "только для чтения".
Теперь попробуйте переименовать базу данных или отключить ее.

Ответ 12

Для меня мне просто нужно было войти в Монитор активности работы и остановить две вещи, которые обрабатывались. Затем он сразу отключился. В моем случае, хотя я знал, что эти 2 процесса были и что было нормально их остановить.

Ответ 13

В моем случае я остановил сервер Tomcat. затем сразу же DB отключился.

Ответ 14

В моем случае база данных была связана со старой установкой Sharepoint. Остановка и отключение связанных сервисов в диспетчере серверов "отменил" действие офлайн-действия, которое выполнялось в течение 40 минут, и оно было немедленно завершено.

Вы можете проверить, действительно ли какие-либо службы используют базу данных.

Ответ 15

В моем случае я просмотрел некоторые таблицы в БД до выполнения этого действия. Моя учетная запись пользовалась активным подключением к этой БД в SSMS. Как только я отключился от сервера в SSMS (оставив диалоговое окно "Take database offline" ), операция завершилась успешно.