Производительность запроса в отчете

[SHiSHok]

Ax3.0sp2 на MSSQL2kSP3:
Есть отчет (по custInvoiceJour + custInvoiceTrans, но это не имеет особого значения). Наворотов нет, то есть квери и отчет подготавливаются базовыми классами, фетчится и выводится.
В запросе отчета, присоединяются еще 2 таблицы и строится отчет за ПЕРИОД по СКЛАДУ1, по которому идет основная отгрузка (+ еще некоторые параметры). Время отрытия курсора несколько секунд, далее построение отчета.
Если в этом же запросе меняется только СКЛАД на редко используемый (например БРАК - записей по этому складу за заданный период нет). запрос на выборку отрабатывает 2 с лишним минуты!!! (индекс по датам есть)
Собственно вопрос почему и что делать???

Мониторил средствами аксапты и профайлером. План исполнения хороший (индексы по всем связкам). В QA запрос отрабатывает пару сек. с любым складом. Профайлер действительно подтвержает что запрос из Axapta исполнялся порядка 150 сек. Eдинственное отличие в том что Axapta использует cursor functionality of ADO, OLE DB, ODBC; а QA Батчем напрямую. И еще: количество чтений (Number of page reads issued by the RPC) при исполнении запроса Axapta порядка 1,500,000 и этот же запрос QA порядка 200,000. Не пойму в чем причина такой разницы???

[Yprit]

А в QA Вы добавляли option (fast xxx)? Там порядок объединения меняется, скорее всего.

[SHiSHok]

Цитата:

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

А в QA Вы добавляли option (fast xxx)? Там порядок объединения меняется, скорее всего.

да. Сначала анализировал запрос выдаваемый монитором запросов Axapta, потом для верности из профайлера взял - идентичны. FirstFast пробовал - результат тотже.

[KiselevSA]

А статистику на SQL сервере пробовали принудительно обновить?

[SHiSHok]

Цитата:

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

А статистику на SQL сервере пробовали принудительно обновить?

угу, with fullscan по CustInvoiceJour (собственно по ней стоит критерий по ДАТАм, есть индекс по датам и нет проводок за задаваемый период)

[KiselevSA]

Цитата:

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

угу, with fullscan по CustInvoiceJour (собственно по ней стоит критерий по ДАТАм, есть индекс по датам и нет проводок за задаваемый период)

Я говорил о процедуре sp_updatestats, которая пересобирает статистику по всем таблицам. Обновление статистики только по одной из таблиц в соединении может не дать результата: связка Axapta + SQL может не изменить план запроса. Дополнительно надо глянуть на состояние отметок "Literals in ..." в настройках сервера AOS.

[SHiSHok]

Цитата:

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

Я говорил о процедуре sp_updatestats, которая пересобирает статистику по всем таблицам. Обновление статистики только по одной из таблиц в соединении может не дать результата: связка Axapta + SQL может не изменить план запроса. Дополнительно надо глянуть на состояние отметок "Literals in ..." в настройках сервера AOS.

Сейчас обновлю статистику по связаным таблицам, у АОС стоит указание literals для отчетов. План должен быть корректным на момент запуска.

[KiselevSA]

Небольшой совет: попробуйте добавить в CustInvoiceTrans индекс для ускорения, содержащий ItemId, SalesId и InventDimId. Во многих случаях такое сочетание дает прирост в скорости в десятки раз.

[SHiSHok]

Цитата:

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

Небольшой совет: попробуйте добавить в CustInvoiceTrans индекс для ускорения, содержащий ItemId, SalesId и InventDimId. Во многих случаях такое сочетание дает прирост в скорости в десятки раз.

К моему удивлению полное обновление статистики по CustInvoiceTrans дало результат!!!! Вышеописанный запрос из Аксапты понимает что нет записей за 1-2 сек, то есть время сравнимое с QA (план в QA не изменился, изменилось распределение стоимости; отрабатывет в QA столькоже). Очень хотелось бы понять почему исполнение из Аксапты имеет такую зависимость . Ведь в запросе ведущая таблица Jour, а транс уже присоединенная (далее InventDim к Trans линкуется). Т.е. с литералами и свежей статистикой по Jour оптимизатор может быстро принять решение что с указанными параметрами нечего выбирать (критерий время). может кто просветит?

А на счет добавления индекса вопрос в использовании данной комбинации при обращениях к таблице.Недавний анализ активности IndexTuningWizard-ом не предложил добавок к существующим индексам.

PS: автообновление статистики всех таблиц стоит еженедельно with resample , но видимо этого недостаточно.

[KiselevSA]

Ну не знаю, как на счет ITW, но оптимальным вариантом поиска отсутствующих индексов является мониторинг длительных запросов с выводом в log. Установить у пользователей порог, например, в 3000 мс. А потом анализировать саму логику запроса и то место, откуда он пришел. В больших выборках помогает принудительное управление способом выборки (см. http://axapta.mazzy.ru/lib/literals_vs_placeholders/)

[SHiSHok]

Цитата:

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

Ну не знаю, как на счет ITW, но оптимальным вариантом поиска отсутствующих индексов является мониторинг длительных запросов с выводом в log. Установить у пользователей порог, например, в 3000 мс. А потом анализировать саму логику запроса и то место, откуда он пришел. В больших выборках помогает принудительное управление способом выборки (см. http://axapta.mazzy.ru/lib/literals_vs_placeholders/)

Мониторинг у меня включен на "ключевых" пользователях. Это можно сказать главный способ оптимизации. ITW я попутно использую для анализа. По крайней мере можно выделить стержневые таблицы и индексы для которых стоит делать дефрагментацию и обновление статистики чаще чем у остальных.

Eще одна ситуация с которой я не разобрался - это почему иногда "слетает" статистика на таблицах. как результат вопли пользователей про "тормоза". решение - обновление статистики по таблицам в запросе (в основном это форма быстрого ввода заявки с основными справочниками: InventTable, InventDim, InventTableModule, InventBatch)

PS: Вадиму за его труды отдельное спасибо.

[KiselevSA]

Земечено "слетание" статистики при удалении данных в таблице. Похоже, что распределение данных в статистике при удалении строк из таблицы становится совсем неверным. Именно поэтому в стандартные процедуры обслуживания SQL включаю пересбор статистики по всем таблицам ночью. На всех перечисленных Вами таблицах нам пришлось добавлять свои индексы SpeedUpIdx

[SHiSHok]

Но вот в том то и делао что в форме быстрого ввода используются почти одни справочные таблицы, которые только плавно растут. Индексы у нас фактически на всех используемых таблицах добавлены/модифицированы для эффективной работы поставленного функционала.

[Shur]

Цитата:

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

Но вот в том то и делао что в форме быстрого ввода используются почти одни справочные таблицы, которые только плавно растут. Индексы у нас фактически на всех используемых таблицах добавлены/модифицированы для эффективной работы поставленного функционала.

Почти - это с остатками в разрезе складских аналитик небось ?

[SHiSHok]

Цитата:

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

Почти - это с остатками в разрезе складских аналитик небось ?

угу, InventSum просто растет; Dim, Serial, Batch как справочники тоже тупо растут, так что менее всего ожидать "слета" статистики у них приходилось.