Тормозит операция комплектации и не только

[Alks]

Похоже разобрались в чём дело...

В нашей системе по ряду причин было создано некоторое кол-во "виртуальных" паллет на каждой из которых в сумме находилось более 100 разных видов ном-р (строк в InventSum/проводках и т.п.). Так вот, жутко тормозила операция резервирования именно по тем позициям, которые учавствовали в таких паллетах. По наитию мы сделали кучу переносов, которые разбили такие паллеты на большое число паллет с меньшим кол-вом на каждой и теперь операция резервирования 500 строк занимает порядка 2-х минут, в то время как раньше 50 строк могли резервироваться полчаса.

При этом нами были выполнены все предложенные тут рекомендации - вплоть до полной трассировки SQL-запросов во время операции комплектации. Был получен, например, следующий результат: для одной отдельно взятой строчки отгрузки при резервировании выполнялось 400 запросов. У подавляющего числа этих запросов время выполнения составляло 2 мс. Примерно У трети - 3 мс. И примерно у 20 запросов время было больше 3 мс, но не превышало 20 мс! Полный анализ всех видов из этих запросов показал что у всех у большей части их оптимальный план выполнения (да и куда уж меньше 2-3 мс то можно выполнятся то??), а кол-во не совсем оптимальных запросов не влияет существенно на время выполнения общей процедуры. Другими словами оптимизировать было просто нечего - запросы выполнялись быстро, тормоза возникали из за дикого их количества... Тем более, что "проблемные" номенклатуры могли иметь число запросов еще больше чем 400 и гораздо, а некоторые вообще приводили к deadlock-ам резервирующего процесса с... самим собой! (про это я писал на axforum)

Т.о. сейчас у меня сложилось впечатление, что тормоза возникли в результате того, что алгоритм стандартного резервирования выполняет число запросов, пропорциональное "загруженности" паллеты на которой находится товар. В условиях когда паллеты очень загружены разными видами товара это вызывает жуткие тормоза.

Может есть какие нибудь мысли и/или комментарии по этому поводу?

P.S.

Кстати, один fullscan, который возник по нашей вине я всё таки нашел. Неаккуратно в прайс-лист внедрили два поля, но это в другом месте сказывалось.