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