Существует такая проблема: при запуске транзакции UCMON "монитор консолидации" (на IDES BW/SEM) и работе с ней, память системы перегружается. Система жутко тормозит. Некоторые транзакции вылетают в дамп из-за нехватки памяти. Почему я думаю, что консолидация, так как до этого таких проблем <я не знать русский языка>, пока я не стал запускать этот компонент. Возможно кто-то сталкивался с этим или есть какие-нибудь советы по этому поводу. Заранее спасибо.

Сталкивались. Дамп покажите.

дампы такие:

SYSTEM_NO_SHM_MEMORY
TSV_TNEW_PAGE_ALLOC_FAILED
TSV_TABH_POOL_NO_ROLL_MEMORY

Изначально транзакции для консолидаици сразу валились в дамп, но базисники настроили некоторые параметры в системе. Сейчас работает нормально и UCMON и UCWB, но при работе с монитором консолидации система жутко память ест и при выходе из монитора память всё еще перегружена.

Да, базисники тут должны принимать непосредственное участие. В одном из дампов были рекомендации по настройке параметров.
Еще читали ноту https://service.sap.com/sap/support/notes/928044, а конкретно меняли параметр abap/shared_objects_size_MB

Ограничивайте данные, переводите систему на Линукс
Сталкивались с подобной проблемой - если система стоит на Винде, то 4 гига максимум что можете получить, а то вроде и того меньше.

К сожалению БВ не предназначен для больших массивов данных так что оптимизируйте

Может смогу вам помочь агрегаты ?

Страшные вещи говорите, кощунственные прям
А что же предназначено?

R/3 мне думается. Куб прода нормально работает когда записей меньше 20 миллионов, дальше начинаются проблемы

А вы не пробовали занятся оптимизацией для избежания проблем? потому как и 50 лимонов при нормально поведенной работы по оптимизации (не только кубов, но и отчетов) жуется системой на ура... уверен, что это не пределы, так как в моем случае даже агрегаты не использовались

Проблемы в другом месте.
Почитайте для начала:

https://www.sdn.sap.com/irj/sdn/go/port ... f0168d41b6

https://www.sdn.sap.com/irj/sdn/go/port ... a9269a23c2


https://www.sdn.sap.com/irj/sdn/go/port ... 2df5763455


https://www.sdn.sap.com/irj/sdn/go/port ... 9ec8157802

RSA1 - спасибо - посмотрю. Хотя цифру в 20 нам называл один уважаемый сотрудник компании SAP - считающийся в BW достаточно компетентным

У нас кубы по 50 млн. записей тормозят и отжирают много памяти. Если учесть что таких кубов много (на каждый календарный год/месяц по кубу) то картина просто не очень красивая

А можете примерно описать свой куб - количество признаков/показателей навигационных атрибутов ?

Позвольте-позвольте, у меня все ходы записаны! (с)
А как же вот это: тынц???
Или-таки врут буржуи?

Идеальный environment да еще в рекламных целях создать нетрудно.

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

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

Очень много зависит от того, насколько правильно разработана модель данных, отношения размеров таблицы фактов к таблицам измерений, да и вообще, "от печки надо плясать". Для начала саму корпоративную отчётность надо "прошерстить" как следует.

Описывать кубы нет смысла, общее количество кубов у нас под сотню. Самые объёмные - CO-PA, SAPPhone CRM (база телефонных соединений, уже под 100 миллионов подкатывает).

Если вы вообще не занимались оптимизацией, то для начала попробуйте запустить отчёт SAP_INFOCUBE_DESIGNS, и посмотрите отношения размеров таблиц фактов к таблицам измерений. Иногда можете "вдруг" с удивлением узнать, что некоторые таблицы измерений больше таблиц фактов.

Ну и напоследок вот еще ссылочка:

https://www.sdn.sap.com/irj/sdn/go/port ... 41e12c72be

Уважаемый RSA1 любоптно было бы узнать Ваше мнение по вопросу какие данные должны хранится в BW. Я всегда думал что там должны быть сагрегированные данные из транзакционных систем. Которые описывают, может с опеделенной степенью детализации, но общую ситуацию. Допустим в разрезе продукт/клиент. А вот если Вы хотите опустится уже до конкретного договора - добро пожаловать в R/3. По Вам я понял что в BW лежит ВСЕ. Зачем тогда нужны отчеты в исходных системах ? (исключая нагрузку)

2StealthS

говорить о том, что BW не предназначен для хранения больших массивов данных некорректно. есть данные, которые хранить в кубике бессмысленно, номер документа, для этого есть ods, но ведь это тоже BW

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

проблемы возникают именно из-за ошибок при проектировании кубика, а не из-за размеров.

по performance есть ноты и презентации, надо вам почитать