Блокировка «захвачено СУБД»: кто держит данные и как их освободить
Содержание
«Захвачено СУБД» означает, что нужные вам строки или таблицу уже заблокировала сама система управления базой данных — SQL Server или PostgreSQL — по запросу другого сеанса 1С. Ваша транзакция встаёт в очередь, ждёт и по таймауту падает. Чтобы исправить ошибку, надо найти сеанс, который держит блокировку, дождаться его или аккуратно завершить, а потом устранить причину долгой транзакции.
Обычно это выглядит так: бухгалтер проводит документ, программа «думает» 20–30 секунд и выдаёт сообщение со словами Конфликт блокировок при выполнении транзакции.
Что происходит, когда данные захвачены на уровне СУБД
В клиент-серверной 1С блокировки бывают двух уровней.
- 🔒 Управляемые блокировки 1С. Их ставит менеджер блокировок кластера 1С. Он знает, какой сеанс 1С держит какие данные, и при конфликте пишет
Превышено максимальное время ожидания предоставления блокировки. - 🗄️ Блокировки СУБД. Их ставит сам SQL Server или PostgreSQL при чтении и записи строк. 1С о них узнаёт только тогда, когда СУБД вернула ошибку. Это и есть случай «захвачено СУБД».
Какие блокировки работают в вашей базе, решает свойство конфигурации Режим управления блокировкой данных. Его видно в Конфигураторе: откройте дерево конфигурации, щёлкните правой кнопкой по корню и выберите Свойства. Значения:
| Режим | Кто блокирует | Чем грозит |
|---|---|---|
| Автоматический | Только СУБД | Блокировки шире нужного, частые конфликты при 10+ пользователях |
| Управляемый | Менеджер 1С + минимум от СУБД | Конфликтов меньше, СУБД держит строки только на время записи |
| Автоматический и управляемый | Зависит от объекта | Старые объекты конфигурации продолжают блокироваться СУБД |
Типовые конфигурации последних редакций (БП 3.0, ЗУП 3.1, УТ 11) работают в управляемом режиме. Но даже там СУБД ставит свои блокировки на время записи. Если транзакция длится минуты, захват СУБД становится заметен всем.
Сообщение СУБД обычно идёт в хвосте ошибки 1С. Для SQL Server это строки вида Lock request time out period exceeded или was deadlocked on lock resources with another process, для PostgreSQL — canceling statement due to lock timeout или deadlock detected. По этому хвосту сразу понятно, какая СУБД и какой тип конфликта.
Пять причин захвата СУБД и как узнать свою
Сначала определите, что именно случилось. Симптомы разных причин отличаются.
- ⏳ Долгая транзакция другого сеанса. Кто-то перепроводит документы за квартал, закрывает месяц или загружает обмен. Пока его транзакция не завершилась, строки регистров заняты. Признак: ошибка у всех, кто трогает те же регистры, и пропадает после окончания операции.
- 🔁 Взаимоблокировка (deadlock). Два сеанса захватили по ресурсу и ждут друг друга. СУБД сама выбирает «жертву» и обрывает её транзакцию. Признак: ошибка мгновенная, без долгого ожидания, в тексте есть
deadlock. - 🧟 Зависший сеанс. Пользователь закрыл ноутбук посреди проведения, или клиент 1С упал. Соединение с СУБД осталось открытым, транзакция не закрыта. Признак: в консоли кластера висит сеанс, который давно ничего не делает, а ошибка не проходит часами.
- 🛠️ Регламентное задание или внешний скрипт. Обновление полнотекстового индекса, обмен по расписанию, план обслуживания SQL (перестроение индексов) или резервное копирование средствами СУБД. Признак: ошибка повторяется в одно и то же время суток.
- 🧱 Автоматический режим блокировок или эскалация. В автоматическом режиме СУБД блокирует данные с запасом. SQL Server при большом числе захваченных строк может поднять блокировку до уровня всей таблицы. Признак: конфликт между операциями, которые по смыслу никак не пересекаются.
Как разблокировать базу 1С: порядок действий
Идите по шагам сверху вниз. Каждый следующий шаг жёстче предыдущего.
Шаг 1. Подождите и повторите операцию
Если ошибка появилась один раз в разгар рабочего дня, чаще всего это короткий конфликт. Подождите минуту и повторите проведение. Большинство транзакций завершается за секунды.
Шаг 2. Найдите сеанс-виновник в консоли кластера
- Запустите
Администрирование серверов 1С Предприятия(консоль кластера). - Раскройте
Кластеры → ваш кластер → Информационные базы → нужная база → Сеансы. - Отсортируйте по колонке времени текущего вызова или по объёму данных, прочитанных и записанных в СУБД. Сеанс, у которого цифры растут, а время вызова исчисляется минутами, — первый кандидат.
- Посмотрите колонки
Пользователь,КомпьютериПриложение. Если это фоновое задание — в колонке приложения будет указано фоновое задание.
В той же ветке базы есть узел Блокировки. Он показывает управляемые и объектные блокировки 1С. Блокировок самой СУБД там нет, поэтому пустой список не значит, что базу никто не держит.
Шаг 3. Поговорите с пользователем
Позвоните человеку, чей сеанс держит данные. Возможно, он закрывает месяц и через пять минут закончит. Прерывать такую операцию — значит потерять уже выполненную работу и запускать её заново.
Шаг 4. Завершите сеанс
Если сеанс точно завис:
- В консоли кластера щёлкните по нему правой кнопкой и выберите
Удалить. - Подождите 10–20 секунд. СУБД откатит незавершённую транзакцию, и блокировка снимется.
- Повторите свою операцию.
Пользователь потеряет несохранённые данные, а его незавершённая транзакция будет полностью откачена. Перед удалением сеанса предупредите его. Длинная транзакция откатывается не мгновенно: откат перепроведения за квартал может занять столько же времени, сколько шло проведение.
Шаг 5. Найдите и снимите блокировку прямо в СУБД
Бывает, что сеанса в консоли уже нет, а соединение с СУБД осталось. Тогда ищите его средствами самой СУБД — команды для SQL Server и PostgreSQL приведены в разделе про особенности СУБД ниже.
Шаг 6. Перезапуск службы — крайняя мера
Перезапуск службы Агент сервера 1С:Предприятия 8.3 рвёт все соединения кластера с СУБД, и все транзакции откатываются. Это обрывает работу всех пользователей всех баз на этом сервере. Делайте это только вне рабочего времени или после общего оповещения, и только если предыдущие шаги не помогли.
Особенности SQL Server, PostgreSQL и файловой базы
Microsoft SQL Server
Откройте SQL Server Management Studio, подключитесь к серверу и выполните запрос в контексте базы 1С:
SELECT r.session_id,
r.blocking_session_id,
r.wait_type,
r.wait_time / 1000 AS wait_sec,
s.host_name,
s.program_name
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
WHERE r.blocking_session_id <> 0;
В колонке blocking_session_id — номер соединения, которое держит блокировку. Цепочка может быть длинной: ищите сеанс, который сам никого не ждёт, но других блокирует. Это «голова» цепочки. Быстрый обзор даёт и встроенная процедура sp_who2 — колонка BlkBy.
Завершить соединение:
KILL 61; -- номер session_id «головы» цепочки
KILL откатывает транзакцию этого соединения. Соединения рабочих процессов 1С переиспользуются, поэтому убитое соединение может обслуживать сразу несколько последовательных вызовов. Сначала попробуйте найти и удалить сеанс в консоли кластера, а KILL оставьте на случай, когда сеанса там уже нет.
Для SQL Server ещё два приёма практика:
- 📈 Эскалация блокировок. Если в мониторинге видна блокировка уровня таблицы (
OBJECTвsys.dm_tran_locks), виновата массовая операция. Помогает разбить обработку на порции или перевести конфигурацию в управляемый режим. - 🧹 План обслуживания. Перестроение индексов в режиме offline блокирует таблицы на всё время работы. Ставьте его на ночь и не пересекайте с обменами.
PostgreSQL
Найти, кто кого держит, помогает функция pg_blocking_pids (есть в PostgreSQL с версии 9.6):
SELECT pid,
pg_blocking_pids(pid) AS blocked_by,
now() - xact_start AS xact_age,
state,
client_addr,
left(query, 80) AS query
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0
OR state = 'idle in transaction';
Особое внимание — на соединения со статусом idle in transaction. Это открытая транзакция, внутри которой ничего не происходит. Именно так выглядит «зависший» сеанс 1С в PostgreSQL.
Снять блокировку можно мягко или жёстко:
SELECT pg_cancel_backend(12345); -- прервать текущий запрос
SELECT pg_terminate_backend(12345); -- закрыть соединение целиком
pg_cancel_backend прерывает только запрос и не всегда снимает блокировку, если транзакция осталась открытой. pg_terminate_backend закрывает соединение и откатывает транзакцию — это то же самое, что KILL в SQL Server, с теми же последствиями для пользователя.
Файловая база
В файловом варианте СУБД как отдельного сервера нет, поэтому «захвачено СУБД» в чистом виде не встречается. Блокировки там грубее: файловая база блокирует данные целыми таблицами. Отсюда частые конфликты уже при 5–7 активных пользователях.
Что делать с файловой базой:
- Попросите всех закрыть 1С и проверьте через Диспетчер задач на компьютерах пользователей и на сервере с базой, что не осталось процессов
1cv8.exeи1cv8c.exe. - Если база лежит в сетевой папке, на сервере откройте
Управление компьютером → Общие папки → Открытые файлыи посмотрите, кто держит файл1Cv8.1CD. - Закрывайте чужой открытый файл только после того, как убедились, что человек не работает . Иначе возможна порча базы.
| Вариант | Чем найти виновника | Чем снять блокировку |
|---|---|---|
| SQL Server | sys.dm_exec_requests, sp_who2 | Сеанс в консоли кластера, затем KILL |
| PostgreSQL | pg_stat_activity, pg_blocking_pids | Сеанс в консоли кластера, затем pg_terminate_backend |
| Файловая | Открытые файлы на сервере, процессы 1cv8 | Закрыть 1С у пользователя, затем закрыть файл |
Как не допустить повторного захвата СУБД
Разовое снятие блокировки лечит симптом. Чтобы ошибка не возвращалась, работайте с причиной.
- 🌙 Разведите тяжёлые операции по времени. Закрытие месяца , перепроведение, обмены с большими пакетами и обслуживание СУБД — вне пиковых часов.
- ✂️ Дробите массовые операции. Перепроводить документы лучше по месяцу или по неделе, а не за год одной транзакцией. Обмены настраивайте на частую выгрузку небольшими порциями.
- 🔧 Проверьте режим блокировок. Если доработанная конфигурация работает в автоматическом режиме, переход на управляемый — главная мера. Это работа программиста: код проведения доработанных объектов надо проверить и при необходимости добавить в него управляемые блокировки.
- 📋 Включите технологический журнал. События
TLOCK(управляемые блокировки),TTIMEOUT(таймауты) иTDEADLOCK(взаимоблокировки) показывают, кто, когда и на каких данных конфликтует. Настройка — файлlogcfg.xmlв каталогеconfплатформы на сервере 1С. - 🧑💻 Не держите транзакцию открытой. В доработках не должно быть диалогов с пользователем, ожиданий и запросов к внешним сервисам внутри транзакции. Одно окно «Вы уверены?» посреди записи держит блокировку, пока человек не нажмёт кнопку.
- 📊 Следите за ресурсами сервера. Медленный диск и нехватка памяти удлиняют каждую транзакцию, а значит, и время захвата.
Технологический журнал быстро растёт. Включайте его на день-два с фильтром по нужным событиям и ограничением срока хранения, а потом выключайте.
Чего не делать при снятии блокировки
Здесь собраны действия, которые часто советуют на форумах и которые делают хуже.
- ❌ Перезагружать сервер СУБД днём «чтобы точно». Откат всех транзакций после перезапуска может идти долго, а пользователи потеряют работу во всех базах сразу.
- ❌ Удалять «лишние» сеансы пачкой. Можно оборвать закрытие месяца или выгрузку в банк. Удаляйте только тот сеанс, который вы опознали как виновника.
- ❌ Менять таймаут блокировок без анализа. Увеличенное ожидание прячет проблему: пользователи вместо ошибки получают «зависание» на минуту.
- ❌ Править данные запросом напрямую в СУБД. Это ломает целостность регистров и лишает поддержки. Снимать блокировку — да, менять таблицы 1С через SQL — нет.
- ❌ Чистить временные файлы и кэш как первое действие. Блокировки СУБД живут на сервере, очистка кэша у пользователя на них не влияет.
Когда без администратора не обойтись
Позовите администратора сервера или программиста 1С, если:
- 🚨 ошибка появляется каждый день, а не раз в месяц;
- 🚨 взаимоблокировки идут пачками, особенно после доработки конфигурации или обновления;
- 🚨 после завершения сеанса блокировка не снимается долгое время — возможно, идёт длинный откат или у СУБД проблемы с диском;
- 🚨 в журнале СУБД есть ошибки ввода-вывода или сообщения о повреждении страниц;
- 🚨 конфигурация работает в автоматическом режиме блокировок и сильно доработана.
Пользователь с правами бухгалтера может только повторить операцию и сообщить, что именно он проводил и в какое время. Эта информация сильно ускоряет поиск: администратор по времени найдёт событие в технологическом журнале.