ALTER DATABASE не вдалося, оскільки блокування не вдалося розмістити в базі даних

Мені потрібно перезапустити базу даних, оскільки деякі процеси не працюють. Мій план - знову перенести його в режим офлайн та повернутись в Інтернет.

Я намагаюся зробити це в Sql Server Management Studio 2008:

use master;
go
alter database qcvalues
set single_user
with rollback immediate;
alter database qcvalues
set multi_user;
go

Я отримую ці помилки:

Msg 5061, Level 16, State 1, Line 1
ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
Msg 5061, Level 16, State 1, Line 4
ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later.
Msg 5069, Level 16, State 1, Line 4
ALTER DATABASE statement failed.

Що я роблю неправильно?

Після отримання помилки запустіть

EXEC sp_who2

Шукайте базу даних у списку. Можливо, що з'єднання не було розірвано. Якщо ви знайшли якісь з'єднання з базою даних, запустіть

KILL <SPID>

де <SPID>SPID для сеансів, підключених до бази даних.

Спробуйте свій сценарій після видалення всіх підключень до бази даних.

На жаль, у мене немає причини, чому ви бачите проблему, але ось посилання, яке показує, що проблема трапилася в іншому місці.

http://www.geakeit.co.uk/2010/12/11/sql-take-offline-fails-alter-database-failed-berely-a-lock-could-not-error-5061/

Мені вдалося відтворити цю помилку, виконавши наступне.

Підключення 1 (залиште працювати пару хвилин)

CREATE DATABASE TESTING123
GO

USE TESTING123;

SELECT NEWID() AS X INTO FOO
FROM sys.objects s1,sys.objects s2,sys.objects s3,sys.objects s4 ,sys.objects s5 ,sys.objects s6

З'єднання 2 і 3

set lock_timeout 5;

ALTER DATABASE TESTING123 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

Спробуйте це, якщо він "переходить" ...

http://learnmysql.blogspot.com/2012/05/database-is-in-transition-try-statement.html

USE master
GO

ALTER DATABASE <db_name>

SET OFFLINE WITH ROLLBACK IMMEDIATE
...
...
ALTER DATABASE <db_name> SET ONLINE

Я додам це сюди, якщо хтось пощастить мені.

Переглядаючи список sp_who2 процесів, зверніть увагу на процеси, які виконуються не тільки для бази даних, що працює, але і для головного . У моєму випадку проблема, що блокувала базу даних, була пов'язана із збереженою процедурою, яка запустила xp_cmdshell.

Перевірте, чи є якісь процеси у стані KILL / RollBack для основної бази даних

SELECT *
FROM sys.sysprocesses
WHERE cmd = 'KILLED/ROLLBACK'

Якщо у вас є та сама проблема, просто команда KILL, ймовірно, не допоможе. Ви можете перезапустити SQL-сервер, а ще краще - знайти cmd.exe під Windows процесами на ОС SQL-сервера та вбити його.

У студії управління SQL перейдіть у розділ Безпека -> Логіни та двічі клацніть свій Логін. Виберіть «Ролі сервера» у лівій колонці та перевірте, чи встановлено прапорець sysadmin.

У моєму випадку я ввійшов у акаунт без цього привілею.

HTH!

Вбивство ідентифікатора процесу добре працювало для мене. Запускаючи команду "EXEC sp_who2" над новим вікном запиту ... і фільтруючи результати за "зайнятою" базою даних, вбиваючи процеси за допомогою команди "Убити" вдалося виконати трюк. Після цього всі знову працювали.

Тільки щоб додати мої два центи. Я поставив себе в ту ж ситуацію, шукаючи мінімально необхідні привілеї для входу в db для успішного запуску оператора:

ALTER DATABASE ... SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Здається, що оператор ALTER успішно завершується , коли виконується з входом у систему sysadmin , але він вимагає частини очищення з'єднань, коли виконується під логіном, який має "лише" обмежені дозволи, наприклад:

ALTER ANY DATABASE

PS Я витрачав години, намагаючись з'ясувати, чому "ALTER DATABASE .." не працює, коли виконується під логіном, який виконує роль dbcreator + ВІДПОВІДЬ будь-яких привілеїв DATABASE . Ось мій потік MSDN !

Я знаю, що це старий пост, але нещодавно я зіткнувся з дуже подібною проблемою. На жаль, я не зміг використати жодну команду бази даних alter, оскільки не вдалося встановити ексклюзивний замок. Але мені так і не вдалося знайти відкрите з'єднання з db. Зрештою, мені довелося насильно видалити стан здоров'я бази даних, щоб змусити її відновити стан замість відновлення.

У рідкісних випадках (наприклад, після здійснення важкої транзакції) запущений системний процес CHECKPOINT, що тримає блокування FILE у файлі бази даних, перешкоджає переходу в режим MULTI_USER.

У моєму сценарії не було жодного процесу, який блокував базу даних під програмою sp_who2. Однак ми виявили, що база даних набагато більша, ніж інші наші бази даних, що процеси, що очікують, все ще запущені, тому база даних у групі доступності все ще відображається як червоний / офлайн після того, як ми спробували «відновити дані», клацнувши правою кнопкою миші на призупиненій базі даних.

Щоб перевірити, чи є у вас все ще запущені процеси, просто виконайте цю команду: виберіть відсоток завершений з sys.dm_exec_requests, де posto_complete> 0