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

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

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

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

30.04.2009 17:53:15
17 ОТВЕТОВ

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

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

28
30.05.2016 09:36:33
ALTER DATABASE <DBNAME> SET SINGLE_USER с немедленным
u07ch 30.04.2009 18:02:38
KMike - единственное соединение, которое у меня есть, открыто для базы данных Master, а не для базы данных, которую я пытаюсь отключить.
Erik Forbes 30.04.2009 18:04:43

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

Чтобы найти соединения, используйте 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
127
23.01.2012 08:45:17
+1, потому что запрос процесса позволяет узнать, что связано с этой базой данных. в моем случае это был мошенник с открытой
MikeMurko 29.11.2012 22:08:36
В моем случае я был мошенником с открытым окном анализатора запросов
dellyjm 16.06.2015 14:03:59
В моем случае у разработчиков был основной производственный веб-сайт для очень известного банка, указывающего на базу данных, обозначенную OLD
ZZ9 5.04.2016 18:14:57
Если он говорит, что ALTER DATABASE failed because a lock could not be placed on databaseкоманда KILL <SPID>поможет
Muflix 16.09.2016 08:07:31
РЕШЕНИЕ

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

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(Обновить)

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

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

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

EXEC sp_who2

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

KILL <SPID>

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

405
3.02.2016 17:13:24
Если это не работает (блокировка не может быть установлена), попробуйте решение по адресу stackoverflow.com/questions/4673065 .
nalply 12.07.2012 10:04:29
Если процесс Take DB Offline все еще выполняется, для машин-разработчиков вы можете убить его из диспетчера задач и выполнить команду, указанную выше.
Null Head 21.06.2015 23:43:30
Если вы запустите команду KILL и получите сообщение «Невозможно использовать KILL, чтобы убить ваш собственный процесс.», Убедитесь, что вы используете основную базу данных для запуска команды
Jarrod 13.04.2018 12:26:59

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

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

4
30.04.2009 18:25:36
Мудрый совет - спасибо - но в этом случае данные являются расходуемыми, поскольку это база данных разработки, которая восстанавливается.
Erik Forbes 30.04.2009 18:28:50

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

17
20.08.2013 15:02:42

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

2
23.01.2014 13:45:49

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

5
10.12.2014 16:23:13

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

3
25.02.2015 15:52:31

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

0
2.07.2015 12:19:50

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

1
17.08.2015 11:58:33

В моем случае я остановил сервер Tomcat. затем БД немедленно отключилась.

-1
2.12.2015 12:49:23

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

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

  1. Щелкните правой кнопкой мыши базу данных -> Свойства -> Параметры
  2. Установите Database Read-Onlyв True
  3. Нажмите «Да» в диалоговом окне с предупреждением, что SQL Server закроет все подключения к базе данных.
  4. Снова откройте Параметры и снова отключите доступ только для чтения.
  5. Теперь попробуйте переименовать базу данных или перевести ее в автономный режим.
1
1.02.2016 19:24:28

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

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

0
11.08.2016 18:45:21
Запустите, sp_who2чтобы увидеть, какие процессы используют базу данных и использовать, kill <PID>чтобы остановить их.
Eric Kigathi 10.10.2016 23:20:18

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

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

7
24.01.2017 03:16:05

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

3
11.09.2017 15:45:25
То же самое со мной. Затем я переподключился, изменил активную базу данных на master и запустил следующую команду: ALTER DATABASE XXX УСТАНОВИТЬ ОФФЛАЙН С
cskwg 4.03.2020 19:50:25

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

0
19.09.2018 16:51:55

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

  1. EXEC sp_who
  2. Убить <SPID>

  3. ALTER DATABASE SET SINGLE_USER с немедленным откатом

    ALTER DATABASE УСТАНОВЛЕНА В ОФФЛАЙНЕ С НЕМЕДЛЕННОЙ РОЛБЭК

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

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

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

В качестве последнего средства я перезапустил службу сервера SQL из диспетчера конфигурации и затем запустил команду ALTER DATABASE SET OFFLINE WITH ROLLBACK IMMEDIATE. Оно работало завораживающе

2
3.10.2018 09:23:31