Axapta - SQL transfer

[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. Вставка занимала относительного немного времени, несмотря на наличие двух уникальных индексов на таблице, одного как кластерного.

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