«1С захвачено СУБД»: в чем измеряется блокировка и как её устранить

Сообщение «1С захвачено СУБД» — одна из самых распространённых ошибок, с которой сталкиваются пользователи и администраторы 1С:Предприятие. Она возникает, когда система не может получить доступ к базе данных из-за активных блокировок со стороны СУБД (например, Microsoft SQL Server, PostgreSQL или IBM DB2). Но что именно означает «захвачено», в каких единицах измеряется эта блокировка и как её правильно диагностировать?

В этой статье мы разберёмся:

• 🔹 Что такое «захват СУБД»** и почему он происходит (технические причины).
• 📏 В каких единицах измеряется блокировка** — секунды, транзакции или что-то ещё?
• 🛠️ Как найти и убить «висящие» сессии** без риска для данных.
• ⚙️ Настройки 1С и СУБД**, которые помогут избежать проблемы в будущем.

Ошибка может проявляться по-разному: от кратковременных «подвисаний» до полной невозможности открыть базу. Чаще всего она связана с длительными транзакциями, некорректным завершением работы 1С или конфликтами блокировок между пользователями. Далее — подробный разбор.

1. Что значит «1С захвачено СУБД» — техническое объяснение

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

• 🔄 Длительная транзакция — например, массовая обработка документов, которая не завершилась.
• 💻 «Подвисший» сеанс пользователя — когда 1С аварийно закрылась, но блокировка в СУБД осталась.
• 🔒 Конфликт блокировок — когда две сессии пытаются изменить одни и те же данные.
• 🛑 Административная блокировка — например, резервное копирование или обслуживание базы.

Важно понимать, что 1С не блокирует саму себя — блокировка происходит на уровне СУБД. Например, в Microsoft SQL Server это могут быть:

• 🔗 Shared (S) блокировки (для чтения).
• 🔒 Exclusive (X) блокировки (для записи).
• 🔄 Update (U) блокировки (перед изменением).

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

⚠️ Внимание: В файловом режиме (1С:Предприятие 8.3 без СУБД) подобная ошибка может означать повреждение файла базы (1Cv8.1CD). В этом случае требуется проверка и восстановление через chdbfl.exe.

2. В чём измеряется «захват СУБД» — метрики блокировок

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

Например, в Microsoft SQL Server можно выполнить запрос:

SELECT
t.session_id,
s.login_name,
t.transaction_id,
l.resource_type,
l.request_mode,
l.request_status,
DATEDIFF(ms, t.transaction_begin_time, GETDATE()) AS duration_ms
FROM
sys.dm_tran_locks l
JOIN
sys.dm_tran_active_transactions t ON l.lock_owner_address = t.transaction_id
JOIN
sys.dm_exec_sessions s ON t.session_id = s.session_id
WHERE
l.request_status = 'GRANTED';

Этот запрос покажет все активные блокировки, их тип, время удержания (в миллисекундах) и какая сессия их удерживает.

3. Как найти и убить «висящую» сессию в СУБД

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

🔹 Для Microsoft SQL Server

1. Откройте SQL Server Management Studio (SSMS).
2. Выполните запрос для поиска блокировок:

   SELECT
   session_id,
   login_name,
   host_name,
   program_name,
   last_request_start_time,
   last_request_end_time
   FROM
   sys.dm_exec_sessions
   WHERE
   is_user_process = 1;

3. Найдите сессию с долгим временем выполнения (last_request_start_time).
4. Завершите её командой:

   KILL {session_id};

🔹 Для PostgreSQL

1. Подключитесь к базе через psql или pgAdmin.
2. Найдите блокирующие процессы:

   SELECT
   pid,
   usename,
   query,
   now() - query_start AS duration
   FROM
   pg_stat_activity
   WHERE
   state = 'active';

3. Завершите проблемный процесс:

   SELECT pg_terminate_backend({pid});

Проверьте, что сессия действительно «висячая» (время > 5 минут)

Убедитесь, что это не критичная транзакция (например, резервное копирование)

Сохраните лог активных запросов для анализа

Предупредите пользователей о возможном разрыве соединения-->

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

4. Типичные причины ошибки «1С захвачено СУБД»

Ошибка редко возникает сама по себе — обычно ей предшествуют конкретные действия или сбои. Вот наиболее частые причины:

• 🖥️ Аварийное завершение 1С — пользователь закрыл программу через «Диспетчер задач» или произошел сбой электропитания.
• ⏳ Длительные операции — массовое проведение документов, перепроводка, обмен данными с внешними системами.
• 🔄 Конфликты при репликации — если используется кластер СУБД или зеркалирование.
• 🔒 Ручные блокировки — администратор базы данных вручную заблокировал таблицы для обслуживания.
• 🐌 Неоптимизированные запросы — медленные SQL-запросы, которые долго удерживают блокировки.

Критическая информация: В 80% случаев проблема связана с некорректным завершением сеансов 1С. Если в вашей организации часто «вылетает» 1С, настройте автоматическое завершение «висячих» сессий через SQL Agent (для SQL Server) или cron (для PostgreSQL).

Чтобы диагностировать причину, проверьте:

• 📅 Журналы 1С (1Cv8.log, 1Cv8Err.log) на наличие ошибок.
• 📊 Логи СУБД — в них могут быть записи о тайм-аутах или дедлоках.
• 🔍 Монитор производительности — если блокировки происходят в пиковые часы нагрузки.

5. Настройки 1С и СУБД для профилактики блокировок

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

🔧 Настройки 1С:Предприятие

• 🕒 Тайм-аут ожидания блокировки — в 1Cv8.ini добавьте:

  [DB]
  DBLockWaitTime=30000 ; 30 секунд (по умолчанию 20000)

• 🔄 Автоматическое освобождение блокировок — включите параметр:

  AutoDisconnect=1

• 📡 Ограничение длительных операций — настройте фоновые задания через Регламентные задания.

⚙️ Настройки Microsoft SQL Server

• 🔒 Уровень изоляции транзакций — используйте READ COMMITTED SNAPSHOT для уменьшения блокировок:

  ALTER DATABASE [YourDB] SET READ_COMMITTED_SNAPSHOT ON;

• ⏱️ Тайм-аут блокировок — настройте через:

  EXEC sp_configure 'remote query timeout', 300;
  RECONFIGURE;

• 📊 Мониторинг блокировок — настройте оповещения через SQL Server Agent.

🐘 Настройки PostgreSQL

• ⏳ Тайм-аут блокировки — в postgresql.conf:

  lock_timeout = '30s' ; максимальное время ожидания блокировки

• 🔄 Автоочистка — включите autovacuum для предотвращения «раздувания» таблиц.

⚠️ Внимание: Изменение уровня изоляции транзакций (READ COMMITTED SNAPSHOT) может повлиять на логику работы некоторых отчётов в 1С. Перед применением протестируйте на копии базы.

6. Как восстановить работу 1С после блокировки

Если база уже «захвачена», следуйте этому алгоритму:

1. Попробуйте переподключиться — иногда проблема решается повторным входом в 1С.
2. Проверьте сессии в СУБД (инструкции в разделе 3).
3. Завершите проблемные сессии через KILL (SQL Server) или pg_terminate_backend (PostgreSQL).
4. Перезапустите службу 1С:

   net stop "1C:Enterprise 8.3 Server Agent"
   net start "1C:Enterprise 8.3 Server Agent"

5. Проверьте целостность базы:

   CHECKDB [YourDB] WITH NO_INFOMSGS;

Если после этих действий ошибка сохраняется:

• 🔄 Восстановите базу из резервной копии (если блокировка привела к повреждениям).
• 📞 Обратитесь к администратору СУБД — возможно, требуется глубокая диагностика.

В файловом режиме (1С без СУБД) при ошибке «База захвачена монопольно»:

1. Закройте все сессии 1С на сервере и рабочих станциях.
2. Проверьте, не запущен ли процесс ragent.exe или rmngr.exe в Диспетчере задач.
3. Если база повреждена, выполните:

   chdbfl.exe -f "C:\Path\To\Your\Base\1Cv8.1CD"

7. Частые вопросы (FAQ)

DECLARE @kill varchar(8000) = '';
SELECT @kill = @kill + 'KILL ' + CAST(session_id AS varchar(5)) + ';'
FROM sys.dm_exec_sessions
WHERE status = 'sleeping' AND last_request_end_time < DATEADD(minute, -15, GETDATE());

EXEC(@kill);

SELECT
t1.resource_type,
t1.resource_database_id,
t1.request_mode,
t1.request_session_id,
t2.blocking_session_id
FROM
sys.dm_tran_locks t1
JOIN
sys.dm_os_waiting_tasks t2 ON t1.lock_owner_address = t2.resource_address;

SELECT
blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement
FROM
pg_catalog.pg_locks blocked_locks
JOIN
pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN
pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN
pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE
NOT blocked_locks.GRANTED;