При работе с крупными базами данных 1С администраторы и разработчики часто сталкиваются с дилеммой: поддерживать актуальность итогов за все периоды или экономить дисковое пространство. Расчет итогов по всем периодам может увеличить размер базы на сотни гигабайт, что существенно замедляет обслуживание БД (создание бэкапов, переиндексацию). Однако отключение итогов заставляет систему вычислять остатки «на лету» из таблицы движений, что создает огромную нагрузку на сервер.
В этой статье мы разберем, как точно определить, к каким периодам и как часто обращаются пользователи и система, чтобы принять обоснованное решение о необходимости расчета итогов.
Основной способ узнать, что происходит «под капотом» платформы — это настройка Технологического журнала. С его помощью мы можем отследить запросы на уровне SDBL (внутренний язык запросов 1С) и DBMSSQL (прямые запросы к SQL-серверу).
Для начала нам необходимо выяснить физические имена таблиц интересующего нас регистра. Это можно сделать с помощью встроенной функции:
ПолучитьСтруктуруХраненияБазыДанных()
Найдите в полученной таблице имена для таблицы итогов (обычно _AccumRegTotalsX) и таблицы движений (_AccumRegX). Далее настроим сбор событий в logcfg.xml. Нас интересуют обращения, где в условиях фигурирует дата.
Проанализируем важный нюанс: платформа 1С интерпретирует текущие (оперативные) остатки как дату 01.11.3999. Если в логах ТЖ в параметрах запроса к таблице итогов вы видите эту дату, значит, система запрашивает актуальные остатки. Если же фигурируют даты из прошлого — система лезет в архивные итоги.
Если настройка ТЖ кажется слишком трудоемкой, мы можем посмотреть на статистику запросов со стороны SQL-сервера. Использование таких инструментов, как SQL Server Extended Events или Query Store, позволяет выявить наиболее «тяжелые» запросы к таблицам регистра.
_AccumRegX) идет аномально много запросов типа SELECT SUM(...), это явный признак того, что итоги на нужный период не рассчитаны, и платформа суммирует записи с самого начала или от ближайшей точки рассчитанных итогов.logical reads при обращении к виртуальным таблицам остатков в отчетах за прошлые периоды подтверждают необходимость включения итогов для этих периодов.Рассмотрим ситуацию, когда нам нужно проверить конкретный отчет или документ. В конфигураторе 1С можно запустить замер производительности. В современных версиях платформы замер позволяет увидеть не только время выполнения строк кода, но и связанные с ними SQL-запросы.
Если при получении остатков через запрос к виртуальной таблице Остатки вы видите, что в тексте SQL-запроса отсутствует обращение к _AccumRegTotals, а вместо этого выбираются данные из _AccumReg (таблица движений), значит, система вынуждена считать данные «на лету».
Нужно понимать, что платформа 1С никогда не выдает ошибку, если итоги не рассчитаны. Она всегда старается получить результат. Если итогов нет, платформа берет остатки на ближайшую дату (например, на сегодня) и начинает «отматывать» движения назад, вычитая их из текущего значения, пока не дойдет до нужного момента в прошлом.
Выясним причину нагрузки: При большом количестве движений (миллионы записей) такой расчет может занимать минуты вместо миллисекунд. Именно поэтому важно знать профиль нагрузки: если 99% запросов идут на текущую дату, то хранить итоги за 10 лет действительно бессмысленно.
Если анализ показал, что запросы к старым периодам редки, но все же случаются, рассмотрим альтернативные варианты:
Индексировать для тех измерений, которые чаще всего используются в фильтрах. Это поможет платформе чуть быстрее собирать остаток из таблицы движений.Таким образом, комбинируя мониторинг через Технологический журнал и инструменты СУБД, мы можем получить точную картину использования данных и сэкономить десятки гигабайт на дисковом массиве без ущерба для пользователей.