Доброго утра!
Помогите, пожалуйста, ускорить открытие сводки, созданной в SAP Query. Инфо-набор состоит из 4-х таблиц, связанных стандартным оператором соединения (связи рисуются мышкой). Это таблицы VBRK, VBRP, Z-товская таблица и LIKP. Создал индексы, но это не сильно ускорило открытие сводки и проблему не решило. Создал инфо-набор на основе ракурса, но это тоже не помогло. Может быть, есть еще какие-то способы ускорения работы сводок, созданных в SAP Query?

может, просто таблицы большие?
сколько записей выходит в результате и сколько тратится на это времени?

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

Таблица VBRK содержит 227 тыс. записей, VBRP - 468 тыс., Z-товская таблица - 93 тыс., LIKP - 269 тыс.
Отчет за квартал формируется примерно 9 минут, в результате выходит примерно 1300 записей

Какие поля вы используете для выборки, т.е. что у вас на selection screen? Если вы создали индекс, но поля из него не используются при выборке, то особого толку не будет. Если у вас delivery-related billing, то попробуйте связать LIPS с VBRP по VGBEL/VGPOS, а потом уже LIKP (связки, которые предлагает Query, не всегда самые оптимальные). Ну и не известно, что у вас там в Z таблице...Кстати, если, например, в ? таблице содержатся номера документов, то наиболее целесообразно будет начинать поиск с нее, т.к. там меньше всего записей.

Индекс должен быть активирован не только в Dictionary, но и в самой базе - зайдите в меню Utilities -> Database Utility. С индексами опять же надо поосторожнее - если их слишком много (народная мудрость говорит, что для SQL Server до 5 шт. на таблицу более-менее безопасно), то они только смущают Optimizer.

Посмотрите SQL Trace в ST05, думаю там будет ясно, что где тормозит.

SQ "криво" делает join больше двух таблиц.
советую делать Join двух таблиц, а затем делать дополнительные поля, к-е через select будут вытягивать то, что нужно из остальных таблиц.

НО! без фанатизма, а то множество seleсts на одну строку будет не эффективно и тормозит отчет.

Есть еще динамический анализ - SE30.

A oткуда такая информация? У нас средний query - это 3-4 таблицы и ничего, работает отлично...

вы посмотрите код отчета , к-й сваял SQ - увидите там один огромный select.

Мне кажется, при таком объеме таблиц рационально переходить на "ручное управление" - переписать отчет вручную на абапе. Опытный абапер наверняка сможет написать селекты оптимальней, чем получится у sap query.

согласен, при этом половина работы оп написанию ТЗ уже сделана в рамках создания query.

Посмотрела - совершенно нормальный SELECT, я бы точно так же написала. А что вы еще ожидали там увидеть? Вложенные SELECT'ы по каждой таблице? Просто не понятно, откуда взялась цифра 2...

Если коряво строить JOIN (иногда сам Query предлагает довольно странные условия), так и будет коряво работать. "Как вы лодку назовете - так она и поплывет".

В случае, если нужна data из 5-6 таблиц, JOIN и SELECT будут по любому корявыми!

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

Кстати, забыл сказать (а может, все это знают?)
В SE30 есть средство для сравнения кода, и советы по построению более быстрого кода.

Меню "Утилиты" - Советы (или просто F6).

О как, сейчас посмотрю.



Все таки не понятно, как можно сделать.

Мне удалось сделать производительный запрос, только используя дополнительные поля. Хотя я понимаю, что это криво - select на каждую строку отчета.