При закрытии месяца в УТ 11.4 начинается рост tempdb, который заполняет все место для tempdb и программа падает.
Нашли запрос, на котором умирает tempdb:
    ВЫБРАТЬ РАЗЛИЧНЫЕ
        ДД.ДокументВыпуска КАК Регистратор,
        ДД.АналитикаУчетаПродукции КАК АналитикаУчетаПродукции,
        Приходы.Период
    ИЗ
        РегистрНакопления.ПартииЗатратНаВыпуск.Остатки(&НачалоПериода, Организация В (&МассивОрганизаций)) КАК ДД
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииЗатратНаВыпуск КАК Приходы
            ПО Приходы.Период < &НачалоПериода
            И Приходы.Регистратор = ДД.ДокументВыпуска
            И Приходы.Регистратор = Приходы.ДокументВыпуска
ТИИ не помогает.
Что делать?

(0) "который заполняет все место для tempdb" - сколько в гигабайтах?

(1) 70

(1) я видел темдб около 100 гигов...
(0)сколько памяти на сервере и сколько доступно скулшю? запрос из сабжа не должен приводить к росту темпдб, он должен жрать память...

(2) Прилично. А размер базы? Статистика SQL обновляется? Регистр ПартииЗатратНаВыпуск.Остатки не распух чересчур?

(3) Запрос запускаем в консоли запросов и в режиме реалтайм мониторим размер tempdb. Свободное место начинает уменьшаться на на 2-3 Мб в секунду.

(3) всего 184, сейчас SQL ограничен 60Гб т.к. база tempDB лежит в оперативке, до появления первой проблемы SQL был не ограничен в памяти

Ограничивать скуль, чтоб темпдб положить в оперативку - спорное решение. Ускорение конечно дает.

(6) Купите SSD хотя бы под tempdb

Разбейте эту херь на 2 запроса во временные таблицы и соеденяйте уже 3 запросом.

Уверены, что итоги по регистру рассчитаны и период расчета адекватный?
Проверьте актуальность статистик в БД.
Нет ли случайно в регистре записей с неадекватными периодами типа 1919 года или 2119 года? (возникают в результате случайной ошибки пользователя при вводе даты документа).
Не переделывали ли в последнее время этот регистр в части измерения ДокументВыпуска? Может меняли его тип?
Попробуйте (9) - какой будет результат.
Ну и план запроса посмотрите.

(0)
вытряхни и посмотри самую старую дату в
РегистрНакопления.ПартииЗатратНаВыпуск КАК Приходы
            ПО Приходы.Период < &НачалоПериода
            И Приходы.Регистратор = ДД.ДокументВыпуска
            И Приходы.Регистратор = Приходы.ДокументВыпуска
видимо там какой-то ахтунг.

(4) Размер базы 65 Гб. Статистики обновляются. В регистре всего записей 19 млн, остатков 75 тысяч.

(9) 19 млн записей во временную таблицу?

(13) первую точно во временную

(10) регистр - типовой, ничего не меняли,
итоги пересчитаны - ТИИ выполнялось,
неадекватных дат нет,

(13) Всяко меньше 70гб будет.

(15) ты всю историю излагай:
- где вызывается запрос
- как раньше работало
- что менялось


+ 70 Гб на темпы это ни о чем

(17)
- в расчете себестоимости в процедуре закрытия месяца;
- работало до марта 2019 года при помесячном закрытии без проблем - за размером темпа никто не следил;
- конфа практически типовая, структура регистров (тем более накоплений) не менялась, доработки косметические на основе расширений и доп.реквизитов

+ (17) когда стали закрывать март 2019 темп вырос до 163 Гб и сожрал все место

(18) точность расчета смени в РСВ

tempdb в оперативке - глупое решение

партионный учет 2.1 до сих пор юзается?

(21) первый tempdb в оперативке - штатное решение, если второй на ssd

(22) Да. Это дело бухгалтеров.