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

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

Способ снятия блокировки зависит от её источника. Если включена блокировка соединений через консоль кластера или функциональную опцию, достаточно отключить её в настройках базы. Если мешают активные сеансы — их нужно корректно завершить. Если блокировка на уровне СУБД (MS SQL, PostgreSQL), потребуется работа с активными подключениями на стороне сервера баз данных.

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

Определяем тип блокировки

Прежде чем что-то снимать, нужно понять, что именно заблокировано. Различают три уровня: блокировка начала сеансов (установлена администратором или регламентным заданием), активные сеансы, удерживающие базу, и блокировки на уровне СУБД. Сообщение об ошибке при входе обычно указывает на первый вариант — там же часто виден текст, который администратор вписал при установке блокировки.

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

Снятие блокировки через консоль кластера серверов

Основной инструмент — консоль администрирования серверов 1С (она же оснастка «Администрирование серверов 1С Предприятия»). Откройте её на сервере или с машины администратора, разверните нужный кластер, перейдите в раздел «Информационные базы» и найдите свою базу.

Откройте свойства базы двойным щелчком. Найдите параметр «Блокировка начала сеансов включена» и снимите флаг. Если в полях «Начало» и «Конец» стоят даты — блокировка могла быть установлена на расписание, проверьте и очистите эти значения. Сохраните изменения кнопкой «ОК», затем попросите пользователя повторить вход.

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

1. 1
   Откройте консоль администрирования серверов 1С
2. 2
   Разверните кластер и перейдите в «Информационные базы»
3. 3
   Откройте свойства нужной базы
4. 4
   Снимите флаг «Блокировка начала сеансов включена» и очистите даты расписания
5. 5
   Сохраните и проверьте вход пользователя в базу

Завершение зависших сеансов и соединений

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

Зависший сеанс обычно узнаваем по давнему времени последнего вызова при том, что пользователь физически уже не работает (компьютер выключен, программа закрыта аварийно). Такой сеанс завершайте через контекстное меню — «Удалить». Действие безопасно для данных: транзакции к этому моменту обычно уже завершены или откачены.

Если сеансов много и нужно освободить базу полностью, удобнее сначала включить блокировку начала сеансов (чтобы никто не входил заново), дождаться выхода активных пользователей и только потом удалять оставшиеся зависшие сеансы. Также проверьте вкладку «Соединения» — иногда соединение остаётся после удаления сеанса и его тоже нужно отключить.

Снятие блокировки, установленной из конфигуратора

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

Порядок действий: убедитесь, что процесс конфигуратора действительно не работает ни на одном компьютере (проверьте диспетчер задач на машине, с которой запускалось обновление). Затем снимите блокировку через консоль кластера, как описано выше. После этого обязательно проверьте целостность: зайдите в конфигуратор и выполните «Тестирование и исправление» в режиме проверки логической целостности, либо повторно запустите обновление конфигурации базы данных — если структура уже приведена в соответствие, оно завершится быстро.

Блокировки на уровне СУБД

Иногда проблема глубже: на сервере баз данных остаются активные подключения с блокировками таблиц. Для MS SQL Server откройте Management Studio и посмотрите активность через «Activity Monitor» или запрос к sys.dm_exec_requests и sys.dm_tran_locks. Зависший процесс завершите командой KILL с номером SPID, предварительно убедившись, что это не активная рабочая транзакция.

Для PostgreSQL активные подключения смотрят через представление pg_stat_activity, а завершают функцией pg_terminate_backend(pid). Признак проблемы — длинные запросы в состоянии active или idle in transaction, которые висят часами.

Крайняя мера — перезапуск службы СУБД или службы агента сервера 1С. Она снимает все блокировки разом, но обрывает и все живые соединения, поэтому применяется только в нерабочее время или при полной недоступности других методов.

SELECT pid, state, query_start, query FROM pg_stat_activity WHERE datname = 'my_base' AND state <> 'idle';

Проверка результата и профилактика

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

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

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