Добрый день!

Подскажите, пожалуйста, в чём может быть причина следующего поведения программы.
Есть запрос на выборку данных:

С некоторого времени выполнение этого запроса в продуктивной системе стало занимать более 2-3 часов времени. (В таблице gt_eban 3.103 записи). В таблице RESB - Более 2 млн.записей. В таблице RESB присутствует индекс по полям banfn, bnfpo,xloek. Администратор говорит, что ресурсов в системе достаточно.
И ещё такой момент - в тестовой системе, содержащей копию продуктивной системы, запрос отрабатывает менее чем за минуту на одинаковых данных.

Спасибо за любой совет!

А проверка что внутренняя таблица gt_eban не пустая имеется в коде?
Если нет, то нужно добавить. Иначе если gt_eban пустая, то будет фулскан по таблице resb в независимости от имеющегося индекса.

skaa, да. Как я писал выше в таблице gt_eban 3.103 записи.

Добрый день. Была аналогичная ситуация, ни с того ни с сего, запрос, выполнявщийся 10 секунд стал выполняться 10 минут. По какой-то причине оптимизатор решил, что нужно не в табличке А подставлять табличку Б, а наоборот. Чтобы это понять запустите этот запрос в qas и prd и смотрите EXPLAIN (dbacockpit > wait event analysis > session monotor > поймайте тут свой запрос и нажмите кнопку EXPLAIN). Вложенность считается от единички до максимальной цифры.

Спасибо, RikoNw. А как вы потом это исправили ?

Абапер правил текст запроса.

Я не понимаю как можно изменить код нашего select'a, ведь он и так максимально лаконичный и выглядит абсолютно правильным.

Хинтом можно принудительно заставить использовать определенный индекс.
Как вам правильно посоветовали - начните с explain, сравните с тестом.

Абапер сказал так: практически наверняка gt_eban содержит 0 записей при выборке. Посмотрите под отладчиком, сколько записей в ней. Если 0, запрос как раз и перебирает все 2 миллиона записей, будто
FOR ALL ENTRIES IN gt_eban вообще бы не было в запросе.

Нет, нет. Я как раз и смотрю программу под отладчиком. gt_eban не пустая! Это известная ошибка, которую иногда допускают, но в данном случае это не так.

На счёт dbacockpit/explain - в тестовой системе запрос отрабатывает очень быстро и не получается его увидеть в dbacockpit.

Вот как выглядит explain по "зависшему" запросу:

Ну вот, фуллскан. Проверьте нужный вам индекс.

агась, индекс видать

observer, мне кажется, что это не фуллскан, потому что количество записей в RESB = 2.172.676:


Вот скриншот отладчика - видно, что таблица условий it не пустая:

1. Проверьте индекc в se11.
2. Даже если se11 считает что все ок, на уровне БД с индексом может быть что-нибудь не так.
Его можно пересоздать через se14 (только не используете "активровать и адаптировать" для самой таблицы - а то мгновенно потеряете все данные)

Спасибо, но индекс существует и активен:

Даже два индекса - в одном сначала перепутали последовательность полей. Такие же индексы есть и в тестовой системе.

При создании индекса в SE14 его активировали.

Есть такой момент - в dbacockpit висит много каких-то запросов к этой же таблице RESB. Не могут ли они настолько "загружать" таблицу RESB, из-за чего запрос долго не отвечает ?

В тестовой системе мы пробовали выполнить этот запрос с такими же данными, и он отрабатывает очень быстро.