Закрыть соединения 1с sql
Нередко при выполнении определенных задач по обслуживанию или обновлению администратору приходится прерывать все соединения пользователей с базой данных. Иногда причиной тому правила эксклюзивности при обновлении или стремление защитить целостность данных и не влиять на работу клиентов при миграции, когда нужно обеспечить корректность изменений. Завершить соединения с базой данных можно несколькими способами.
Вариант 1. Простой, но неисчерпывающий подход: перевести базу данных в автономный режим
При использовании этого метода мы просто переводим базу данных в автономный режим, а затем возвращаем ее в оперативный режим. Этот процесс прост, но он не завершится до тех пор, пока не будут закончены все текущие транзакции и закрыты все сеансы. Это не лучший подход к переводу базы данных в монопольный режим, и я не рекомендую его использовать.
Вы можете выполнить отмену всех открытых транзакций и закрыть сеансы с помощью дополнительного предложения ROLLBACK IMMEDIATE, но помните, что администратору базы данных следует избегать команд, негативно влияющих на работу конечных пользователей:
- Транзакции завершаются перед разрывом соединения, если не выдана команда ROLLBACK IMMEDIATE; простота выполнения.
Против:
- В зависимости от открытых транзакций вам, возможно, придется ждать завершения автономной команды, если не включить ROLLBACK IMMEDIATE.
Открытые сеансы без активных транзакций не завершаются и не закрываются, если не задействовано ROLLBACK IMMEDIATE, поэтому технически этот вариант не позволяет достичь цели.
Рекомендуется избегать этого метода, если только у вас нет полного понимания того, как приложения и пользователи работают с базой данных, и уверенности, что перечисленные выше недостатки не помешают вам получить монопольный доступ.
Вариант 2. Динамическая инструкция SQL для завершения всех пользовательских сеансов базы данных
Можно воспользоваться динамическим административным представлением sys.dm_exec_sessions для идентификации всех пользовательских сеансов для определенной базы данных — или всех баз данных, если применяемые изменения охватывают область сервера, — и создать динамическую инструкцию KILL для каждого сеанса, возвращаемого из запроса, код которого приведен в листинге.
- Возможности этого программного кода несколько шире, чем у первого варианта, и теперь в вашем распоряжении есть код (благодаря этой статье).
Против:
- Существует проблема промежутка времени между выполнением запроса для получения динамической инструкции SQL и запуском этой динамической инструкции. В этот период создаются новые сеансы, которые будут вне действия динамической инструкции SQL или, хуже того, могут быть выполнены, а значения session_id завершаемых сеансов могут быть назначены сеансам, не имеющим никакого отношения к базе данных, с которой вы работаете.
- Во время применения KILL выполняется откат сеансов, и пользователи могут думать, что их транзакции зафиксированы, хотя на самом деле произошла их отмена.
Вариант 3. Изменение базы данных на SINGLE_USER или RESTRICTED_USER
Существует три различных режима подключения пользователей к базам данных: MULTI_USER, SINGLE_USER и RESTRICTED_USER. Обычно база данных находится в режиме MULTI_USER, то есть несколько пользователей могут подключаться одновременно. В режиме SINGLE_USER база данных может обслуживать один сеанс, и, когда этот сеанс открыт, для базы данных не может быть организовано никаких других сеансов. В режиме RESTRICTED_USER любой пользователь, который является участником роли базы данных db_owner или участником роли сервера sysadmin или dbcreator, может подключиться к базе данных, но все остальные пользователи лишаются этой возможности. При переключении, например, первого режима все открытые сеансы, не относящиеся к привилегированным ролям, должны завершить работу, прежде чем будет выполнена инструкция ALTER DATABASE.
Программный код для каждого режима:
Если приемлемо выполнить отмену всех открытых транзакций базы данных, можно усовершенствовать приведенную выше команду, но помните о проблемах, уже упомянутых в отношении WITH ROLLBACK IMMEDIATE:
По окончании вернитесь к режиму MULTI_USER с помощью команды:
- Транзакции могут завершиться, прежде чем разрываются подключения (если не включено предложение WITH ROLLBACK IMMEDIATE).
- У привилегированных пользователей по-прежнему остается возможность подключения через RESTRICTED_USER. Если вы корректно назначили права, то у вас не будет конечных пользователей с уровнем разрешений, который обеспечил бы им непрерывный доступ. Единственные пользователи, которым нужен такой уровень доступа, — это администраторы баз данных и ИТ-персонал, непосредственно ответственный за администрирование среды обработки данных и часто выполняющий процесс обновления или миграции, ради ознакомления с которым вы и читаете эту статью.
Против:
- В зависимости от открытых транзакций вам, возможно, придется ждать завершения автономной команды, если вы не используете предложение WITH ROLLBACK IMMEDIATE.
- Если применяется параметр SINGLE_
USER, рекомендуется вставить его в сценарий обновления в начале сценария. В противном случае после закрытия сеанса, выполнившего инструкцию ALTER DATABASE… SET SINGLE_USER, конечный пользователь может получить контроль над базой данных, и вам не удастся подключиться или изменить ее, пока этот сеанс не будет закрыт и при условии, что никто другой не предпримет попытки подключения.
Дополнительные соображения
В зависимости от особенностей использования баз данных настоятельно рекомендуется в первую очередь везде, где возможно, ограничить подключения приложений. Есть вероятность, что пользовательские соединения будут восстановлены, если не пресечь попытки пользователей вернуться к базе данных после принятия описанных выше мер.
Данная задача — еще одно напоминание о том, что, имея дело с технологиями, вы никогда не работаете индивидуально. Это непременно коллективные усилия, когда успех всего проекта зависит от слаженных действий нескольких групп.
Я хочу переименовать базу данных, но продолжаю получать ошибку, что "не удалось получить эксклюзивную блокировку" в базе данных, что означает, что некоторые соединения все еще активны.
Как я могу убить все подключения к базе данных, чтобы я мог переименовать ее?
причина в том, что подход, который Адам предложил не будет работать в том, что в течение времени, когда вы зацикливаетесь на активных соединениях, может быть установлен новый, и вы пропустите их. В статье, с которой я связан, используется следующий подход, который не имеет этого недостатка:
скрипт для этого замените "DB_NAME" на базу данных, чтобы убить все подключения к:
Убейте его и убейте огнем:
с помощью среды SQL студии экспресс:
в дереве обозревателя объектов в разделе Управление перейдите к" Монитор активности "(если вы не можете найти его там, щелкните правой кнопкой мыши на сервере базы данных и выберите"Монитор активности"). Открыв Монитор активности, вы можете просмотреть всю информацию о процессе. Вы сможете найти блокировки для интересующей вас базы данных и убить эти блокировки, которые также убьют соединение.
после этого вы сможете переименовать.
Я всегда использовал:
автономный режим занимает некоторое время, и иногда я испытываю некоторые проблемы с этим..
самый солидный способ на мой взгляд:
отключить Щелкните правой кнопкой мыши DB - > задачи - > отсоединить. проверить " Drop Connections" Ok
Reattach Щелкните правой кнопкой мыши базы данных - > прикрепить.. Добавлять. - >выберите базу данных и измените столбец Attach As на нужное имя базы данных. Ok
используйте базу данных "master" и запустите этот запрос, он убьет все активные соединения из вашей базы данных.
обычно я сталкиваюсь с этой ошибкой, когда пытаюсь восстановить базу данных, я обычно просто иду в верхнюю часть дерева в Management Studio и щелкаю правой кнопкой мыши и перезапускаю сервер базы данных (потому что он находится на машине разработки, это может быть не идеально в производстве). Это закрыть все подключения к базе данных.
в MS SQL Server Management Studio в обозревателе объектов щелкните правой кнопкой мыши базу данных. В контекстном меню, которое следует выберите "задачи - > Take Offline"
другой подход "убить его огнем" - просто перезапустить службу MSSQLSERVER. Мне нравится делать что-то из командной строки. Вставка этого точно в CMD сделает это: ЧИСТАЯ ОСТАНОВИТЕ MSSQLSERVER & ЧИСТЫЙ ЗАПУСТИТСЯ MSSQLSERVER
или открыть "сервис.msc "и найдите" SQL Server (MSSQLSERVER)" и щелкните правой кнопкой мыши, выберите "перезапустить".
Это" наверняка, наверняка " убьет все подключения ко всем базам данных, запущенным на этом экземпляре.
(Мне это нравится больше, чем многим подходы, которые изменяют и изменяют конфигурацию на сервере / базе данных)
вот как надежно такого рода вещи в MS SQL Server Management Studio 2008 (может работать и для других версий):
- в дереве обозревателя объектов щелкните правой кнопкой мыши корневой сервер базы данных (зеленой стрелкой) и выберите монитор активности.
- откройте вкладку процессы в мониторе активности, выберите раскрывающееся меню "базы данных" и отфильтруйте нужную базу данных.
- щелкните правой кнопкой мыши БД в Обозревателе объектов и запустите " задачи - > взять Offline " задача. Оставьте это в фоновом режиме, пока вы.
- безопасно выключите все, что сможете.
- убить все оставшиеся процессы на вкладке процесс.
- включите БД.
- переименовать БД.
- верните свой сервис в онлайн и укажите его на новую БД.
параметр работает для меня в этом случае выглядит следующим образом:
- запустите операцию "отсоединить" в соответствующей базе данных. Это откроет окно (в SQL 2005), отображающее активные соединения, которые предотвращают действия в БД.
- убить активные соединения, отменить операцию отсоединения.
- Теперь база данных должна быть доступна для восстановления.
щелкните правой кнопкой мыши на имени базы данных, нажмите на свойство, чтобы получить окно Свойства, откройте вкладку Параметры и измените свойство "ограничить доступ" с нескольких пользователей на одного пользователя. При нажатии на кнопку OK, он предложит вам закрыть все открытые соединения, выберите "Да", и вы настроены на переименование базы данных.
Они не работали для меня (Sql2008 Enterprise), я также не видел никаких запущенных процессов или пользователей, подключенных к БД. Перезапуск сервера (щелкните правой кнопкой мыши на Sql Server в Management Studio и выберите перезапуск) позволил мне восстановить БД.
Я использую SQL Server 2008 R2, моя БД уже была установлена для одного пользователя, и было соединение, которое ограничивало любые действия в базе данных. Таким образом, рекомендуется SQLMenace решение ответило ошибкой. вот один, который работал в моем случае.
Я использую sp_who для получения списка всех процессов в базе данных. Это лучше, потому что вы можете захотеть просмотреть, какой процесс убить.
результат
Вы можете использовать команду аннулирования команда в колонну, чтобы убить процесс, который вы хотите.
вы можете использовать команду SP_Who и убить весь процесс, который использует вашу базу данных, а затем переименовать вашу базу данных.
Управление новыми сеансами производится путем установки с командной строки параметров базы данных, представленных в консоли управления кластером.
Существующие сеансы могут быть просто перечислены в логах, а могут быть частично или полностью завершены.
Если для кластера не определены администраторы, следует явно указать параметры "/CU: /CP:" для "пустой" аутентикации, в противном случае аутентикация не будет производиться вообще, что допустимо только для пользователей, связанных с текущим пользователем операционной системы (это не работает для локальных пользователей ОС, если кластер размещен не на локальной машине).
Аналочично производится аутентикация пользователей агента и информационных баз. Для последних, кроме общего имени и пароля, вводимых до имени первой базы, можно указать после имени базы личные (аутентификация в API странная, такое ощущение, что можно свалить все именпа пользователей в кучу, а сервер разберет; у кого будут накладки или соображения по этому вопросу, прошу постить сюды).
Под 64-битной системой скрипт будет работать только в 32-битном интерпретаторе. Интерактивно открывается 32-битный CMD.EXE, а вот в назначенном задани нужно явно указать C:\Windows\SysWOW64\cmd.exe или C:\Windows\SysWOW64\cscript.exe, чтобы избежать ошибок при создании COM-объектов.
Перенаправление стандартных потоков родительского процесса нужно делать конструкцией '1>FileName 2>&1' а не '2>&1 1>FileName', иначе STDErr перенаправляться не будет.
Также при перенаправлении в файл с кодировкой CP866 следует указать параметр /OutputCodepage:866, иначе весь вывод скрипта получится кракозябрами (в кодировке Win1251). При выводе на консоль этот параметр нужно убирать, так как CScript в этом случае перекодирует сам, а двойное преобразование приведет понятно к чему.
Пример использования скрипта с сервером 8.3.5 (вывод cmd-скрипта перенаправлен в файл, поэтому используется ключ /OC):
Это кусок процуедуры, вырванный из контекста рабочего скрипта. Естественно, придется допиливать, но в качестве пример имхо сойдет - прошу сильно не пинать.
Я хочу переименовать базу данных, но продолжаю получать ошибку, которая «не может получить эксклюзивную блокировку» для базы данных, которая подразумевает, что некоторые соединения все еще активны.
Как я могу убить все соединения с базой данных, чтобы я мог переименовать ее?
Причина, по которой предложенный Адамом подход не сработает, заключается в том, что в течение цикла, в течение которого вы перебираете активные соединения, вы можете установить новое соединение, и вы его пропустите. Вместо этого вы можете использовать следующий подход, который не имеет этого недостатка:
Я только что запустил это в 2008 году без проблем. ALTER DATABASE aspnetdb SET SINGLE_USER WITH ROLLBACK IMMEDIATE select GETDATE () ALTER DATABASE aspnetdb SET MULTI_USER Что у вас есть вместо закомментированного кода? Работал для меня с SQL Server 2008 и экземпляром SQL Express. @Wagner, если в базе данных есть «-» в имени, которое необходимо использовать в скобках: ALTER DATABASE [foo-bar] SET SINGLE_USER WITH ROLLBACK IMMEDIATE Обратите внимание - НЕ пытайтесь сделать это на SQL Server, размещенном в Amazon RDS. Вы не сможете сбросить БД обратно в режим MULTI_USER. Убедитесь, что у вас есть другой набор учетных данных DBA, прежде чем пытаться это сделать. Я исправил это, вернувшись к одному из предыдущих снимков. Потеряли некоторые данные. К счастью, данные не были критическими.Сценарий, чтобы выполнить это, замените 'DB_NAME' на базу данных, чтобы уничтожить все соединения с:
Только пользовательские процессы могут быть убиты . все еще заблокированы и не могут восстановить режим multi_user из-за тупика. mateuscb - единственный способ, которым он не будет работать на mssql 10.00, - это если у вас есть имя базы данных, которое требует [], и вы не используете их. ALTER DATABASE [YourDatabase] SET SINGLE_USER с опцией ROLLBACK IMMEDIATE работает в 10, 10.5, 11 и 12.Убей его и убей огнем
Использование SQL Management Studio Express:
В дереве обозревателя объектов перейдите в раздел «Управление» до «Монитор активности» (если его там нет, щелкните правой кнопкой мыши сервер базы данных и выберите «Монитор активности»). Открыв Activity Monitor, вы можете просмотреть всю информацию о процессе. Вы должны быть в состоянии найти блокировки для базы данных, которая вас интересует, и убить эти блокировки, что также уничтожит соединение.
Вы должны быть в состоянии переименовать после этого.
Я не вижу этот элемент «Монитор активности» в разделе «Управление» . Опять же, может быть, это потому, что я использую SQL 2008? Я нашел «Монитор активности», если щелкнуть правой кнопкой мыши СЕРВЕР, а не БД. Затем вы можете выбрать вкладку «Процессы» и выполнить фильтрацию по базе данных. По-видимому, вам нужно поочередно завершать остановленный процесс, но это простой метод, который не требует локального входа в систему или отключения всего сервера базы данных.Я всегда использовал:
Работа в автономном режиме занимает некоторое время, и иногда у меня возникают некоторые проблемы с этим ..
Самый солидный способ на мой взгляд:
Отсоединение правой кнопкой мыши БД -> Задачи -> Отключение . отметьте «Отключить соединения» Ok
Повторно подключите правой кнопкой мыши Базы данных -> Вложить .. Добавить . -> выберите свою базу данных и измените столбец Вложить как на нужное имя базы данных. Хорошо
Нравится это. Самый быстрый способ сделать это из GUI точно. Работает как часы! Легкий путь - это хороший путь. Спасибо.используйте базу данных 'master' и выполните этот запрос, он уничтожит все активные соединения из вашей базы данных.
Это действительно работает :) Однако я бы посоветовал держать закомментированную часть этого скрипта и поместить вместо нее print @query, просто чтобы убедиться, что вы не запустили это на рабочем сервере по ошибке.Обычно я сталкиваюсь с этой ошибкой, когда пытаюсь восстановить базу данных. Обычно я просто захожу в верхнюю часть дерева в Management Studio, щелкаю правой кнопкой мыши и перезагружаю сервер базы данных (поскольку он находится на компьютере разработчика, это может быть не идеально в производственной среде). ). Это закрыть все соединения с базой данных.
Спасибо, это сработало ( ALTER DATABASE . SET SINGLE_USER команды в других ответах возвращали ту же ошибку «не удалось получить эксклюзивную блокировку»).В MS SQL Server Management Studio в обозревателе объектов щелкните правой кнопкой мыши базу данных. В появившемся контекстном меню выберите «Задачи -> Отключить».
Вы не можете сделать это, если есть активное соединение.Другой подход «убей его огнем» - просто перезапустите службу MSSQLSERVER. Мне нравится делать вещи из командной строки. Вставка именно в CMD сделает это: NET STOP MSSQLSERVER и NET START MSSQLSERVER
Или откройте «services.msc» и найдите «SQL Server (MSSQLSERVER)» и щелкните правой кнопкой мыши, выберите «restart».
Это «наверняка, наверняка» уничтожит ВСЕ соединения со ВСЕМИ базами данных, работающими в этом экземпляре.
(Мне нравится это лучше, чем многие подходы, которые меняют и меняют конфигурацию на сервере / базе данных)
Что вы имеете в виду «не рекомендуется»? Если вас не интересуют какие-либо соединения с этим сервером (например, отладочная или промежуточная среда или рабочий сервер с временным временем простоя), это может быть самый простой способ. Для производства - вы не хотите портить конфигурацию, если можете просто перезапустить сервис. Что бы вы сделали? Я бы пошел на все, что должно повлиять только на мою целевую БД. Ваш подход к уничтожению всех БД на целевом сервере не такой разумный. но, честно говоря, в постановочной среде это, пожалуй, самый простой способ, как вы сказали.Вот как надежно работать с такими вещами в MS SQL Server Management Studio 2008 (может работать и для других версий):
Читайте также: