Администрирование · 10 мин
Захвачено СУБД в 1С: причины блокировки и способы её снять
Что означает ошибка «захвачено СУБД» в 1С, почему возникают блокировки базы данных и как их снять в файловом и клиент-серверном режиме без потери данных.
Сообщение о том, что объект «захвачен СУБД», появляется в 1С, когда платформа пытается выполнить действие с данными, которые в этот момент заблокированы на уровне системы управления базами данных. Типичные тексты ошибок: «Конфликт блокировок при выполнении транзакции», «Превышено время ожидания блокировки», «Ошибка СУБД: Lock request time out period exceeded». Все они говорят об одном: два процесса претендуют на один и тот же ресурс, и один из них вынужден ждать или завершиться с ошибкой.
Важно понимать, что блокировка сама по себе — не сбой, а штатный механизм защиты целостности данных. СУБД не позволяет двум пользователям одновременно изменить одну и ту же запись, иначе итог был бы непредсказуемым. Проблемой блокировка становится, когда она длится слишком долго, возникает взаимоблокировка (deadlock) или соединение с базой оборвалось, а блокировка «зависла» и не снялась.
Дальше разберём, чем отличаются управляемые и транзакционные блокировки, как определить, кто держит ресурс, и как безопасно снять захват в файловом и клиент-серверном вариантах работы.
Что на самом деле означает «захвачено СУБД»
В клиент-серверном варианте 1С работает поверх MS SQL Server, PostgreSQL, Oracle или IBM Db2. Когда пользователь проводит документ или изменяет элемент справочника, платформа открывает транзакцию, и СУБД накладывает блокировку на затронутые строки или таблицы. Пока транзакция не завершена (не выполнен COMMIT или ROLLBACK), другие сеансы, которым нужны те же данные, встают в очередь ожидания.
Если ожидание превышает установленный таймаут (по умолчанию в настройках СУБД это обычно десятки секунд), ожидающий сеанс получает ошибку — её и видит пользователь как «захвачено СУБД» или «конфликт блокировок». Отдельный случай — взаимоблокировка: сеанс А держит ресурс 1 и ждёт ресурс 2, а сеанс Б держит ресурс 2 и ждёт ресурс 1. СУБД сама выбирает «жертву» и откатывает одну из транзакций.
В файловом варианте роль СУБД выполняет собственный движок 1С, и блокировки там накладываются на уровне таблиц целиком. Поэтому в файловых базах конфликты возникают чаще: один проводящий документ пользователь может заблокировать целый регистр для всех остальных.
Типичные причины захвата базы
Чаще всего к ошибке приводят несколько повторяющихся ситуаций. Первая — длительные операции: групповое перепроведение, закрытие месяца, загрузка большого пакета данных, восстановление последовательностей. Пока такая операция идёт, она удерживает блокировки на значительной части таблиц.
Вторая причина — регламентные и фоновые задания, запущенные в часы активной работы пользователей. Обмен данными с другой базой, расчёт итогов, обновление индексов полнотекстового поиска в разгар рабочего дня почти гарантированно создадут конфликты.
Третья группа причин — технические сбои: обрыв соединения клиента с сервером, «зависший» сеанс, аварийно закрытый клиент. Сеанс на сервере при этом может остаться живым и продолжать держать блокировку, хотя пользователь уже видит перед собой закрытую программу. Наконец, конфликты провоцируют ошибки в коде: транзакция, открытая и не закрытая, или обращение к объектам в разном порядке в разных процедурах — классический источник взаимоблокировок.
Проверьте, не запускал ли он сам тяжёлую операцию в другом окне
Ищите активный фоновый процесс или зависший сеанс
Сверьте время с расписанием регламентных заданий и обменов
Проверьте список активных сеансов в консоли кластера
Как найти, кто держит блокировку
Первый инструмент — консоль кластера серверов 1С. Откройте ветку «Сеансы» нужной информационной базы и отсортируйте по времени начала или по признаку «блокирует». Зависшие сеансы обычно заметны: они активны давно, хотя пользователь уже не работает, либо принадлежат фоновому заданию, которое по логике должно было завершиться.
Второй источник — сама СУБД. В MS SQL Server активные блокировки видны через представление sys.dm_tran_locks и активность в Activity Monitor, в PostgreSQL — через представление pg_locks и pg_stat_activity. По идентификатору процесса можно сопоставить блокировку с сеансом 1С и понять, какой пользователь или задание её удерживает.
Для регулярной диагностики включите технологический журнал с событием TLOCK или TDEADLOCK — он фиксирует, какие объекты конфликтовали и в каком контексте. Это особенно полезно, когда блокировки возникают периодически и поймать их «вживую» не удаётся.
- 1Откройте консоль кластера и посмотрите список сеансов проблемной базы
- 2Найдите сеансы с аномально долгим временем работы или фоновые задания
- 3Уточните у пользователя, не запущена ли у него тяжёлая операция
- 4При необходимости проверьте блокировки на стороне СУБД (Activity Monitor, pg_locks)
- 5Завершите проблемный сеанс через консоль кластера
- 6Попросите пострадавших пользователей повторить операцию
Как снять захват: безопасные способы
Самый мягкий вариант — подождать. Если блокировку держит штатная операция (проведение большого документа, обмен), она завершится сама, и повторная попытка через несколько минут пройдёт успешно. Прерывать такую операцию не стоит: откат большой транзакции может занять не меньше времени, чем её выполнение.
Если операция зависла, завершите сеанс через консоль кластера: правый клик по сеансу → «Удалить». СУБД откатит незавершённую транзакцию и снимет блокировки. Для фоновых заданий сначала попробуйте корректную отмену через консоль заданий, и только потом — удаление сеанса.
Крайняя мера для файловой базы — завершить работу всех пользователей и перезапустить службу агента сервера или просто закрыть все сеансы. Удалять файл блокировок или сам файл базы 1Cv8.1CD, а также перезагружать сервер СУБД «вслепую» нельзя: это почти гарантированно приведёт к повреждению данных или к рассогласованию транзакций.
Особенности файлового и клиент-серверного режимов
В файловом варианте блокировки накладываются на таблицы целиком, поэтому конфликты возникают даже при работе с разными записями одного регистра. Если в файловой базе постоянно появляется «захвачено СУБД», это сигнал о том, что число одновременно работающих пользователей выросло и пора рассматривать переход на клиент-серверный режим.
В клиент-серверном варианте платформа использует управляемые блокировки: они накладываются на конкретные записи по определённым полям и позволяют параллельно работать с разными данными одной таблицы. Но управляемые блокировки работают корректно только если код конфигурации правильно указывает поля и диапазоны — иначе блокировка захватывает лишнее или, наоборот, не защищает нужное.
Файловый и клиент-серверный режимы
Блокировки на уровне таблиц, конфликты частые уже при 5–10 активных пользователях; снять захват проще — достаточно завершить сеансы
Построчные блокировки средствами СУБД, выше параллельность, но диагностика сложнее: нужны консоль кластера и инструменты СУБД
Как предотвратить повторение блокировок
Основная мера — разнести тяжёлые операции по времени. Перенесите регламентные задания, обмены и пересчёт итогов на ночные часы или на периоды минимальной активности. Проверьте расписание: нередко два задания стартуют в одну минуту и стабильно конфликтуют друг с другом.
Вторая мера — работа с кодом. Убедитесь, что транзакции короткие, не содержат интерактивных действий (вопросов пользователю внутри транзакции — классическая ошибка) и обращаются к объектам в едином порядке во всех процедурах. Включённый режим управляемых блокировок и корректное указание полей блокировки данных снижают число конфликтов на порядок.
Третья мера — мониторинг. Настройте сбор технологического журнала по событиям блокировок и периодически анализируйте, какие объекты конфликтуют чаще всего. Если один и тот же регистр регулярно становится источником проблем, возможно, стоит пересмотреть методику проведения документов по нему или разнести нагрузку.
Частые вопросы
Что важно запомнить
«Захвачено СУБД» — это следствие конкуренции сеансов за данные, а не поломка базы. Диагностируйте через консоль кластера и средства СУБД, снимайте блокировку завершением зависшего сеанса, а предотвращайте — расписанием заданий и качеством кода. Резервная копия обязательна перед любыми жёсткими действиями.
Опасна ли ошибка «захвачено СУБД» для данных?
Сама по себе — нет: это защитный механизм, который не даёт испортить данные. Опасны действия по её «лечению»: принудительная перезагрузка сервера или удаление файлов базы могут оборвать транзакции и привести к несогласованному состоянию данных.
Что делать пользователю, который увидел эту ошибку?
Подождите несколько минут и повторите действие — чаще всего блокировка к этому моменту снята. Если ошибка повторяется, сообщите администратору точное время, текст ошибки и операцию, которую вы выполняли: это сильно ускорит поиск источника.
Почему ошибка возникает каждый день примерно в одно время?
Почти наверняка в это время запускается регламентное задание, обмен данными или резервное копирование. Сверьте время ошибок с расписанием заданий в консоли кластера и разведите конфликтующие процессы по разным интервалам.
Можно ли снять блокировку, не завершая сеанс пользователя?
Если блокировку держит штатная транзакция, корректный путь — дождаться её завершения. Принудительное снятие блокировки средствами СУБД без отката транзакции невозможно: блокировка существует, пока жива транзакция. Поэтому выбор всегда один — либо ждать, либо завершать сеанс с откатом.
Поможет ли переход на клиент-серверный режим избавиться от ошибок?
Он резко снизит частоту конфликтов за счёт построчных блокировок вместо табличных, но не устранит их полностью. Взаимоблокировки и конфликты с длительными операциями возможны и на SQL — просто диагностировать их там нужно другими инструментами.
Что такое взаимоблокировка и чем она отличается от обычной?
Взаимоблокировка (deadlock) — ситуация, когда два сеанса держат ресурсы и ждут друг друга, поэтому ни один не может продолжиться. СУБД автоматически откатывает одну из транзакций. От обычной блокировки это отличается тем, что ожидание никогда не закончилось бы само, и повторяющиеся deadlock всегда указывают на ошибку в логике кода.