Обновление 1С не получает монопольный режим при нуле сеансов

Мастер обновления остановился на шаге «Установка монопольного режима», хотя список сеансов пуст. Проверьте соединения информационной базы: ноль сеансов ещё не означает, что к базе никто не подключён.

Откройте список соединений и включите колонку «Приложение». Если там есть COMConnection, завершите это соединение и снова запросите монопольный режим. Перезапускать SQL Server или весь кластер не нужно.

Так развивался инцидент с COMConnection, описанный на Хабре. Мастер восемь минут ждал монопольного режима при нуле активных сеансов. Базу удерживал внешний скрипт, который подключился через V83.COMConnector.

Где искать соединение, которого нет среди сеансов

Список сеансов показывает пользовательские подключения, но не всю активность информационной базы. Пользователи могли выйти, а внешний обмен — оставить соединение внутри rphost.

Откройте консоль администрирования кластера и перейдите к соединениям нужной базы. Если поле «Приложение» скрыто, добавьте его. Объекты оснастки и переходы между ними описаны в руководстве по консоли кластера.

Ищите строку с COMConnection в поле приложения. Именно такое зависшее подключение нашли в опубликованном инциденте.

Пустой список сеансов закрывает только первую проверку. Перед обновлением откройте соединения базы и посмотрите поле «Приложение».

Внешние программы подключаются к серверу 1С через объект V83.COMConnector. Этот способ описан в документации «1С:Предприятия» о запуске компонентов платформы. На сервере с ним связана библиотека comcntr.dll.

Перерегистрировать библиотеку при такой ошибке не нужно. Строка COMConnection уже подтверждает, что подключение создано. Теперь найдите процесс, который не освободил объект после обмена или сбоя.

Технологический журнал подтверждает причину

Само по себе соединение COMConnection ещё не доказывает, что обновление остановилось из-за него. Сопоставьте соединение с отказом монопольного режима в технологическом журнале.

Откройте журнал процесса rphost, который обслуживает нужную информационную базу. Найдите событие EXCP, записанное во время остановки мастера. В опубликованном инциденте у записи было два признака:

Exception=MonopolyMode
Descr='Не удалось установить монопольный режим'

Эта пара отличает нужный сценарий от других блокировок. Нужны оба наблюдения: ошибка MonopolyMode в журнале и COMConnection в консоли.

Если свежей записи нет, не завершайте соединения наугад. Монопольному режиму могут мешать запрет начала сеансов, фоновое задание или другое подключение. Продолжите диагностику по инструкции о поиске владельца блокировки базы.

Смотрите только узкий интервал вокруг конкретной попытки обновления. Старое событие MonopolyMode могло относиться к другой операции и другому соединению.

Почему команда «выгнать пользователей» не освобождает базу

Скрипт массового отключения способен завершить все выбранные сеансы и оставить COMConnection. Результат зависит от того, какие AppID проверяет код.

Опубликованный kickoutallusers.vbs обрабатывает только 1CV8, 1CV8C и WebClient. Подключения COMConnection, Designer и BackgroundJob в этот отбор не входят.

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

После массового завершения сеансов откройте список соединений. Сам скрипт не выясняет, готова ли база отдать монопольный доступ.

Таблица описывает конкретный kickoutallusers.vbs, опубликованный на wiki.mihanik.net. Это не полный справочник AppID платформы. В материалах инцидента нет официальной таблицы изготовителя с такой расшифровкой.

Ограниченный отбор подходит для повседневной работы. Если скрипт начнёт завершать все служебные подключения без разбора, он сможет оборвать обмен или регламентное задание. Поэтому перед обновлением нужна отдельная проверка соединений.

Как завершить блокирующее COM-соединение

Сначала подтвердите причину. В консоли должно быть соединение с Application=COMConnection, а в журнале rphost — свежая ошибка MonopolyMode, записанная во время обновления.

Затем выполните шесть действий:

1. Откройте свойства нужной информационной базы в консоли кластера.
2. Перейдите к списку соединений, а не только к сеансам.
3. Добавьте колонку «Приложение», если она скрыта.
4. Найдите соединение с Application=COMConnection.
5. Завершите найденное соединение через консоль администрирования.
6. Повторите установку монопольного режима в Конфигураторе.

В инциденте с Хабра этих шести действий хватило. Мастер продолжил обновление без перезапуска SQL Server и кластера 1С.

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

Если COMConnection появился снова, вы убрали следствие, но причина осталась. Внешний скрипт продолжает работать либо служба интеграции открывает новое подключение. Остановите обмен штатным способом, затем ещё раз проверьте соединения.

Не завершайте rphost, пока блокировку можно снять удалением одного соединения. Перезапуск рабочего процесса оборвёт и другие подключения, которые он обслуживает. В описанном инциденте такая мера не понадобилась.

Как отличить старое соединение от работающего обмена

Название COMConnection не раскрывает, какая система открыла подключение. Сопоставьте время его появления с расписанием интеграций и записями в их журналах.

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

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

Обновите список соединений после остановки обмена. Строка COMConnection должна исчезнуть и не появляться снова до запуска обновления. После этого повторно запросите монопольный режим.

Почему перезапуск кластера скрывает причину

Перезапуск кластера разорвёт все соединения, в том числе зависшее. Вместе с ним исчезнет и главный след: вы уже не увидите, какое приложение удерживало базу.

При следующем обновлении проблема может вернуться. Внешний обмен снова оставит COMConnection, а регламент опять проверит только пользовательские сеансы.

Точечное завершение сохраняет цепочку диагностики. Вы видите соединение в консоли, находите отказ в журнале и проверяете, исчезла ли блокировка после удаления строки. Этих данных хватит владельцу интеграции, чтобы искать дефект.

Перезапуск SQL Server ещё дальше от причины. В описанном случае база и СУБД продолжали работать. Монопольный доступ удерживало соединение платформы, а остановка SQL Server затронула бы все размещённые на нём базы.

Что исправить в интеграции

После обновления передайте владельцу интеграции два факта: время появления зависшего соединения и значение поля «Приложение». Требование к исправлению простое: COM-объект должен освобождаться и при штатном завершении, и после ошибки.

В инциденте со складским обменом разработчик изменил общий модуль ОбменWMSСервер. В блок обработки исключения добавили явное обнуление COM-объекта. В журнал регистрации начали записывать событие ЗакрытиеCOMПослеОбмена.

Не копируйте этот фрагмент в любую конфигурацию. Имена объектов и устройство обмена зависят от конкретной системы. Администратору нужен проверяемый результат: после ошибки обмена строка COMConnection исчезает из консоли.

Исправление проверяйте на тестовой базе. Вызовите контролируемую ошибку обмена, затем откройте список соединений и журнал регистрации. В журнале должно появиться событие закрытия, а в консоли — исчезнуть COMConnection.

Что добавить в регламент обновления

Проверки «активных сеансов: ноль» недостаточно. Перед выкладкой cf или cfu регламент должен охватывать и служебные соединения.

Готовность базы подтверждают три проверки: сеансы, соединения и журнал. Одного пустого списка сеансов мало.

После опубликованного инцидента в регламент внесли проверку COMConnection и Designer перед выкладкой cf или cfu. Она закрывает две причины, которые пропускает скрипт массового отключения.

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

Проверка перед повторным запуском обновления

Перед новой попыткой пройдите короткий маршрут:

• Откройте соединения нужной информационной базы.
• Включите колонку «Приложение».
• Найдите COMConnection и сопоставьте его со временем обмена.
• Подтвердите в журнале rphost ошибку Exception=MonopolyMode.
• Завершите найденное соединение.
• Снова запросите монопольный режим.

Если мастер продолжил обновление, исправьте освобождение COM-объекта в интеграции. В регламенте оставьте отдельную проверку COMConnection и Designer перед каждой выкладкой cf или cfu.

Правило для следующего обновления короткое: ноль сеансов — только первая проверка. База готова, когда в ней нет и блокирующих соединений.