Конфликт блокировок при выполнении транзакции в 1С 8.3

Сообщение «Конфликт блокировок при выполнении транзакции» в 1С 8.3 — одна из самых частых ошибок в многопользовательских системах. Для бухгалтера это барьер к проведению документа, для администратора — повод оценить производительность сервера и качество конфигурации. В пиковые периоды (закрытие месяца, сдача отчётности) такие ошибки могут парализовать работу целого отдела.

В материале разберём, почему возникают блокировки, как быстро снять конфликт в моменте и устранить его причину навсегда.

Что такое конфликт блокировок

Блокировка в СУБД — механизм защиты данных от одновременного изменения двумя процессами. Когда один пользователь записывает документ, программа блокирует связанные записи в регистрах. Второй пользователь, обратившийся к тем же данным, должен ждать освобождения блокировки.

Конфликт возникает, когда время ожидания превышает заданный лимит. По умолчанию — 20 секунд. После этого транзакция отменяется, а пользователь видит ошибку.

Полный текст ошибки

Стандартное сообщение выглядит так: «Конфликт блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки». Дополнительно может указываться имя таблицы и тип блокировки.

Зачем вообще нужны блокировки

Без блокировок невозможна корректная работа системы. Представьте, что два кассира одновременно списывают последний товар на складе. Без блокировки оба документа пройдут — и в учёте появится отрицательный остаток. С блокировкой второй кассир получит предупреждение, что товара уже нет.

Что защищают блокировки

• Целостность остатков на складах.
• Правильность расчёта взаиморасчётов.
• Корректность проводок по счетам.
• Уникальность номеров документов.
• Соответствие данных в нескольких регистрах.

Два режима управления блокировками

В 1С 8.3 поддерживаются два режима. Они отличаются принципом работы и нагрузкой на систему.

В современных типовых конфигурациях 1С 8.3 (Бухгалтерия, ЗУП, Управление торговлей, ERP) по умолчанию используется управляемый режим. На старых самописных конфигурациях встречается автоматический.

Уровни блокировок: S и U/X

В управляемом режиме платформа использует два уровня.

Разделяемая блокировка (Shared, S)

Накладывается при чтении данных. Несколько пользователей могут одновременно получать одну и ту же запись для чтения. Конфликт возникает, только если кто-то пытается изменить заблокированные на чтение данные.

Исключительная блокировка (Update/Exclusive, U/X)

Накладывается при изменении или планируемом изменении данных. Только один процесс может держать исключительную блокировку. Все остальные ждут.

В коде запросов исключительная блокировка задаётся фразой ДЛЯ ИЗМЕНЕНИЯ в конце запроса.

5 главных причин конфликтов

1. Одновременная работа с большим объёмом данных

В пиковые часы (утро понедельника, последние дни месяца) сотни пользователей одновременно проводят документы по одним и тем же регистрам. Это объективная причина — её нельзя устранить полностью, только снизить через оптимизацию.

2. Неоптимальные запросы

Неправильно написанный запрос может заблокировать целую таблицу вместо одной строки. Типичные ошибки разработчиков:

• Отсутствие условия по индексу в запросе.
• Использование ДЛЯ ИЗМЕНЕНИЯ без необходимости.
• Чтение остатков без указания периода.
• Использование ОБЪЕДИНИТЬ вместо СОЕДИНИТЬ.

3. Длинные транзакции

Чем дольше длится транзакция, тем дольше держатся блокировки. Транзакции, выполняющие сложные расчёты в одном проведении, — постоянный источник конфликтов.

4. Регламентные операции в рабочее время

«Закрытие месяца», «Восстановление последовательности», обновление информационной базы — операции, которые сами по себе блокируют большие объёмы данных. Запуск во время активной работы пользователей гарантирует конфликты.

5. Устаревшая конфигурация в автоматическом режиме

Конфигурации, не переведённые на управляемые блокировки, в 2026 году считаются критически устаревшими. Они блокируют целые страницы данных там, где управляемый режим заблокировал бы одну запись.

Диагностика: где смотреть подробности

Чтобы понять причину конфликта, нужно собрать данные о блокировке.

Журнал регистрации

В программе откройте Сервис → Журнал регистрации. Установите фильтр по уровню «Ошибка» и времени возникновения проблемы. Журнал покажет:

• Имя пользователя.
• Документ, при проведении которого возник конфликт.
• Имя метода, в котором случилась ошибка.

Технологический журнал

Расширенный инструмент для администраторов. Включается в файле logcfg.xml в каталоге сервера 1С. Записывает все обращения к СУБД, тайминги, события блокировок.

Технологический журнал — основа для серьёзного анализа производительности. Используется специалистами по оптимизации.

Центр управления производительностью (ЦУП)

Платная утилита от фирмы 1С. Анализирует технологический журнал и строит отчёты о проблемах производительности. Подходит для постоянного мониторинга в крупных системах.

Сервис «Мониторинг» в 1С 8.3.18+

Встроенный инструмент, доступный в свежих версиях платформы. Раздел Администрирование → Мониторинг. Показывает текущие сеансы и активные блокировки в реальном времени.

Быстрое решение: снять конфликт прямо сейчас

Когда нужно срочно сдать отчёт, а ошибки мешают — действуйте по одному из двух сценариев.

Сценарий 1. Завершить блокирующий сеанс

Подходит для систем до 50 пользователей.

1. Откройте консоль администрирования сервера 1С.
2. Найдите активные сеансы.
3. Определите сеанс с длительной транзакцией (по времени старта).
4. Завершите этот сеанс.
5. Заблокированные данные освободятся.

Сценарий 2. Перезагрузка сервера 1С

Радикальный, но быстрый способ. Снимает все активные блокировки одновременно.

1. Уведомите пользователей о краткой перезагрузке.
2. Через консоль или PowerShell перезапустите службу 1С:Предприятия.
3. После запуска (1–2 минуты) пользователи смогут войти заново.

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

Долгосрочное решение: перевод на управляемые блокировки

Если конфигурация работает в автоматическом режиме — это первое, что нужно поменять.

Что включает перевод

• Изменение режима в свойствах конфигурации (с «Автоматический» на «Управляемый»).
• Доработка кода всех проведений документов.
• Добавление управляемых блокировок в нужных местах.
• Тестирование всех сценариев работы.

Сколько занимает

В типовой Бухгалтерии 8.3 — уже сделано. В самописных конфигурациях работа специалиста — от 40 до 200 часов в зависимости от сложности.

Оптимизация запросов

Даже в управляемом режиме плохо написанные запросы вызывают конфликты.

Что проверить

• Каждый запрос имеет фильтр по индексируемому полю.
• Условия отбора расположены до соединений (через ВНУТРЕННЕЕ СОЕДИНЕНИЕ).
• Большие запросы разбиты на несколько мелких через временные таблицы.
• Запросы остатков всегда содержат границу периода.
• Конструкция ДЛЯ ИЗМЕНЕНИЯ используется только при реальном намерении изменить данные.

Инструменты анализа

В Конфигураторе встроен «Анализ запросов» в режиме отладки. Показывает план выполнения и время каждого этапа.

Для глубокого анализа применяется SQL Server Profiler (для MS SQL) или pg_stat_statements (для PostgreSQL).

Настройки СУБД

Производительность сервера баз данных напрямую влияет на частоту конфликтов.

PostgreSQL для 1С

Основные параметры в postgresql.conf:

• shared_buffers — 25 % от оперативной памяти сервера.
• work_mem — 64–128 МБ для сложных запросов.
• maintenance_work_mem — 256 МБ для VACUUM.
• max_connections — на 20 % больше числа пользователей 1С.
• lock_timeout — установить в 30000 (30 секунд).

MS SQL Server для 1С

• Включите Read Committed Snapshot Isolation (READ_COMMITTED_SNAPSHOT ON).
• Регулярно выполняйте обслуживание индексов.
• Настройте автоочистку статистики.
• Выделите достаточно оперативной памяти SQL-серверу.

Профилактика конфликтов

Регламент работы

• Запускайте регламентные операции (закрытие месяца, обновление информационной базы) ночью или в выходные.
• Не проводите массовые перепроведения в рабочее время.
• Распределяйте сложные расчёты по разным временным окнам.

Регулярный мониторинг

• Раз в неделю — анализ журнала регистрации на ошибки.
• Раз в месяц — проверка производительности через ЦУП или Мониторинг.
• Раз в квартал — обновление статистики СУБД.

Типичные сценарии конфликтов

Сценарий 1. Конфликт при закрытии месяца

Менеджер пытается провести реализацию, в это время бухгалтер запустил «Закрытие месяца». Закрытие захватывает регистр продаж — реализация ждёт.

Решение: делайте закрытие месяца после окончания рабочего дня.

Сценарий 2. Дублирование номеров

Два пользователя одновременно создают документ. Программа блокирует генератор номеров. Второй пользователь ждёт.

Решение: устраняется автоматически — конфликт длится миллисекунды и не доходит до тайм-аута.

Сценарий 3. Длинный отчёт блокирует учёт

Финансовый директор формирует ОСВ за год. Запрос блокирует регистр бухгалтерии. Бухгалтеры не могут провести документы.

Решение: формируйте тяжёлые отчёты в нерабочее время или используйте копию базы для аналитики.

Часто задаваемые вопросы

Можно ли увеличить тайм-аут блокировок?

Да, через свойства информационной базы в конфигураторе. Но это не решение проблемы — пользователи будут просто дольше ждать. Лучше устранить причину.

Что такое deadlock и чем отличается от обычного конфликта?

Deadlock — это взаимная блокировка. Транзакция А ждёт ресурс Б, транзакция Б ждёт ресурс А. Без вмешательства они блокируют друг друга навсегда. СУБД распознаёт deadlock и принудительно отменяет одну из транзакций.

Почему конфликт возникает только в одной базе?

Видимо, в этой базе самописные доработки или другие данные. Сравните с типовой базой и проверьте, что в ней изменено.

Поможет ли увеличение оперативной памяти сервера?

Косвенно — да. Больше памяти ускоряет работу СУБД, транзакции выполняются быстрее, блокировки держатся меньше. Но это не лечит причину.

Стоит ли переходить с MS SQL на PostgreSQL?

В рамках импортозамещения — да. PostgreSQL официально поддерживается фирмой 1С с 2014 года и в ряде сценариев показывает лучшую производительность. При корректной настройке.

Как понять, что конфигурация работает в управляемом режиме?

В конфигураторе откройте свойства корневого объекта конфигурации. В разделе «Совместимость» проверьте параметр «Режим управления блокировкой данных».

Помогает ли разнесение пользователей по разным сеансам?

Нет. Все пользователи работают с одной базой. Разнесение по сеансам не уменьшает количество блокировок.

Резюме

• Конфликт блокировок в 1С 8.3 — следствие конкуренции за данные. Возникает при превышении 20-секундного тайм-аута ожидания.
• Современные типовые конфигурации работают в управляемом режиме. Самописные базы в автоматическом режиме — главный источник проблем.
• Быстрое решение — завершить блокирующий сеанс или перезапустить сервер. Оба способа — аварийные, постоянное использование недопустимо.
• Долгосрочное решение — оптимизация запросов, перевод на управляемые блокировки, настройка СУБД и регламент запуска тяжёлых операций в нерабочее время.