О производительности - loop / select / cursor

tester

Всем привет.
Есть таблица БД ztab:
---------------------------------------
MANDT MANDT
KEY_FLD NUMC 10 - ключ
F01 CHAR 20
...
F30 CHAR 20
---------------------------------------
число полей данных - 30
число строк - 100000

есть программа:

Code:

TABLES ztab.
DATA itab TYPE TABLE OF ztab WITH HEADER LINE.

DATA: t TYPE i,
      t1 TYPE i,
      t2 TYPE i.

DATA   c1 TYPE cursor.


GET RUN TIME FIELD t1.
SELECT * INTO TABLE itab FROM ztab.
LOOP AT itab.
  CLEAR itab-f01.
ENDLOOP.
GET RUN TIME FIELD t2.
t = t2 - t1.
WRITE: / '1. time - ', t.

GET RUN TIME FIELD t1.
SELECT *  FROM ztab.
  CLEAR ztab-f01.
ENDSELECT.
GET RUN TIME FIELD t2.
t = t2 - t1.
WRITE: / '2. time - ', t.

GET RUN TIME FIELD t1.
OPEN CURSOR c1 FOR SELECT * FROM ztab.
DO.
  FETCH NEXT CURSOR c1 INTO ztab.
  IF sy-subrc <> 0.
    CLOSE CURSOR c1. EXIT.
  ENDIF.
  CLEAR ztab-f01.
ENDDO.
GET RUN TIME FIELD t2.
t = t2 - t1.
WRITE: / '3. time - ', t.

Результат:

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

Пономарев Артем

Принцип простой: не сравнивать сферических коней в вакууме

В вашем случае вполне ожидаемый результат.

tester

Хорошо, и при каких условиях разница в производительности станет заметной?

tester

Пробоал и select с join, результаты в основном те же.

trop

- добавьте какой-нибудь where
- засекайте по одному варианту, отключив другие
- запускайте с интервалом в час
- укажите package size

tester

История вопроса в том, что при выполнении довольно сложного SELECT-a не хватало памяти на сервере приложений,
отчет вылетал в дамп.
Пробовали все - и package size и курсоры, базис выделил максимально возможное кол-во памяти,
в итоге SELECT разбили на несколько последовательных подзапросов, чем все и решили.
Я так и не понял, что дает применение package size и курсоров.

John Doe

Для информации - PACKAGE SIZE
Рыбак рыбака, как говорится...

tester

Представлялось, что выборки типа SELECT PACKAGE SIZE и FETCH
передают блоки данных от сервера БД на сервер приложений,
а по экспериментам - первый же SELECT или OPEN CURSOR - сразу гонят всю таблицу на сервер приложений.

trop

with hold, по ссылке выше посомтри посты mike1

DKiyanov

tester написал(а):

первый же SELECT или OPEN CURSOR - сразу гонят всю таблицу на сервер приложений.

Думаю что это не так, где то вы ошиблись

tester

Это видно даже по времени выполнения первого SELECT-а в
цикле типа

Code:

SELECT * FROM ztab PACKAGE SIZE 10.
...
ENDSELECT.

Время выполнения первого оператора SELECT совпадает с временем конструкции

Code:

SELECT * FROM ztab INTO TABLE itab.

Такая же ситуация и с OPEN CURSOR.

Получается, у серверов БД и приложений свои представления о минимальном размере выборки.
Наверное, эффект от применения этих операторов скажется на очень больших объемах.

Удав

tester написал(а):

первый же SELECT или OPEN CURSOR - сразу гонят всю таблицу на сервер приложений.

У таблицы ZTAB в технических параметрах не включена буферизация?

Пономарев Артем

tester, почему вы упорно продолжаете считать что ваши конкретные примеры и в частности время их выполнения о чем-то свидетельствуют? Это в корне неверно.
Вы не привели никаких данных о том, на какой версии, каком железе, каких каналах и т.д. запускаете свой код.
И сейчас хотите чтобы вам дали конкретный ответ по неполным данным.

Вам уже привели ссылку с достаточной информацией по курсорам и зачем оно надо.

Правила форума

О производительности - loop / select / cursor

Кто сейчас на конференции