Ситуация, когда при расчете себестоимости в тяжелых конфигурациях, таких как 1С:ERP Управление предприятием, временная база данных SQL Server (tempdb) разрастается до невероятных размеров, превышающих объем основной базы в несколько раз, является критической для бизнеса. Мы можем столкнуться с тем, что даже выделение нескольких терабайт дискового пространства не решает проблему — процесс «съедает» всё доступное место и аварийно завершается. Рассмотрим детально, почему это происходит и как найти выход из этой ситуации, опираясь на технические особенности работы 1С и MS SQL Server.
Для начала проанализируем, какие механизмы заставляют SQL Server так активно использовать временное хранилище. В 1С:ERP расчет себестоимости — это сложнейший итерационный процесс, включающий решение систем линейных алгебраических уравнений (СЛАУ). Рассмотрим основные технические факторы:
READ_COMMITTED_SNAPSHOT. При этом режиме SQL Server хранит версии изменяемых строк в «хранилище версий» (Version Store), которое физически находится в tempdb. Если расчет себестоимости длится 20–30 часов, то всё это время tempdb обязан хранить старые версии всех строк, которые изменяются любыми другими процессами в системе.tempdb, так как выделенной оперативной памяти не хватает для обработки миллионов строк «в уме».Как показывает практика, «ларчик часто открывается просто». Одной из главных причин аномального поведения системы является некорректное закрытие предыдущего месяца. Даже если формально месяц отмечен как «закрытый», в нем могут остаться логические ошибки, которые система пытается исправить в текущем периоде.
Рассмотрим алгоритм проверки:
ПрочиеРасходы. Выясним, нет ли в нем зависших остатков по статьям, которые должны были распределиться «на себестоимость товаров».tempdb. В этом случае поможет автоматическое устранение отрицательных остатков.Важный момент: если вы обнаружили, что последовательность закрытия сбита и система просит пересчитать данные за несколько прошлых лет, не стоит запускать расчет сразу за весь период. Рекомендуется выполнять расчет постепенно, по одному месяцу или кварталу, предварительно исправляя ошибки в каждом этапе.
Чтобы понять, какая именно часть расчета вызывает рост, проанализируем активность SQL Server. Мы можем использовать SQL Базомер или следующий запрос для мониторинга использования tempdb конкретными сессиями:
SELECT
s.session_id,
s.login_name,
s.host_name,
t5.text AS [Query Text],
(user_objects_alloc_page_count + internal_objects_alloc_page_count) * 8 / 1024 AS [AllocatedMB],
(user_objects_dealloc_page_count + internal_objects_dealloc_page_count) * 8 / 1024 AS [DeallocatedMB]
FROM sys.dm_db_session_space_usage AS s
JOIN sys.dm_exec_requests AS r ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t5
WHERE s.session_id > 50;
Этот запрос позволит нам увидеть, какой именно SQL-запрос от 1С «пожирает» место. Часто это бывают огромные временные таблицы, создаваемые при детализации себестоимости до дополнительных расходов. Если мы видим, что объем AllocatedMB исчисляется сотнями гигабайт, значит, мы столкнулись либо с логической петлей в данных, либо с декартовым произведением (Cartesian Product) из-за пустых аналитик в регистрах.
В настройках 1С:ERP существует возможность включить параллельный расчет себестоимости. Проанализируем, как это влияет на ресурсы. При большом количестве потоков каждый поток создает свои собственные копии временных таблиц в tempdb. Если дисковая подсистема не справляется, это приводит к лавинообразному росту очереди и объема временных файлов.
Рекомендация: попробуем временно снизить количество потоков расчета до 1 или 2 в настройках параметров системы. Это позволит локализовать проблему и убедиться, что рост не связан с избыточным параллелизмом.
Разберем ситуацию с партионным учетом. При переходе между версиями ERP (например, с 2.2 на 2.5) или смене учетной политики могут остаться некорректные записи в технических регистрах. Если в регистре ПартииТоваровОрганизаций присутствуют записи с пустой аналитикой (например, не указан Склад или Заказ), механизм распределения партий может пытаться сопоставить их со всеми доступными документами поступления. Это создает гигантскую временную таблицу в памяти SQL, которая мгновенно сбрасывается в tempdb.
Для поиска таких записей воспользуемся стандартными консолями запросов или выполним сравнение регистров «Товары на складах» и «Товары организаций», проверяя наличие пустых значений в ключевых измерениях регистров:
АналитикаУчетаНоменклатурыОрганизацияРазделУчетаПартияЕсли программные методы не помогают, проанализируем настройки самого сервера баз данных. Рассмотрим следующие шаги:
FULLSCAN для всех таблиц, участвующих в расчете себестоимости (регистры накопления СебестоимостьТоваров, ВыручкаИСебестоимостьПродаж).tempdb разделен на несколько файлов одинакового размера (согласно количеству ядер процессора, но обычно не более 8). Это поможет избежать конкуренции за страницы (PFS/GAM contention) и немного ускорит работу, хотя и не спасет от роста объема.Выясним краткую последовательность действий, если ваш tempdb начал бесконтрольно расти:
Помните, что SQL версия ERP — это не про экономию места, но рост временной базы до 2.7 ТБ при основном объеме 2 ТБ — это всегда признак логической ошибки в данных или зацикливания алгоритма, а не нормальное поведение системы. Регулярный аудит корректности закрытия прошлых периодов и контроль чистоты данных в регистрах — залог стабильной работы процедуры закрытия месяца.