Добрый день. Перешли на S4 (S4CORE 108)
Все Z-отчеты не работают, что касается выборки из ANEP, ANEA, ANLP, ANLC
Очень долго выбираются данные.
Ноты, которые оптимизируют эти таблицы стоят. Некоторые коллеги предложили перейти на считывание из ACDOCA.
Если у кого-то опыт изменений своих отчетов из этих таблиц? Действительно ли нужно переходить на другие выборки или что-то может недоустановлено?
По остальными модулями таких проблем нет.
И что интересно, написала 2 выборки. Не пойму и не найду причину такой разницы в производительности.

Добрый день. У меня нет для вас готовых ответов, но есть кое-какая информация.
1. В HANA в SE11 для ANEA выберите меню Дополнительная информация - Замещающий объект.
Увидите что такой таблицы физически в БД больше нет, а есть VIEW. Дальше если в SE11 последовательно смотреть определение VIEW, то вы увидите что через несколько слоев оберток запрос идет к таблице ACDOCA.
Поэтому писать выборки сразу к ACDOCA может быть разумной идеей, если понимаете что именно там писать.

2. Если два запроса работают по-разному, снимите трассировку в ST05 и сравните план выполнения запросов. В SAP GUI этот план обрезанный, но можно из ST05 выгрузить файл PLanVis и посмотреть его в HANA STUDIO.

3. Обратите внимание на то, как у вас партиционирована таблица ACDOCA. Если запросы не попадают в ключ партиционирования, то идет перебор всех партиций и это может быть в разы дольше.

А если в wa_where2 убрать пробел в конце, то тоже тормозить начинает?

По поводу скорости обработки двух одинаковых запросов - трассировка. Довольно странно, что такая разбежка.

По поводу в принципе выборки - надо поработать с логикой и ключами. Кроме партиционирования ACDOCA, в большинстве случаев, SELECT * из ANEA/ANEP может быть замещен комбинацией селектов из ANLC+ANEA/ANEP, т.к. все суммы из позиционных таблиц все равно абсорбируются в ANLC по году, поэтому за редким и очень специфичным исключением ходить в ANEA/ANEP за данными прошлых лет не имеет смысла. Далее - если Ваш случай такой специфичный, имеет смысл подумать о дриллдауне на уровне отчетного экрана, типа "вот колоночки текущего года, следом колоночка всех прошлых лет, хотите прошлые годы в деталях - даблклик на сумме, указываем год или диапазон лет и немножечко ждем" - таким образом Вы снимаете необходимость пробирать все движения с начала времен при запуске основного отчета. Хотя, если Вы только перешли, то прям гигантского количества позиций по идее быть не должно, бОльшая часть должны быть схлопнута в миграцию...

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