Закрытие месяца в УПП при использовании РАУЗа #559124

Конфигурация 8.2.13.205 УПП 1.2.39.1. Конфигурация работает через 64х битный сервер приложений 1С. Сервер базы данных: Microsoft SQL Server Enterprise Edition (64-bit) 9.00.1399.06 В Конфигурации УПП включен режим расширенной аналитики учета затрат. Ведетсе бухгалтерский и налоговый учет, управленческий учет приравнен к бухгатерскому. При проведении документа "РасчетСебестоимостиВыпуска", время расчета, в зависимости от закрываемового периода, изменяется от 3-4х часов до 24х и более, при этом (во время расчета) размер log файлов tempdb и базы данных превышает 220 Гигабайт! Вопрос: Почему происходят такие прыжки по времени и почему требуется так много дискового пространства.

"... но продолжали жрать кактус" :)

24-х при рауз это жестоко. а сколько у вас видов ГП+ПФ, переделов?

2 вида готовой продукции, 4 передела.

Используются серии, документооборот очень большой, отчетов производства за смену в месяц 2 и более тысяч.

Настройки расчета себестоимости такие: граница СЛУ - 10, кол-во итераций - 999, отклонение решений -7.

ох фак...

Блин, у меня итерационная самописка расчета себестоимости при таком же документообороте считала более 1700 видов готовой продукции с 2-10 переделами около двух часов... Мне было стыдно за столь долгое время расчета, раз в три месяца пытались хоть на секунды отрефакторить код, а оно вон как оказывается...

локально в файловом варианте попробуй расчитать

+ о результатах тут отпишись

В файловом варианте закрытие умирает навсегда ждал 3 суток и прервал.

Количество записей первичных документов в регистре учет затрат около 140 тысяч в месяц, в результате проведения расчета себестоимости выпуска (4-15 часов) добавляется порядка 2,3- 2,7 миллиона записей в рег. учет затрат, при использовании временных таблиц необходимо до 300 Гб свободного места на диске.

А можно вопрос - чего выпускаето то? Кому РАУЗ (УПП) не рекомендовать, если спросят?

Текстильная промышленность. Производство ткани. Покусочное производство.

как можно 300 гигов запустить в файле?? о_о

Принято. Т.е. вам еще повезло - покусочное - это я так понял - дискретное.

что мешает?

+ 50гиг - базу лично разорачивал в файловый

Я не могу понять одного, как так получается, я закрывал апрель за 3,5 часа, потом обнаружили несколько ошибок. подправили, начали перезакрывать, закрыл за 15 часов. В модуле удалось выяснить, что 90% времени тратит на Волновой алгоритм, но если раньше он проходил за 3 часа, то теперь за 14. Может быть он какие то копейки пытается закрыть и не может или я не знаю уже что.

Копейки раскидывает. По параметрам точности и количества итераций явно перебор, верните дефолтные настройки. Итоги рассчитаны? Проведение вне транзакции пробовали?

Итоги рассчитаны по конец января, кстати вариант. Что такое проведение вне транзакции?

мешает ограничение на размер таблицы есличо..

Неважно что такое "вне транзакции". Итоги рассчитайте. Быстро, Решительно!

>>>Что такое проведение вне транзакции? Пункт меню, открывающегося в форме документа по кнопке "Действия" Попробуй обязательно! У меня на одной базе время уменьшилось в 10 раз.

Не важно. Волновой алгоритм распределения ошибок округления выполняет в цикле запросы к остаткам регистра затрат. При нерассчитанных итогах получается как раз картина как у ТС. Отсюда мораль - за базой надо следить. Внезапно, да?

"Отсюда мораль - за базой надо следить." ПисАть надо нормально.

таки я знаю, что вместо замены масла ты меняешь машину когда движок клинит. Мог бы и не напоминать.

Да вообще ужосс... Я уже писал про такое, см. мои последние темы.... Так писать платформу нельзя...

а кто спорит то? И кто сказал что обязательно в такой базе присутствует таблица с превышением критического размера для файлового варианта?

Там код офигенно не оптимальный, занимался этим вопросом, в результате оптимизации удалось ускорить выполнение некоторых запросов в 30 и более раз!! До оптимизации расчет себестоимости выполнялся более 10 часов - прерывали, т.к. tempDB распухал до неимоверных размеров, после оптимизации 30 минут.