Sizing specifically for the live part of SAP HANA live
I have been looking around for a while now and I couldn't get any information regarding the sizing for the reporting side of SAP HANA. I am aware that this is quite a specific question, still, here's my bottle in the ocean !
For more context, a customer of mine is implementing FICO on HANA, and they have bought HANA live on top of that. They already had a reporting solution they wanted to keep so we have plugged Cognos on HANA live's views via JDBC. Usage wise, some FICO users, not all of them, will be using the views provided in the live package. Some extra users will be using the reporting even though they don't have any access to ECC. And yes, that comes with licences stuff to do.
I would like to be able to have an idea of the potential impact a heavy use of the database, for reporting purpose, might have on the ECC layer in order to recommend (or not) some extra power for the appliance. The testing we have done so far shows that surpringly enough the bottleneck is the network, and that the appliance is not suffering at all from a few users asking for data, even when the dataset that has to be fetched is large-ish (around 1millions line per users). Figures are as follow : 200 users for FICO, 80 for the reporting (including let's say 60 FICO users) on a 512 Go appliance from IBM (that can be extended to 1To).
Any input is more than welcome for helping figuring out a sizing method for the reporting side alone so that several scenarios (ECC+reporting 1, ECC+reporting2, etc...) can be evaluated.
Many thanks for your help,
Erich Schneider replied
all relevant notes and white papers w reagrds to sizing are maintained in this link:
scn.sap.cpm/docs/DOC-59920 as part of the Suite on HANA FAQ.
In General, you can run a sizing script on an existing data set in order to determine the memory size. In an OLAP heavy-use case it is also important to consider the ratio of number of cores to the memory size to provide enough computing power.