Тормозит запрос. Сильно умная аксапта - DAX: Программирование

Perc · 19.02.2007, 09:48

Есть у нас отчет оборотная ведомость ГК по счету в коррсепонденции с другим счетом. Ну и фильтры по финаналитикам на счете или корсчете. В итоге пролучается запрос который переводится в SQL чтото вроде:
SELECT SUM(A.AMOUNTMST),A.ACCOUNTNUM,A.CREDITING,A.DIMENSION3_,B.ACCOUNTNUM
FROM LEDGERTRANS A,LEDGERTRANS B
WHERE ((A.DATAAREAID='xxx') AND (((A.ACCOUNTNUM=' acc1')
AND ((A.TRANSDATE>={ts '2006-10-01 00:00:00.000'}) AND (A.TRANSDATE<={ts '2006-12-31 00:00:00.000'})))
AND ((A.DIMENSION3_>='0001') AND (A.DIMENSION3_<='0100'))))
AND ((B.DATAAREAID='xxx')
AND ((((A.BONDBATCH_RU=B.BONDBATCH_RU) AND (A.BONDBATCHTRANS_RU=B.BONDBATCHTRANS_RU)) AND (A.CREDITING<>B.CREDITING))
AND (B.ACCOUNTNUM=' acc2')))
GROUP BY A.ACCOUNTNUM,A.CREDITING,A.DIMENSION3_,B.ACCOUNTNUM
ORDER BY A.ACCOUNTNUM,A.CREDITING,A.DIMENSION3_,B.ACCOUNTNUM OPTION(FAST 14)
SQL сервер сильно напрягается. загрузка ЦПУ - 100%. Но результата не дождались.
Стоило закомментировать "OPTION(FAST 14)" - запрос выполнился в несколько секунд.
Вопрос соответсвенно, как отключить эти хинты из аксапты, а если нет, то как быть тогда?
Тормоза из этого хинта наблюдаются у нас и в других формах...

Torin · 19.02.2007, 10:28

OPTION(FAST 14) Не мог привести к такому ускорению. Скорее всего, дело в другод - база, в момент тестов, была под нагрузкой ?

Perc · 19.02.2007, 10:46

Цитата:

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

OPTION(FAST 14) Не мог привести к такому ускорению. Скорее всего, дело в другод - база, в момент тестов, была под нагрузкой ?

Запрос не однократно запускался в кверианализире. Ошибки быть не может. Комментирование опции позволяет запросу выполнится. И повторюсь косяк за этой опцией замечен и вдругих местах. Форму прогнозов продаж открываем с фильтром на закладке "фильтр" - она зависает очень надолго (возможно навсегда).

Torin · 19.02.2007, 11:31

Странно все это. Эта опцич не влияет на план выполнения запроса !.
Чудес не бывает. Так - база была под нагрузкой ?

Perc · 19.02.2007, 11:43

Цитата:

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

Странно все это. Эта опцич не влияет на план выполнения запроса !.
Чудес не бывает. Так - база была под нагрузкой ?

Была конечно маленько. Люди работают. Описанная выше ситуация стабильно повторяется. Уверен, что если я дождусь когда вообще все с работы уйдут и в пользователях останусь только я эффект повторится )

Torin · 19.02.2007, 11:55

У меня лично никогда не повторялось. Давайте тогда подробнее - версия СУБД ? Версия Аксы ?
Если это Юкон - то без запросов системного харакетра (waiter-ры, block-ры) не обойтись, но так не бывает из за этого параметра

**Vadik** · 19.02.2007, 12:01

Цитата:

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

OPTION(FAST 14) Не мог привести к такому ускорению

OPTION FAST - не мог. А вот его отсутствие - вполне
http://www.axforum.info/forums/showt...0765#post80765

Perc · 19.02.2007, 20:43

Цитата:

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

OPTION FAST - не мог. А вот его отсутствие - вполне
http://www.axforum.info/forums/showt...0765#post80765

Прочитал ссылку - оптимизма не прибавилось.Предложений то нет. Что ж делать то...У нас куча информации собирается из проводок ГК с фильтрами по корсчету. Много логики опирается на эти выборки. В этом месяце полная ж.. с работоспособностью сервера.. чего ожидать в самом ближайшем будущем?.. полная остановка (

Recoilme · 19.02.2007, 21:22

Попробуйте отключить оптионфаста в критичных по производительности местах:
Управление опциями SQL запроса
Можно выключить целиком в конфиг-й утилите, но мои замеры показывали падение во многих местах (например разноска заказов, формы), поэтому имхо оптимальней точечно отключить и потом включить в узких местах.

MironovI · 19.02.2007, 22:58

Добавлю свои пять копеек - как-то прихожу на работу - а мне сообщают - унас справочник клиентов пустой - ну думаю приехали, оказалось, что при выключенном fast записи выбираются, а при включенном - нет.. вобщем помогла реиндексация, мож и вам с этого начать $)

TravellerInTime · 20.02.2007, 10:03

Аксапта работает посредством курсоров. Сравнивать результаты выполнения запроса по времени в Query Analyzer и в Аксапта просто не корректно. Часто бывают даже различные планы выполнения.

PS: речь об MS SQL...

AndyD · 20.02.2007, 10:15

Ну в QA курсоры тоже можно использовать

Delfins · 20.02.2007, 11:36

Может поможет sp_updatestats !?

PS: помоему реиндексация тоже это делает.

TravellerInTime · 20.02.2007, 11:52

Цитата:

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

Ну в QA курсоры тоже можно использовать

Можно! И даже те которые использует Аксапта.

Но вот делает ли это кто?...

Delfins · 20.02.2007, 13:10

Смотря что вы называете курсором - есть сам курсор, и есть Prepared Statements

Аxапта использует Prepared курсоры, когда проставлена опция ForcePlaceholders, либо у таблицы стоит определённая группа (читайте мануал)

Я пробовал смотреть план, вроде ничего такое не изменяется... Насчет нужно ли использовать курсор - когда один запрос выполняется 100x раз - кончно надо использовать Prepared

Волчара · 20.02.2007, 18:18

Разработчики dis слоя были умные люди и таких запросов не писали - специально искал.
Впрочем структура хранения информации о кор проводках в dis дурная... Что из нее выжмешь ?...

Цитата:

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

...Давайте тогда подробнее - версия СУБД ? Версия Аксы ?

Добавлю: сколько записей в LedgerTrans?

А для начала попробуйте разбить запрос на 2:
SELECT ...
WHERE ... A.CREDITING= 1 B.CREDITING=0 ...
+
SELECT ...
WHERE ... A.CREDITING= 0 B.CREDITING=1 ...

Может поможет...

Потом еще попробуйте добавить условие а.Voucher = б.Voucher (док ГК то должны быть одинаковыми)

Perc · 20.02.2007, 19:02

Волшебство от AndyD помогает:
SqlSystem sqlSystem = new SqlSystem();
int hints;
;
hints = SqlSystem::databaseHints();
SqlSystem::databaseHints(hints & 0xfffd);

// ваш select или QueryRun

SqlSystem::databaseHints(hints);

Пока надеюсь этим чудом выкрутится.
В ледгертранс у меня 4 млн записей за полгода, и это удручает. джойнить такие огромные таблицы.. Чувствую что в ближайшем будущем всеравно в это упремся )

**Vadik** · 20.02.2007, 20:13

В качестве альтернативного варианта создайте на LedgerTrans кластерный индекс по AccountNum - вдруг шаманство не потребуется

Волчара · 21.02.2007, 16:07

Цитата:

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

В ледгертранс у меня 4 млн записей за полгода, и это удручает. джойнить такие огромные таблицы.. Чувствую что в ближайшем будущем всеравно в это упремся

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

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

Сколько пользователей?
Насколько мощьный сервер?
Может можно железо подтянуть.....

VORP · 28.03.2007, 16:34

Цитата:

OPTION(FAST 14) Не мог привести к такому ускорению. Скорее всего, дело в другод - база, в момент тестов, была под нагрузкой ?

Мог. Дело в особенностях работы оптимизатора. Если ему написать firstonly или ещё что либо, генерящее OPTION FAST, то оптимизатор может решить (а может и не решить) найти их тупую, делая INDEX SCAN. А если запись где нить в конце (в таблице из миллионов записей) или её вовсе нет тормоза происходят неслабые. Если же убрать OPTION FAST то операция меняется на INDEX SEEK и отрабатывает за доли секунды.

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Каков процент внедрений "стандартной" поставки системы Аксапта?	coolibin	DAX: Прочие вопросы	17	10.02.2009 12:45
Почему join запрос разбивается на подзапросы!?	3oppo	DAX: Программирование	59	28.06.2007 11:52
Тормозит запрос	FirstOnly	DAX: Программирование	8	07.04.2007 17:30
Запросы в Аксапта	ibc	DAX: Программирование	5	08.08.2005 22:47
Аксапта сильно тормозит	AndreyStar	DAX: Администрирование	43	12.04.2004 23:48