Доброго дня, прошу несколько советов, которые можно применить для целей оптимизации производительности отчета.
Имеется тяжелый отчет: исполнение контрактов логистики, данный отчет имеет основной список, в котором приводятся различные итоги исполнения по контракту ММ (закупка, поступление, оплата, фактурирование и т.д.). Также имеются подробные списки: заказов на поставку, заявок, документов материала, документов бухгалтерии. Итоговые суммы подробных списков приводятся в основной список. По выделенным позициям основного списка, пользователю предоставляется возможность просматривать анализировать документы подробных списков. Также следует заметить что есть такая группа пользователей которой необходимо запускать данный отчет по нескольким ЗО, таким образом, в основной список попадает более 10ти тысяч контрактов, естественно подробные списки содержат кучу данных, пользователю их также необходимо анализировать.
Для целей оптимизации производительности уже были применены методы:
- select into table
- пересмотрены и оптимизированы сами выборки
- добавлены основные индексы в таблицы
- оптимизированы read table бинарный поиск
- оптимизированы loopы
- отсутствуют вложенные селекты
Непонятно из за чего в разное время суток на одних и тех же критериях выбора на одном и том же рабочем месте, данный отчет может отработать (примерно 1,5 часа) а иногда может вывалится в дамп? (дампы: DBIF_RSQL_INVALID_RSQL, или дамп по нехватке памяти)
Полагаю что основные проблемы расчетов это нехватка памяти, какими еще методами можно оптимизировать работу? Время на расчеты устраивает, главное надежность, не хотелось бы получать дампы. Может можно каким нибуть образом упаковать расчеты в ФМ и отправить его рассчитываться на сервер приложений? Основная цель это надежность расчета.
Спасибо!

Подобные задачи, при правильном подходе, не должны выполняться на стороне OLTP системы. Этот отчет должен строится в BW.

Как вариант могу предложить следующее:
Вряд ли пользователям интересен статус он-лайн. Поэтому, как вариант, можно создать необходимые таблицы в словаре данных и заполнять их необходимыми данными для отчета в фоновом задании. Ночью. При вызове программы - только отображать уже выбранные и обработанные данные из таблиц, обрезанные для конкретного пользователя и параметров выбора.

По поводу оптимизации кода http://sapforum.biz/index.php/topic,174.msg713.html#msg713 + se30 + se30(советы), если код оптимизирован до нельзя то +1 к Пономареву Артему, тоже решали через фоновое выполнение с заполнением рассчитанных данных в таблицы БД...
На счет дампов, какие именно дампы? DBIF_RSQL_INVALID_RSQL это вроде как не из-за памяти. Так же поговорите с админами чтоб они у себя выставили параметры некоторые по максимуму, например на размер вн. таблицы.

Данный дамп, насколько я помню, показывает проблему в движке работы с базой данных.
На уровне ABAP-программы не лечится. Необходимо искать ноты и обновлять ядро, если нот нет - выставить сообщение в SAP

По нехватке памяти:
В SE30 есть режим, позволяющий отследить потребление памяти(вкладка продолжительность+вид, убрать агрегацию по вызовам и включить галку "С потреблением памяти")

1.Все воспомогательные таблицы объявлять внутри подпрограмм.
2.Для глобальных таблиц как в отчетах, так и в группах функций после использования вызывать REFRESH и FREE (Обязательно!). REFRESH и DELETE по факту не освобождают занимаемую память.
3.Копирование из одной таблицы в другую лучше делать без присвоения всей таблицы и выборочного удаления записей, а через LOOP..WHERE ... INSERT ... ENDLOOP..

По DBIF_RSQL_INVALID_RSQL :
1.Проверьте в дампе количество записей в используемых RANGE. Из-за большого количества записей возможно превышение длины SQL-выражения (для Oracle ограничение - 64 кб)
2.Перед SELECT .. FOR ALL ENTRIES нужно обязательно делать проверку, что внутренняя таблица непустая. При пустой внутренней таблице выберутся ВСЕ записи. Из-за этого кстати и может быть неконтролируемое увеличение времени выполнения разработки.

Полностью согласен, добавлю свои 5 копеек: в роли таких таблиц могут выступать инфоструктуры логистики. Настраивать, может быть, замороченно, но зато они будут обновляться онлайн при сохранении документа, и не потеряется оперативность. Плюс можно сделать несколько инфоструктур с разной степенью агрегации (например, в одной с точностью до документа, в другой свернуто до поставщика). Есть, конечно, и стандартные ИС (напр., S012), но вряд ли они подойдут.

Всем спасибо) по порядку

Варианты с фоновой ночной обработкой и частичными выборками исключаются, причины: сложность реализации, ненадежность фонового задания, отчет нужен актуальный на время запуска

спасибо за ссылку посмотрю почитаю ST05 воспользуюсь, хотя наврятли там что поможет((
Да дамп именно такой
DBIF_RSQL_INVALID_RSQL
вот выдержка из дампа
Possible error causes:
o The maximum size of an SQL statement was exceeded.
o The statement contains too many input variables.
o The input data requires more space than is available.
o ...
полагаю причина кроется в п.3, так как почему то на одних и тех же критериях выбора отчет то падает то не падает в дамп. По ряду организационных причин с админами говорить не хотелось бы только исключительно в крайних случаях.

А можно поподробнее пожалуйста
что за нота?

SE30 попробую.
Так и сделано все внутрении структуры объявлены в TOPе.
REFRESH и FREE вызываются внутреннюю память очищаю, я забыл написать про это в заголовке(.
Дамп вообщем падает на таком селекте

Проанализировал код, поля условия WHERE все время на выборке заполнены а P_LIFNR гарантировано содержит поставщика контракта и его выставителя счета
То есть ничего особенного в этом селекте не вижу.
По FOR ALL ENTRIES уже собак ел знаю))

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

+1
Насчет селекта - видимо ranges LIFNR все-таки содержит большой список поставщиков (несколько тысяч), вот и не хватает длинны селекта.

Наверняка в рэйндже в какие моменты число записей превышает ограничения.

P.S. Если не ошибаюсь, в SQL-запросе SAP рекомендует выражения с операторами IN ставить первыми

Сколько по времени работает программа? В диалоге или в фоне?
Рекомендую анализ se30, st05\db02. Если на db02 нет полномочий, как вариант тр. ora_space. Необходимо проанализировать планы запросов. При необходимости пересобрать статистику, дополнить индексы, добавить hints, при надобности разбить селекты на несколько. Особо рекомендую проверить правильность применения хешированных, сортированных и стандартных таблиц.

Превышение объема с запроса в select-options действительно частая вещь.
Пользователи обожают заполнять s\o из файлов excel ))

Note 635318 - Open SQL: Size restrictions for commands


1.Зачем делать GROUP BY по позиции бух.документа?
2.Если есть номер и позиция заказа на поставку, то условие по LIFNR лишнее, оптимальнее сразу на предыдущем шаге выбрать нужные заказы по поставщику.

Я правильно понимаю, что это всё ещё внутри какогото цикла по PP_P_ITAB_1 крутится?
М.б. вообще отказаться от group by, дёрнуть в память AS сразу всё, и там итоги подбить?

можно начать оптимизировать начиная с этого селекта.