Закрыть соединения 1с sql
Управление новыми сеансами производится путем установки с командной строки параметров базы данных, представленных в консоли управления кластером.
Существующие сеансы могут быть просто перечислены в логах, а могут быть частично или полностью завершены.
Если для кластера не определены администраторы, следует явно указать параметры "/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):
Это кусок процуедуры, вырванный из контекста рабочего скрипта. Естественно, придется допиливать, но в качестве пример имхо сойдет - прошу сильно не пинать.
Я хочу переименовать базу данных, но продолжаю получать ошибку, что "не удалось получить эксклюзивную блокировку" в базе данных, что означает, что некоторые соединения все еще активны.
Как я могу убить все подключения к базе данных, чтобы я мог переименовать ее?
причина в том, что подход, который Адам предложил не будет работать в том, что в течение времени, когда вы зацикливаетесь на активных соединениях, может быть установлен новый, и вы пропустите их. В статье, с которой я связан, используется следующий подход, который не имеет этого недостатка:
скрипт для этого замените "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 и убить весь процесс, который использует вашу базу данных, а затем переименовать вашу базу данных.
Нередко при выполнении определенных задач по обслуживанию или обновлению администратору приходится прерывать все соединения пользователей с базой данных. Иногда причиной тому правила эксклюзивности при обновлении или стремление защитить целостность данных и не влиять на работу клиентов при миграции, когда нужно обеспечить корректность изменений. Завершить соединения с базой данных можно несколькими способами.
Вариант 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, конечный пользователь может получить контроль над базой данных, и вам не удастся подключиться или изменить ее, пока этот сеанс не будет закрыт и при условии, что никто другой не предпримет попытки подключения.
Дополнительные соображения
В зависимости от особенностей использования баз данных настоятельно рекомендуется в первую очередь везде, где возможно, ограничить подключения приложений. Есть вероятность, что пользовательские соединения будут восстановлены, если не пресечь попытки пользователей вернуться к базе данных после принятия описанных выше мер.
Данная задача — еще одно напоминание о том, что, имея дело с технологиями, вы никогда не работаете индивидуально. Это непременно коллективные усилия, когда успех всего проекта зависит от слаженных действий нескольких групп.
Проблема следующая: не возможно сделать штатный бекап. Т.е. выгрузка ИБ начинается и продолжается вечно. Проблема, видимо, кроется в том, что сеансов нет, а соединения и блокировки есть. И как эти соединения закрыть/удалить совершенно не понятно. Если заблокировать базу то через 20-30 минут они пропадают сами.
(1) Win98, Обычно обновление БД и/или архивирование выполняется так:
1. Выполнить блокировку.
2. Подождать от 1 до 5 минут (пока отработает стандартное отключение пользователей).
3. Войти в консоль и удалить оставшиеся подключения.
Сеансов нет, а блокировки и соединения остались и живут, ориентировочно, до 30 минут.
Сеансы удалить могу, а блокировки и соединения нет - нет такой функции/кнопки/поля меню. :(
(3) Win98, Обычно с сеансами соединения удаляются.
Значит какие-то длительные операции (под этими пользователями) запущены. К примеру удаление помеченных объектов.
(4) dj_serega, нет, ничего не запущено. есть подозрение что как-то связано с "время засыпания пассивного сеанса" и с "время завершения спящего сеанса" .
PS. У нас тонкий и веб-клиент.
(6) dj_serega, 20 минут и 1 час, до этого было больше (по умолчанию) оставались повисшие Сеансы, сократили, стало явно лучше, может еще сократить?
У меня такая же проблема проявляется (Платформа 8.3.5.1248). До установки данной платформы такой проблемы не было. Проявляется проблема в том, что выгрузка в dt зависает, при этом возможно войти в режиме 1С: Предприятие. Единственное решение, которое нашёл (причину так и не нашёл) - с помощью диспетчера задач завершить сеанс работы конфигуратора, после этого используя консоль администрирования удалить зависший сеанс конфигуратора и ещё раз начать выгрузку в архив (только задать другое имя архива) - тогда проходит всё быстро.
(9) Ted1982, в консоли сервера посмотри, плиз, наверняка в это время есть блокировки и соединения, а пока "убиваешь" конфигуратор и подцепляешься по новой они уже отмирают.
(10) Win98, Возможно. как буду следующий раз обновлять базы - обязательно посмотрю.
Но вопрос остаётся открытым по причинам такого поведения 1С.
(10) Win98, начал обновлять базы - проблема осталась, однако никаких дополнительных блокировок/соединений кроме самого конфигуратора нет. Видимо проблема в чём-то другом. В ближайшее время системные администраторы обновят на серверах платформу - посмотрю, может быть что-то и изменится
(9) Ted1982, У меня клиент-серверный вариант. Выгрузку делаем через sql. Поэтому и все хорошо по данному вопросу.
1С, в принципе, не рекомендует активно пользоваться выгрузками через dt.
(12) dj_serega, у нас в компании средствами sql делаются ночные архивы. А dt используем перед обновлением конфигурации в течение рабочего дня, чтобы сохранить на всякий случай то, что пользователи наработали за день.
sql конечно лучше, но подразделения, отвечающие за 1С и за SQL, отдельные - так что при обновлении каждой базы быстрее получается средствами 1С, оперативнее.
(15) Ted1982, а почему не делать sql'ьные каждый час в рабочее время? dt - хорошо, но не безопасно :(
У нас каждый час + ежедневные. И такую практику встречал во многих компаниях.
У кого не файловая то про dt вообще забыли (читать забили :) ).
(16) dj_serega, Эээээ. имея на одном сервере порядка 100 продуктивных баз, в которых постоянно работают, делать ежечасные архивы никаких мощностей не хватит.
(17) Ted1982, скуль сделает, он такой :)
У нас так же, ночью полный, каждый час инкрементный, и юзеров 500+, и объемы гигабайтные. но dt наше все :)
(17) Ted1982, Ну так а что мешает сделать sql-выгрузку а не dt? Почему именно dt?
Имхо, если есть возможность sql то только он. DT это привилегии файловой базы. Хотя и там лучше скопировать 1cd.
Вообщем мы друг друга поняли :)
необязательно, рекомендуется или обязательно закрывать SqlConn и SqlData?
вы должны закрыть объект sqlconnection, как только вы закончите с ним. Если вы этого не сделаете, соединение останется открытым и не будет доступно для обработки других запросов.
оператор using полезен для этого. Он вызовет Dispose () на объекте для вас:
вам не нужно иметь отдельный оператор using для SqlDataReader (а также один оператор using для соединения), если вы не планируете выполнять другие операции с соединением после того, как SqlDataReader полностью прочитал набор строк.
Если вы просто открываете соединение, читаете некоторые данные с помощью считывателя, а затем закрываете соединение, то одного оператора using для всего блока кода (окружающего соединение) будет достаточно в качестве мусора collector очистит все ресурсы, привязанные к соединению, которое удаляется первой инструкцией using.
в любом случае, вот хороший статьи это описывает все.
вы должны закрыть все, прежде чем возвращаться из функции. Open datareaders означает открытые курсоры в базе данных, что приводит к увеличению использования памяти. То же самое касается подключений к базе данных.
все три класса имеют метод Dispose (). Обязательный слишком силен, но определенно настоятельно рекомендуется использовать ключевое слово using, поэтому Dispose() вызывается автоматически. Неспособность сделать это делает вашу программу "тяжелой", используя больше системных ресурсов, чем необходимо. И прямой сбой, когда вы не используете ключевое слово "new" достаточно, чтобы вызвать сборщик мусора.
вызов Close при подключении SQL фактически не закроет его, но вернет его в пул соединений для повторного использования, улучшая производительность.
кроме того, как правило, плохая практика не явно распоряжаться неуправляемыми ресурсами, когда вы закончите с ними (asap).
будьте осторожны с абсолютами здесь. Многое зависит от того, что вы делаете и где может лежать неэффективность. На веб-странице, где каждый пользователь имеет отдельный контекст безопасности, у вас может не быть выбора, кроме как установить новое соединение SQL с новыми учетными данными безопасности при каждом попадании страницы. Явно лучше, если вы можете использовать пул соединений SQL с общим контекстом безопасности и позволить веб-странице фильтровать результаты, но, возможно, вы не можете.
в качестве примерного руководства, если вы думаете, что ваше приложение захочет поговорить с SQL в следующем, скажем, 30 секунд. Держать соединение открытым. Если они минимизировали ваше приложение, не коснулись его в течение тайм-аута, или у вас есть все данные в ОЗУ, и им вряд ли понадобится что-то еще из системы SQL. Закрывать соединение.
рассмотрите возможность создания Класс с системным таймером для удержания соединения. Ваш класс всегда будет предоставлять действительное соединение, но, возможно, класс решит удалить его и освободить нагрузку соединения на SQL, когда это необходимо.
Если вы также не пишете серверный код, небольшое количество неэффективности памяти может даже не быть замечено. Но 2-10,000 клиентов все плохо через свои сервера и безопасность данных может принести свои ЦОД на колени.
явное распоряжение в заявлении finally-это еще один подход, хотя using заявление является гораздо лучшим решением. Он создает немного больше кода, но демонстрирует цель.
любой класс обработки SQL вещи как соединения должны реализовывать интерфейс IDisposable, как заявили в Microsoft .Чистая принципов кодирования.
таким образом, вы, вероятно, должны закрыть и утилизировать свое соединение в своем методе Dispose.
Читайте также: