Master Guide to SAP HANA Sizing - Part 1

What do you mean by Sizing?
Sizing is a standard term in SAP, which means determining the hardware requirements of an SAP System such as physical memory, CPU power, and I/O capacity.
Determining sizing requirement ensures that customers purchase hardware as per their business need and also ensures lower cost and reduce TCO.

Sizing in SAP HANA:
The critical factor for SAP HANA implementation is the right sizing of the server based on the business requirement and this means correct calculation of amount of memory, the CPU processing power.
SAP HANA sizing consists of Memory sizing for static data, Memory sizing of objects created during runtime (data load and query execution), Disk Sizing and CPU Sizing.

For the purpose of successful SAP HANA implementation, SAP has provided various guidelines and methods to calculate the correct hardware size.
We can use any of the below method:
1. SAP HANA sizing using the QuickSizer tool
2. SAP HANA sizing using the DB specific scripts
3. SAP HANA sizing using the ABAP report

Later on we will learn more about these sizing methods.

Product Availability Matrix (PAM):
All available SAP certified HANA hardware configurations can be looked up in the HANA PAM (Product Availability Matrix). In addition SAP also certifies additional configurations as required by customer scenarios. You should check with your hardware vendors and SAP Account Executive in case you are interested in any other configuration than listed in the HANA PAM.
Product Availability Matrix(PAM).

Selecting a T-shirt size:
According to the sizing results, select a SAP HANA T-shirt size that satisfies the sizing requirements in terms of main memory, and possibly CPU capabilities. For example, a sizing result of 400 GB for the main memory (C) suggests a T-shirt size of M.

Check this article to learn more about SAP HANA T-shirt - SAP HANA T-Shirt Size - Which Size Fits Your Requirements

Key Performance Indicators for SAP HANA Sizing:
Sizing of the SAP HANA appliance is mainly based on the required main memory size. Memory sizing is determined by the amount of data that is to be stored in memory. In general the sizing of other components within the server is derived from the main memory size. Apart from main memory sizing, other 2 important part of sizing is Disk Sizing and CPU Sizing.

The three main KPIs used to size for SAP HANA is

  • Main memory (RAM) space,
  • CPU processing performance
  • Disk size.

The RAM size is the basic figure to find the necessary T-shirt size.


Note-1: Data is compressed in SAP HANA. Since the expected compression factor is not the same for different scenarios, the main memory size is evaluated depending on the scenario.

SAP HANA Main Memory Sizing:
SAP HANA Main Memory Sizing is divided into static and the dynamic RAM requirement.

Static RAM Requirement:
The static RAM requirements relates to the amount of main memory that is used for the holding the table data. 
Static memory sizing of HANA is determined by the amount of data that is to be stored in memory.

Dynamic RAM Requirement:
Additional main memory is required for objects that are created dynamically when new data is loaded or queries are executed. Since SAP recommends reserving as much memory for dynamic objects as for static ones, for calculating the total RAM the static RAM is multiplied by two.


Steps to Calculate RAM Size:

1.Calculate Uncompressed Data Volume to be loaded in HANA -  Source Data Footprint:
Determine the information that has to be transferred (either by replication or extraction) to the SAP HANA database. Note that typically customers will only select a sub-set of information from their ERP or CRM database, so this has to be done at the table level.

The sizing methodology is based on uncompressed source data size, so in case compression is used in the source database, this has to be taken into account as well.

The information required for this step can be acquired with database tools. SAP Note 1514966 contains a script supporting this process for several database systems, for example, DB2 LUW and Oracle.

The current size of all the tables (without DB indexes) storing the required information in the source database is called Source Data Footprint.

2.Compression Factor in HANA
In HANA as a side-by-side scenario, the expected compression was 1:5. Through new compression mechanisms the compression ratio increased to 1:7.
There are, however, also significantly higher values, so customers are circulating examples where a factor has been achieved of over 1:50
The compression ratio achieved by SAP HANA can vary depending on the data distribution.

3.Calculation of Static RAM Size
Static RAM Size means the amount of RAM required to store the data in the SAP HANA database.
Assuming the compression factor as 7:



4.Calculation of Dynamic RAM Size
Dynamic RAM is for additional main memory required for objects that are created dynamically when new data is loaded or queries are executed. SAP recommends to keep Dynamic RAM size same as Static RAM size.


5.Calculation of Total RAM Size


The total amount of RAM should be rounded up to the next T-shirt configuration size. For example, if total RAM size is 400 GB, then T-shirt size of M should be selected.

SAP Notes on Sizing:
Since compression factor and other hardware requirements are dependent on the scenario, there are different sizing rules and SAP notes.

General Sizing (SAP Note 1514966): This describes the sizing of the SAP HANA as it is used e.g. for replication of ERP data coming from an ERP system. In particular, these rules must not be used for sizing BW on HANA and Business Suite on HANA systems.

Sizing for BW on HANA (SAP Notes 1736976 and 1637145): In the SAP Notes listed above a detailed description of the sizing of the various components is included. Besides, there is a sizing script available that supports sizing for a migration.

Sizing for Suite on HANA (SAP Note 1872170): The corresponding SAP Note describes how to implements a report to estimate the memory space requirement for the database tables of Suite on HANA systems.

Non-active data concept for BW on HANA (SAP Note 1767880) and Nearline Storage Solutions: Large BW systems contain large amounts of data that are no longer or rarely actively used but that should remain in the system (historical data, keeping data for legal reasons, and so on). This data is called non-active data. An implementation for BW on HANA allows to displace non-active data in case of main memory bottenecks leveraging a last-recently-used concept. This concept improves main memory resource management, which has positive effects on hardware sizing for a large amount of non-active data. For more information about this, see also SAP Note 1736976. Besides, nearline storage solutions could be used to store “cold data”, which can additionally help to reduce the memory amount.

SAP HANA Smart Data Access (SAP Note 1879294): SAP HANA smart data access enables remote data to be accessed as if it was stored in local tables. Since the data is not copied to SAP HANA, it does not need to be considered for the main memory sizing of the SAP HANA server.


Disk Sizing:

SAP HANA is an in-memory database. But it still requires disk storage space — to preserve database information if the system shuts down, either intentionally or due to a power loss, for instance.

Disk sizing can be categorized into
  • Persistence Layer (also called Data Volume)
  • Disk Log (also called Log Volume)
Persistence Layer (Data Volume): Data changes in the database are periodically copied to disk to ensure a full image of the business data on disk in Data Volume (Persistence Layer).

The capacity for this storage is calculated based on the total amount of RAM:


Disk Log (Log Volume): Log Volume saves log files to ensure that changes are durable and the database can be restored to the last committed state after a restart.
The minimum size for the Log Volume is equal to the size of the SAP HANA server‘s main memory.


Note that the certified hardware configurations already take these rules into account, so there is no need to perform this disk sizing. However, we still include it here for your understanding.


CPU Sizing:

A CPU sizing only has to be performed in addition to the memory sizing if a massive amount of users working on a relatively small amount of data is expected. Choose the T-shirt configuration size that satisfies both the memory and CPU requirements.

The CPU sizing is user-based. The SAP HANA system has to support 300 SAPS for each concurrently active user. The servers used for the IBM Systems Solution for SAP HANA support about 60 - 65 concurrently active users per CPU, depending on the server model.


What is SAPS? 
The SAP Application Performance Standard, known as SAPS is a unit of measurement that describes the performance (throughput result) of a SAP system configuration.
It is defined as:
      2,000 fully processed order line items per hour = 100 SAPS

To know more about SAPS, refer to the following links:

Note: That the CPU sizing has to be adjusted so that the server load does not exceed 65% in average (i.e. to obtain the maximum number of users per server, the absolute server SAPS capacity has to be multiplied by .65).

No comments:

Post a Comment