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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.06.2008, 13:44   #1  
Saber is offline
Saber
Участник
 
10 / 10 (1) +
Регистрация: 07.03.2007
Тормоза на ровном месте при инициализации формы резервирования
Люди добрые! Помогите!!!
Не могу поймать кота за хвост.
Уже продолжительное время не могу вычислить причину "самопроизвольного" увеличения времени исполнения запросов при инициализации или рефреше формы резервирования товара.

Исходные данные такие:
Axapta 2.5 RU SP5
База данных: Microsoft SQL Server 2005
Железо новое и нормальное. Проблем с ним нет.
Переиндексация - раз в неделю.
Сбор статистики - 2 раза в неделю.

Симптомы.
После некоторого промежутка времени с нормальной работой (от нескольких дней до нескольких часов) форма резервирования начинает жутко тормозить. А через время опять все становиться нормально.

Практически постоянно мониторю ситуацию. Наблюдения показывают, что загрузка сервера к развитию событий отношения не имеет.
Во время тормозов через PerfMon вижу резкий скачек IndexSearch. Остальные параметры в норме.
Трассировка запросов средствами Аксапты показывает что наибольшее время исполнения имеют 6 одинаковых запросов:
Цитата:
Расчет времени: 5126 мс на 'EXECUTE+FETCH (execute, first chunk of data)'
SQL запрос: SELECT SUM(A.COSTAMOUNTPOSTED),SUM(A.COSTAMOUNTADJUSTMENT),SUM(A.QTY) FROM INVENTTRANS A,INVENTDIM B WHERE ((A.DATAAREAID=?) AND ((((A.ITEMID=?) AND (A.CONFIGID=?)) AND (A.STATUSISSUE=?)) AND (A.STATUSRECEIPT=?))) AND ((B.DATAAREAID=?) AND ((((B.INVENTDIMID=A.INVENTDIMID) AND (B.INVENTLOCATIONID=?)) AND (B.INVENTBATCHID=?)) AND (B.INVENTGTDID_RU=?))) OPTION(FAST 5,LOOP JOIN) [Идентификатор=9885, Использовано повторно=Да]
Есть смутное подозрение, что данный глюк как-то связан со статистикой, но принудительный сбор статистики во время работы по таблицам INVENTTRANS и INVENTDIM моментального результата не дает.

Может вопрос и глупый, но я уже не знаю на что еще нужно обратить внимание что бы разобраться с проблемой.
Старый 28.06.2008, 15:20   #2  
fed is offline
fed
Moderator
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,176 / 3994 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Если используются placeholders (то есть вопросики, а не конкретные значения), статистика по большей части просто не используется. Например - если у тебя в запросе стоит значение statusReceipt==3, система может посмотреть в статистике гистограмму распределения значений и оценить что по этому условию отбирается всего 1-2% таблицы inventTrans. А вот если в запросе стоит statusReceipt==?, то система смотрит что всего поле statusReceipt может принимать 7 возможных значений, соответственно - по этому условию будет отобрана 1/7 от выборки.

Поэтому прежде чем чего-либо делать дальше, рекомендую в этом запросе тупо подставить forceLiterals и посмотреть чего будет...
Старый 28.06.2008, 21:57   #3  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,726 / 839 (31) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Если используются placeholders (то есть вопросики, а не конкретные значения), статистика по большей части просто не используется
Не согласен с данным утверждением. При первом вызове такого запроса статистика используется и строится корректный план исполнения, а вот при повторном использовании план сохраняется, что и может приводить к подобным эффектам.
Например, сначала вы искали проводки по партии (использовался индекс по партиям), а потом стали искать по ГТД (и опять используется индекс по партиям).
Цитата:
прежде чем чего-либо делать дальше, рекомендую в этом запросе тупо подставить forceLiterals и посмотреть чего будет
а с этим согласен
Старый 29.06.2008, 17:17   #4  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
416 / 196 (7) ++++++
Регистрация: 13.12.2001
1. Попробуйте убрать из запроса в Аксапте forceNestedLoop
2. Проанализируйте в Managment Studio план выполнения этого запроса в "быстром"/"медленном" варианте и если они различаются, то пропишите в запрос хинт с индексом из "быстрого" плана.
3. В качестве "лома" можно попробовать покрывающий индекс на InventTrans:
- ItemId
- StatusIssue
- StatusReceipt
- ConfigId
- InventDim
- Qty
- CostAmountPosted
- CostAmountAdjustment
Можно дополнить имеющийся индекс, главное использовать такую последовательность полей.

PS. Начинать лучше всего, на мой взгляд, с анализа планов выполнения запроса.
PS2. А так ли нужна вам себестоимость в форме резервирования, может выкинуть ее?
Старый 29.06.2008, 21:47   #5  
fed is offline
fed
Moderator
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,176 / 3994 (138) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Wamr Посмотреть сообщение
Не согласен с данным утверждением. При первом вызове такого запроса статистика используется и строится корректный план исполнения, а вот при повторном использовании план сохраняется, что и может приводить к подобным эффектам.
Например, сначала вы искали проводки по партии (использовался индекс по партиям), а потом стали искать по ГТД (и опять используется индекс по партиям).

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

Последний раз редактировалось fed; 29.06.2008 в 21:51.
Старый 30.06.2008, 10:54   #6  
Saber is offline
Saber
Участник
 
10 / 10 (1) +
Регистрация: 07.03.2007
Спасибо всем.
Действительно, пока попробую повторно внимательно проанализировать планы запросов при нормальной работе и с "тормозами".
Старый 30.06.2008, 12:53   #7  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,726 / 839 (31) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Обращаю внимение, что имеет смысл анализировать планы запросов полученные MS SQL Profiler-ом, а не Аксаптой
Старый 01.07.2008, 11:58   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,916 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Wamr Посмотреть сообщение
Обращаю внимение, что имеет смысл анализировать планы запросов полученные MS SQL Profiler-ом, а не Аксаптой
А что, они могут отличаться ?
Старый 01.07.2008, 11:59   #9  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,916 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Alexius Посмотреть сообщение
3. В качестве "лома" можно попробовать покрывающий индекс на InventTrans:
- ItemId
- StatusIssue
- StatusReceipt
- ConfigId
- InventDim
- Qty
- CostAmountPosted
- CostAmountAdjustment
Можно дополнить имеющийся индекс, главное использовать такую последовательность полей.
Как бы нам этим ломом не убить другие запросы. Индекс уж очень тяжелый получается
Старый 01.07.2008, 12:11   #10  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
416 / 196 (7) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Logger Посмотреть сообщение
Как бы нам этим ломом не убить другие запросы. Индекс уж очень тяжелый получается
С запросами вставки/обновления/удаления в Аксапте ничего страшного не произойдет, а для запросов на чтение индекс действительно добавит остроты в "драке" за оперативную память
Старый 01.07.2008, 12:17   #11  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,916 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Alexius Посмотреть сообщение
С запросами вставки/обновления/удаления в Аксапте ничего страшного не произойдет,
А как же перестройка ключа индекса при обновлениях ? Дополнительные затраты ресурсов сервера на это дело?

Особенно вот эти поля настораживают.
- Qty
- CostAmountPosted
- CostAmountAdjustment
Старый 01.07.2008, 12:33   #12  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
416 / 196 (7) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Logger Посмотреть сообщение
А как же перестройка ключа индекса при обновлениях ? Дополнительные затраты ресурсов сервера на это дело?
Операции вставки/обновления/удаления производятся для одной записи и накладные расходы в них по перестройке ключей индексов незначительны.
Цитата:
Сообщение от Logger Посмотреть сообщение
Особенно вот эти поля настораживают.
- Qty
- CostAmountPosted
- CostAmountAdjustment
А без них не получить покрывающего индекса В идеале нужно их воткнуть в INCLUDE-поля индекса, но Аксапта это делать не умеет
Старый 01.07.2008, 13:46   #13  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,916 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Alexius Посмотреть сообщение
А без них не получить покрывающего индекса В идеале нужно их воткнуть в INCLUDE-поля индекса, но Аксапта это делать не умеет
Да я понимаю что не получить, но напрягают как-то индексы которые на любое изменение данных перестраиваются.
Старый 01.07.2008, 13:47   #14  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,916 / 1540 (57) ++++++++
Регистрация: 12.10.2004
А INCLUDE поля - это чо за зверь ?
Чем они в данной ситуации полезны ?
Старый 01.07.2008, 14:03   #15  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
416 / 196 (7) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Logger Посмотреть сообщение
А INCLUDE поля - это чо за зверь ?
Чем они в данной ситуации полезны ?
Эта опция появилась в MS SQL 2005. В крации - это поля, включенные в индекс, по которым не производится упорядочивание данных. Подробности в BOL: CREATE INDEX.
Старый 02.07.2008, 08:46   #16  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,726 / 839 (31) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
А что, они могут отличаться ?
Да, так как профайлер покажет используемый план, а Аксапта расчетный.
Старый 02.07.2008, 11:52   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,916 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Wamr Посмотреть сообщение
Да, так как профайлер покажет используемый план, а Аксапта расчетный.
Но ведь Аксапта сама запрашивает план запроса у БД. Почему БД будет его разным строить ? Если настройки БД не менялись то и планы должны по идее одинаковые получаться.
Теги
ax2.5

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Создание Lookup формы Maxim Gorbunov DAX: База знаний и проекты 9 26.06.2007 16:44
Крэш на ровном месте Falcon DAX: Функционал 12 19.01.2006 13:46
setFocus в момент инициализации формы k!D DAX: Программирование 3 10.11.2005 13:33
Русская локализация Axapta 3 ? SlavaK DAX: Администрирование 59 01.07.2003 22:38
Динамические Lookup формы. Андрей Василюк DAX: База знаний и проекты 0 07.12.2001 07:07
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 05:37.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.