Тормоза на ровном месте при инициализации формы резервирования

[fed]

Если используются placeholders (то есть вопросики, а не конкретные значения), статистика по большей части просто не используется. Например - если у тебя в запросе стоит значение statusReceipt==3, система может посмотреть в статистике гистограмму распределения значений и оценить что по этому условию отбирается всего 1-2% таблицы inventTrans. А вот если в запросе стоит statusReceipt==?, то система смотрит что всего поле statusReceipt может принимать 7 возможных значений, соответственно - по этому условию будет отобрана 1/7 от выборки.

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

[Wamr]

Цитата:

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

Если используются placeholders (то есть вопросики, а не конкретные значения), статистика по большей части просто не используется

Не согласен с данным утверждением. При первом вызове такого запроса статистика используется и строится корректный план исполнения, а вот при повторном использовании план сохраняется, что и может приводить к подобным эффектам.
Например, сначала вы искали проводки по партии (использовался индекс по партиям), а потом стали искать по ГТД (и опять используется индекс по партиям).

Цитата:

прежде чем чего-либо делать дальше, рекомендую в этом запросе тупо подставить forceLiterals и посмотреть чего будет

а с этим согласен

[Alexius]

1. Попробуйте убрать из запроса в Аксапте forceNestedLoop
2. Проанализируйте в Managment Studio план выполнения этого запроса в "быстром"/"медленном" варианте и если они различаются, то пропишите в запрос хинт с индексом из "быстрого" плана.
3. В качестве "лома" можно попробовать покрывающий индекс на InventTrans:
- ItemId
- StatusIssue
- StatusReceipt
- ConfigId
- InventDim
- Qty
- CostAmountPosted
- CostAmountAdjustment
Можно дополнить имеющийся индекс, главное использовать такую последовательность полей.

PS. Начинать лучше всего, на мой взгляд, с анализа планов выполнения запроса.
PS2. А так ли нужна вам себестоимость в форме резервирования, может выкинуть ее?

[Logger]

Цитата:

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

3. В качестве "лома" можно попробовать покрывающий индекс на InventTrans:
- ItemId
- StatusIssue
- StatusReceipt
- ConfigId
- InventDim
- Qty
- CostAmountPosted
- CostAmountAdjustment
Можно дополнить имеющийся индекс, главное использовать такую последовательность полей.

Как бы нам этим ломом не убить другие запросы. Индекс уж очень тяжелый получается

[Alexius]

Цитата:

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

Как бы нам этим ломом не убить другие запросы. Индекс уж очень тяжелый получается

С запросами вставки/обновления/удаления в Аксапте ничего страшного не произойдет, а для запросов на чтение индекс действительно добавит остроты в "драке" за оперативную память

[Logger]

Цитата:

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

С запросами вставки/обновления/удаления в Аксапте ничего страшного не произойдет,

А как же перестройка ключа индекса при обновлениях ? Дополнительные затраты ресурсов сервера на это дело?

Особенно вот эти поля настораживают.
- Qty
- CostAmountPosted
- CostAmountAdjustment

[Alexius]

Цитата:

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

А как же перестройка ключа индекса при обновлениях ? Дополнительные затраты ресурсов сервера на это дело?

Операции вставки/обновления/удаления производятся для одной записи и накладные расходы в них по перестройке ключей индексов незначительны.

Цитата:

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

Особенно вот эти поля настораживают.
- Qty
- CostAmountPosted
- CostAmountAdjustment

А без них не получить покрывающего индекса В идеале нужно их воткнуть в INCLUDE-поля индекса, но Аксапта это делать не умеет

[fed]

Цитата:

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

Не согласен с данным утверждением. При первом вызове такого запроса статистика используется и строится корректный план исполнения, а вот при повторном использовании план сохраняется, что и может приводить к подобным эффектам.
Например, сначала вы искали проводки по партии (использовался индекс по партиям), а потом стали искать по ГТД (и опять используется индекс по партиям).

а с этим согласен

Угу. Это вроде бы как раз в MS SQL 2005 появилось. План строится при первой подстановке значений в параметры, а не при компиляции исходного запроса. И обычно вот такое вот поведение из серии "обычно нормально работает но иногда ни с того ни с сего тормозит" и объясняется тем, что при первом исполнении были какие-то сильно нетипичные значения параметров подставлены. Просто я обычно при рассказе о пользе forceLiterals про это ленюсь рассказывать Вообще - когда такие вопросы задают, почти всегда в ветке появляется масса доброхотов с советами построить какие-нить магические индексы, подставить хинт, постучать по дереву, покропить сервер куриной кровью и тп А про то что SQL Server не такой уж тупой сам по себе и кривой план на простых запросах строит не от дурости, а по каким-то внешним причинам никто не задумывается...

[Saber]

Спасибо всем.
Действительно, пока попробую повторно внимательно проанализировать планы запросов при нормальной работе и с "тормозами".