Почему оборотно-сальдовая ведомость по счету долго формируется после обновления и как это исправить?

← На главную

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

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

Почему стандартные методы оптимизации базы данных не помогают

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

Пересчет итогов бухгалтерского регистра из режима «Конфигуратор» или обработкой «Управление итогами».
Тестирование и исправление информационной базы (ТИИ).
Обновление статистик и реиндексация таблиц на сервере MS SQL Server.
Очистка кэша планов выполнения запросов с помощью системной команды СУБД:

DBCC FREEPROCCACHE;

Однако при анализе производительности через Центр управления производительностью (ЦУП) или Технологический журнал выясняется важная деталь: сам SQL-запрос к виртуальной таблице остатков и оборотов регистра бухгалтерии отрабатывает мгновенно — за 1–2 секунды. Основное зависание происходит уже после получения данных из СУБД, внутри системы компоновки данных (СКД) на сервере приложений 1С.

Причины зависания отчета на уровне СКД

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

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

Пошаговая локализация узкого места

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

Посмотрим на типовой программный код формирования отчета через СКД и расставим точки замера:


// 1. Компоновка макета
ВремяСтарт = ТекущаяУниверсальнаяДатаВМиллисекундах();
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, НастройкиОтчета, ДанныеРасшифровки);
ЗафиксироватьВремя("Компоновка макета", ВремяСтарт);

// 2. Инициализация процессора компоновки
ВремяСтарт = ТекущаяУниверсальнаяДатаВМиллисекундах();
ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, , ДанныеРасшифровки, Истина);
ЗафиксироватьВремя("Инициализация процессора", ВремяСтарт);

// 3. Вывод в табличный документ
ВремяСтарт = ТекущаяУниверсальнаяДатаВМиллисекундах();
ТабличныйДокумент.Очистить();
ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(ТабличныйДокумент);
ПроцессорВывода.Вывести(ПроцессорКомпоновки);
ЗафиксироватьВремя("Вывод в табдок", ВремяСтарт);

Если максимальное время уходит на метод КомпоновщикМакета.Выполнить или ПроцессорКомпоновки.Инициализировать, источник проблемы гарантированно кроется в настройках полей, характеристиках или структуре наборов данных самой схемы СКД.

Способы решения проблемы

Рассмотрим варианты устранения проблемы в зависимости от возможности внесения изменений в конфигурацию:

Проверка справочника дополнительных реквизитов:
Выясним, нет ли переполнения в таблице свойств после синхронизации данных. Для этого выполним простой запрос в консоли запросов:
```
ВЫБРАТЬ
    КОЛИЧЕСТВО(Ссылка) КАК ВсегоЭлементов
ИЗ
    Справочник.НаборыДополнительныхРеквизитовИСведений
```
Если количество записей аномально велико (десятки тысяч дублей), необходимо запустить процедуру поиска и удаления дублирующихся элементов либо очистить неиспользуемые наборы свойств, созданные ошибочным обменом.
Отключение характеристик в схеме СКД:
Если для стандартной оборотно-сальдовой ведомости не требуется вывод произвольных дополнительных реквизитов субконто, откроем схему компоновки отчета, перейдем на вкладку Характеристики и удалим или временно отключим строки, связывающие типы субконто со свойствами. Это избавит платформу от необходимости анализировать метаданные при первой компоновке.
Замена схемы компоновки на стабильную версию (быстрое решение):
Если проблему требуется решить немедленно без долгого рефакторинга типового механизма, воспользуемся проверенным решением: выгрузим схему отчета или объект отчета целиком из предыдущей стабильной версии конфигурации (до обновления), где отчет работал быстро, и заменим им текущую схему.

Чтобы сохранить конфигурацию на полной поддержке поставщика, реализуем эту замену через расширение конфигурации с назначением «Исправление» или «Адаптация», переопределив макет или основную схему компоновки отчета ОборотноСальдоваяВедомостьПоСчету.
Очистка пользовательских настроек отчета:
В некоторых случаях старые сохраненные варианты отчета конфликтуют с новой структурой группировок. Через раздел Администрирование — Настройки пользователей и прав — Очистка настроек сбросим индивидуальные настройки отчета для проблемных учетных записей.

Таким образом, когда отчет зависает при быстром выполнении SQL-запроса, источник торможения всегда находится в механизмах обработки данных платформы 1С. Локализация этапа компоновки и корректировка схемы СКД позволяют полностью восстановить штатную скорость формирования оборотки.