Axapta - SQL transfer

[Oleksandr]

Цитата:

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

Вы точно уверены в отсутствии возможности оптимизации вашего

while selecе a join b join c //возвращает под сотню тысяч записей.
{
while (bla bla ) // несколько повторов на одну запись
{
someoperation();
recordinsertlist.ins();
}
recordinsertlist.insertdatabse();
}
???

Как показывает опыт, проигрыш X++ по сравнению с чистым T-SQL конечно же бесспорный, но не настолько катастрофичный, что бы пренебречь высокоуровневой средой
Job - задача одного-двух использований? Тогда наверняка есть верхняя грань приемлемости времени выполнения Job'а. Не нужен 100% оптимальный результат, достаточно достичь указанной величины. Оптимизируя 20% кода можно достичь 80% возможной оптимальности, imho

Код оптимизировал настолько, насколько мне позволили мои познания. Интересно, что операции с БД занимают в процентном соотношении немного времени. Из-за количества переменных даже операции в памяти с инсертлистом занимают немало.

Кстати, для меня сюрпризом были, что запрос из while select исполняется по мере выполнения цикла (если верить систем монитору). Собственно селект занимает пару минут, не больше. Возможно, есть способ заставить выполнить весь запрос (т.е. набрать рекордсет), а потом по нему производить операции?

Насчет приемлимости - да, операция нечастая, и в принципе приемлема, но клиент готов платить если улучшение будет раза в два...
Высокоуровневой средой можно пожерствовать, посколку код не универсален, а под одного клиента, ну и в подзабтом SQL поупражняться

[Recoilme]

Цитата:

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

Возможно, есть способ заставить выполнить весь запрос (т.е. набрать рекордсет), а потом по нему производить операции?

может логичнее select firstOnly firstFast, вместо select firstOnly
Управление опциями SQL запроса

[Oleksandr]

Цитата:

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

может логичнее select firstOnly firstFast, вместо select firstOnly
Управление опциями SQL запроса

там нету firstOnly, там while select...., но исполняется постепенно, а не сразу, за ссылку спасибо

[Oleksandr]

Цитата:

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

может логичнее select firstOnly firstFast, вместо select firstOnly
Управление опциями SQL запроса

По ссылке - поэксперементировал с buffer size в конфигурации. При значении 2048 было ускорение процентов на 5-10, видимо потому что записи из запроса весьма тяжелые. Не знаю, правда как это может сказатсья на прочей производительности.

[Oleksandr]

Решил немного подытожить, чтобы знания не поропали в дебрях треда .

1. Axapta code profiler нагло врет и жрет ресурсы при больших количествах вызовов/подвызовов и операций с БД . Потратил много времени пытаясь оптимизировать неоптимизируемое, и вообще, пошел по ложному пути. В таких случаях лучше:

• Замерять ручками с помощью timenow() или gettickcount().

• Смотреть кто (Client/AOS/SQL) больше берет ресурсов и в какое время.

• Исползовать SQL trace или сиквельный профайлер для анализа реальных SQL запросов.

Более реальные результаты получились примерно такие:

select < 5% (в зависимости от условий)
операции - 80 %
insert ~ 10%

2. Основной боттлнек был в нагрузке на сиквел сервер при выполнении операций. Все три таблицы из селекта были достаточно тяжелыми (много стринговых полей, и т.д. - отдельное спасибо проектировщикам БД).
Таким образом, добавление field list-a в запросы ускорило обработку в несколько раз (sic) - отдельное спасибо Wamr! Предположительно, сиквелу было легче выделять память, разбивать страницы и т.д.
При этом он не занимал весь 1.25 гиг свободной памяти, хотя при бОльших количествах допускаю возможность своппинга.

3. Время исполнения нелинейно зависит от количества обрабатываемых записей, а выигрыш по времени - условно линейно.

количество зап.                неоптим.             оптим. 
______________________________________________________________
  1000                     15 сек.                  10 сек
  5000                     5 мин 30 сек             2 мин 10 сек
  ...                        ...                           ...
  80К                      > 10 ч                    3 ч 10 мин

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

-------------------
Еще раз всем спасибо за помощь