Почему документы Перемещение товаров в 1С зависают при проведении и работают только в режиме отладки?

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

Анализ ситуации: почему отладка «помогает» проведению?

Когда мы сталкиваемся с тем, что в режиме отладки документ «проскакивает», а в обычном — виснет, мы имеем дело не с ошибкой в коде, а с особенностями работы менеджера блокировок и СУБД. Разберем, почему это происходит:

1. Разные контексты соединения. При запуске отладки платформа может инициировать новое соединение с SQL-сервером с иными параметрами. Это часто заставляет оптимизатор СУБД сбросить старый, неэффективный план запроса и построить новый, который отрабатывает быстро.
2. Изменение тайм-аутов. В режиме отладки механизмы ожидания блокировок могут вести себя иначе, что позволяет транзакции завершиться там, где в обычном режиме она упирается в бесконечное ожидание или конфликт.
3. Фоновые задания. В режиме отладки некоторые регламентные процессы могут блокироваться или иметь низший приоритет, освобождая ресурсы для основной транзакции проведения.

Решение проблемы через механизмы РИБ

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

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

• Проведем полный обмен данными. Необходимо инициировать сеанс связи с главным узлом. В процессе обмена таблицы регистрации очищаются, а конфигурация и метаданные синхронизируются.
• Проверим кэш конфигурации. Иногда в узлах РИБ возникает микро-рассогласование динамического обновления. Обмен данными принудительно актуализирует структуру таблиц.

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

Технические особенности блокировок в MS SQL Server

Если обмен РИБ не помог, проанализируем ситуацию на уровне СУБД. Зависание без выдачи ошибки («бесконечные песочные часы») — классический признак эскалации блокировок. Проанализируем, что происходит внутри SQL:

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

Для решения рекомендуется выполнить регламентные операции на уровне SQL-сервера:

-- Обновление статистики для более точного построения планов запросов
UPDATE STATISTICS [Имя_Таблицы];
-- Очистка процедурного кэша (использовать с осторожностью на рабочих базах)
DBCC FREEPROCCACHE;

Проверка полнотекстового поиска и индексов

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

Попробуем выполнить следующие шаги:

• Временно отключите полнотекстовый поиск через консоль администрирования или программно.
• Если проведение восстановилось — необходимо выполнить полную очистку и обновление индекса ППС.
• Выполните индексацию таблиц базы данных через «Обслуживание» в режиме 1С:Предприятие или через Типовые регламентные операции.

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

Если стандартные методы не помогают, проанализируем проблему с помощью Технологического журнала (ТЖ). Нам интересны события TLOCK (управляемые блокировки) и TTIMEOUT (превышение времени ожидания). Рассмотрим пример настройки файла logcfg.xml для поиска виновника зависания:

<config xmlns="http://v8.1c.ru/7.4/config/log">
  <log location="C:\LOGS\LOCKS" history="2">
    <event>
      <eq property="Name" value="TLOCK"/>
    </event>
    <event>
      <eq property="Name" value="TTIMEOUT"/>
    </event>
  </log>
</config>

Анализ логов позволит точно определить, на каком именно регистре накопления (например, ЗапасыИПотребности или ТоварыНаСкладах) происходит остановка и какое другое соединение удерживает блокировку. Часто виновником оказывается «спящий» сеанс, который завис в терминальной сессии и продолжает удерживать объектные блокировки на сервере приложений 1С.

Итоги и рекомендации

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

1. Синхронизацию РИБ (если используется).
2. Очистку серверного кэша и перезапуск службы 1C:Enterprise Server Administration.
3. Обновление статистики СУБД.
4. Проверку и отключение зависших сеансов в консоли кластера.

Эти действия в 90% случаев позволяют восстановить работоспособность системы без внесения изменений в программный код документа.