В работе с конфигурацией Управление производственным предприятием (УПП 1.3) специалисты часто сталкиваются с ситуацией, когда документ Расчет себестоимости выполняется многие часы, а в итоге выдает ошибку, связанную с нехваткой места в базе tempdb на SQL-сервере. При этом системные администраторы могут утверждать, что свободного места на дисках достаточно. Разберем подробно, почему это происходит и как решить данную проблему.
Для начала проанализируем, как работает механизм РАУЗ (Расширенная аналитика учета затрат). В отличие от традиционной партионки, РАУЗ решает задачу распределения затрат через систему линейных алгебраических уравнений (СЛАУ). Расчет происходит итерационным методом (как правило, методом Гаусса-Зейделя).
Когда в системе все данные корректны, итерации быстро сходятся к результату. Однако, если в данных присутствуют отрицательные остатки по количеству или стоимости, математическая матрица становится «плохо обусловленной». Процесс итераций вместо того, чтобы завершиться, начинает «разгоняться»: суммы в расчетах растут до триллионов, а количество временных таблиц в SQL-сервере увеличивается в геометрической прогрессии. Именно это приводит к тому, что tempdb разрастается до гигантских размеров и в итоге «падает» по тайм-ауту или нехватке места в выделенном файле.
Это самый важный этап. Как справедливо замечено в обсуждении, отрицательные остатки — это «смерть» для РАУЗ. Даже несколько копеечных «минусов» могут заставить систему выполнять расчет бесконечно долго. Выясним причину их появления и способы локализации.
Проанализируем данные с помощью отчета Ведомость по учету затрат. Для поиска проблемных мест настроим отчет следующим образом:
Раздел учета, Аналитика вида учета (Склад), Аналитика учета номенклатуры (Номенклатура, Характеристика, Серия).Количество Конечный остаток Меньше 0 ИЛИ Стоимость Конечный остаток Меньше 0.Если отчет показал наличие отрицательных остатков, их необходимо исправить (инвентаризацией, корректировкой записей регистров или исправлением первичных документов) до запуска расчета себестоимости.
Если исправить данные оперативно невозможно, а расчет нужно получить «здесь и сейчас», можно применить методику временной корректировки. Рассмотрим, как это сделать программно или с помощью документа Корректировка записей регистров.
Суть метода заключается в том, чтобы на последнюю секунду месяца, предшествующего расчетному, ввести записи, которые выведут остатки в ноль, а первым числом следующего месяца эти записи сторнировать. Рассмотрим пример логики обработки, которая могла бы помочь найти такие остатки и сформировать движения по регистру УчетЗатрат:
// Пример логики для поиска минусов в РАУЗ
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| УчетЗатратОстатки.АналитикаВидаУчета,
| УчетЗатратОстатки.АналитикаУчетаНоменклатуры,
| УчетЗатратОстатки.АналитикаУчетаЗатрат,
| УчетЗатратОстатки.КоличествоОстаток,
| УчетЗатратОстатки.СтоимостьОстаток
|ИЗ
| РегистрНакопления.УчетЗатрат.Остатки(&ДатаРасчета, ) КАК УчетЗатратОстатки
|ГДЕ
| (УчетЗатратОстатки.КоличествоОстаток < 0 ИЛИ УчетЗатратОстатки.СтоимостьОстаток < 0)";
Результат = Запрос.Выполнить().Выгрузить();
// Далее формируем движения в плюс для компенсации минуса
Важно: Помните, что это лишь временная мера, чтобы расчет прошел. После завершения процедуры «минусы» вернутся, и их все равно придется исправлять методами бухгалтерского учета.
Если данные очищены, но tempdb все равно растет, необходимо проверить настройки SQL-сервера. Проанализируем рекомендации для работы с высоконагруженными базами 1С:
tempdb (обычно по количеству ядер процессора, но не более 8). Все файлы должны иметь одинаковый начальный размер и одинаковый шаг авторасширения.tempdb вынесен на самый быстрый диск (лучше всего NVMe SSD), так как при расчете себестоимости в УПП идет колоссальное количество операций записи во временные таблицы.Рассмотрим возможности самого документа Расчет себестоимости. В нем есть режимы, которые могут облегчить выполнение задачи:
Использование транзакций: Одним из дельных советов является запуск расчета «вне транзакции». По умолчанию 1С пытается выполнить весь расчет в одной огромной транзакции. Если происходит сбой, SQL долго откатывает изменения. В некоторых релизах можно попробовать разбить расчет на этапы (отдельные документы на разные регламентные операции: «Расчет прямых затрат», «Расчет косвенных затрат» и т.д.).
Точность решения СЛАУ: В настройках параметров учета (вкладка «Затраты») можно найти параметры РАУЗ. Попробуйте временно снизить точность итераций. Если стоит 0.000001, установите 0.01. Это позволит системе быстрее «схлопнуть» расчет, даже если в данных есть небольшие логические перекосы.
Чтобы понять, на каком именно этапе «зависает» система, проанализируем Журнал регистрации. Однако более эффективным будет использование Консоли запросов или Консоли анализа временных таблиц. Если вы видите, что на этапе расчета МПЗ (материально-производственных запасов) SQL-сервер начинает потреблять аномально много памяти, значит, вы столкнулись с «зацикливанием» встречного выпуска.
Проанализируем ситуацию со встречным выпуском. В УПП есть регистр сведений Встречный выпуск продукции (услуг). Если у вас продукция «А» участвует в производстве продукции «Б», а «Б» — в производстве «А», и это не описано в регистре, РАУЗ может уйти в бесконечный цикл. Обязательно проверьте заполнение этого регистра для всех циклических производственных процессов.
Выясним причину сбоя окончательно: в 99% случаев это сочетание отрицательных остатков и некорректных петель встречного выпуска. SQL-сервер лишь сигнализирует о последствиях, пытаясь переварить математически невозможную задачу.
Для успешного решения задачи придерживайтесь следующего алгоритма:
УчетЗатрат.tempdb (фиксированный шаг роста, быстрый диск).Выполнение этих шагов позволит сократить время расчета с «половины дня» до разумных пределов и полностью избавит от ошибок переполнения временных таблиц.