Сильные тормоза при разноске Заказа на продажу

[ena_ax]

Коллеги,

проблема с обработкой Заказов на продажу. Проявляется разными способами:
1. При нажатии кнопки Запросы/Итоги система зависает. Форма Итоги открывается после очень длительного времени (несколько минут).
2. При обработке документов: Отгрузочная накладная, Накладная - система зависает надолго (дождаться завершения выполнения невозможно).

После переиндексации производительность восстанавливается.

Исходные данные:
Axapta 4.0, SQL 2005.
Каждую ночь на SQL запускается джоб по реиндексации базы.
Раз в неделю делается Shrink.

В чем может быть проблема?
Какими средствами можно найти "слабое место"?

Помню раньше была в аксапте такая проблема - все строки разносятся в одной транзакции и MSSQL после обработки нескольких строк принимал решение "блокировать всю таблицу"
Проблема решалась добавлением одной строчки в коде:

sort by itemId

в методе, который вибирал строки для разноски

[mazzy]

Цитата:

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

Какими средствами можно найти "слабое место"?

Аксаптовскими http://axapta.mazzy.ru/lib/querytuning/
а также новой утилитой TraceParser, которая пришла на смену аксаптовским средствам (ищите на форуме)

[ena_ax]

спасибо.

[Vadik]

Цитата:

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

Раз в неделю делается Shrink

Перестаньте мучать животное
Stop Shrinking Your Database Files. Seriously. Now.

[ena_ax]

Цитата:

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

Аксаптовскими http://axapta.mazzy.ru/lib/querytuning/
а также новой утилитой TraceParser, которая пришла на смену аксаптовским средствам (ищите на форуме)

Следую указаниям включил Трасировку запросов SQL, выставил значение Апертура равное 100, Установил checkbox Таблица (база данных)

За сутки Журнал трасирвоки запросов SQL пустой.
Что-то недонастроил или зпросы все быстро выполняются?

[mazzy]

Цитата:

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

За сутки Журнал трасирвоки запросов SQL пустой.
Что-то недонастроил или зпросы все быстро выполняются?

Во-первых, настраивать апертуру надо у каждого пользователя, которого хочется отслеживать.
Во-вторых, в ax4 и выше в конфигурационной утилите надо включать галочки на закладке Tracing (по крайней мере эти)

Об этом Еременко где-то в своих блогах писал.

[sukhanchik]

Хм... а я пользовался трассировкой и без этих галок. Единственное что требовалось - это в конфигурации аоса поставить галки:, по крайней мере нижнюю.

А дальше - выставляешь апертуру, вывод в инфолог и уже все сразу сыпется

Не, понятно - что без флажка Bind variables к примеру - значения переменных не увидишь, но отловить долгий запрос и понять где он в коде генерируется - вполне можно

[ena_ax]

При помощи Tracer выявил запрос, который долго обрабатывается (время выполнения - 222598). Помогите разобраться в причине столь медленного выполненния. После реиндексации запрос обрабатывается без замедлений.

SELECT SUM(A.POSTEDQTY),SUM(A.POSTEDVALUE),SUM(A.PHYSICALVALUE),SUM(A.DEDUCTED),SUM(A.RECEIVED),SUM(A.RESERVPHYSICAL),SUM(A.RESERVORDERED),SUM(A.REGISTERED),SUM(A.PICKED),SUM(A.ONORDER),SUM(A.ORDERED),SUM(A.ARRIVED),SUM(A.QUOTATIONRECEIPT),SUM(A.QUOTATIONISSUE),SUM(A.AVAILPHYSICAL),SUM(A.AVAILORDERED),SUM(A.POSTEDVALUESECCUR_RU),SUM(A.PHYSICALVALUESECCUR_RU),SUM(A.PHYSICALINVENT) FROM INVENTSUM A WHERE ((A.DATAAREAID=?) AND ((A.ITEMID=?) AND (A.CLOSED=?))) AND EXISTS (SELECT 'x' FROM INVENTDIM B WHERE ((B.DATAAREAID=?) AND ((B.INVENTDIMID=A.INVENTDIMID) AND (B.INVENTLOCATIONID=?))))


Место в коде таблица InventSum\findSum

*********
 
default:
                select #inventSumFields from inventSum
                    where inventSum.ItemId      == _itemId   &&
                          inventSum.Closed      == NoYes::No
                #inventDimExistsJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);

У вас в заказах строк сколько?
есть ли одинаковые номенклатуры?

[sukhanchik]

Есть еще в Tracer такая кнопочка - План исполнения, а затем Рассчитать новый план - там показывается по какому индексу идет выборка.

Для начала попробуйте в индексе \Data Dictionary\Tables\InventSum\Indexes\ClosedItemDimIdx поставить первым полем ItemId, а вторым Closed.

А также скажите - какие индексы у Вас на таблице InventSum (интересует список полей по индексам с учетом положения поля в индексе). Плюс скажите по какому индексу ведется выборка по InventSum.

Общие правила такие:
1. Поля, в которых содержится большее количество разнородной информации должны быть раньше в индексе. Очевидно, что в ItemId содержится больше разнородной информации, чем в Closed
2. Наибольшее количество полей с наибольшим количеством разнородной информации, участвующие в предложениях Where, Join, Group by, Order by запроса должны присутствовать в индексе. При этом БД должна правильно выбрать индекс (не запутаться в многообразии). Неправильно выбранный индекс приведет к более долгому исполнению запроса. Например, наличие енума в индексе на производительность может не повлиять (мало разнородной информации), но может повлиять на выбор индекса.
3. Увеличение количества индексов на таблице увеличивает время на вставку записей.

[ena_ax]

Цитата:

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

У вас в заказах строк сколько?
есть ли одинаковые номенклатуры?

Количество строк в Заказе порядка 10, одинаковых номенклатур нет.

Цитата:

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

Есть еще в Tracer такая кнопочка - План исполнения, а затем Рассчитать новый план - там показывается по какому индексу идет выборка.

Для начала попробуйте в индексе \Data Dictionary\Tables\InventSum\Indexes\ClosedItemDimIdx поставить первым полем ItemId, а вторым Closed.

А также скажите - какие индексы у Вас на таблице InventSum (интересует список полей по индексам с учетом положения поля в индексе). Плюс скажите по какому индексу ведется выборка по InventSum.

Общие правила такие:
1. Поля, в которых содержится большее количество разнородной информации должны быть раньше в индексе. Очевидно, что в ItemId содержится больше разнородной информации, чем в Closed
2. Наибольшее количество полей с наибольшим количеством разнородной информации, участвующие в предложениях Where, Join, Group by, Order by запроса должны присутствовать в индексе. При этом БД должна правильно выбрать индекс (не запутаться в многообразии). Неправильно выбранный индекс приведет к более долгому исполнению запроса. Например, наличие енума в индексе на производительность может не повлиять (мало разнородной информации), но может повлиять на выбор индекса.
3. Увеличение количества индексов на таблице увеличивает время на вставку записей.

Таблица InventSum без модификаций. Привожу индексы:
1. ClosedItemDimIdx - по рекомендации выставил порядок полей ItemId, Closed
2. ItemDimIdx - ItemId, InventDimId
3. DimIdIdx - InventDimId, Closed

План запроса показал использование индексов ItemDimIdx, DimIdIdx.

[sukhanchik]

Помогла моя рекомендация? Если нет - вертайте все взад

Вот индекс DimIdIdx при этой выборке не сдался совершенно. В нем нет ItemId, по которому идет выборка. Индекс ItemDimIdx в общем-то нормальный... Количество записей в InventTable больше количества записей в InventDim ? (иначе в этом индексе можно попробовать переставить поля)

[ena_ax]

Цитата:

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

Помогла моя рекомендация? Если нет - вертайте все взад

Вот индекс DimIdIdx при этой выборке не сдался совершенно. В нем нет ItemId, по которому идет выборка. Индекс ItemDimIdx в общем-то нормальный... Количество записей в InventTable больше количества записей в InventDim ? (иначе в этом индексе можно попробовать переставить поля)

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

[sukhanchik]

Цитата:

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

После перестановки полей в индексе ClosedItemDimIdx лучше не стало. Вернул в исходное состояние.

Не, ну понятно - если выборка идет по одному индексу, то игра с другим индексом погоды не сделает, если только не будет выбран другой индекс.

Игра с производительностью часто происходит на рабочей БД, т.к. не всегда на тестовой все воспроизводится.

Не забывайте, что если Вы хоть как-то тронете индекс ItemDimIdx, по которому у Вас идет выборка - то это будет эквивалентно переиндексации InventSum по данному индексу, т.е. после этого у Вас опять все будет летать.

[sukhanchik]

А можно подетальнее сообщить по плану запроса? Интересуют параметры, нарисованные в зеленых овалах. А в нижней строке - интересует где больше просаживается производительность - на объединении таблиц или на поиске.

[ena_ax]

Цитата:

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

А можно подетальнее сообщить по плану запроса? Интересуют параметры, нарисованные в зеленых овалах. А в нижней строке - интересует где больше просаживается производительность - на объединении таблиц или на поиске.

Странно, по плану небольшие затраты и ожижаемое кол-во строк.

[Волчара]

Цитата:

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

При помощи Tracer выявил запрос, который долго обрабатывается (время выполнения - 222598). Помогите разобраться в причине столь медленного выполненния. После реиндексации запрос обрабатывается без замедлений.

Место в коде таблица InventSum\findSum

default:
                select #inventSumFields from inventSum
                    where inventSum.ItemId      == _itemId   &&
                          inventSum.Closed      == NoYes::No               #inventDimExistsJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);

1. Проблема всегда возникает только в этом запросе?
2. Сколько записей в InventDim сколько записей в InventSum ?
3. Можно попробовать заменить #inventDimExistsJoin на #inventDimInnerJoin
а) кажется такой есть
b) думаю что нарушений алгоритма не будет - но если не уверены - выложите плиз сюда полный текст X++ метода, какая версия системы, какая структура вызова - из какого метода был вызван InventSum\findSum

[sukhanchik]

Цитата:

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

Странно, по плану небольшие затраты и ожижаемое кол-во строк.

А на суммировании? (Stream Aggregate)

Может просто сейчас не тормозит запрос?

Возможны по идее еще варианты - если кто-то другой лочит InventSum - и Вы подвисаете. Например - один (пакетник к примеру) запустил сводное планирование (пересчет склада), остальные наслаждаются скоростью работы.

[ena_ax]

Цитата:

Сообщение от Волчара

1. Проблема всегда возникает только в этом запросе?
2. Сколько записей в InventDim сколько записей в InventSum ?
3. Можно попробовать заменить #inventDimExistsJoin на #inventDimInnerJoin
а) кажется такой есть
b) думаю что нарушений алгоритма не будет - но если не уверены - выложите плиз сюда полный текст X++ метода, какая версия системы, какая структура вызова - из какого метода был вызван InventSum\findSum

1. Я наблюдал проблему только в этом запросе. Проявляется как при разноске Накладной на продажу, так и при формировании запроса Итогов по Заказу на Продажу (Запросы/Итоги)
2. В InventDim - 192685 записей
в InventSum - 174377 записей

3. Версия kernel 4.0.2501.116
Appl - 4.0.2501.347