← На главную

Ситуация, когда расчет себестоимости в 1С:ERP «съедает» всё доступное место в tempdb, является классической проблемой высоконагруженных систем. Даже существенное увеличение дискового пространства часто дает лишь временный эффект. Давайте разберем, как локализовать причину и какие шаги предпринять для исправления ситуации.

Этап 1: Мониторинг и поиск «тяжелых» запросов

Первым делом нам необходимо выяснить, какой именно запрос провоцирует лавинообразный рост временных таблиц. Не стоит надеяться на удачу — нужно приступать к сбору данных.

1. Анализ текущей активности SQL Server. В момент, когда начинается активный рост tempdb, используйте инструменты мониторинга (SQL Server Management Studio или штатные средства мониторинга 1С), чтобы выявить TOP-5 запросов по чтению/записи в системную базу данных.
2. Использование ТЖ (Технологического журнала). Если стандартные средства не дают ответа, настройте технологический журнал для логирования запросов, длительность которых превышает пороговое значение.
3. Анализ планов выполнения. Обратите внимание на операции типа Hash Match и Sort. Если в плане запроса вы видите, что SQL Server постоянно сбрасывает данные в tempdb (TempDB Spool), значит, запрос составлен неоптимально для текущего объема данных.

Этап 2: Проверка логики запросов и структуры данных

Иногда причина кроется в неочевидных моментах, например, в способе получения данных из периодических регистров.

Рассмотрим распространенный пример: получение среза последних для соединений с курсами валют или ценами. Если вы соединяете таблицу движений сразу с функцией получения среза, SQL может тратить колоссальные ресурсы на вычисление. Попробуйте разбить запрос на этапы:

1. Сначала получите необходимые данные из регистра (срез последних) во временную таблицу.
2. Проиндексируйте эту временную таблицу.
3. Выполните соединение уже подготовленных данных с основной выборкой.

Такой подход позволяет серверу работать с меньшими объемами данных на каждой итерации, что радикально снижает нагрузку на tempdb.

Этап 3: Техническая настройка SQL Server

Даже оптимизированный код может пасовать перед неверно настроенным экземпляром SQL Server. Разберем критические параметры:

• Файлы tempdb. Убедитесь, что tempdb разбит на несколько файлов данных. Рекомендуется создавать их по количеству логических ядер процессора (до 8 штук). Важно, чтобы все файлы имели абсолютно одинаковый начальный размер и шаг авторасширения. Это предотвращает конкуренцию за страницы распределения (PAGELATCH_UP).
• Актуальность статистики. Обязательно проверьте, как часто обновляется статистика по таблицам регистров. Если статистика устарела, оптимизатор может выбрать план сканирования всей таблицы вместо точечного поиска, что приведет к катастрофическому росту временных объектов.
• Итоги регистров. Проверьте, не отключены ли итоги в регистрах, по которым идет расчет. Несмотря на то, что РСВ штатно ими управляет, сбои в регламентных заданиях могут привести к тому, что итоги перестают считаться или становятся неактуальными.

Этап 4: Работа с конфигурациями сторонних разработчиков

Поскольку в вашем случае используется «Бит.Финанс», нельзя исключать влияние стороннего кода. Посмотрите, не запускаются ли регламентные задания «Бит.Финанса» параллельно с расчетом себестоимости. Конкуренция за таблицы может приводить к блокировкам, из-за которых расчет себестоимости становится «бесконечным», а временные таблицы в tempdb растут до исчерпания места.

Попробуйте временно ограничить расписание других фоновых заданий на период закрытия месяца. Это позволит изолировать влияние основной конфигурации и точно понять, в каком именно процессе происходит затык.

Что делать, если ничего не помогает?

Если после всех оптимизаций расчет по-прежнему падает, стоит проанализировать настройки параллелизма (MAXDOP). Если сервер выполняет множество задач, попробуйте ограничить MAXDOP значением от 4 до 8. Это уменьшит количество параллельных потоков, каждый из которых требует свой кусок памяти и места в tempdb.

Также рекомендуется использовать Query Store (в SQL Server 2016+), чтобы увидеть, не произошел ли «регресс плана запроса». Часто бывает, что раньше отчет работал быстро, а после изменения объема данных (например, добавления записей за новый месяц) сервер начал выбирать другой, менее эффективный план выполнения для тех же самых запросов.

Помните: работа с tempdb — это всегда поиск баланса между эффективностью алгоритма и аппаратными ресурсами. Начните с анализа запросов, оптимизируйте работу с временными таблицами, и вы увидите, что стабильность системы заметно возрастет.