Ax 2012 R3 CU12 and SQL 2016

[Polgid]

У одного из клиентов похожая ситуация. Большой InventDim - около 4 млн записей, который из-за новых LicensePlate каждый день растет где-то на 30000 записей.

Из-за этого несколько запросов, где был join с InventDim (с InventSum, InventTrans и даже с InventSumDelta и InventSumDeltaDim) выполнялись очень медленно, в случае если SQL почему то выбирал план выполнения
c Nested Loops и InventDim на верхнем уровне или с Merge join. Причем это не из-за неоднородных данных, пробовали добавлять forceliterals, SQL все равно выбирает не оптимальный план.

SQL2016 и AX2012R3 CU13, так что если установите SQL2016 сильно лучше с планами запросов не будет.

Пока что проблему решили добавлением в этих запросах forceNestedLoop forceSelectOrder и перемещением InventDim в самый низ запроса (в случае если он был не последний).
Во всех этих запросах есть фильтр по определенному ItemId или ttsId, так что верхний уровень запроса отрабатывает быстро.

Интерестно что будет через 2-3 года, когда InventDim будет 20-30 млн записей (go live у клиента был меньше года назад).
Проблему в том, что даже если LicensePlate полностью отгружен и получен и InventSum по нему Closed и удален (стандарной процедурой очистки),
ссылки на LicensePlate остаются в InventTrans и стандартная процедура по очистке InventDim не удаляет строки с этим LicensePlate.

Как вариант думаю написать периодическую операцию, которая будет идти по InventTrans и заменять InventDimId c "закрытым" LicensePlate, на такой же но с пустым LicensePlate.
В функциональном плане, вроде как, смыла хранить ссылки на такие "закрытые" LicensePlate нет. Таким образом, операция по очистке InventDim будет держать его размер в разумных пределах.

[Vadik]

Цитата:

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

Интерестно что будет через 2-3 года, когда InventDim будет 20-30 млн записей (go live у клиента был меньше года назад)

Постепенно придет понимание (и у Вас, и у оптимизатора) того, что в WHS со временем размер InventSum стабилизируется а InvendDim будет за счет партий и LP расти постоянно, и это реальность в которой надо жить, а не бороться с ней (все стандартные для WHS процедуры очистки разумеется используем). У нас в данный момент в InventDim 17M записей, и растет довольно быстро за счет новых компаний

Кластерный индекс по InventDimId и скан по нему конечно зело привлекателен для оптимизатора. Будут пограничные моменты "вчера работало сегодня перестало" когда оптимизатор путается, но со временем статистика выравнивается в пользу того что InventDim все же слишком большой для скана и InventSum отфильтровать по ItemId дешевле . После их прохождения с доработкой напильником можно сказать, что прозводительность стабилизируется. В качестве эксперимента - попробуйте DimIdIdx сделать некластерным - InventDim будет гораздо реже выбираться для ранних стадиях обработки

Есть достаточно много мест в WHS где идет обращение к "финансово открытому" складу (InventSum.Closed) а по-хорошему должно было бы к "незакрытому физически" (InventSum.ClosedQty) - там правили код и дополнительно индексировали (ClosedQty+InventDimId+PhysycalInvent) . Помогало

Цитата:

Хочу установить SQL 2016. Но многие отговаривают, говорят что будет еще хуже

"Хуже" не будет. Просто "летать" _все_ после апгрейда не будет, и обязательно вылезет пара мест где будет хуже, чем до него (по закону Мерфи, или даже в местах вообще не связанных с апгрейдом, просто по времени два события наложатся). Из-за особенностей человеческой психики, большинство улучшений остаются незамеченными или про них очень быстро забывают, а негативные моменты запоминаются надолго. Но это моменты из плоскости управления ожиданиями, не технические

Проблема немного шире и не должна сводиться к версии СУБД (хоть я и за то чтобы работать на актуальной). Новый оптимизатор в чем-то умнее старого, но "продавать" как универсальное решение проблем с производительностью его нельзя. Есть узкие места в приложении вроде того же "финансового закрытия", могут быть дурацкие настройки самого WHS (консультанты например регулярно какой-то трэш устраивают в location directives) - со всем этим приходится разбираться по месту