Настройка AOS (Axapta 2009)

[Rivez]

Добрый день!
На форме настроек AOS'а (Axapta 2009) есть такой параметр (галка)
Include LTRIM in all SELECT statements to remove leading space from right-aligned columns

Правильно ли я понимаю, что если установлена эта галка, то для всех запросов от AOS к MS SQL по строковым полям будет добавляться ltrim? Если да, то ведь это очень сильно замедляет систему, т.к. это очень влияет на использование индексов по таблицам, в каких случаях этот параметр нужно включать?

Заранее спасибо!

[gl00mie]

Рассмотрим такую ситуацию: вы переходите на 2009-ю с версии 3.0, где у вас было включено правое выравнивание для фиговой тучи полей. Допустим, вы пошли штатным путем и применили приблуду для выравнивания полей влево, которая идет проектом в поставке 2009-й. Приблуда предлагает использовать штатные средства ядра: поменять свойства на EDT, после чего ядро начнет при синхронизации отправлять на СУБД запросы вида update salesline set salesid=ltrim(salesid), itemid=ltrim(itemid)... То же происходит с накладными, фактурами и кучей других таблиц. В теории все прекрасно, но если по каким-то причинам документов у вас - фигова туча (заказов/накладных/фактур - сотни тысяч, строк в них - десятки миллионов), то может статься так, что обновление шапок документов в ходе синхронизации пройдет успешно, а обновление строк (которое для каждой таблицы идет в своей транзакции) обломится из-за того, что переполнятся транзакционные логи. В результате у вас строки документов "отвалятся" от шапок, потому что в шапках поля будут выравнены влево, а в строках останутся выравнены вправо. Наверно, чтобы в такой ситуации иметь возможность что-то сделать средствами Аксапты, и придумали такой режим работы.

скорее похоже на программистскую "заднюю дверь", перекочевавшую в релиз из бета-версии по недосмотру.

[Rivez]

Спасибо за ответы!
Кто-нить может скинуть скриншот формы настройки сервера AOS вкладки Database Tuning?

Просто заметил, что Ax 2009 дольше обрабатывает запросы (в частности по LedgerTrans), чем Ax 3.0. Предполагаю, что как раз это связано с тем, что AOS какие-то не оптимальные запросы засылает в MS SQL...

[Rivez]

Например такой вот джоб:

static void Job259(Args _args)
{
    ledgerTrans LedgerTrans;
    int         i;
    ;
    info(strfmt('Начало %1', time2str(timenow(),1,1)));
    while select accountnum, crediting, dimension[1], dimension[2], dimension[4], dimension[6], sum(amountmst) from ledgertrans
    group by accountnum, crediting, dimension[1], dimension[2], dimension[4], dimension[6]
    where ledgerTrans.accountnum like '20*'
            && ledgerTrans.transdate >= 01\01\2009
            && ledgerTrans.transdate <= 31\03\2009
    {
        i++;
    }
     info(strfmt('Окончания в %1, выбрано записей %2', time2str(timenow(),1,1), i));

}

в Ax 3.0 работает 4 секунды, а в Ax 2009 десять секунд. Там и там выбирает 11164 записей, в таблице 73 млн записей.

[egorych]

Цитата:

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

в Ax 3.0 работает 4 секунды, а в Ax 2009 десять секунд. Там и там выбирает 11164 записей, в таблице 73 млн записей.

Планы запросов смотрели? Статистику пересобирали? Индексы перестраивали?

[Rivez]

1. план смотрели в 3ке и в 5ке - одинаковый, за исключением того, что в Ax 5.0 используется parallelism
2. Делаем аналогичные запросы прямо в БД (через SQL Managment Studio) время запроса к БД 5ки, меньше чем к 3ке

[egorych]

Цитата:

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

1. план смотрели в 3ке и в 5ке - одинаковый, за исключением того, что в Ax 5.0 используется parallelism

Поставьте для сервера "Max Degree of Parallelism" - 1. Т.е. отключите его нафик!
В бытность свою на MSSQL это дало приличный эффект.

[Rivez]

+ посмотрели повнимательнее sql-запрос в 3ке и 5ке
нашли отличие в том, что в 3ке ещё в конце запроса добавляется
OPTION(FAST 20)

в 5ке этого нет..., может тоже какой-то настройки не хватает?

[gl00mie]

А вы приведенное время точно указывается для одного и того же джобика, а не для джобика и запроса с формы? Обычно option(fast n) добавляется при отработке запроса с формы, чтобы СУБД выдала первые записи как можно раньше (визуально на форме запрос так отработает быстрее, если не начать "листать" результат), при этом план запроса зачастую отличается от случая, когда важно быстрее получить все записи выборки, как в джобе. Кроме того, на форме используется Query, где по умолчанию включен RLS (это влияет на сортировку в запросе), а при использовании select из кода RLS по умолчанию выключен. Индексы у вас точно в обоих случаях одинаковые? Выравнивание LedgerAccount тоже одинаковое? Потому что для запросов с like это может быть существенно...

Цитата:

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

Делаем аналогичные запросы прямо в БД (через SQL Managment Studio) время запроса к БД 5ки, меньше чем к 3ке

В "аналогичных запросах" в Mgmt Studio вы фильтр по dataareaid добавляете?

[Rivez]

Цитата:

А вы приведенное время точно указывается для одного и того же джобика, а не для джобика и запроса с формы? Обычно option(fast n) добавляется при отработке запроса с формы, чтобы СУБД выдала первые записи как можно раньше (визуально на форме запрос так отработает быстрее, если не начать "листать" результат), при этом план запроса зачастую отличается от случая, когда важно быстрее получить все записи выборки, как в джобе. Кроме того, на форме используется Query, где по умолчанию включен RLS (это влияет на сортировку в запросе), а при использовании select из кода RLS по умолчанию выключен.

сравниваются абсолютно два одинаковых ДЖОБА

Цитата:

Выравнивание LedgerAccount тоже одинаковое? Потому что для запросов с like это может быть существенно...

в 3ке Right, в 5ке Left

Цитата:

В "аналогичных запросах" в Mgmt Studio вы фильтр по dataareaid добавляете?

ага, фильтр используется

Запрос к БД Ax 3.0 (в БД 17 секунд, в Аксапте 30 секунд):

select accountnum, crediting, dimension, dimension2_, dimension4_, dimension6_, sum(amountmst) from ledgertrans where dataareaid='xxx'
and ltrim(accountnum) like '20%' 
and transdate between '01.01.2009' and '12.31.2010'
group by accountnum, crediting, dimension, dimension2_, dimension4_, dimension6_

Запрос к БД Ax 5.0 (в БД 12 секунд, в Аксапте 50 секунд):

select accountnum, crediting, dimension, dimension2_, dimension4_, dimension6_, sum(amountmst) from ledgertrans where dataareaid='xxx'
and accountnum like '20%' 
and transdate between '01.01.2009' and '12.31.2010'
group by accountnum, crediting, dimension, dimension2_, dimension4_, dimension6_

т.е. если через MS SQL, то быстрее в Ax 5.0, если из Axapta (через джоб), то в Ax 3.0

[ansoft]

Rivez.
Мое личное мнение и наблюдения говорят о том что эта галка сильно тормозит работу.
У нас она отключена. Кроме того где-то в форуме здесь или на SQL.RU мне встречались
слова о том, что при использовании функций LTRIM не оптимизятся запросы...
Поищите...

Кроме того, меня несколько удивляет высказывание:

Цитата:

Рассмотрим такую ситуацию: вы переходите на 2009-ю с версии 3.0, где у вас было включено правое выравнивание для фиговой тучи полей. Допустим, вы пошли штатным путем и применили приблуду для выравнивания полей влево, которая идет проектом в поставке 2009-й. Приблуда предлагает использовать штатные средства ядра: поменять свойства на EDT, после чего ядро начнет при синхронизации отправлять на СУБД запросы вида update salesline set salesid=ltrim(salesid), itemid=ltrim(itemid)... То же происходит с накладными, фактурами и кучей других таблиц. В теории все прекрасно, но если по каким-то причинам документов у вас - фигова туча (заказов/накладных/фактур - сотни тысяч, строк в них - десятки миллионов), то может статься так, что обновление шапок документов в ходе синхронизации пройдет успешно, а обновление строк (которое для каждой таблицы идет в своей транзакции) обломится из-за того, что переполнятся транзакционные логи. В результате у вас строки документов "отвалятся" от шапок, потому что в шапках поля будут выравнены влево, а в строках останутся выравнены вправо. Наверно, чтобы в такой ситуации иметь возможность что-то сделать средствами Аксапты, и придумали такой режим работы.

По рекомендованной практике перехода генерятся SQL запросы той самой утилитой (проектом),
которая может и EDT поправить и запросы для SQL сгенерить. После генерации запросов
их дробят на несколько скриптов и запускают в параллель для ускорения процесса.
Скрипты выполняются средствами SQL. Скрипт можно запускать многократно, если вдруг
будет сбой (время? ну ведь каждый тестит перенос данных и меряет и смотрит), так что
ситуация когда шапки разбежались со строками - жесть жестокая. Мы в 3.0 не меняли EDT,
проверили типы в 2009, чтобы не было Rigth aligned и получили SQL скрипты, разбили на части,
у нас получилось 6 (группировали по тяжести таблиц) и... все работает.
Переполнение лога невозможно, так как опять таки по рекомендациям ее переключают в режим simple.

[ansoft]

Вспомнил где видел

http://msdn.microsoft.com/en-us/libr...34(AX.10).aspx

Adjust the use of autogenerated string functions
Microsoft Dynamics AX embeds some string functions in SELECT statements automatically. String functions are included to support:

Treating uppercase and lowercase versions of the same text as the same text (single case) for Oracle installations.

Left justification or right justification.

When a string function is included in a query, the optimizer may have to choose a less-than-optimal access plan, such as a table scan, for retrieving data. If customers do not require the use of mixed case outside Microsoft Dynamics AX and do not use left justification or right justification, these functions are not required and should be turned off. To improve performance, we recommend that all values be stored left-aligned by default.

If queries take longer to run than anticipated or appear to be using table scans rather than indexes, try the following adjustments:

Clear Include LTRIM in all SELECT statements to remove leading space from right-aligned columns.

Clear Include SUBSTR and LOWER in all SELECT statements to support Oracle mixed-case systems.

If the adjustment is successful, queries use query plans and return results more quickly.

[Rivez]

Цитата:

Clear Include LTRIM in all SELECT statements to remove leading space from right-aligned columns.

Clear Include SUBSTR and LOWER in all SELECT statements to support Oracle mixed-case systems.

убрав эти галки, всё равно этот запрос медленнее работает в Ax 5.0 (((
p.s. хотя стало немного быстрее...

[ansoft]

Цитата:

убрав эти галки, всё равно этот запрос медленнее работает в Ax 5.0 (((
p.s. хотя стало немного быстрее...

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

P.S. Попробуйте в свой JOB добавить index hint

static void Job259(Args _args)
{
    ledgerTrans LedgerTrans;
    int         i;
    ;
    info(strfmt('Начало %1', time2str(timenow(),1,1)));
    while select accountnum, crediting, dimension[1], dimension[2], dimension[4], dimension[6], sum(amountmst) from ledgertrans
    index hint ACDate
    group by accountnum, crediting, dimension[1], dimension[2], dimension[4], dimension[6]
    where ledgerTrans.accountnum like '20*'
            && ledgerTrans.transdate >= 01\01\2009
            && ledgerTrans.transdate <= 31\03\2009
    {
        i++;
    }
     info(strfmt('Окончания в %1, выбрано записей %2', time2str(timenow(),1,1), i));

}

... интересно поменяется ли скорость

[ansoft]

Прикол!!!

Запустил JOB!
AOS умер! Ужас...
У нас только 5 аналитик и dimension[6] приводит к тому, что хотя все компилируется АОС падает в усмерть...

[Rivez]

Цитата:

Запустил JOB!
AOS умер!

такая же фигня получилась ))))

вообщем сейчас настроили у сервера AOS на вкладке Database Tuning:
- галка "Include LTRIM in all SELECT statements to remove leading space from right-aligned columns" -снята
- галка "Generate ORDER BY clauses from WHERE clauses" - отмечена
- галка "Allow INDEX hints in queries" - отмечена
- галка "Use literals in complex joins from X++" - отмечена
- галка "Use literals in join queries from forms and reports" - отмечена

небольшой прирост производительности есть...
есть ещё у кого-нибудь ещё идеи по улучшению производительности (из личного опыта)?

[Rivez]

Цитата:

Поставьте для сервера "Max Degree of Parallelism" - 1. Т.е. отключите его нафик!
В бытность свою на MSSQL это дало приличный эффект.

это вы про такую настройку у MS SQL ?
у AOS не нашел ))
парадокс в том, что этот же запрос в 1,5 раза быстрее работает по БД Ax 5.0, чем по БД Ax 3.0
А если делать запрос через джобы (из аксапты) получается наоборот
=> проблема в AOS..., только не понятно в чём конкретно, вроде настройки все сделали оптимально, однако должного эффекта нет (((((

[ansoft]

Цитата:

Поставьте для сервера "Max Degree of Parallelism" - 1. Т.е. отключите его нафик!

Да такая настройка на SQL, в свойствах сервера, в "дополнительно" (максимальная степень параллелизма), на 2008 не требует перезапуска SQL. 1 - рекомендованный параметр.

[ansoft]

- галка "Use literals in complex joins from X++" - отмечена
- галка "Use literals in join queries from forms and reports" - отмечена
У меня эти галки сняты... они не всегда дают плюс... Первый параметр может быть
включен для конкретного запроса в коде, по необходимости, а по умолчанию вроде как
он не нужен, второй действует тока на формы и репорты... Оба параметра следуя прочтению
мануалов по настройке ставяться и снимаються по ситуации, если это медленно то попробуйте
так, непомогло попробуйте иначе... жесть.