Подскажите, что можно сделатьв данном случае для оптимизацииЖ
SELECT belnr gjahr budat blart shkzg dmbtr
wrbtr waers lifnr rebzg rebzj
FROM bsik
INTO TABLE t_table
FOR ALL ENTRIES IN lt_temp
WHERE bukrs EQ p_bukrs
AND lifnr EQ lt_temp-lifnr
AND umskz EQ ''
AND shkzg EQ 'S'
AND rebzg EQ lt_temp-belnr
AND rebzj EQ lt_temp-gjahr.
(lt_temp содержит около 100 000 записей и запрос падает в дамп по тайм ауту)

IMHO, выбрать все, ограничившись по LIFNR и GJAHR в виде ranges, а потом пофильтровать... было бы здорово для фильтрации сделать таблицу t_table типа hashed. но это IMHO, на деле все может быть по-другому

FOR ALL ENTRIES губительно для производительности ... отмахивайся от него руками и ногами ... лучше сначала без этого условия все выбирай во внутр. таблицу, а уж потом выбирай из выбранного ...

В качестве индекса у вас используется только часть первичного ключа BUKRS & LIFNR.
1) Убедитесь, что нет пустых значений в полях LT_TEMP, которые используется в выборке. Наборы этих полей должны быть уникальны для корректной выборки.
2) Создайте пользовательский индекс MANDT-BUKRS-LIFNR-REBZG-REBZJ и немного поменяйте условие выбора.
После разбора п.1, думаю, записей в LT_TEMP станет гораздо меньше

согласен с EHOT,

смотря как этот FOR ALL ENTRIES в UNION собирается,
в UNION не может сразу 100 тыс запросов объединиться,
следовательно, будет несколько тысяч отдельных запросов,
объединение результатов и завершающее выкидывание повторяющихся строк.
допустим каждый запрос оборачивается в сетевой обмен,
судя по всему этого времени достаточно для timeout dump..

можно убрать FOR ALL ENTRIES, считать BSIK отдельно в T_TABLE,
затем отдельно отфильтровывать записи по LT_TEMP.

вообще хотелось бы узнать, откуда формируется LT_TEMP,
не из таблицы ли, вдруг там JOIN-ом обойтись можно ?