В процессе эксплуатации систем на базе 1С:Предприятие 8.3 администраторы и разработчики часто сталкиваются с парадоксальной ситуацией: один и тот же отчет (например, оборотно-сальдовая ведомость) за один месяц формируется мгновенно, а за другой — вызывает длительное «зависание» системы. Особенно остро эта проблема проявляется после обновления платформы, перехода на новые релизы БСП (Библиотеки стандартных подсистем) или повышения режима совместимости конфигурации. В данной статье мы подробно разберем, почему это происходит, как диагностировать проблему с помощью инструментов SQL Server и как программно восстановить производительность системы.
Рассмотрим типовую ситуацию. После обновления базы с режима совместимости 8.3.14 до 8.3.17 и подключения новых механизмов БСП, отчеты за прошлые периоды (например, за сентябрь) начинают работать крайне медленно, в то время как за текущие (октябрь) — «летают». Стандартные действия, такие как пересчет итогов в конфигураторе, обновление статистики SQL или реструктуризация таблиц, в данном случае могут не приносить результата.
Проанализируем ситуацию с точки зрения СУБД. При изучении планов запроса через SQL Profiler или Extended Events можно заметить колоссальную разницу в объеме обрабатываемых данных. В «быстром» запросе система может обрабатывать около 200 тысяч строк, в то время как в «медленном» — более 6 миллионов строк для аналогичного периода. Это происходит потому, что в первом случае 1С обращается к таблицам итогов, а во втором — игнорирует их и выполняет полное сканирование основной таблицы движений регистра (например, AccRg для бухгалтерии).
Выясним причину такого поведения платформы. В 1С существует малозаметный, но критически важный механизм — Минимальный период рассчитанных итогов. Его задача заключается в оптимизации ресурсов: платформа отсекает возможность использования итогов для слишком старых периодов, которые считаются архивными. Если дата начала отчета оказывается меньше этого установленного периода, система перестает доверять таблицам итогов и начинает пересчитывать остатки и обороты «с нуля» по таблице движений от самого начала ведения учета.
При обновлении конфигурации или смене режима совместимости этот параметр может установиться некорректно или сброситься. В результате «граница доверия» к итогам сдвигается, и отчеты за вполне актуальные месяцы начинают требовать сканирования миллионов записей.
Для решения проблемы нам потребуется выполнить несколько действий на стороне сервера. Мы не будем полагаться только на стандартный интерфейс «Управление итогами», так как он не всегда позволяет увидеть скрытые настройки регистра. Разберем по шагам, как проверить и установить нужные значения для Регистра Бухгалтерии.
Во-первых, проверим текущее значение минимального периода. Для этого выполним следующий код (где Типовой — имя вашего регистра бухгалтерии):
// Получаем дату, ранее которой итоги не используются
ДатаМинимума = РегистрыБухгалтерии.Типовой.ПолучитьМинимальныйПериодРассчитанныхИтогов();
Сообщить("Минимальный период итогов сейчас: " + ДатаМинимума);
Если возвращаемая дата позже, чем период, за который отчет тормозит, значит, причина найдена. Для исправления ситуации необходимо принудительно установить минимальный период на более раннюю дату, например, на начало прошлого года или на дату начала ведения учета в базе:
// Устанавливаем корректную границу для использования итогов
НужнаяДата = Дата(2021, 01, 01);
РегистрыБухгалтерии.Типовой.УстановитьМинимальныйПериодРассчитанныхИтогов(НужнаяДата);
Сообщить("Минимальный период успешно изменен на " + НужнаяДата);
После выполнения этого кода система снова начнет использовать таблицы итогов для построения отчетов за указанный период, что моментально сократит количество сканируемых строк в SQL Server.
Проанализируем дополнительные факторы, которые могут усугублять проблему. При использовании SQL Server 2019 включаются механизмы Intelligent Query Processing. Один из них — Adaptive Join. В некоторых случаях 1С генерирует запросы, которые конфликтуют с этой функцией, вызывая неоптимальный выбор плана выполнения.
Если изменение периода итогов помогло частично, попробуем изменить настройки базы данных на стороне SQL. В частности, можно попробовать отключить адаптивные соединения или понизить уровень совместимости базы (Compatibility Level) до 140 (соответствует SQL Server 2017). Для отключения конкретной фичи без смены уровня совместимости используйте команду:
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ADAPTIVE_JOINS = OFF;
Также стоит обратить внимание на Parameter Sniffing. Поскольку 1С активно использует временные таблицы, SQL Server может кэшировать план запроса, построенный для «легкого» периода, и пытаться применить его к «тяжелому». Регулярное обновление статистики (особенно по таблицам AccRg) и очистка процедурного кэша могут помочь в стабилизации производительности.
Разберем вопрос увеличения объема базы данных на 25-30% после перехода на режим 8.3.17. Это часто связано с особенностями хранения данных в новых версиях БСП и платформы:
SHRINK не поможет, пока фоновый процесс очистки не завершит работу.Для минимизации размера рекомендуется выполнить полную реиндексацию и убедиться, что в базе не хранятся избыточные данные версионирования за длительный период.
Подведем итог нашему исследованию. Если ваши отчеты в 1С работают выборочно медленно, следуйте этой инструкции:
ПолучитьМинимальныйПериодРассчитанныхИтогов() для проверки границ расчета.УстановитьМинимальныйПериодРассчитанныхИтогов().BATCH_MODE_ADAPTIVE_JOINS.Соблюдение этих шагов позволяет восстановить нормальную работу системы без необходимости дорогостоящего апгрейда оборудования или глубокой переработки кода конфигурации.