Как устранить конфликты блокировок при одновременном проведении реализации и расчета себестоимости в УПП 1.3?

← На главную

Ситуация, когда в крупной информационной базе 1С:УПП 1.3 возникают конфликты блокировок при выполнении тяжелых транзакций, таких как Расчет себестоимости (РАУЗ), является классической проблемой для высоконагруженных систем. Особенно остро это проявляется на предприятиях с непрерывным циклом производства, где отгрузка продукции (документы Реализация товаров и услуг) происходит круглосуточно, в том числе во время регламентного закрытия месяца.

Многие технические специалисты ошибочно полагают, что для решения проблемы достаточно перевести конфигурацию на платформу 8.3, отключить режим совместимости и выставить настройки ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT на уровне SQL-сервера. Однако эти меры — лишь фундамент. Разберем по шагам, что необходимо сделать для полной победы над конфликтами блокировок.

Шаг 1. Переход на программное управление блокировками

Установка свойства конфигурации Режим управления блокировками данных в значение Управляемый — это только половина дела. В этом режиме ответственность за целостность данных перекладывается с СУБД на разработчика 1С. Если вы переключили режим, но не изменили код модулей проведения, система может продолжать работать неэффективно или накладывать избыточные блокировки.

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

Шаг 2. Реализация объекта БлокировкаДанных

Для исключения конфликтов между расчетом себестоимости и реализацией необходимо внедрить механизм явной блокировки в модули проведения соответствующих документов. Рассмотрим пример использования объекта БлокировкаДанных, который позволяет ограничить область блокировки только необходимыми измерениями регистра.


Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.УчетЗатрат");

// Устанавливаем блокировку по организации, чтобы не мешать расчетам по другим юрлицам
ЭлементБлокировки.УстановитьЗначение("Организация", Организация);

// Уточняем область блокировки до конкретной номенклатуры или склада
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = Ссылка.Товары; // Используем ТЧ документа как источник
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");

Блокировка.Заблокировать();

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

Шаг 3. Борьба с эскалацией блокировок на уровне SQL

Даже при идеально настроенных управляемых блокировках 1С, СУБД (MS SQL Server) может выполнить эскалацию блокировок. Это автоматический процесс перевода множества мелких блокировок строк (Row Locks) в одну большую блокировку всей таблицы (Table Lock). Обычно это происходит, когда транзакция затрагивает более 20 000 записей в одной таблице.

Выясним причину: Расчет себестоимости при использовании РАУЗ оперирует огромными массивами данных в регистре Учет затрат. Для минимизации эскалации рекомендуется:

Разделять расчет по организациям: Вместо одного документа на всю компанию создавайте отдельные документы по каждой организации.
Оптимизировать индексы: Проверьте, чтобы измерения, по которым устанавливается блокировка (Организация, Раздел учета, Аналитика вида учета), входили в состав уникальных индексов.
Настройка TempDB: РАУЗ активно использует временные таблицы. Убедитесь, что файлы TempDB вынесены на самые быстрые диски (NVMe/SSD) и их количество соответствует количеству ядер процессора.

Шаг 4. Настройка версионности (Snapshot Isolation)

Вы упоминали использование флагов READ_COMMITTED_SNAPSHOT. Это верное решение для разделения "читателей" и "писателей". В этом режиме отчеты и запросы на чтение не будут блокироваться транзакциями записи. Однако помните: это не помогает, если две транзакции одновременно пытаются записать данные в одни и те же строки. В случае с РАУЗ и реализацией, оба документа пишут в регистры накопления, поэтому без правильного программного управления (Шаг 2) конфликты сохранятся.

Дополнительные рекомендации по РАУЗ

Рассмотрим специфику УПП 1.3: в этой конфигурации предусмотрен механизм предварительного расчета себестоимости. Если бизнес-процессы позволяют, используйте его для оперативного контроля остатков в течение дня, а полный расчет с жесткими блокировками выполняйте порционно. Также проанализируйте возможность отключения лишней детализации (например, до заказов), если она не является критически важной — это значительно уменьшит количество записей в регистрах и снизит нагрузку на менеджер блокировок.

Резюмируем: Одних настроек сервера недостаточно. Необходимо методично просмотреть модули проведения документов, вызывающих конфликт, и добавить в них объект БлокировкаДанных с максимально точным указанием измерений. Только совмещение системных настроек SQL и грамотного кода на языке 1С позволит добиться стабильной работы системы без простоев.