Вихід з режиму для одного користувача

Наразі моя база даних перебуває в режимі одиночного користувача. Коли я намагаюся розширити базу даних, я отримую помилку:

База даних "my_db" недоступна. (ObjectExplorer)

Крім того, коли я намагаюся видалити базу даних, я отримую помилку:

Наразі зміни стану або параметрів бази даних "my_db" неможливо внести. База даних знаходиться в режимі однокористування, і користувач наразі підключений до неї.

Як вийти з режиму однокористування? У мене немає жодного користувача, який використовує цю базу даних.

Коли я намагаюся переглядати свій сайт за допомогою IIS, я отримую помилку:

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

Я відчуваю, ніби однокористувацький режим викликає це.

SSMS взагалі використовує кілька підключень до бази даних за кадром.

Перед тим, як змінити режим доступу, вам потрібно буде перервати ці з'єднання.

По-перше, переконайтеся, що провідник об’єктів вказаний на системну базу даних, наприклад, на головну.

По-друге, виконайте sp_who2 і знайдіть всі підключення до бази даних 'my_db'. Вбийте всі з'єднання, зробивши KILL { session id }там, де SPIDвказано ідентифікатор сеансу sp_who2.

По-третє, відкрийте нове вікно запитів.

Виконайте наступний код.

-- Start in master
USE MASTER;

-- Add users
ALTER DATABASE [my_db] SET MULTI_USER
GO

Дивіться мою статтю в блозі про керування файлами баз даних. Це було написано для переміщення файлів, але управління користувачами те саме.

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

Потім запустіть наступне, T-SQLщоб перевести базу даних у MULTI_USERрежим.

USE master
GO
DECLARE @kill varchar(max) = '';
SELECT @kill = @kill + 'KILL ' + CONVERT(varchar(10), spid) + '; '
FROM master..sysprocesses 
WHERE spid > 50 AND dbid = DB_ID('<Your_DB_Name>')
EXEC(@kill);

GO
SET DEADLOCK_PRIORITY HIGH
ALTER DATABASE [<Your_DB_Name>] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [<Your_DB_Name>] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

Щоб вимкнути режим "Єдиний користувач", спробуйте:

ALTER DATABASE [my_db] SET MULTI_USER

Щоб повернутися до режиму одиночного користувача, ви можете використовувати:

ALTER DATABASE [my_db] SET SINGLE_USER

1. Клацніть правою кнопкою миші вашу базу даних у розділі баз даних
2. Виберіть "Властивості"
3. Виберіть сторінку "Параметри"
4. Прокрутіть вниз "Інші параметри" та змініть поле "Обмежити доступ"

Я спробував це працює

ALTER DATABASE dbName SET MULTI_USER WITH ROLLBACK IMMEDIATE

У мене була така ж проблема, і session_id to kill був знайдений за допомогою цього запиту:

Select request_session_id From sys.dm_tran_locks Where resource_database_id=DB_ID('BI_DB_Rep');

Натисніть CTRL + 1

знайти процес, який блокує вашу базу даних. Подивіться у колонці dbname свого db та відзначте spid. Тепер ви повинні виконати це твердження:

kill <your spid>
ALTER DATABASE <your db> SET MULTI_USER;

Для мене працювало наступне:

USE [master]
SET DEADLOCK_PRIORITY HIGH
exec sp_dboption '[StuckDB]', 'single user', 'FALSE';
ALTER DATABASE [StuckDB] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [StuckDB] SET MULTI_USER WITH ROLLBACK IMMEDIATE

Ще один варіант:

• взяти базу даних в автономному режимі; у SMSS правою кнопкою миші клацніть на базі даних та оберіть «Офлайн», позначте «Перервати всі з'єднання».
• бігати ALTER DATABASE [Your_Db] SET MULTI_USER

На всякий випадок, якщо хтось натрапив на цю нитку, ось ось куленебезпечне рішення для SQL Server, що застряг у режимі SINGLE USER

- Отримайте ідентифікатор процесу (spid) з'єднання, яке потрібно вбити
- Замініть 'DBName' фактичним іменем БД

SELECT sd.[name], sp.spid, sp.login_time, sp.loginame 
FROM sysprocesses sp 
INNER JOIN sysdatabases sd on sp.dbid = sd.dbid  
WHERE sd.[name] = 'DBName'

В якості альтернативи ви також можете скористатися командою "sp_who", щоб отримати "spid" відкритого з'єднання:

- Або використовуйте замість цього SP

exec sp_who

- Потім виконайте наступне та замініть [spid] та [DBName] правильними значеннями

KILL SpidToKillGoesHere
GO

SET DEADLOCK_PRIORITY HIGH
GO

ALTER DATABASE [DBName] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

Не впевнений, чи допомагає це комусь, але у мене було те саме питання, і я не міг знайти процес, який мене стримував. Я закрив SSMS і зупинив усі сервіси, що потрапляють у місцевий екземпляр. Потім, коли я повернувся і запустив exec sp_who2, це показало мені винуватця. Я вбив процес і зміг змусити Multi_User працювати, а потім перезапустити служби. У нас IIS вдаряв його кожні кілька хвилин / секунд, шукаючи певні пакети.

Я зіткнувся з тим же питанням цього ранку. Це виявилося простим питанням. У мене було відкрито вікно запитів, яке було встановлено на єдину базу даних користувачів у провіднику об'єктів. Збережена процедура sp_who2 не показала з'єднання. Як тільки я закрив її, я зміг її встановити

Додавши до відповіді Джеспера , щоб бути ще ефективнішим:

SET DEADLOCK_PRIORITY 10;-- Be the top dog.

SET DEADLOCK_PRIORITY HIGHвикористання DEADLOCK_PRIORITY5.

Що відбувається, так це те, що інші процеси отримують тріщину в базі даних, і якщо ваш процес має менший рівень DEADLOCK_PRIORITY, він втрачає гонку.

Це ухиляється від знаходження та вбивства іншого павука (що може знадобитися зробити кілька разів).

Цілком можливо, що вам доведеться бігати ALTER DATABASEне один раз (але це робить Jesper). Змінений код:

USE [master]
SET DEADLOCK_PRIORITY HIGH
exec sp_dboption '[StuckDB]', 'single user', 'FALSE';
ALTER DATABASE [StuckDB] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [StuckDB] SET MULTI_USER WITH ROLLBACK IMMEDIATE

Скористайтеся цим сценарієм

exec sp_who

Знайдіть колонку dbname та spid

тепер виконати

kill spid 
go
ALTER DATABASE [DBName]
SET MULTI_USER;

Сьогодні я зіткнувся з тією ж проблемою, коли мою базу даних було змінено з режиму "Багатокористувацький" на "Однокористувацький", і це врешті-решт зупинило мене публікувати базу даних.

Щоб виправити цю проблему, мені довелося закрити всі екземпляри Visual Studio і запустити команду нижче у вікні запиту сервера Sql -

USE [Your_Database_Name]; ALTER DATABASE [Your_Database_Name] SET MULTI_USER GO

Ця команда змінила БД з Однокористувацького на Багатокористувацький і згодом мені вдалося опублікувати.

Навіть я зіткнувся з тією самою проблемою, не в змозі знайти активні з'єднання з my_db, щоб її вбити, але все одно виявляється така ж помилка. Я закінчую відключення всіх можливих підключень SSMS для будь-якої бази даних на сервері, створюю нове з'єднання із SSMS та змінюю його на багатокористувацький.

-- Actual Code to change my_db to multi user mode
USE MASTER;
GO
ALTER DATABASE [my_db] SET MULTI_USER

Примітка. Це здається можливою помилкою в SQL Server 2005!

Ми щойно пережили це в SQL 2012. Процес реплікації вскочив, коли ми знищили оригінальний сеанс, який встановив його для одного користувача. Але sp_who2 не показав, що новий процес додається до БД. Закриття SSMS і повторне відкриття дозволили нам побачити цей процес у базі даних, і тоді ми могли його вбити і негайно перейти в режим мультикористувача, і це спрацювало.

Я не можу розробити логіку цього, але, схоже, це помилка в SSMS і все ще проявляється в SQL 2012.

використовувати майстер

ПОВЕРНУТИСЯ

виберіть d.name, d.dbid, spid, login_time, nt_domain, nt_username, логін із системних процесів p внутрішнє з'єднання системних баз d на p.dbid = d.dbid, де d.name = 'ім'я бази даних'

убивати 568 - вбивати павука

АЛЬТЕР Ім'я бази даних '

SET MULTI_USER йти