Закрыть соединения 1с sql

Обновлено: 07.07.2024

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

Вариант 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 (может работать и для других версий):

  1. в дереве обозревателя объектов щелкните правой кнопкой мыши корневой сервер базы данных (зеленой стрелкой) и выберите монитор активности.
  2. откройте вкладку процессы в мониторе активности, выберите раскрывающееся меню "базы данных" и отфильтруйте нужную базу данных.
  3. щелкните правой кнопкой мыши БД в Обозревателе объектов и запустите " задачи - > взять Offline " задача. Оставьте это в фоновом режиме, пока вы.
  4. безопасно выключите все, что сможете.
  5. убить все оставшиеся процессы на вкладке процесс.
  6. включите БД.
  7. переименовать БД.
  8. верните свой сервис в онлайн и укажите его на новую БД.

параметр работает для меня в этом случае выглядит следующим образом:

  1. запустите операцию "отсоединить" в соответствующей базе данных. Это откроет окно (в SQL 2005), отображающее активные соединения, которые предотвращают действия в БД.
  2. убить активные соединения, отменить операцию отсоединения.
  3. Теперь база данных должна быть доступна для восстановления.

щелкните правой кнопкой мыши на имени базы данных, нажмите на свойство, чтобы получить окно Свойства, откройте вкладку Параметры и измените свойство "ограничить доступ" с нескольких пользователей на одного пользователя. При нажатии на кнопку 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 (может работать и для других версий):

Читайте также: