Возможно, у вас просто маленькая база;-)
Или очень простые отчеты
Из личного опыта: попробуйте какой-нибудь нетривиальный отчет, использующий т.н. "оконные" функции (window function)

Спасибо за наводку.
База большая. Этого в РФ всегда будет в достатке )))

hp load runner

Элегантно, значит простыми легкими средствами, без излишних затрат. В идеале, простым селектом.
А load runner - это стандартное средтво тестировщиков, которое требует несколько хостов и много времени для настройки конфигрурации инструмента и скриптов.

IBM RPT. У них 30 триальный период и есть облачный сервис по генерации распределенной нагрузки.
https://www.ibm.com/developerworks/downloads/r/rpt/

Привет,

Кстати, объём HANA какой будет, если в Oracle 5 Tb?

превед
запусти отсюдова скрипт сайзинга в исходнике, применительно к текущей субд
1514966 - SAP HANA 1.0: Sizing SAP In-Memory Database

навскидку 1/7 или 1/10 если оракл.

пасиб,
что-то, помниться, запускал в абапе, но на объём дисков не было расчёта

так что - на 50 Тб ориентироваться?!

Не могу молчать!
Оракл же тоже умеет сжимать данные. И как в этом случае будет? Относительно чего считает этот самый сайзинг?
Ну и отдельно мне доставило, когда ковырялся в хане, что никаких объяснений в hana studio про показатель компрессии столбца не было. Т.е. как он получается - не объясняется. Ну и совсем вишенка на торте: почему этот показатель иногда был отрицательным?;-)

ненене...наоборот ))))) 500гиг



это из анекдота:
-Что сказал папа?
- Матом можно?
- Нет!
- Промолчал!

just 2 cent's :

Для одной ERP на DB2 размером в 1.4TB скрипт get_size.csh показывает, что размер 1066GB (без индексов и с учетом компрессии)
Т.е. если использовать формулу <SOURCE_DATA>*2/7, то получается 304GB в памяти HANA'ы.
В то же время репорт /SDF/HDB_SIZING, используемый для SoH-сайзинга, после прогона сказал, что на все-про-все понадобится 1047GB RAM (feel the difference (c))
Отдельно в репорте доставила таблица EDI40 (30 милл. строк), которая при декластеризации превратится в EDID4 на 2.9 ярда строк и размером в 220GB
В том же репорте из рабочих таблиц топовой была FMIFIIT на 11.5Gb. После пробной загрузки в тестовую базу с оптимизацией merge delta заняла 4.5GB.

это типа примерный объём экспорта получается

кстати, после компрессии ораклом становиться в два раза меньше база, т.е. 2,5 Tb

и ещё: SAP рекомендует только сертифицированное железо, но по этому (сайзингу 300saps/акт. юзверя), ну сколько там активных? - 5, ну 10. И что - 3000saps. Да такого железа в списке не найдёшь воще .

Взял "самый крохотный для BW HANA" - Dell PowerEdge R930,

4 processor / 96 cores / 192 threads,
Intel Xeon Processor E7-8890 v4, 2.20 GHz, 64 KB L1 cache
and 256 KB L2 cache per core, 60 MB L3 cache per processor,
1024 GB main memory
SAP Certification number: 2016043
Так там saps-ов на 30000 юзверей (ERP)

А мы люди не гордые, мы и матом послушаем.
Так шо вам есть сказать на предмет?

точнее не рекомендует, а требует

Согласно TDI-модели для продакшена маленьких хан можно использовать двух-сокетные Xeon E5-based машинки с минимумом в 16 CPU core и 128GB RAM
В такую машинку нынче можно напихать 1.5TB памяти.

Апну-ка темку.
Вот тут неплохое техническое Intro от Carnegie-Mellon University (курс Advanced Database Systems, весна 2017), поясняющее разницу между традиционными и In-Memory БД. Для всех интересующихся темой в целом - очень рекомендую. Там, кстати, приведен ответ на вопрос, почему нельзя просто взять и положить традиционную DBMS в память, чтобы получить сопоставимую с In-Memory DB производительность.
А для адептов Оракла трейлер (слайд 35):
- Disk-oriented DBMSs are a relic of the past.
- The world has finally become comfortable with in-memory data storage and processing.



Есть еще отличное видео от Константина Осипова, архитектора Tarantool (In-Memory DBMS разработки Mail.ru) - в целом об особенностях таких баз данных.

В удивительное время живем, господа!