Проблема с CustTrans - Страница 2 - DAX: Программирование

belugin · 19.11.2009, 16:26

это не план

Alexanderrrr · 19.11.2009, 16:35

Цитата:

это не план

упс..

имеется ввиду дерево в плане исполнения запроса?

S.Kuskov · 19.11.2009, 16:38

Увидев текст запроса целиком сразу вспомнил про SelectionField:: Database Хоть небольшая, но всётаки оптимизация

belugin · 19.11.2009, 16:40

ну да или текстовое его представление, которое, например, аксапта выводит.

Alexanderrrr · 19.11.2009, 17:10

Цитата:

ну да или текстовое его представление, которое, например, аксапта выводит.

Я правильно понимаю: включил sql-трассировку..запустил отчет, появился инфолог с временем выполнения, открываю мониторинг запросов sql, далее функции-экспорт в файл..создается 2 файлика .dat и .def. В dat много всего..

Alexanderrrr · 20.11.2009, 09:19

правильно делаю? какой именно файлик из двух нужен?

S.Kuskov · 20.11.2009, 09:36

Честно? Не знаю как экспортировать из аксапты сам план исполнения. Выложите хотябы скриншот дерева и распишите 'Ожидаемое число строк' и 'Затраты' для каждого узла (отображаются в нижней части формы 'План исполнения операторы')

belugin · 20.11.2009, 10:00

Самая последняя галка в Мониторинге запросов SQL

Alexanderrrr · 20.11.2009, 10:25

Вроде бы вот это

:

belugin · 20.11.2009, 10:39

а можно еще окно расширить, чтобы весь план было видно?

Alexanderrrr · 20.11.2009, 13:41

извиняюсь..

KiselevSA · 20.11.2009, 13:45

Скажите, а как часто у вас обновляется статистика на рабочем сервере? Может быть дело в том, что SQL по "устаревшей" статистике пытается оптимизировать запрос

Alexanderrrr · 20.11.2009, 14:23

Цитата:

Скажите, а как часто у вас обновляется статистика на рабочем сервере? Может быть дело в том, что SQL по "устаревшей" статистике пытается оптимизировать запрос

ежедневно ночью

Сейчас отчет работает быстро, вопрос в том, надолго ли хватит такого кода..ведь размер таблиц увеличивается довольно быстро..

belugin · 20.11.2009, 22:04

Щас под рукой аксапты нет, поэтому немного пустых умствований

тут основная проблема - то что отчет уходит в глубины прошлого и выбирает за все даты. Если у вас группы договоров меняют свою актуальность - то есть запрос по группе договоров отсекает заведомо старые, неактуальные, договора, до добавление полей RCONTRACTACCOUNT, RCONTRACTCODE в индекс может помочь. Правда надо исследовать, насколько изменится быстродействие вставки при таком изменении.

Еще совершенно непонятно, зачем переписывать совсем все проводки во временную таблицу, судя по всему дальше оно группируется в мепах. Может можно мепам передать уже скгруппированное?

KiselevSA · 23.11.2009, 09:38

Цитата:

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

ежедневно ночью

Сейчас отчет работает быстро, вопрос в том, надолго ли хватит такого кода..ведь размер таблиц увеличивается довольно быстро..

У нас в свое время была похожая "засада" с отчетом, помогал update статистики на лету: пользователям приходилось ждать 8-10 минут. Отчет собирался по SalesTable, т.ч. симптомы очень похожи. Попробуйте в тот момент, когда начинает медленно работать, запустить sp_updatestat и повторить попытку после обновления статистики.

belugin · 23.11.2009, 10:43

Цитата:

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

Отчет собирался по SalesTable

настораживает...

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Проблема с LedgerJournalTrans	Alexanderrrr	DAX: Программирование	14	23.09.2009 13:42
Проблема с единицей измерения	longson	DAX: Программирование	4	16.07.2007 14:35
Как в форме CustTrans через query отобрать записи у которых AmountCur != 0 ( когда в QueryBuildRange ставишь value(strFmt('!0')); - не работает!)	rkorchagin	DAX: Программирование	12	02.04.2007 17:58
Проблема с созданием объекта	Lelya	DAX: Администрирование	33	27.06.2005 16:38
Проблема: русские шрифты в отчетах, формируемых на сервере.	Anais	DAX: Администрирование	3	17.11.2003 13:20