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

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

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

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

17 ответов


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

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(обновить)

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

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

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

EXEC sp_who2

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

KILL <SPID>

запустить снова. Теперь это должно сработать.


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

чтобы найти соединения, используйте sys.ѕуѕргосеѕѕеѕсистемная

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

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

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

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

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


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


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

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


в SSMS: щелкните правой кнопкой мыши значок SQL server, Монитор активности. открытый процесс. Найдите обработанное подключенное. Щелкните правой кнопкой мыши на процессе, Kill.


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

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


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


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


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


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


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

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

  1. Правой Кнопкой Мыши базу данных -> свойства -> параметры
  2. Set Database Read-Only истина
  3. нажмите " Да " в диалоговом окне предупреждение SQL Server закроет все подключения к базе данных.
  4. повторно открыть Параметры и повернуть только для чтения отступить
  5. теперь попробуйте переименовать базу данных или отключить ее.

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


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


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

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


в следующий раз в диалоговом окне Take Offline не забудьте установить флажок "удалить все активные соединения". Я также был на SQL_EXPRESS на локальной машине без подключений, но это замедление произошло для меня, если я не проверил этот флажок.


Я попробовал все предложения ниже и ничего не получалось.

  1. exec для процедуры sp_who
  2. убить

  3. базы данных изменить набор single_user указан с отката непосредственной

    ALTER DATABASE SET OFFLINE С ОТКАТОМ НЕМЕДЛЕННО

    результат: обе вышеуказанные команды также застряли.

4 . Щелкните правой кнопкой мыши базу данных -> свойства -> параметры Установить значение True только для чтения базы данных Щелчок "Да" в диалоговом окне предупреждение SQL Server закроет все подключения к базе данных.

результат: окно застряло при выполнении.

в крайнем случае я перезапустил службу SQL server из configuration manager, а затем запустил alter DATABASE SET OFFLINE с немедленным откатом. Это сработало как заклинание