Как устранить массовые взаимоблокировки по регистру «Товары к передаче» в старой базе УТ?

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

Оценим риски «очереди проведения»

Идея вынести проведение документов в отдельный сеанс через «Очередь проведения» кажется заманчивой, но она несет серьезные риски для бизнеса:

1. Потеря актуальности данных: Оперативный учет перестает быть оперативным. Менеджеры будут видеть остатки, которые не соответствуют реальности, что приведет к пересортице и ошибкам при отгрузке.
2. Проблемы с контролем остатков: При отложенном проведении документ может «не провестись» из-за нехватки товара, выявленной уже постфактум. Уведомление пользователя через некоторое время после нажатия кнопки «Провести» создает хаос в бизнес-процессах.
3. Эффект бутылочного горлышка: Отдельный фоновый сеанс превращается в узкое место. Если количество документов велико, очередь начнет расти, и задержка проведения увеличится до неприемлемых значений.

Таким образом, использование очереди — это лишь «костыль», который маскирует симптомы, но не лечит болезнь. Наша задача — найти истинную причину конфликтов.

Диагностика с помощью технологического журнала

Первым делом мы должны увидеть, какой именно программный код «держит» блокировку дольше всех. Единственный достоверный инструмент для этого в 1С — Технологический журнал. SQL-сервер сам по себе может быть лишь жертвой, а причина всегда кроется в логике транзакций 1С.

Настроим сбор данных для фиксации событий tdeadlock и tlock. Создадим конфигурационный файл logcfg.xml:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
 <dump create="false"/>
 <log location="C:\TechLogs\" history="1">
  <event>
   <eq property="name" value="tdeadlock"/>
  </event>
  <event>
   <eq property="name" value="tlock"/>
  </event>
  <property name="all">
   <event>
    <eq property="name" value="tdeadlock"/>
   </event>
   <event>
    <eq property="name" value="tlock"/>
   </event>
  </property>
 </log>
</config>

Разберем, что мы ищем: события TLOCK, длительность которых превышает 1-2 секунды, укажут на «тяжелые» транзакции. Сопоставив время возникновения события с журналом регистрации 1С, мы вычислим конкретный документ или обработку, которая блокирует регистр ТоварыКПередаче.

Оптимизация работы с регистром

После того как мы выяснили, какой участок кода вызывает блокировки, применим следующие методы оптимизации:

1. Анализ транзакций: Посмотрите, не открывается ли транзакция слишком рано. Старайтесь сократить время между НачатьТранзакцию() и ЗафиксироватьТранзакцию(). Все тяжелые вычисления, запросы к внешним источникам и проверку прав доступа выполняйте до открытия транзакции записи.
2. Разбиение на части: Если документ двигает множество записей по регистру, попробуйте разбивать проведение на несколько транзакций, если это позволяет логика учета. Хотя для регистров накопления это сложная задача, иногда помогает оптимизация алгоритма записи, чтобы минимизировать количество одновременно блокируемых строк.
3. Обслуживание БД: Убедитесь, что на сервере SQL выполнены регламентные работы. Для старых баз жизненно важно актуализировать статистику. Используйте команду UPDATE STATISTICS и выполните перестроение индексов. Фрагментация индексов — частая причина того, что SQL-сервер блокирует целые страницы данных вместо конкретных записей.
4. Проверка уровня изоляции: Убедитесь, что база данных использует уровень изоляции READ_COMMITTED_SNAPSHOT. Это позволяет считывать данные без блокировок, что критически важно для работы 1С в режиме высокой конкуренции.

Технические нюансы: сеансовые данные

В ходе обсуждения часто упоминается очистка папок scntx или файлов srvinfo. Хотя это не влияет на логику блокировок в БД напрямую, очистка кэша сеансов сервера 1С помогает при «зависаниях» и необъяснимых ошибках взаимодействия клиент-сервер. Если у пользователей возникают странные ошибки, попробуйте остановить службу 1С и очистить временные файлы кластера — это стандартная гигиеническая процедура для крупных систем.

Итого: не спешите переписывать архитектуру под очередь проведения. Сначала соберите логи через технологический журнал, найдите «виновника» — конкретную транзакцию, и оптимизируйте именно её алгоритм записи. Чаще всего проблема решается либо сокращением длительности транзакции, либо обновлением статистики и индексов на уровне SQL-сервера.