Администрирование · 10 мин
Блокировки в 1С: что это и как с ними работать
Что такое блокировки в 1С, чем отличаются объектные и транзакционные блокировки, почему возникает ошибка «конфликт блокировок» и как безопасно снять зависший сеанс.
Блокировка в 1С — это механизм, который не даёт нескольким пользователям или фоновым процессам одновременно изменять одни и те же данные. Когда бухгалтер проводит документ «Поступление товаров», система блокирует связанные записи: остатки по складу, регистры, сам документ. Если в этот момент другой пользователь попытается изменить те же данные, он получит ошибку «Конфликт блокировок при выполнении транзакции» или будет ждать освобождения ресурса.
Блокировки — не ошибка и не признак неисправности, а штатный способ защиты целостности учёта. Без них два пользователя могли бы одновременно списать один и тот же товар со склада, и остатки «разъехались» бы. Проблемы начинаются тогда, когда блокировки удерживаются слишком долго, захватывают лишние данные или «зависают» из-за аварийно завершённых сеансов.
Разобраться в теме нужно в двух случаях: когда пользователи жалуются на ошибки «конфликт блокировок» и когда база начинает тормозить из-за массовых ожиданий. Дальше — виды блокировок, причины конфликтов, способы диагностики и безопасные методы снятия зависших блокировок.
Какие виды блокировок существуют в 1С
В платформе 1С:Предприятие работают два больших класса блокировок: объектные и транзакционные. Их часто путают, хотя механизмы разные и диагностируются по-разному.
Объектные блокировки возникают, когда пользователь открывает объект на редактирование: документ, элемент справочника, запись регистра сведений. Пока форма открыта в режиме изменения, другой пользователь может просматривать объект, но при попытке его изменить получит сообщение «Объект заблокирован». Такая блокировка снимается при закрытии формы или при записи объекта.
Транзакционные блокировки накладываются на уровне СУБД в момент проведения документа, записи регистров или выполнения запроса на изменение. Они живут только внутри транзакции и снимаются при её завершении. Именно транзакционные блокировки вызывают ошибку «Конфликт блокировок при выполнении транзакции» и взаимоблокировки (deadlock).
Управляемый и автоматический режим блокировок
В свойствах конфигурации есть параметр «Режим управления блокировкой данных»: автоматический, управляемый или смешанный («автоматический и управляемый»). От него зависит, как платформа и СУБД распределяют блокировки.
В автоматическом режиме платформа сама решает, что блокировать, и часто блокирует таблицы целиком. Это просто для разработчика, но в многопользовательской базе приводит к частым конфликтам: два документа по разным складам могут конфликтовать из-за блокировки всей таблицы регистра.
В управляемом режиме СУБД блокирует только конкретные строки, а разработчик дополнительно управляет блокировками через объект «БлокировкаДанных» в коде. Это снижает число конфликтов и повышает параллельность работы. Современные типовые конфигурации рассчитаны на управляемый режим, поэтому перевод старой базы на него — одна из стандартных мер против массовых ошибок блокировок.
Сравнение режимов
Подходит для небольших баз с несколькими пользователями; недостаток — блокировки целых таблиц и частые конфликты при росте нагрузки.
Рекомендуется для клиент-серверных баз с десятками пользователей; требует, чтобы прикладной код корректно работал с ним.
Переходный вариант: часть объектов работает в управляемом, часть в автоматическом; используется при постепенной доработке конфигурации.
Почему возникает ошибка «Конфликт блокировок»
Наиболее частая причина — реальное пересечение работы пользователей: два менеджера проводят документы, списывающие один товар, или бухгалтер запускает закрытие месяца, пока операторы вводят первичку. Это нормальная ситуация: транзакция, получившая ошибку, откатывается, и операцию можно повторить через несколько секунд.
Вторая группа причин — длительные транзакции. Тяжёлые отчёты с построением по регистрам, обмены данными, групповое перепроведение, регламентные задания, запущенные в рабочее время, удерживают блокировки минутами. Все, кто обращается к тем же таблицам, в это время ждут или получают ошибку по тайм-ауту.
Третья группа — ошибки в коде: запись в цикле без пакетной обработки, чтение данных после начала транзакции, избыточные блокировки через «БлокировкаДанных» с широким диапазоном значений. Такие конфликты воспроизводятся стабильно и не лечатся повтором операции.
Кто в это время работал с теми же документами или регистрами
Активные сеансы и фоновые задания в консоли кластера
Журнал регистрации и технологический журнал по событию TLOCK
Активные запросы на СУБД и цепочки ожиданий
Как найти источник блокировки
Первый инструмент — консоль кластера серверов 1С. В разделе «Сеансы» видно, какие пользователи и фоновые задания активны, сколько времени выполняется текущий вызов, какой объём данных прочитан. Сеанс, который «висит» часами с активным вызовом СУБД, — главный подозреваемый при массовых жалобах.
Второй инструмент — технологический журнал. Включив события TLOCK, TDEADLOCK и TTIMEOUT, можно увидеть, какие таблицы и ключи блокируются, кто держит блокировку и кто ждёт. Настройка выполняется через файл logcfg.xml на сервере; для постоянной работы журнал нагружает диск, поэтому его включают на период диагностики.
Третий источник — средства самой СУБД. В MS SQL Server это представления sys.dm_tran_locks и sys.dm_exec_requests, в PostgreSQL — pg_locks и pg_stat_activity. Они показывают цепочку: какой запрос держит блокировку и какие запросы стоят в очереди ожидания.
- 1Зафиксируйте время ошибки и текст сообщения у пользователя
- 2Откройте консоль кластера и найдите сеансы с длительным активным вызовом
- 3Проверьте фоновые и регламентные задания, работающие в это время
- 4Включите технологический журнал с событиями TLOCK и TDEADLOCK
- 5По журналу определите таблицу и сеанс, удерживающий блокировку
- 6После диагностики отключите расширенный сбор событий в технологическом журнале
Как снять зависшую блокировку
Зависшая блокировка почти всегда означает зависший сеанс: клиентский компьютер выключился без завершения сеанса, тонкий клиент убит через диспетчер задач, обмен данными прерван по сети. Сервер 1С какое-то время считает сеанс живым, а блокировки на СУБД остаются активными.
Правильный способ — завершить конкретный сеанс в консоли кластера: выделить сеанс и выбрать «Удалить». Транзакция откатится, блокировки освободятся, остальные пользователи продолжат работу. Перед удалением убедитесь, что это действительно зависший сеанс, а не реально работающее регламентное задание — принудительное прерывание длительного обмена может оставить данные в промежуточном состоянии.
Если блокировка видна только на уровне СУБД, а сеанса в кластере уже нет, завершите соответствующий процесс средствами СУБД (KILL в MS SQL, pg_terminate_backend в PostgreSQL). Это крайняя мера: сначала всегда ищите сеанс штатными средствами 1С.
Как снизить количество конфликтов блокировок
Организационные меры дают эффект без изменения кода. Тяжёлые операции — закрытие месяца, перепроведение, обмены, загрузку прайсов — переносят на нерабочее время через расписание регламентных заданий. Пользователям объясняют, что при ошибке конфликта документ нужно просто провести повторно, а не нажимать кнопку десять раз подряд.
Технические меры: перевод конфигурации в управляемый режим блокировок, настройка разделения базы по времени работы фоновых заданий, оптимизация запросов, чтобы транзакции выполнялись быстрее и меньше держали блокировки. В коде — минимизация действий внутри транзакции: всё, что можно вычислить до её начала, вычисляется заранее.
Для файловых баз ситуация жёстче: там блокировки накладываются на уровне всей таблицы, и при одновременной работе нескольких пользователей конфликты неизбежны. Если база выросла до 5–10 активных пользователей, переход на клиент-серверный вариант — самое действенное решение проблемы.
Частые вопросы по блокировкам в 1С
Что важно запомнить
Блокировки — штатный механизм защиты данных, а не поломка. Разовый конфликт решается повтором операции, массовые конфликты — поиском зависшего сеанса или длительной транзакции, а системная профилактика — управляемым режимом блокировок и выносом тяжёлых операций в нерабочее время.
Опасна ли ошибка «Конфликт блокировок» для данных?
Нет. Транзакция, получившая ошибку, полностью откатывается, и база остаётся в согласованном состоянии. Достаточно повторить операцию через несколько секунд. Опасность представляет только принудительное обрывание процессов на уровне СУБД или перезагрузка сервера.
Почему документ «заблокирован», хотя пользователь давно закрыл программу?
Сеанс завершился аварийно, но сервер ещё считает его активным. Найдите этот сеанс в консоли кластера и удалите его — объектная блокировка снимется. Если консоли нет, дождитесь тайм-аута завершения спящих сеансов, который задаётся в свойствах информационной базы.
Можно ли вообще отключить блокировки в 1С?
Нет, и это было бы разрушительно для учёта: без блокировок одновременные изменения приводили бы к потере и рассогласованию данных. Отключить можно только отдельные избыточные блокировки в прикладном коде, но делать это должен разработчик с анализом последствий.
Чем отличается блокировка в файловой и клиент-серверной базе?
В файловой базе блокировки накладываются на таблицы целиком, поэтому конфликты возникают даже при работе с разными документами. В клиент-серверном варианте с управляемым режимом блокируются конкретные строки, и параллельная работа заметно легче.
Как понять, что база тормозит именно из-за блокировок, а не из-за железа?
Характерный признак: запросы «висят» в ожидании, а процессор и диск при этом недогружены. Подтверждение дают события TLOCK и TTIMEOUT в технологическом журнале и цепочки ожиданий в средствах мониторинга СУБД.
Что делать, если конфликты возникают каждый день в одно и то же время?
Совпадение по времени почти всегда указывает на регламентное задание или запланированный обмен. Проверьте расписание фоновых заданий в этот период и перенесите тяжёлую операцию на нерабочие часы либо оптимизируйте её.