Блокировка базы 1С 8.3: rac, SQL-запросы и скрипты для администратора

Чтобы снять блокировку 1С через консоль, выполните на сервере rac infobase update с параметрами --sessions-deny=off и --scheduled-jobs-deny=off. Команда работает через службу ras и снимает запрет на вход пользователей и запуск регламентных заданий. Если базу держит зависший сеанс или транзакция в СУБД, нужна другая команда: rac session terminate или KILL / pg_terminate_backend на уровне SQL.

Всё ниже относится к платформе 1С:Предприятие 8.3 в клиент-серверном варианте. Для файловой базы консоли кластера нет, у неё свой отдельный способ, он описан в разделе про альтернативы.

Какую блокировку 1С вы снимаете

Под словом «блокировка» администраторы имеют в виду четыре разные ситуации. Команды для них разные, поэтому сначала определите свою.

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

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

Подготовка: служба ras, утилита rac и пароли

Консольная утилита rac не подключается к кластеру напрямую. Она обращается к серверу администрирования ras, а тот уже к агенту сервера 1С (порт 1540). По умолчанию ras слушает порт 1545.

Что понадобится до начала работы:

1. 🖥 Доступ к серверу 1С или к машине, где установлена та же версия платформы. Утилиты лежат в каталоге bin платформы, например C:\Program Files\1cv8\8.3.xx.xxxx\bin\rac.exe.
2. ⚙️ Запущенный ras. В Windows его регистрируют службой, в Linux запускают демоном.
3. 🔑 Логин и пароль администратора кластера, если он задан.
4. 👤 Логин и пароль пользователя информационной базы с правами администратора. Без них команда изменения свойств базы вернёт отказ.

Запуск ras вручную для проверки:

cd "C:\Program Files\1cv8\8.3.xx.xxxx\bin"
ras.exe cluster --port=1545 localhost:1540

В Linux:

/opt/1cv8/x86_64/8.3.xx.xxxx/ras cluster --daemon

Проверьте связь: rac.exe localhost:1545 cluster list. Если в ответе есть строка cluster : <идентификатор>, всё готово. Скопируйте этот идентификатор, он нужен во всех следующих командах.

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

Порядок действий для одной базы.

Шаг 1. Получите идентификатор кластера:

rac.exe localhost:1545 cluster list

Шаг 2. Найдите идентификатор информационной базы:

rac.exe localhost:1545 infobase summary list --cluster=<id_кластера> --cluster-user=admin --cluster-pwd=secret

В выводе ищите блок, где name совпадает с именем вашей базы, и берите значение infobase. Параметры --cluster-user и --cluster-pwd пропустите, если администратор кластера не назначен.

Шаг 3. Посмотрите текущее состояние блокировки:

rac.exe localhost:1545 infobase info --cluster=<id_кластера> --infobase=<id_базы> --infobase-user=Администратор --infobase-pwd=123

В ответе есть поля sessions-deny, scheduled-jobs-deny, denied-from, denied-to, denied-message и permission-code. Значение on у первых двух и означает включённую блокировку.

Шаг 4. Снимите её:

rac.exe localhost:1545 infobase update --cluster=<id_кластера> --infobase=<id_базы> --infobase-user=Администратор --infobase-pwd=123 --sessions-deny=off --scheduled-jobs-deny=off

Шаг 5. Повторите infobase info и убедитесь, что оба флага стали off. Попросите одного пользователя зайти в базу.

Та же команда умеет и ставить блокировку. Для этого задайте --sessions-deny=on, время окончания в --denied-to и текст для пользователей в --denied-message. Точный формат даты и полный список параметров выводит rac help infobase.

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

Иногда флаг блокировки снят, а работать всё равно нельзя: обновление пишет, что есть активные соединения, или пользователь давно ушёл, а лицензия занята. Тогда смотрите сеансы.

Список сеансов конкретной базы:

rac.exe localhost:1545 session list --cluster=<id_кластера> --infobase=<id_базы>

Для каждого сеанса выводятся session (идентификатор), user-name, host, app-id, started-at и last-active-at. По ним видно, кто сидит в базе и когда последний раз что-то делал.

Признаки зависшего сеанса:

• 🕰 last-active-at отстаёт от текущего времени на часы;
• 💻 host указывает на компьютер, который уже выключен;
• 🔁 один пользователь «сидит» в базе несколько раз с одного хоста;
• ⚙️ app-id равен BackgroundJob и задание давно не завершается.

Завершение одного сеанса:

rac.exe localhost:1545 session terminate --cluster=<id_кластера> --session=<id_сеанса>

Кроме сеансов, у rac есть объекты connection (соединения с рабочими процессами) и process (сами рабочие процессы rphost). Смотреть их полезно, когда сеанс уже завершён, а соединение осталось. Подкоманды для них выводит rac help connection.

Перезапуск рабочего процесса или службы агента сервера 1С обрывает работу всех пользователей всех баз кластера. Это крайняя мера, только в нерабочее время.

Снятие блокировки 1С на уровне СУБД

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

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

MS SQL Server

Откройте SQL Server Management Studio или sqlcmd и выполните:

SELECT r.session_id,
       r.blocking_session_id,
       r.wait_type,
       r.wait_time / 1000 AS wait_sec,
       s.host_name,
       s.program_name,
       DB_NAME(r.database_id) AS db_name
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON s.session_id = r.session_id
WHERE r.blocking_session_id <> 0;

В колонке blocking_session_id стоит номер сеанса, который держит блокировку. Если он сам кого-то ждёт, идите дальше по цепочке до сеанса, который никого не ждёт. Это и есть виновник.

Завершение:

KILL 57;

где 57 — найденный номер. Откат большой транзакции может занять время. Ход отката показывает KILL 57 WITH STATUSONLY;.

Отдельный случай: после неудачной операции база осталась в однопользовательском режиме SQL Server, и 1С к ней не подключается. Возврат:

ALTER DATABASE [buh] SET MULTI_USER WITH ROLLBACK IMMEDIATE;

PostgreSQL

Подключитесь через psql под пользователем СУБД, от которого работает 1С, или под суперпользователем:

SELECT pid,
       pg_blocking_pids(pid) AS blocked_by,
       usename,
       client_addr,
       state,
       now() - xact_start AS tx_duration,
       left(query, 80) AS query
FROM pg_stat_activity
WHERE datname = 'buh'
  AND cardinality(pg_blocking_pids(pid)) > 0;

В blocked_by — номера процессов, которые держат блокировку. Посмотрите их отдельно: SELECT pid, state, now() - xact_start, left(query, 80) FROM pg_stat_activity WHERE pid = 12345;. Состояние idle in transaction у такого процесса — частый признак зависшего соединения.

Сначала попробуйте мягко отменить запрос, потом завершить процесс:

SELECT pg_cancel_backend(12345);
SELECT pg_terminate_backend(12345);

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

Если базу регулярно блокирует ночное обновление, держите под рукой bat-файл. Идентификаторы кластера и базы постоянны, их достаточно один раз узнать и вписать.

@echo off
chcp 65001 >nul
set RAC="C:\Program Files\1cv8\8.3.xx.xxxx\bin\rac.exe"
set SRV=localhost:1545
set CL=11111111-2222-3333-4444-555555555555
set IB=66666666-7777-8888-9999-000000000000
set IBUSER=Администратор
set IBPWD=123

%RAC% %SRV% infobase update --cluster=%CL% --infobase=%IB% ^
  --infobase-user=%IBUSER% --infobase-pwd=%IBPWD% ^
  --sessions-deny=off --scheduled-jobs-deny=off

if errorlevel 1 (
  echo Ошибка: блокировка не снята >> C:\scripts\unlock.log
  exit /b 1
)
%RAC% %SRV% infobase info --cluster=%CL% --infobase=%IB% ^
  --infobase-user=%IBUSER% --infobase-pwd=%IBPWD% | findstr "deny" >> C:\scripts\unlock.log

Как использовать:

1. Узнайте идентификаторы командами из раздела про rac и впишите в CL и IB.
2. Сохраните файл, например C:\scripts\unlock-buh.bat. Если кириллица в логине ломается, сохраните файл в UTF-8 или заведите в базе служебного пользователя с латинским именем.
3. Ограничьте доступ к папке: в файле лежит пароль администратора базы.
4. Добавьте задание в планировщик Windows на время после окна обслуживания, например на 06:30. Тогда даже упавшее обновление не оставит бухгалтерию без базы утром.

В Linux тот же набор команд кладётся в shell-скрипт и запускается через cron.

Другие способы, если консоль недоступна

Консоль администрирования серверов 1С

Графическая оснастка делает то же самое, что rac. Раскройте Кластеры → <кластер> → Информационные базы, откройте свойства базы и снимите флажки «Блокировка начала сеансов включена» и «Блокировка регламентных заданий включена». Сеансы завершаются из узла Сеансы через контекстное меню.

Параметры запуска 1С

Если при блокировке задан код разрешения, войти в базу можно с параметром /UC:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S"srv1c\buh" /N"Администратор" /P"123" /UC"KOD123"

В типовых конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11) блокировку можно снять запуском с ключом /C"РазрешитьРаботуПользователей" вместе с тем же /UC. Внутри программы то же делается в разделе Администрирование → Обслуживание, команда «Блокировка работы пользователей».

Файловая база

В файловом варианте кластера нет. Блокировку начала сеансов платформа хранит в файле 1Cv8.cdn в каталоге базы. Если блокировка осталась после сбоя и войти нельзя, переименуйте этот файл.

Файл 1Cv8.1CL — это признак того, что базу кто-то открыл. Его удаляют, только когда точно никто не работает . Если база на общей папке, проверьте, кто держит 1Cv8.1CD: Управление компьютером → Общие папки → Открытые файлы. Оттуда можно закрыть файл у конкретного пользователя.

Ошибки при снятии блокировки и как их не повторять

Как не попадать в эту ситуацию снова:

• ⏳ Ставьте блокировку сразу с временем окончания (--denied-to). Даже если обновление упадёт, вход откроется сам.
• 🔐 Задавайте код разрешения: администратор зайдёт через /UC, остальные будут ждать.
• 🗓 Разносите по времени обслуживание SQL (индексы, статистика) и тяжёлые регламентные задания.
• 📋 Раз в неделю смотрите session list на «вечные» сеансы и фоновые задания, которые не заканчиваются.

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