Экстремальное время ожидания при отключении базы данных 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, установите базу данных только для чтения, а затем обратно. Соединения будут закрыты, что освободит замки.
в моем случае был сайт, который имел открытые соединения с базой данных. Этот метод был достаточно прост:
- Правой Кнопкой Мыши базу данных -> свойства -> параметры
- Set
Database Read-Only
истина - нажмите " Да " в диалоговом окне предупреждение SQL Server закроет все подключения к базе данных.
- повторно открыть Параметры и повернуть только для чтения отступить
- теперь попробуйте переименовать базу данных или отключить ее.
для меня мне просто нужно было войти в монитор активности работы и остановить две вещи, которые обрабатывались. Затем он сразу же отключился. В моем случае, хотя я знал, что эти 2 процесса были и что было нормально их остановить.
в моем случае база данных была связана со старой установкой Sharepoint. Остановка и отключение связанных служб в диспетчере серверов "отцепили" действие take offline, которое выполнялось в течение 40 минут, и оно завершилось немедленно.
вы можете проверить, если какие-либо службы в настоящее время используют базу данных.
в следующий раз в диалоговом окне Take Offline не забудьте установить флажок "удалить все активные соединения". Я также был на SQL_EXPRESS на локальной машине без подключений, но это замедление произошло для меня, если я не проверил этот флажок.
Я попробовал все предложения ниже и ничего не получалось.
- exec для процедуры sp_who
убить
-
базы данных изменить набор single_user указан с отката непосредственной
ALTER DATABASE SET OFFLINE С ОТКАТОМ НЕМЕДЛЕННО
результат: обе вышеуказанные команды также застряли.
4 . Щелкните правой кнопкой мыши базу данных -> свойства -> параметры Установить значение True только для чтения базы данных Щелчок "Да" в диалоговом окне предупреждение SQL Server закроет все подключения к базе данных.
результат: окно застряло при выполнении.
в крайнем случае я перезапустил службу SQL server из configuration manager, а затем запустил alter DATABASE SET OFFLINE с немедленным откатом. Это сработало как заклинание