началась заявочная компания, и вылезла огромная системная проблема САПа - сабжевая транзакция сохраняет большие заявки (эдак 9000 позиций в док-те) больше часа (иногда 2 часа, иногда вываливается по таймауту). Переписка с SAP пока ни к чему не привела, ноты 638441 678397 504054 пока эффекта не дали

Стал короче колупать транзакцию под отладчиками - запустил под ST05 (предположил, что дело в неоптимальной выборке из БД), оно полтора часа молотило, потом свалилось в дамп TIME_OUT. Стал раскручивать модуль с дампом (прог. SAPLFMOI include LFMOIF01 строка 1516, внутри процедуры form AL_SAVE_OLD_DATA).

Получается вот что - там внутри 2 вложенных цикла (начиная со строки 1497):

*----- Cf-data are always saved
LOOP AT u_t_fmioi_old WHERE refbt = u_refbt ....
LOOP AT c_t_fmioi WHERE refbn = u_t_fmioi_old-refbn ...
...
и вот внутри этих циклов происходит таймаут (в SM50 видно, что висит выполнение именно в программе SAPLFMOI)

причем - обе внутренние таблицы содержат по 27567 записей (я так понял, несколько записей по каждой позиции, с разным значением поля BTART), причем они упорядоченны одинаково.

Получается, что эти вдоженные циклы выполняют построчное сопоставление "27567 в квадрате" записей вн.таблиц, причем оба LOOP имеют весьма-замысловатое WHERE. Подскажите плиз, LOOP WHERE строит-ли некоторый "внутренний индекс" для ускорения WHERE-поисков для внутренних таблиц (т.е. умеет-ли сервер приложений "оптимизировать" поиски, или он тупо перебирает 759 милиллионов комбинаций? )

Т.е. у меня серьезные подозрения, что беда именно в этом кривом саповском алгоритме (они в переписке признали, что заявки действительно очень плохо работают с большими объемами данных, и что есть много разных причин такой плохой работы).

Теперь вопрос - как лучче всего оперативно потестировать? Очень хочется подправить этот алгоритм "на свой лад" и откаталь в тестовой системе на своих реальных данных. Можно-ли править без выклянчивания "ключа" на САПе? Ведь впринципе все эти "защиты" в sap-системе легко обходятся (например запрет на "ведение таблиц" в тех или иных мандантах представляет собой строчечку абап-кода:
if системный_флажок=запрет.
ругаемся "фигвам, ведение запрещено админом".
else.
правим таблицу
endif.
которую можно легко обойти, поставив точку останова в одной из системных программ и модифицировав флажок отладчиком) - подозреваю, что и требование "ключа" перед правкой SAP-программ тоже "обходимо"

Т.е. как лучче поступить, просто не уверен на все 100% что это именно "оно", а сроки поджимают.
Что делать?

Если внутрення таблица не объявлена как хеш или сорт-таблица, то никакого упорядочивания не выполняется, так что чего зависает понятно..

По поводу ключик клянчить, это ты чего-то путаешь, вот годиков ну может 6 назад надо было клянчить, а сейчас зашел на SAP-сервер и получил ключик, только ведь потом патчики будут, нотки... и потом подправить то конечно подрпвишь только ведь и задеть можно то что и без тебя криво прибили может проще заявочки такие большие не клепать