sizing in hana

8/11/2019 Sizing in HANA

1/7

Over the past couple years I have been involved in many sizing activities for BW on HANA. I

have collected some valuable lessons learned. This should help you understand better whatcommon mistakes to avoid and how the sizing works in more detail.

Note: This blog is specifically for sizing existing BW systems. For sizing brand new installations,we recommend using SAP QuickSizer (http://service.sap.com/quicksizer). Also if you are

planning to run multiple applications on a single SAP HANA database (in addition to BW), you

have to size these applications independently and added them together.

The following is based on an actual customer case. The customer says their BW system is 6.1 TB.

Quick, takes a guess of how big the SAP HANA appliance needs to be.... Well, I hope you gavethe proper "consulting answer" that you need more details. But let's see if you would have taken

all of the following into consideration.

1) Do not count log and free space

In this case we were dealing with BW running on a Microsoft SQL server database. The 6.1 TB

was actually the total size of the data and log files. Ha! Beginner mistake. Clearly only data files

excluding the free space are relevant for HANA sizing (=allocated space). I'm sure everyone got

that right.


2/7

2) Do not count indexes

Next we look at the allocated space. Much of it is taken up by database indexes and some

database-specific administration data. We are really interested in the pure database tables only.In our case study, over half of the allocated space was indexes! HANA persists data differently,

so we disregard all indexes.

3) Do not count aggregates

BW on HANA does not need aggregates. All related menu items have been removed andaggregate functionality is disabled since SAP HANA can aggregate billions of records on the

fly.

4) Do not calculate with size of compressed data

We are down significantly from the original 6.1 TB but here's a surprise... The MS-SQL database

was compressed already. We need the uncompressed data into consideration. However, we needto do it right. Don't rely on any compression factors provided by the database. It's hard to

understand how these were calculated. They are irrelevant anyway since SAP HANAcompresses differently.


3/7

Here's an example, you have a table with char(100) field and 1 million records. Some might saythat's 100 million bytes of uncompressed data. But this again is not enough information to

determine the size of the table in HANA. It matters what data is actually stored in the table! If a

record contains "ABC", we need 3 bytes and not 100. Ergo, what you really need to do is look atall the data in the table.

Reading the complete database would be rather time consuming so we take some shortcuts: Wesample only a small subset of the records and extrapolate the results. And we can exclude

reading fields that have a fixed size like INT4. In the example, we select a sample of 100,000

records and determine an average field length of 10. This gives us an uncompressed, raw datasize of 10 million bytes.

Your system is not on Unicode yet? Typically, there's not much textual information stored inBW (this will certainly change over the coming years) so you need to apply an uplift of about 5%

(based on experience).

If we follow this process for all tables, we get about 3.2 TB of uncompressed data that will needto fit into our SAP HANA database. Grouped into the usual BW categories, it looks like this:


4/7

5) Do not apply the same compression factor to all tables

Sure, HANA does some incredible compression of data but it's not the same for each type oftable. For example, InfoCube fact tables contain integer values only (pointers to dimensions or

master data) and we usually find only few unique values per column. These will therefore

compress very well. We assume factor 7 based on experience with other customer systems.

For master data tables, the opposite is true. Mostly all values in a column are different (not so

much for attributes of master data of course). Overall, we will get little compression (1-2x).

6) Do not assume the complete table must be in memory

We also have to take into consideration that many tables are partitioned by default in BW on

HANA and only the used partitions will be loaded into memory. Best example are PSA tables

which are partitioned by request id. BW usually works only with the most recent requests andtherefore much of the PSA table will not be loaded. This is the default behavior for PSA tables

and write-optimized DataStore Objects.

Optionally, we can apply the "non-active" data logic to other InfoProviders as well (if you

configure BW accordingly).

The result in our case study: We end up with approximately 925 GB of memory once the data is

compressed inside HANA.


5/7


6/7

In our case study, the result was either 5x 512 GB nodes or 3x 1 TB nodes.

9) Do not forget to size the master node properly

As mentioned above, the master node will contain certain tables as a default configuration.

Therefore you have to make sure that these tables will fit into the given size of the master node...including future growth of these tables. If you follow best practices for housekeeping in BW, thisis not a problem at all. However, if you are a bit lax on housekeeping, you might run into the

restriction of the master node.

For a one time clean up and frequent housekeeping for row store tables, please see SAP Note

706478.

The most common areas for BW customers are:

BW request archiving

Application log deletion Archiving Idocs

Additional details on sizing the master node, see SAP Note 1855041.


7/7

10) Do not ignore means for system size reduction

So far we assumed that the complete system is migrated as is. However, there are things to

consider that will reduce the over size of your system significantly:

Removal of complete data layers, for example reporting off DSO instead of an InfoCubewith the same or just aggregated data

More aggressive housekeeping of PSA, change log, and DTP error stacks

Usage of near-line storage solution (NLS)

Revisit data retention strategy and archiving

For more details see "Optimization of Data Retention".

Finally...

Now you know how to avoid these pitfalls. Did you get them all? Of course it would be

extremely cumbersome and time consuming to calculate all of this by hand. But here's the bestnews: We have a program available that fully automates the complete sizing calculation!

For the one and only way to size a BW system properly for SAP HANA, please see SAP Note

1736976 and its attachments.

sizing in hana

Documents