Влияет ли режим блокировок оборотного регистра на скорость проведения и параллельность в 1С?

При оптимизации производительности информационных баз 1С разработчики нередко сталкиваются с ситуацией, когда конфигурация работает в управляемом режиме блокировок, но у отдельных нетиповых регистров накопления (оборотных или остаточных) в свойствах указан автоматический режим. Разберем, как платформа 1С обрабатывает такие сочетания, нужно ли вручную менять режим блокировки у оборотного регистра, как влияет механизм Read Committed Snapshot Isolation (RCSI) на СУБД и где искать причины медленного проведения документов, если замер производительности не показывает явных проблем.

Сочетание режимов блокировок на уровне конфигурации и метаданных

Рассмотрим, как платформа 1С:Предприятие 8 управляет транзакционными блокировками при различных настройках конфигурации и отдельных объектов:

1. Режим «Управляемый» в корне конфигурации: Если для всей базы установлен управляемый режим, то индивидуальные настройки объектов метаданных игнорируются. При записи документов и формировании движений система всегда использует исключительно собственный менеджер транзакционных блокировок 1С. Перевод конкретного регистра из автоматического режима в управляемый не окажет никакого влияния на поведение базы.
2. Режим «Автоматический и управляемый» в корне конфигурации: В этом режиме платформа смотрит на свойства конкретных объектов метаданных. Транзакции проводятся в том режиме, который задан для участвующих объектов.
3. Оборотные регистры и контроль остатков: Оборотный регистр накопления фиксирует только факты свершения событий за период и не хранит текущие остатки. Если в коде проведения отсутствует чтение данных этого регистра для проверок (а выполняется только добавление новых записей), наложение управляемых блокировок на чтение не требуется.

Особенности применения режима Read Committed Snapshot Isolation (RCSI)

Включение версионирования строк на стороне MS SQL Server (READ_COMMITTED_SNAPSHOT) позволяет запросам на чтение данных не ожидать снятия блокировок записи и не блокировать читаемые таблицы. Однако здесь важно учитывать тонкости работы платформы:

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

Если разработчик не наложит явную управляемую блокировку в коде через объект БлокировкаДанных, при включенном RCSI параллельные транзакции прочитают снимок данных на момент начала транзакции из базы tempdb. В результате обе транзакции посчитают, что остаток достаточен, и параллельно спишут товар, что приведет к возникновению отрицательных остатков.

Посмотрим на пример правильной установки управляемой блокировки перед проверкой остатков:

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

Как локализовать проблему медленного проведения

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

1. Проверка в монопольном режиме: Выполним проведение документа в тестовой базе, где нет других активных сеансов. Если скорость проведения остается низкой, проблема гарантированно не связана с ожиданиями на блокировках 1С или СУБД.
2. Анализ специфики встроенного замера производительности: Замер отладчика 1С фиксирует только время исполнения строк встроенного языка. В замер не попадают многие платформенные операции: ожидание сетевого пакета между сервером 1С и СУБД (RTT), неявные вызовы при обновлении связанных данных, невидимые ожидания синхронной записи журнала транзакций СУБД (WRITELOG).
3. Проверка актуальности итогов регистров: Если в базе вовремя не сдвигается граница рассчитанных итогов регистров накопления, платформа при проведении документов и расчете виртуальных таблиц вынуждена читать все движения за огромный период из таблицы _AccumRg, вместо быстрого чтения итогов из таблицы _AccumRgT.
4. Проведение документов задним числом: Если дата проводимого документа лежит раньше актуальной границы итогов, платформа в момент фиксации транзакции выполняет фоновый пересчет агрегатов по всем последующим периодам для каждого затронутого регистра. При наличии десятков регистров это вызывает значительную задержку.
5. Подписки на события и регистрация изменений: При записи движений срабатывают механизмы авторегистрации для планов обмена. Запись изменений в таблицы регистрации (_ChangeRec) на множестве узлов обмена кратно увеличивает время фиксации транзакции.
6. Диагностика через Технологический журнал (ТЖ): Настроим сбор событий DBMSSQL (или DBPOSTGRS) с отбором по длительности duration > 100000 (от 100 мс), а также событий CALL и SCALL. Это позволит точно увидеть текст SQL-запросов и понять, сколько реального времени уходит на стороне сервера баз данных.