Тормозит прогнозное планирование

[Andrew K.]

Цитата:

Сообщение от Perc

--------
Начало транзакции;
Очистить прогнозный план запущеный на расчет;
Рассчитать прогнозный план;
Конец транзакции;
-----------

Уберите "Начало транзакции;" и "Конец транзакции;" это возможно главная причина "косячка". Представьте себе объем лога когда 500 тыс записей удаляются и столько же вставляются..
Эта ф-я (ReqCalc) выполняет расчет для каждой номенкл. отдельно и изолированной транзакции. Не совсем ясно зачем операция "Очистить". Система сама все очистит если запущен полный пересчет. С вашим объемом данных и обычным hardware должно все за ночь пересчитать. Если не устраивает, то ищите способы уменьшения кол-ва данных.

[Perc]

Цитата:

Сообщение от Andrew K.

Уберите "Начало транзакции;" и "Конец транзакции;" это возможно главная причина "косячка". Представьте себе объем лога когда 500 тыс записей удаляются и столько же вставляются..
Эта ф-я (ReqCalc) выполняет расчет для каждой номенкл. отдельно и изолированной транзакции. Не совсем ясно зачем операция "Очистить". Система сама все очистит если запущен полный пересчет. С вашим объемом данных и обычным hardware должно все за ночь пересчитать. Если не устраивает, то ищите способы уменьшения кол-ва данных.

Несомненно объем лога больше, если удалять и вставлять в отной транзакции. Только в этом проблема и сервер не может ее преодолеть? А если его "подкрутить"?
"Начало транзакции;" и "Конец транзакции;" - стандарная реализациия и не хочется лезть в коде копошиться микрософтовском (не такой уж и большой объем, что бы разработчики не могли его допустить).
Ф-я (ReqCalc) действительно выполняет расчет для каждой номенкл. отдельно, но удаление плана идет полностью перед началом расчета, если запущен полный расчет.
Операцию удаления плана как раз и делаю предварительно, так как расчет на практике проходит значительно быстрее если план пуст. Без отчистки на порядок дольше. Ну не СУБД ли это косяк?
Объем данных уменьшить это не реальным мне представляется ))