Люди добрые, здравствуйте.
Работаем c R3, с WHS. Работаем давно, практически с момента выхода этой функциональности.
Помогите разобраться с проблемкой. Для начала, если в общем, проблема в том, что периодически (несколько раз в день) стандартный запрос к InventSum в связке с InventDim начинает выполняться долго, точнее, ОЧЕНЬ ДОЛГО, со всеми вытекающими.
InventSum - 3,5 млн записей, InventDim - 35 млн.
Говоря про стандартный запрос я имею ввиду метод findSumQty на таблице InventSum.
X++:
select
#inventSumQtyFields
from inventSum
where inventSum.ItemId == _itemId
&& inventSum.ClosedQty == NoYes::No
#inventDimExistsJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);
//#InventDimJoin(inventSum.InventDimId,inventDim,_InventDimCriteria,_InventDimParm);
В стандарте InventDim джойнится к InventSum через exists join. На начальном этапе запуска exists join поменяли на join tableId (вместо макроса #inventDimExistsJoin использовали #InventDimJoin).
И вроде все было хорошо, пока в какой-то момент времени запрос периодически не начал тормозить (не всегда, но бывало). В целях эксперимента вернули стандартный exists join и оно полетело. Довольные своей сообразительностью, оставили стандартный вариант.
Никогда такого не было и вот опять. Начал тормозить уже exists join. Менять обратно на join пока не стали - наблюдаем дальше.
Лечим сбросом кэша - dbcc freeproccache, да, плохо, знаем, но пока других вариантов не придумали.
Вот сам запрос из SQL MS и план запроса, меня настораживает в нем KeyLookup. Запрос взял из SQL MS в тот момент когда было все плохо, таких запросов в статусе SUSPENDED там было бесчисленное множество.
Код:
SELECT SUM(T1.POSTEDQTY),
SUM(T1.DEDUCTED),
SUM(T1.RECEIVED),
SUM(T1.RESERVPHYSICAL),
SUM(T1.RESERVORDERED),
SUM(T1.REGISTERED),
SUM(T1.PICKED),
SUM(T1.ONORDER),
SUM(T1.ORDERED),
SUM(T1.ARRIVED),
SUM(T1.QUOTATIONRECEIPT),
SUM(T1.QUOTATIONISSUE),
SUM(T1.AVAILPHYSICAL),
SUM(T1.AVAILORDERED),
SUM(T1.PHYSICALINVENT) FROM INVENTSUM
T1 WHERE (((T1.PARTITION=@P1) AND (T1.DATAAREAID=N'lm'))
AND ((T1.ITEMID=@P2)
AND (T1.CLOSEDQTY=@P3)))
AND EXISTS (SELECT 'x' FROM INVENTDIM T2
WHERE (((T2.PARTITION=@P4) AND (T2.DATAAREAID=N'lm'))
AND ((((((((((((((((T2.INVENTDIMID=T1.INVENTDIMID) AND 1=@P5) AND 1=@P6) AND 1=@P7) AND 1=@P8)
AND (T2.INVENTSITEID=@P9))
AND (T2.INVENTLOCATIONID=@P10))
AND (T2.WMSLOCATIONID=@P11))
AND (T2.LICENSEPLATEID=@P12))
AND (T2.INVENTSTATUSID=@P13))
AND (T2.INVENTGTDID_RU=@P14))
AND (T2.INVENTOWNERID_RU=@P15))
AND (T2.INVENTCULTIVARID=@P16))
AND (T2.INVENTMARKETINGID=@P17))
AND (T2.INVENTCOUNTRYID=@P18))
AND (T2.INVENTTRACKID=@P19))))
Не пойму откуда это взялось
Код:
AND 1=@P5) AND 1=@P6) AND 1=@P7) AND 1=@P8)
На таблице InventDim с другого проекта перекочевали индексы, которые у нас не используются, сами индексы кастомизированы, вот 2, которые из плана запроса
В общем конкретного вопроса нет. Расскажите кто как решал такие проблемы. Тапками сразу не бросайте, топики на эту тему на форуме я почитал. Рекомендации разные - использовать join вместо exists join, индексы напильником подпилить.
План обслуживания индексов у нас настроен, выполняется каждую ночь. Периодические операции по очистке неиспользуемых аналитик + очистка записей InventSum+WHSInventReserve выполняются.