Коллеги, доброго дня!

Используем SAP BW 7.4 с огромным количеством одновременных загрузок/расчётов. Много где используются огромные таблицы с какими-то нужными дополнительными данными. Например, договора и контрагенты. Происходит следующее: запускается несколько расчётов по нескольким БЕ одновременно, и каждый из них выполняется отдельно по каждому месяцу. И везде нужны, скажем, договора. Таблица большая, и периодически её чтение из таблицы БД заканчивается дампом по нехватке памяти.
При этом сама таблица договоров внутри абапа никак не изменяется.

Хотелось бы считать её в память в каким-то одном месте, а затем использовать эти данные во всех параллельных процессах. Пробовали использовать SHMA, но без особого результата: всё равно таблицы читаются каждый раз в разные версии. Может быть, как-то не так настроили...

Подскажите, есть ли подобная возможность? Может, пример кода?

Вариантов много. Самый простой - пакетная обработка в селекте. Изобретать что-то с распределенной памятью - как стрелять из плазмогана по воробьям.

Проблемы с памятью определяются через SAT.
У нас подобные проблемы с нехваткой памяти для процесса решались с помощью освобождения памяти временных внутренних таблиц. Кроме REFRESH нужно было делать FREE.
И да - нехватка памяти для процесса, или глобальной памяти?
Опять же - зачем для таблиц договоров и контрагентов читать все поля?

подобное для большинства компаний скорее всего только после 2030 года?
Внутренние таблицы как источник в SQL запросах

Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.
Разумеется, в борьбе за память потеряете в производительности - по другому и быть не должно.

Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка.

Ну да. Несколько десятилетий существования продуктов R/3 и ERP, SAP объяснял какие они молодцы, что при помощи абапа позволяют снять нагрузку с единой точки отказа (БД) за счет горизонтально масштабируемых серверов приложений. Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.

Видимо шустрые ssd-диски подешевели, что теперь нет смысла экономить на ИО-Костах, БД на шустром железе и так прожуёт. Логично такто, но както не по саповски

Только не совсем понятно, что имеется в виду под «перенести логику в БД». Если использовать возможности обновлённого SQL – то да: он стал мощнее (например, если раньше нужно было делать несколько выборок, а потом сочетать таблицы на AS, то теперь можно всё сделать одним селектом), да и HANA тянет ранее тяжёлые селекты «на ура». Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.

Странное утверждение. Проверил в 2ух системах (7.5 и 7.52) ни в одной нет такого класса

Нет класса CL_SADL_SQL_EXECUTOR?

Ага

Во-первых, самой темой задано снижение нагрузки с сервера приложений.
Во-вторых, за трёхзвенку не беспокойтесь, сервер приложений без работы не останется. Сами же знаете, что задачи обычно сложнее простой выборки и отображения простого отчёта. Иначе было бы достаточно Report Painter, а нас разогнать.
В-третьих, разумеется SQL-запросы должны писаться максимально грамотно - оптимизация, ключи, индексы и т.д. Но начинать надо с грамотного проектирования БД, что, к сожалению, не всегда осуществимо. Т.н. "декомпозиция джойнов" не сильная сторона, а вынужденная мера, например, для связки таблиц пула (а ля BSEG) или нестыкуемых полей связи (ошибки проектирования БД). В целом же такой подход всегда работает хуже - медленнее и больше нагружает все узлы системы (СУБД, шины данных, каналы связи, серверы приложений). Во всяком случае за свою практику исключений не встречал, и даже споры выигрывал.

Полагал, что эта вынужденная мера позволяла сап-коробке не одно десятилетие сознательно замедлять и нагружать работу единичного пользователя (и евоного отчёта ... ну и абапера, кто это всё декомпозирует и отлаживает ),
но за счёт возможности давать толктись на ноде тысячам такихже активных пользователей. Чтобы они все дружно колом не вставали на блокировках СУБД, если 50ти тяжёлые коммиты "вот ща последнюю фактуру допровожу", а у остальных 100 экземпляров годовой отчётности уже запущены "вот прям щас надо"

А щас получается обратно в дремучее двухзвенное прошлое.

У транзакционной ханы очень низкая нагрузка по CPU обычно. Вот и решили догрузить ее немного...