Защо изпълнението на Query след опресняване отнема 100 пъти повече време?

Имам формуляр с 4 източника на данни. Той е в стил на страница със списък и има Datasource1 (голяма таблица с много релации, колони и индекси), показана в решетка. Когато отворя този формуляр, отнема около 200 милисекунди, за да го отворя, но когато го опресня, опресняването отнема 13 секунди.

Използвах инструмента за профилиране на код и открих, че времето се изразходва в Datasource1 в метода executeQuery() чрез команда super();

Когато executeQuery() се извиква от формуляр от

Datasource1_ds.executeQuery();

отнема 200ms, за да го извикате.

Има около 15 колони в мрежата във формуляра и сортирането по една отнема малко по-малко от 1 секунда.

Та въпросът ми е. Какво се извиква в super();, когато формулярът се обновява от задача F5 и не се извиква чрез отваряне на формуляр и извикване на Datasource1_ds.executeQuery();?

Опитвам се да използвам Code Profiler с различни настройки и действия, отстранявам грешки в кода в различни изпълнени действия, използвам Visual Studio Profiler, използвам Activity Monitor в Microsoft SQL сървър на Microsoft Dynamics AX база данни, променям таблицата Datasource1, без успех.

Всеки път, когато се окажа на super(); Единственият път, когато опресняването е бързо, е когато имам филтри в мрежата и тя показва по-малко редове. (Опитвам се да използвам свойството VisibleRows в мрежата, но не помага.)

Използвам Microsoft Dynamics AX 2012 R2


performance-testing axapta
person boucekv    schedule 02.04.2015    source източник
comment
Чели ли сте тази страхотна статия?   -  person Maxim Lazarev    schedule 02.04.2015
comment
@MaximLazarev Да, но имам проблем с метода task(#taskF5). F5 във формуляра и метода на задачите не се променя.   -  person boucekv    schedule 02.04.2015
comment
@boucekv: Променете ли сортирането във формуляра, преди да натиснете опресняване? Питам, защото извличането на данни във форма с решетка се влияе от клъстерния индекс на таблиците и ако сортирането не отговаря на клъстерния индекс, това може да е причината за по-бавното извличане на данни. Можете също така да погледнете парсера за проследяване (technet.microsoft.com/en- us/library/jj149695.aspx) и проверете дали заявките между отваряне на формуляра и опресняване са различни.   -  person FH-Inway    schedule 03.04.2015
comment
@FH-Inway Просто използвам Trace Parcer, за да намеря проблемна заявка. Добър съвет е да погледнете заявката при отваряне на формуляра и да я сравните. Анализаторът на проследяване ми връща заявка с ? напр. (T1.RECID‹?) къде? означава реална стойност. Възможно ли е да получа 1 заявка с реални стойности, за да мога да я анализирам в мениджъра на SQL Server?   -  person boucekv    schedule 03.04.2015
comment
@boucekv: ключовата дума е литерали или принудителни литерали. Не съм използвал това от известно време, така че ще трябва да направя някои собствени проучвания, но тези връзки трябва да ви помогнат да започнете: technet.microsoft.com/en-us/library/aa569637.aspx и ax.nom.es/dynamicsax/axapta-comman-line-parameters-2. Просто направете търсене по литерал на ключова дума на тези страници.   -  person FH-Inway    schedule 03.04.2015
comment
Опитайте се да добавите this.query().literals(true); след super() в метода init на източника на данни.   -  person Jan B. Kjeldsen    schedule 07.04.2015

Отговори (1)


arrow_upward
2
arrow_downward

Бих предложил да се заснемат със SQL Server Profiler заявки, които се изпълняват (1) при първоначалния executeQuery(), когато се отвори формулярът ListPage, след това (2) при извикване на executeQuery() при опресняване на формуляра.

Сравнението на плановете за изпълнение на тези две заявки трябва да покаже тясното място. Можете да заснемете събитие Showplan XML.

person kirv    schedule 04.04.2015
comment
Проблемът е в заявката, която се извиква. Те са различни. Бавният има 15 пъти повече нещо е WHERE клауза. Сега се опитвам да намеря какво да променя, за да променя querz, който се извиква, когато формата се опреснява. Сега без успех. - person boucekv; 09.04.2015