AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.11.2006, 15:15   #1  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Cool Производительность запроса в отчете
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. Не пойму в чем причина такой разницы???
__________________
--- SHiSHok

Последний раз редактировалось SHiSHok; 07.11.2006 в 16:47.
Старый 07.11.2006, 15:28   #2  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
А в QA Вы добавляли option (fast xxx)? Там порядок объединения меняется, скорее всего.
Старый 07.11.2006, 15:34   #3  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Цитата:
Сообщение от Yprit Посмотреть сообщение
А в QA Вы добавляли option (fast xxx)? Там порядок объединения меняется, скорее всего.
да. Сначала анализировал запрос выдаваемый монитором запросов Axapta, потом для верности из профайлера взял - идентичны. FirstFast пробовал - результат тотже.
__________________
--- SHiSHok
Старый 07.11.2006, 15:39   #4  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
А статистику на SQL сервере пробовали принудительно обновить?
Старый 07.11.2006, 15:43   #5  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
А статистику на SQL сервере пробовали принудительно обновить?
угу, with fullscan по CustInvoiceJour (собственно по ней стоит критерий по ДАТАм, есть индекс по датам и нет проводок за задаваемый период)
__________________
--- SHiSHok
Старый 07.11.2006, 15:51   #6  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Цитата:
Сообщение от SHiSHok Посмотреть сообщение
угу, with fullscan по CustInvoiceJour (собственно по ней стоит критерий по ДАТАм, есть индекс по датам и нет проводок за задаваемый период)
Я говорил о процедуре sp_updatestats, которая пересобирает статистику по всем таблицам. Обновление статистики только по одной из таблиц в соединении может не дать результата: связка Axapta + SQL может не изменить план запроса. Дополнительно надо глянуть на состояние отметок "Literals in ..." в настройках сервера AOS.
Старый 07.11.2006, 16:18   #7  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
Я говорил о процедуре sp_updatestats, которая пересобирает статистику по всем таблицам. Обновление статистики только по одной из таблиц в соединении может не дать результата: связка Axapta + SQL может не изменить план запроса. Дополнительно надо глянуть на состояние отметок "Literals in ..." в настройках сервера AOS.
Сейчас обновлю статистику по связаным таблицам, у АОС стоит указание literals для отчетов. План должен быть корректным на момент запуска.
__________________
--- SHiSHok
Старый 07.11.2006, 16:43   #8  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Небольшой совет: попробуйте добавить в CustInvoiceTrans индекс для ускорения, содержащий ItemId, SalesId и InventDimId. Во многих случаях такое сочетание дает прирост в скорости в десятки раз.
Старый 07.11.2006, 17:05   #9  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Thumbs up проблема разрешилась
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
Небольшой совет: попробуйте добавить в CustInvoiceTrans индекс для ускорения, содержащий ItemId, SalesId и InventDimId. Во многих случаях такое сочетание дает прирост в скорости в десятки раз.
К моему удивлению полное обновление статистики по CustInvoiceTrans дало результат!!!! Вышеописанный запрос из Аксапты понимает что нет записей за 1-2 сек, то есть время сравнимое с QA (план в QA не изменился, изменилось распределение стоимости; отрабатывет в QA столькоже). Очень хотелось бы понять почему исполнение из Аксапты имеет такую зависимость . Ведь в запросе ведущая таблица Jour, а транс уже присоединенная (далее InventDim к Trans линкуется). Т.е. с литералами и свежей статистикой по Jour оптимизатор может быстро принять решение что с указанными параметрами нечего выбирать (критерий время). может кто просветит?

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

PS: автообновление статистики всех таблиц стоит еженедельно with resample , но видимо этого недостаточно.
__________________
--- SHiSHok
Старый 07.11.2006, 17:21   #10  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Ну не знаю, как на счет ITW, но оптимальным вариантом поиска отсутствующих индексов является мониторинг длительных запросов с выводом в log. Установить у пользователей порог, например, в 3000 мс. А потом анализировать саму логику запроса и то место, откуда он пришел. В больших выборках помогает принудительное управление способом выборки (см. http://axapta.mazzy.ru/lib/literals_vs_placeholders/)
За это сообщение автора поблагодарили: kashperuk (3).
Старый 07.11.2006, 17:36   #11  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
Ну не знаю, как на счет ITW, но оптимальным вариантом поиска отсутствующих индексов является мониторинг длительных запросов с выводом в log. Установить у пользователей порог, например, в 3000 мс. А потом анализировать саму логику запроса и то место, откуда он пришел. В больших выборках помогает принудительное управление способом выборки (см. http://axapta.mazzy.ru/lib/literals_vs_placeholders/)
Мониторинг у меня включен на "ключевых" пользователях. Это можно сказать главный способ оптимизации. ITW я попутно использую для анализа. По крайней мере можно выделить стержневые таблицы и индексы для которых стоит делать дефрагментацию и обновление статистики чаще чем у остальных.

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

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

Последний раз редактировалось SHiSHok; 07.11.2006 в 17:37. Причина: добавка
За это сообщение автора поблагодарили: kashperuk (3).
Старый 07.11.2006, 17:55   #12  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Земечено "слетание" статистики при удалении данных в таблице. Похоже, что распределение данных в статистике при удалении строк из таблицы становится совсем неверным. Именно поэтому в стандартные процедуры обслуживания SQL включаю пересбор статистики по всем таблицам ночью. На всех перечисленных Вами таблицах нам пришлось добавлять свои индексы SpeedUpIdx
Старый 07.11.2006, 18:19   #13  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Но вот в том то и делао что в форме быстрого ввода используются почти одни справочные таблицы, которые только плавно растут. Индексы у нас фактически на всех используемых таблицах добавлены/модифицированы для эффективной работы поставленного функционала.
__________________
--- SHiSHok
Старый 08.11.2006, 17:53   #14  
Shur is offline
Shur
Участник
 
8 / 10 (1) +
Регистрация: 07.03.2003
Адрес: Украина, Донецк
Цитата:
Сообщение от SHiSHok Посмотреть сообщение
Но вот в том то и делао что в форме быстрого ввода используются почти одни справочные таблицы, которые только плавно растут. Индексы у нас фактически на всех используемых таблицах добавлены/модифицированы для эффективной работы поставленного функционала.
Почти - это с остатками в разрезе складских аналитик небось ?
Старый 13.11.2006, 19:04   #15  
SHiSHok is offline
SHiSHok
Участник
Аватар для SHiSHok
Дети Юза
 
219 / 103 (4) +++++
Регистрация: 28.07.2005
Адрес: Донецк
Цитата:
Сообщение от Shur Посмотреть сообщение
Почти - это с остатками в разрезе складских аналитик небось ?
угу, InventSum просто растет; Dim, Serial, Batch как справочники тоже тупо растут, так что менее всего ожидать "слета" статистики у них приходилось.
__________________
--- SHiSHok

Последний раз редактировалось SHiSHok; 14.11.2006 в 12:58.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Изменить план выполнения запроса Sequel DAX: Администрирование 2 29.05.2008 15:46
Вопрос по формированию запроса ek_Pendulum DAX: Программирование 3 27.04.2007 17:06
Динамические контролы в отчете основанные на display-методе petr DAX: Программирование 19 18.09.2006 15:29
dialog в отчёте gaenar DAX: Программирование 6 14.04.2005 11:15
Установка Range в отчёте Paul_ST DAX: Программирование 13 06.01.2004 17:33

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 19:23.