Как закрыть базу 1С для пользователей на время обновления: блокировка соединений и сеансов

Чтобы закрыть базу 1С на обновление, включите блокировку начала сеансов в свойствах базы (консоль кластера или rac), задайте код разрешения, завершите уже открытые сеансы и войдите в Конфигуратор с ключом /UC. Ниже: команды, скрипт для окна обслуживания и разбор на базе из 8 рабочих мест.

Что такое блокировка соединений и почему «все вышли» не работает

Сначала определимся с терминами, потому что их путают постоянно. «Блокировка соединений» (в интерфейсе платформы она называется блокировкой начала сеансов) — это флаг в свойствах информационной базы. Пока он стоит, новый сеанс с обычными параметрами начаться не может: пользователь получает отказ с вашим текстом. Уже работающие сеансы флаг не трогает вообще. Это два разных действия — запретить новые входы и убрать старые сеансы — и обновление требует обоих. Если вам нужна помощь с серверной 1С и PostgreSQL, мы ставим этот порядок в регламент сразу, а не после первой аварии.

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

Эта статья про конкретный механизм закрытия базы. Общий регламент обновления — тестовая база, резервная копия, окно, откат — я разобрал отдельно в материалах про обновление 1С без простоя и в пошаговой инструкции по самому процессу. Здесь мы остановимся на одном: как правильно закрыть базу, как не закрыть её навсегда вместе с собой и как снять блокировку, если что-то пошло не так.

• блокировка начала сеансов запрещает новые подключения, но не завершает активные;
• завершение сеансов — отдельная операция, её делают после включения блокировки, а не до;
• код разрешения — пропуск для администратора, с которым можно войти вопреки блокировке;
• блокировка регламентных заданий включается отдельным флагом, о нём легко забыть.

Как включить блокировку в консоли кластера и что вписать в поле «Код разрешения»

Для клиент-серверной базы самый наглядный способ — консоль администрирования серверов 1С:Предприятия. В дереве выбираете кластер, раздел информационных баз, открываете свойства нужной базы. В свойствах есть блок блокировки: флаг включения блокировки начала сеансов, время начала и конца блокировки, сообщение для пользователя, параметр блокировки и код разрешения. Рядом отдельный флаг блокировки регламентных заданий. Точные подписи полей слегка отличаются между версиями платформы, поэтому ориентируйтесь на смысл и проверяйте в своей версии.

Сообщение пишите так, чтобы человеку не пришлось звонить вам. «База закрыта на плановое обновление до 23:00, обращайтесь по номеру внутреннего телефона» — достаточно. Время окончания блокировки я всегда ставлю с запасом и записываю в сообщение: если вы забудете снять блокировку руками, система сама откроет вход по истечении интервала. Без конца интервала блокировка действует, пока её не выключат вручную, и именно так по понедельникам утром у бухгалтеров появляется ошибка о запрете начала сеанса.

Код разрешения — это обычная строка, которую вы придумываете сами. Она нужна, чтобы вы сами могли войти в закрытую базу: запускаете клиент или Конфигуратор с ключом /UC и этим кодом. Не используйте в качестве кода идентификатор базы и не оставляйте простейшие значения вроде 123. В поле кода у нас живёт короткая случайная строка, и она не лежит в общей папке рядом с ярлыками пользователей: код — не секрет уровня пароля, но зачем облегчать жизнь тому, кто захочет зайти без спроса. Существенная деталь: блокировка действует и на администратора. Без верного кода вы сами окажетесь за дверью, поэтому проверьте вход с кодом до того, как будете закрывать всех остальных.

Как закрыть базу командой: rac для скрипта и ночного окна

Ручные клики в консоли годятся для разового обновления. Если окно ночное или обновлений много, нужен скрипт, и здесь на помощь приходит утилита администрирования rac, которая обращается к серверу администрирования RAS. Адрес RAS по умолчанию — localhost:1545. Служба RAS должна быть запущена на сервере; как её настроить и держать в рабочем состоянии, я описывал в разборе управления кластером через rac. Сначала узнаём идентификатор кластера и базы.

Дальше команда включения блокировки. Параметры, которые мне пригодились: sessions-deny включает блокировку начала сеансов, scheduled-jobs-deny закрывает регламентные задания, denied-from и denied-to задают интервал, denied-message — текст для пользователей, permission-code — код разрешения. Формат даты — ISO со временем, как в примере ниже. Параметр denied-parameter я не использую и вам не советую вслепую: пользуйтесь им, только если понимаете, что он делает в вашей конфигурации. Любые имена и значения сверяйте встроенной справкой вашей версии, потому что в сторонних материалах встречаются разные написания.

Минимальный набор команд выглядит так. Угловые скобки замените своими значениями, даты берите в формате из примера:

rac localhost:1545 cluster list
rac localhost:1545 infobase summary list --cluster=<id-кластера>
rac localhost:1545 infobase update --cluster=<id-кластера> --infobase=<id-базы> --infobase-user=<admin> --infobase-pwd=<пароль> --sessions-deny=on --scheduled-jobs-deny=on --denied-from=2026-10-10T21:00:00 --denied-to=2026-10-10T23:00:00 --denied-message='Плановое обновление до 23:00' --permission-code=<код>
rac localhost:1545 session list --cluster=<id-кластера> --infobase=<id-базы>
rac localhost:1545 session terminate --cluster=<id-кластера> --session=<id-сеанса> --error-message='Плановое обновление базы'

Пароль администратора базы в тексте команды — плохая привычка: он остаётся в истории и в журналах запуска. В скрипте берите его из защищённого хранилища или из переменной окружения, которую вы задаёте в сессии задачи. Если у учётной записи кластера нет пароля, параметры cluster-user и cluster-pwd можно опустить; если есть, добавьте их к каждой команде. Все примеры ниже используют условные значения: example.com, 10.x и заглушки в угловых скобках.

• rac localhost:1545 cluster list — находим идентификатор кластера;
• rac localhost:1545 infobase summary list --cluster=... — находим идентификатор базы;
• rac localhost:1545 infobase update ... --sessions-deny=on — закрываем базу;
• rac localhost:1545 infobase update ... --sessions-deny=off — открываем базу.

Как завершить уже открытые сеансы и не повредить данные

После включения блокировки заглянем в список сеансов базы. Команда session list с фильтром по базе покажет все подключения: пользователей, клиентские приложения, фоновые задания, соединения COM и веб-сервисов. Нормальные пользовательские сеансы завершаем командой terminate с идентификатором сеанса и текстом причины в параметре error-message — пользователь увидит его, а не молчаливое закрытие окна. Сначала предупреждение за 15–30 минут, потом блокировка, потом завершение: так мы не обрываем документ на середине. В конфигурациях на библиотеке стандартных подсистем есть собственная форма блокировки работы пользователей с отсчётом времени. Она красиво предупреждает людей внутри программы, но предупреждение видят только интерактивные пользователи: сеансы веб-сервисов, COM-соединения обменов и фоновые задания сообщений не читают, и их всё равно приходится проверять по списку сеансов, поэтому скриптовый контроль остаётся нужным.

Особое внимание — на сеансы, которые на самом деле не пользователи. Фоновые и регламентные задания, обмен с сайтом, интеграции через веб-сервисы, подключение внешней обработки. Включая блокировку регламентных заданий отдельным флагом, вы предотвращаете их запуск, но уже стартовавшее задание нужно дождаться или завершить осознанно. Я смотрю в список сеансов и в эти минуты, и повторно прямо перед запуском обновления. Тема регламентных заданий и их влияния на нагрузку подробно разобрана в статье про регламентные задания как тихого убийцу производительности.

Бывает хуже: сеанс завершён на уровне 1С, а соединение с СУБД висит и держит блокировки. Тогда на стороне PostgreSQL смотрим представление pg_stat_activity: нас интересуют строки, где state не равен idle, и в первую очередь idle in transaction и долгие запросы по времени query_start и xact_start. Функция pg_terminate_backend завершает сеанс по его pid; по документации PostgreSQL она отправляет сигнал SIGTERM, а при нулевом timeout возвращает true, даже если процесс ещё не завершился, поэтому для проверки передавайте таймаут в миллисекундах. Это крайняя мера, и применять её нужно только после сверки pid с именем базы и пользователя: ошибившись, вы завершите чужой сеанс. Разбор долгих блокировок на стороне СУБД я вёл в статье про блокировки и deadlock в 1С.

• предупредить пользователей заранее — за 15–30 минут;
• включить блокировку начала сеансов и блокировку регламентных заданий;
• посмотреть session list и завершить оставшиеся сеансы с понятным сообщением;
• проверить PostgreSQL: нет ли висящих транзакций по этой базе;
• только потом снимать резервную копию и обновлять.

Как войти в закрытую базу и обновить её: ключ /UC и снятие блокировки

Когда база закрыта, администратор заходит с кодом разрешения. В Конфигураторе это ключ /UC в строке запуска или в поле дополнительных параметров списка баз. Дальше обычный путь: резервная копия, обновление конфигурации и применение изменений к базе данных. Для командного запуска Конфигуратора используются режим DESIGNER и ключи для обновления конфигурации и конфигурации базы данных; проверьте точный набор ключей в справке своей платформы, потому что у разных версий он отличается. Выгрузку в dt я описывал в материале про резервное копирование 1С без потерь: без свежей копии блокировку включать рано.

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

С файловой базой всё проще и грубее. Консоли кластера и rac нет: файловый режим работает без сервера, поэтому блокировку начала сеансов ставит сама конфигурация — например, через форму блокировки работы пользователей в БСП. Завершить чужой сеанс извне командой вы не можете, остаётся список активных пользователей в Конфигураторе и телефон. Если в такой базе больше пяти-шести человек и обновления идут регулярно, это один из аргументов за переход на клиент-серверный вариант, о чём я писал в материале про переход с файловой базы на клиент-сервер.

• запуск клиента для администратора: ключ /UC и код разрешения;
• снятие блокировки — тем же способом, каким включали: консоль, rac или форма БСП;
• после снятия — пробный вход под обычным пользователем, а не под администратором с кодом.

Скрипт окна обслуживания и разбор на базе питомника «Питомник Гранд»

Покажу, как это выглядело у клиента — питомника «Питомник Гранд», 8 рабочих мест. Бухгалтерская база около 3 ГБ, клиент-серверный вариант на Windows Server с PostgreSQL, платформа 8.3.25. До нас обновления делались по принципу «все вышли»: бухгалтер писала в общий чат, потом кто-то один всё равно оставался в базе, обновление падало на монопольном доступе, администратор из подрядчика перезапускал службу сервера, и в один раз после такого перезапуска пришлось поднимать вчерашнюю копию. Мы заменили это четырьмя шагами: предупреждение, блокировка, завершение сеансов, обновление, разблокировка. Окно сократилось с неопределённого «пока все выйдут» до плановых 40 минут: около 6 минут на dt-выгрузку, 15 минут на обновление и применение, остальное — проверка.

Ниже упрощённый вариант скрипта, который мы запускаем по заданию планировщика Windows в согласованное окно. Идентификаторы кластера и базы скрипт берёт из вывода rac, код разрешения и пароль приходят из переменных окружения. Блок finally снимает блокировку при любом исходе. Скрипт не заменяет проверку: первый запуск делайте на тестовой копии, а в рабочей базе не забывайте о резервной копии до его старта. Путь к rac.exe и номер версии платформы подставьте свои, а структуру вывода rac проверьте один раз руками.

Сам скрипт выглядит так. Идентификатор базы подставьте из вывода команды infobase summary list, а переменные окружения задайте в учётной записи, под которой работает планировщик:

$rac = 'C:\Program Files\1cv8\<версия>\bin\rac.exe'
$srv = 'localhost:1545'
$code = $env:IB_PERMISSION_CODE
$cl = (& $rac $srv cluster list | Select-String '^cluster\s*:' | Select-Object -First 1).ToString().Split(':')[1].Trim()
$ib = '<идентификатор-базы>'
$from = (Get-Date).ToString('yyyy-MM-ddTHH:mm:ss')
$to = (Get-Date).AddHours(2).ToString('yyyy-MM-ddTHH:mm:ss')
try {
  & $rac $srv infobase update --cluster=$cl --infobase=$ib --infobase-user=<admin> --infobase-pwd=$env:IB_ADMIN_PWD --sessions-deny=on --scheduled-jobs-deny=on --denied-from=$from --denied-to=$to --denied-message='Плановое обновление, вход откроем не позднее чем через два часа' --permission-code=$code
  # здесь: session list, terminate, dt-выгрузка, обновление
}
finally {
  & $rac $srv infobase update --cluster=$cl --infobase=$ib --infobase-user=<admin> --infobase-pwd=$env:IB_ADMIN_PWD --sessions-deny=off --scheduled-jobs-deny=off
}

Обратите внимание: в блоке finally пароль тоже берётся из переменной, а не пишется в тексте.

Итог по питомнику: за следующие три плановых обновления не было ни одного случая «не удалось получить монопольный доступ» и ни одной остановки службы сервера. Один раз скрипт нашёл висящий сеанс директора, который ушёл домой, не закрыв программу, и завершил его с понятным сообщением. Администратор клиента получил короткую памятку: где лежит код разрешения, как открыть базу вручную, если задание остановилось, и кому звонить. Дальше мы подключили к этому мониторинг: проверка, что после окна блокировка снята, — единственная проверка, которая реально окупилась с первой недели.

• T-60 минут: рассылка пользователям с точным временем закрытия;
• T-15 минут: включена блокировка регламентных заданий, повторное предупреждение;
• T-0: блокировка начала сеансов, завершение оставшихся сеансов, проверка PostgreSQL;
• T+5: резервная копия dt и обновление;
• T+40: проверка под обычным пользователем, снятие блокировки.

Типичные ошибки при блокировке соединений и как их исправить

Первая ошибка — путать запрет новых сеансов с завершением старых. Включили флаг, ушли пить чай, а обновление не стартует. Вторая — не снять блокировку: актуально для бессрочных блокировок, поэтому ставьте конец интервала и сообщение с временем. Третья — потерять код разрешения. Тогда спасает консоль кластера: отключите флаг в свойствах базы. Четвёртая — забыть про регламентные задания и обмены: они не пользователи, но держат базу не хуже. Пятая — закрывать базу, не сняв копию. Блокировка не защищает данные, она только создаёт тишину, в которой удобно делать работу.

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

Частые вопросы