Здравствуйте, коллеги!

Столкнулся с такой ситуацией:

В программе делаю выборку нескольких полей из таблицы BSIS во внутреннюю таблицу.
Отрабатывает за 28 минут... выбирает 1 060 000 записей во внутреннюю таблицу.
Всего записей в Bsis - 15 700 000.

Подскажите, пожалуйста:
Это нормальная скорость работы? Как можно ускорить процесс?

Ниже представлен кусок программы.

Во-первых, сходу можно предложить создать соответствующий индекс в таблице BSIS(но все таки лучше убедиться в трассировке ST05, какой идекс в данный момент используется в запросе);

Во-вторых, заменить INTO CORRESPONDING FIELDS OF TABLE на INTO TABLE,
где lt_bsis будет только с необходимыми полями.

Индекс не помог.

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

Покажите explain из st05.

С базисом разговаривали?

В BSIS всего один вторичный индекс и для данного запроса он не самый оптимальный.
Имеет ли смысл создавать свой индекс для отчета - вопрос неоднозначный. Если это очень частый и важный отчет - может быть имеет. А так - при появлении нового индекса планировшик запросов может начать предлагать неоптимальный вариант и производитеьность снизится уже у системных программ.

28 минут - это много
1. s_hkont, s_gjahr, s_blart у вас заполнены?
2. проверьте в тр. DB20 когда обновлялась статистика по BSIS
3. Миллион записей во внутр. таблицу - многовато, желательно добавить ограничений

Это мелочи, можно не заморачиваться. Так даже лучше - меньше вероятность ошибки при дальнейшем расширении списка полей

Нужно оптимизировать не столько выборку, сколько саму задачу. Не поверю, что кто-то будет читать отчет в 1 миллион строк. Скорей всего нужны агрегированные суммы по каким то признакам, по возможности используйте group by. Зачем выбирается BELNR, что с ним дальше делается?

1. Как тут правильно заметили - где explain из ST05?
2. Какая СУБД используется?

1) explain из st05 по ссылке http://savepic.su/2454042.htm

2) Oracle

Если в индекс полностью попадаете, 1 млн записей по ощущениям должны минут за 5 выбираться.
Какие у вас поля в этом самом индексе ZH1?

bukrs, hkont, gjahr, sgtxt, monat, blart

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

Время выполнения сильно зависит от заполнения полей s_hkont, s_gjahr, s_blart. Из ST05 видно что заполнены и low и high. В этом случае сложно что-то оптимизировать. Если в s_hkont задан достаточно большой интервал (а похоже в вашем случае так оно и есть) - быстрее будет выбирать по s_blart+s_gjahr (для этого blart и gjahr должны быть в начале индекса). И наоборот, если задан большой интервал по датам и относительно небольшой по счетам - быстрее получится по индексу ZH1. Проблема в том, что даже если вы создадите оба индекса, без использования гистограмм оптимизатор БД никак не сможет определить каким индексом лучше воспользоваться

А в полях HKONT и GJAHR разброс значений большой?
В подобной ситуации помогает разбиение запроса на несколько с ограничением по равенству поля.
Но для начала попробуйте использовать хинт Oracle SUBSTITUTE_VALUES.

номер счета наиболее узкий критерий,
для сравнения ,попробуйте предварительно выбрать номера счетов из плана во внутр таблицу
и запустить по (bukrs, hkont) используя for all entries ,остальные критерии укажите в where

как бы то ни было, 1млн записей это ад