База 1С на сервере занята сеансами СУБД: как найти и снять блокировку

Когда 1С Сервер пишет, что база захвачена СУБД, обычно не работает именно монопольный доступ. Обновление, загрузка .dt или реструктуризация упираются в чужое соединение: либо сеанс пользователя, либо рабочий процесс кластера, либо отдельная сессия самой СУБД. Лечится это по порядку: сначала кластер 1С, потом PostgreSQL или MS SQL Server.

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

Когда базе нужен монопольный доступ и откуда берётся «захват»

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

Конфликт возникает, когда в базе уже есть соединения. Типичные источники:

• 👤 сеансы пользователей, которые забыли закрыть окно или ушли в спящий режим;
• ⚙️ фоновые и регламентные задания, запущенные кластером;
• 🔌 соединения внешних систем: обмены, веб-сервисы, BI-инструменты;
• 🗄️ «осиротевшие» сессии СУБД после аварийно закрытого рабочего процесса;
• 📊 долгая транзакция, которую держит запрос, не завершившийся по таймауту.

Первые три пункта видны в 1С. Последние два видны только на стороне СУБД. Поэтому диагностику начинают с кластера, а потом идут вглубь.

Диагностика: кто сейчас держит базу

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

Раздел «Соединения» показывает рабочие процессы, подключённые к базе. Если сеансов нет, а соединения остались, значит рабочий процесс держит их сам.

То же самое доступно из командной строки через утилиту rac, которая идёт в составе сервера 1С:

rac cluster list
rac infobase summary list --cluster=<идентификатор_кластера>
rac session list --cluster=<идентификатор_кластера>

Идентификатор кластера возьмите из вывода первой команды. Остальные параметры и их точные названия уточняйте в справке: rac help.

Запрет входа и регламентных заданий на время работ

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

В свойствах информационной базы в консоли кластера включите блокировку начала сеансов и задайте время её действия. Можно указать сообщение для пользователей и код разрешения. Администратор потом заходит с параметром /UC и этим кодом, тогда блокировка на него не действует.

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

Порядок такой:

1. Предупредите пользователей и назначьте время.
2. Включите блокировку начала сеансов и блокировку регламентных заданий.
3. Завершите оставшиеся сеансы в консоли.
4. Только потом заходите в конфигуратор или запускайте обновление в монопольном режиме.
5. После работ снимите обе блокировки.

Блокировку можно включать и из скрипта через rac, если вы автоматизируете окно обслуживания. Точные параметры команды смотрите в rac help для вашей версии платформы.

Снимаем блокировки в PostgreSQL

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

Сначала посмотрите, что вообще подключено к базе:

SELECT pid, usename, application_name, state,
       xact_start, query_start, wait_event_type, left(query, 120) AS query
FROM pg_stat_activity
WHERE datname = 'имя_базы'
ORDER BY xact_start NULLS LAST;

Подозрительны сессии со статусом idle in transaction и старым xact_start. Это транзакции, которые открылись и не закрылись. Именно они держат блокировки.

Чтобы увидеть, кто кого блокирует, используйте pg_blocking_pids:

SELECT a.pid AS ждёт, pg_blocking_pids(a.pid) AS его_блокируют
FROM pg_stat_activity a
WHERE cardinality(pg_blocking_pids(a.pid)) > 0;

Если нашли виновника, сначала мягко отмените его запрос:

SELECT pg_cancel_backend(12345);

Эта команда отменяет текущий запрос, но не разрывает соединение. Если не помогло, завершайте сессию целиком:

SELECT pg_terminate_backend(12345);

Вместо 12345 подставьте pid из первого запроса. Массово «убить всё по базе» можно так же, но делайте это только при остановленных пользователях и заблокированном входе.

Управление сессиями в MS SQL Server

В MS SQL Server откройте SQL Server Management Studio и подключитесь с правами, достаточными для просмотра активности.

Быстрый обзор даёт хранимая процедура:

EXEC sp_who2;

В выводе смотрите колонки DBName, Status, BlkBy (кто блокирует) и Command. Если в BlkBy стоит номер, это спид блокирующей сессии.

Подробнее — через динамические представления:

SELECT r.session_id, r.blocking_session_id, r.wait_type,
       r.wait_time, DB_NAME(r.database_id) AS db, t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0;

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

KILL 57;

Вместо 57 подставьте номер сессии. После KILL СУБД откатывает транзакцию, и это может занять столько же времени, сколько она выполнялась. Прогресс смотрят так:

KILL 57 WITH STATUSONLY;

Не перезапускайте службу SQL Server из-за долгого отката: при старте откат повторится, и база будет недоступна ещё дольше.

Когда база переведена в однопользовательский режим

Иногда администратор вручную переводит базу в SINGLE_USER, а потом забывает вернуть. Тогда обычные соединения 1С не проходят вовсе. Проверить режим:

SELECT name, user_access_desc FROM sys.databases WHERE name = N'имя_базы';

Если стоит SINGLE_USER, а работа окончена, верните многопользовательский режим:

ALTER DATABASE [имя_базы] SET MULTI_USER;

Если команда ждёт, значит, в базе висит чужое соединение. Найдите его через sp_who2 и завершите, как описано выше.

Фоновые задания и обновление: как не нарваться на конфликт

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

📋 До обновления:

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

⚙️ Во время:

• не запускайте обновление из двух мест сразу;
• не держите открытым конфигуратор «на всякий случай»: он тоже займёт сеанс.

✅ После:

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

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

Профилактика: как реже сталкиваться с захватом

Главная причина повторов — привычки. Пара настроек их заметно снижает.

• 🕐 Окно обслуживания. Выберите время без пользователей и держите все тяжёлые операции в нём: обновление, пересчёт итогов, реиндексацию, сжатие.
• 🔒 Блокировка входа через расписание. Включайте блокировку начала сеансов перед окном обслуживания, а не после.
• 🧹 Служебное обслуживание СУБД. Для PostgreSQL это регулярный VACUUM/ANALYZE, для MS SQL — обновление статистики и работа с индексами. Запускайте их в то же окно.
• 👀 Контроль долгих транзакций. Хотя бы раз в день запрос к pg_stat_activity или sys.dm_exec_requests за транзакциями старше часа показывает проблему до того, как она сорвёт обновление.
• 📝 Единая точка входа. Администратор работает с кластером под одной учётной записью и по регламенту, а не «как получится».

Типичные сценарии и что в них делать

Три ситуации встречаются чаще остальных. Разберём каждую с конкретными действиями.

Утром не открывается база после ночного обновления

Обычно ночью обновление оборвалось, а соединение осталось. В консоли кластера сеансов нет, но монопольный доступ не включается. Проверьте в СУБД idle in transaction (PostgreSQL) или сессии с открытой транзакцией (sp_who2, колонка Status). Завершите её, затем повторите обновление. Если ночью падал сервер, перед повторным обновлением проверьте целостность копии базы.

Конфигуратор выдаёт отказ при включении монопольного режима

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

Тяжёлая операция упирается в блокировки при работающих пользователях

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

Что проверить на стороне сервера, если «захваты» повторяются

Если после каждого обновления одно и то же, дело не в одной сессии. Пройдитесь по списку.

1. Хватает ли памяти. Когда СУБД и рабочие процессы 1С делят одну машину и нехватка оперативной памяти заставляет систему свопить, транзакции растягиваются в разы. Они держат блокировки дольше и кажутся «зависшими».
2. Не конкурирует ли резервное копирование . Если копия базы запускается в тот же час, что и обновление, они мешают друг другу. Разнесите их.
3. Сколько рабочих процессов и баз на кластере. Перегруженный сервер замедляет всё. Если несколько тяжёлых баз живут вместе, разнесите их по разным рабочим серверам.
4. Регулярность служебных операций. Давно не обновлялась статистика или раздуты таблицы — запросы идут долго, и вы видите «захват» там, где виновата медленная работа.
5. Версии. Старая версия платформы с известной ошибкой в работе с СУБД может оставлять висящие соединения. Проверьте, что версия платформы и СУБД сочетаются и не устарели.

Как не навредить, когда завершаешь сеансы

Принудительное завершение — крайняя мера, и у неё есть правила.

• 🚫 Не завершайте сеансы СУБД, если не уверены, чьи они. На одном сервере СУБД часто живут несколько баз, и чужая сессия может принадлежать соседней системе.
• 🚫 Не завершайте системные процессы СУБД: они нужны ей самой.
• ✅ Перед массовым завершением зафиксируйте список: сохраните вывод pg_stat_activity или sp_who2 в файл.
• ✅ Если сессия принадлежит пользователю, лучше сначала позвонить ему.
• ✅ Если возможно, перенесите операцию на ночь, а не рвите сеансы днём.

Если после всех шагов база по-прежнему занята и причина непонятна, остановите службы сервера 1С в согласованное окно, проверьте сессии в СУБД, затем запустите службы снова. Этот шаг оборвёт работу всех баз кластера, поэтому предупредите всех заранее.

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