Продолжительная работа сводного планирования

[ds1678]

Настораживеат время выполнения прогнозного и сводного плана(( База:

Номенклатура - ок 100 000 строк
Прогноз на 100 изделий, уровень вложенности спецификации от 5 до 10 уровней
Среднее количество строк в спецификации включая подуровни от 50 до 2000
Количество рабочих центров - ок. 300. РЦ укрупненные, представляют собой Цеха\участки с увеличенным процентом мощности.
Маршрут на одну спецификацию в среднем из 20 операций, только первичные
Каждому изделию типа номенклатура определено макс кол-во в произв заказе так, что, как правило, количество изделий в плане бьется на 10-20 партий.
Резервных запасов нет.

Данный план имитирует месячную загрузку предприятия, но в настройках покрытия и развертывания везде стоит 1 год.

Процедура прогнозного плана длится в лучшем случае суток 4, сводного плана - больше недели, если не вылетят раньше с ошибками, ссылающимися на AOSовский протокол...

Может, педальку какую надо подкрутить, чтобы ускорить рассчеты?

[ds1678]

Да, все работает в честной трехзвенке, АОС и SQLServer на разных машинах, обе довольно неплохого уровня (2-хксеоновые брэндовые сервера).

Сводное планирование запускается с ограничением мощности.

Стоит версия 3.0 sp3


ПОДЕЛИТЕСЬ, ПОЖАЛУЙСТА ОПЫТОМ, КАК КТО УСКОРЯЛ ПРОЦЕДУРЫ ПЛАНИРОВАНИЯ?

[Андре]

Цитата:

Номенклатура - ок 100 000 строк
Прогноз на 100 изделий, уровень вложенности спецификации от 5 до 10 уровней
Среднее количество строк в спецификации включая подуровни от 50 до 2000
Количество рабочих центров - ок. 300. РЦ укрупненные, представляют собой Цеха\участки с увеличенным процентом мощности.
Маршрут на одну спецификацию в среднем из 20 операций, только первичные
Каждому изделию типа номенклатура определено макс кол-во в произв заказе так, что, как правило, количество изделий в плане бьется на 10-20 партий.
Резервных запасов нет.

Какое количество потребностей порождается в ходе планирования ?

Цитата:

Может, педальку какую надо подкрутить, чтобы ускорить рассчеты?

Вообще, у меня сложилось впечатление, что у процедуры планирования есть верхний предел в количестве потребностей, дальше которого система масштабируется очень плохо и всевозможные настройки системы и параметры СУБД на этот расчет влияют крайне мало. Ну, скажем так, можно достичь уменьшения времени расчета в 2 раза, но если ситема планирует неделю, то жизнь это сильно не облегчает.

Универсального совета нет, но можно попробовать изменить свой подход к процедуре планирования, ставя своей целью уменьшения количества потребностей. Не буду вдаваться в детали, просто приведу один пример: при планировании отгрузок, нас естественно интересует КОМУ, мы планируем отгрузить данную позицию; в то время как при планировании производства и закупок нам уже , в принципе, не важно под кого мы закупаем компоненты и кому именно мы производим этот товар -> после планирования переносов мы можем сгруппировать все потребности, сознательно теряя информацию которую мы принесли в жертву производительности.
Естественно все вышеописанное подразумевает модификации стандартного функционала.

[ds1678]

Из системного журнала:

Число строк прогноза продаж: 93
Количесвто спланированных производств: 62578
Количество спланированных закупок: 10289

Настройка покрытия по материалам - период 15 и 30 дней (2 группы покрытия)
Настройка покрытия для спецификаций - период 5 дней

[Maxim Gorbunov]

Почитайте вот этот документ: http://technet.navision.com/usered/A...01.00-ENUS.doc (Master Plan Strategies). Возможно, поможет.

[glibs]

На всякий случай сходите на technet'овский форум. По-моему, я там видел подобного рода вопрос, связанный с производительностью. Какой-то мастер советовал в каком-то месте добавить индекс, и, вроде, все начинало довольно быстро шевелиться. Может и вас это на какие-то мысли натолкнет.

[Андре]

Вообще то я спрашивал про число чистых потребностей. Ну да ладно. Вообще, судя по тем данным, что ты привел - работать должно не так долго. В нашем случае замедление начало проявляться при гораздо большем объеме данных.
Кстати, я не понял - вы все настроили, запустили и обнаружили, что медленно планирует на таком объеме данных; или все прекрасно работало, но однажды перестало... ?

p.s. Если чем то могу помочь, может быть имеет смысл перейти на почту или icq, с учетом того, что работаем вместе

[Vadim Korepin]

to ds1678: а базу посмотреть можно? - с реальным примером попроще данную проблему решать.

[ds1678]

To Андре:
Написал письмо

To Vadim Korepin
Это вряд ли... )) Понимаю, что правильнее один раз увидеть, но 1) объем 2) база заказчика - не могу публиковать конкретные данные

To glibs
Спасибо, разработчик уже думает над дополнительным индексированием

To Maxim Gorbunov
Такой есть, даже на родном языке...

Что предпринял:
- Укрупнил рабочие центры
- Укрупнил количественное разбиение для номенклатуры в производственных заказах (Номнклатурные единицы\Количество\Макс кол-во), но не отменил совсем!
- Оставил ограничение по мощности только для критически важных участков (РЦ)
заметен небольшой эффект, но вот вопрос об укрупнении РЦ открыт - непонятно, как влияет на скорость рассчетов количество РЦ

[Vadim Korepin]

Ладно, сейчас сгенерим базу.
А про индексирование правильная идея.

[xan]

Цитата:

Что предпринял:
.....

Может есть смысл отказаться от разбиения на переделы?