Aplication стандартный. 500 строк в заказе.
Проблема разбивается на:
1. Нажимаем на кнопку Обработка в заказе. Ждем.....
2. Когда идет непосредственно сама обработка накладной. Тоже долго долго ждем.
Предварительно сделал чистку, а после описанных изменения обновление статистики
http://axapta.mazzy.ru/lib/dbgrowthsolution/
Да... Сам диагноз похож на описанный здесь
http://forum.mazzy.ru/index.php?showtopic=1790
Попытки поиска и решения:
По первой проблеме
Мониторинг показал тормоза вот здесь
Class SalesTableType\checkSalesQty
Код:
...
while select salesLine
index hint SalesStatusIdx
where salesLine.salesId == salesTable.salesId
&& (salesLine.salesStatus != SalesStatus::Invoiced && salesLine.salesStatus != SalesStatus::Canceled)
|| (salesLine.SalesDeliverNow < 0)
...Без оптимизации запрос выполнялся больше 2 минут. смотрел у же в профайлере Query Analyzer.
Создал кластерный индекс по (SalesID, RecID), добавил в SalesStatusIdx поле SalesDeliverNow . в коде убрал хинт. в профайлере Query Analyzer получилось около 400 милисекунд. в аксапте менюшка открывается с задержкой 2 - 4 секунды.
Можно ли еще что нибудь сделать? Если да, то что? Вообще к чему стремится надо?
По второй проблеме
Мониторинг показал, что по таким таблицам
SalesParmLine, CustInoviceTrans, TaxTrans, LedgerBalancesDimTrans не оптимально выборка проходит. По той же схеме провел оптимизацию.
В профайлере кода получил картинку (прилагается).
Там динамически запрос создается. Вроде по SalesParmtable, SalesParmLine.
особо не разбирался, но может кто подскажет, что можно сделать..?
еще тормоза наблюдаютя в Tax\adjustAmount....
В итоге обработка 500 строк получилась около 5 минут. это нормально?
Еще вопрос: Почему у многих таблиц нет Primary key и кластерных индексов в стандартном функционале?