SAP HANA Sizing Essentials - A Quick Guide To HANA Sizing For License Calculation - SAP Blogs

3/31/23, 6:24 PM SAP HANA Sizing Essentials – A quick guide to HANA Sizing for license calculation | SAP Blogs
Community
Ask a Question Write a Blog Post Login
Technical Articles
Rilo Naumann
August 26, 2020 | 9 minute read
SAP HANA Sizing Essentials – A quick guide to HANA

Sizing for license calculation
 10  17  35,786
Follow
 Like 1. Overview and conciderations

A proper HANA Sizing is important for any customer who wants to switch to SAP HANA as platform to run the SAP
 RSS Feed Business Suite or SAP Business Warehouse. It is mandatory for calculating the SAP license for Enterprise Edition (in-
memory metric based) and it is as well important to assure the optimal performance of SAP HANA.
Whereas the SAP HANA memory requirement is most important for the license calculation there is also a sizing for CPU
cores, disk space and network load which are important for the expected performance of the HANA-System. In this article
https://blogs.sap.com/2020/08/26/sap-hana-sizing-essentials-a-quick-guide-to-hana-sizing-for-license-calculation/ 1/25
we concentrate on the HANA-in-momory sizing.
SAP HANA memory size is determined by the data footprint of the system which consists of two main areas:
1. Column store (contains the business data)

2. Row store (contains mainly meta data like data dictionary, some system tables)
The HANA memory is also used by other processes like
HANA caches
Operating System
Working Memory
A typical memory distribution of the HANA memory can look like this:
Typical HANA memory distribution
The following questions are important before doing the HANA-Sizing:
1. Does the customer already run SAP-Systems or non-SAP (Greenfield sizing)?

2. Does the customer want to convert ERP-Systems or BW-Systems?
3. If ERP, does the customer want to run Suite on HANA or S/4HANA?
4. If BW, does the customer want to run BW on HANA or BW/4HANA?
5. Does the customer want to convert his whole IT-Landscape (multiple ERP and/or BW-systems)? Is there potential for
System Landscape Optimisation?
2 Methods of HANA-Sizing

2.1 Quick-Sizer (Greenfield)

If a customer runs non-SAP systems the only way of Sizing the required Hardware for SAP HANA is the Quick-Sizer tool
(https://www.sap.com/about/benchmark/sizing.quick-sizer.html#quick-sizer).
This is more or less a questionnaire the customer has to provide online to achieve a rough estimate of the HW-
requirements. As SAP does not know the figures of data and tables in the non-SAP system it is the only way to estimate
the required memory.
You will find detailed information and hands-on for the Quick-sizer tool on the landing page above. Be aware that there are
different versions of Quicksizer available: QS classic, QS for HANA, QS for HANA Cloud and choose according to customer
needs.
Click here to access the HANA-version of Quick Sizer or navigate to www.sap.com/sizing and select Quick Sizer tab.
Quick-Sizer Questionaire
2.2 SAP HANA-sizing for ERP systems

If the customer runs SAP ERP systems on any DB and wants to change to SAP HANA the HANA-Sizing report (also known
as ABAP sizing report) is the tool to use. Detailed information and prerequisites are described in SAP note 1872170
See also: http://help.sap.com/disclaimer?site=https://service.sap.com/sap/support/notes/1872170
The procedure described in SAP note 187210 provides a SAP ABAP report to estimate the memory requirement for SAP
S/4HANA and SAP Suite on HANA. You have to set the required target in the starting page of the report parameter set.
The report ZNEWHDB_SIZE can be implemented in the customers namespace. It requires at least SAP_BASIS 620. It is
also available in ST-PI 2008_1, SP09 and ST-PI 740 SP00 and above under the name /SDF/HDB_SIZING. Both reports
have the same code and functionalities. The only difference is the installation procedure. The reports are suitable for sizing
of all Net-Weaver based products at the exception of BW.
At the end of SAP note 1872170 you will find an attachment FAQ_of_SAP_note_1872170 which is highly recommended to
read carefully before installing and using the Sizing Report.
You will also find detailed information on the installation and prerequisites of the Report how to set it up and run it.
Here we will focus on some common mistakes and questions that arise often when interpreting the results of the report.
Please note that the selection screen of the sizing report varies slightly depending on the system if it is already a SAP
HANA system or not. Set the
choice of HANA version to HANA 2.0
and set the
sizing scenario to Suite on HANA or S/4HANA
accordingly.
Selection parameters of Sizing Report
Please also consider the settings for Data aging estimations on technical objects, where you put in the residence time in
days (the default is 15 days, which might be too less for your needs) You can set it up to 365 for one year (max. is 999).
If a transition to S/4HANA is possible you have some other choices on the Sizing scenario:
Selecting the sizing scenario
After performing the sizing report don’t forget to watch for the error list at the end of the output. If errors occur the results
might not be reliable and the problems should be solved before re-running the report. The above mentioned FAQ
document will help you to solve the main error sources.
How to read and interpret the report

In the top part of the report you will find a short summary with the essential information regarding the HANA memory
requirement:
Sizing Result Main Table
The report shows if the calculated values are with respect to S/4HANA or Suite on HANA and reveals the following
information:
For the initial installation you need a HANA memory min. of 2.420 GB. If the customer is willing to do some initial data
cleansing on his data the estimation goes down to 1.340 GB (3. row). This estimation is derived on data aging information
(depending on the settings on the parameter screen) and the age of data in the tables incl. system tables like logging data,
workflow, idocs and so on. If the difference is more than 50% this indicates a lot of old data in the system and probably
lots of aggregated data in temporary system tables, logging e.g.
In this case it is recommended to do some elementary data cleanup and re-run the report.
The 2. and 4. row shows the requirement for disk space (initial and after data cleansing).
This information does not pay to the license calculation and can be omitted for that purpose.
The estimated memory size of business data is useful for a S/4HANA Cloud deployment, as it shows the pure value of
business data.
Following are some informations on the report version, the system evaluated, the SAP HANA version and some other
technical information.
Further on you have some detailed information about the sizing calculation ending up in an overview of the biggest tables
in the system and some data aging information. This information is only needed for an expert sizing, to find errors or
potential for optimization.
Interesting might be the section of detailed calculation for the data cleansing and reduction of memory due to S/4HANA
compression and data structure reduction:
Details of data cleansing calculation
You can see, that the initial data size is reduced from 1.170 GB to 626 GB due to S/4HANA data structure changes and to
data aging.
The result of 626 GB has do be doubled for the HANA work space and some caches and code stack. The result is the
HANA memory requirement after data cleanup (from above).
2.3 SAP HANA-sizing for BW systems

For a sizing of Business Warehouse systems you need to run another report according to SAP note 2296290.
(https://launchpad.support.sap.com/#/notes/2296290)
Please follow the instructions in this note and pay attention to the prerequisites: ST-PI 2008_1_700 SP 12, ST-PI
2008_1_710 SP 12, ST-PI 740 SP 2 mentioned.
As an attachement to the SAP note you will find the most recent version of a PDF document that describes the process of
installation, running and interpreting the report in more detail.
The new report HANA_BW_SIZING is applicable for “BW on HANA” as well as on “BW/4HANA scenarios as well.
As with the S/4HANA Sizing report there is also a selections screen for the BW sizing report:
Selection Page for BW sizing
If you want to do a sizing for BW/4HANA don’t forget to check this marker in the first part of the selection screen,
otherwise a BW on HANA sizing is performed.
In the document attached to the sap note you will find detailed information on each parameter of the selection screen and
how to use it.
Reading and interpreting the results of the BW sizing report

The interpretation of the BW sizing should be done by an expert as the values can be misinterpreted easily without a
technical background. There are several situations where the results can be misleading, esp. when the temporary data (in
the PSA e.g.) is very high. In this cases an elementary data housekeeping has to be performed on the BW-system and the
report has to be re-run.
Here we will focus on the most important parts of the report results.
In the first part you will find some general infos on the sizing result and its distribution to row and column store and typical
BW data types:
BW Sizing Result
If the size of Change log, PSA and others is high compared to the overall sizing amount, the temporary technical data has
a lot of influence in the overall sizing leading to possible wrong numbers. In case these values increase 60% you will see a
warning “Too much non-active data…” at the end of this section and a data housekeeping has to be performed for better
results.
The next parts shows the main results of the sizing “MEMEORY SIZING RESULTS”.
It is important to understand the meaning of the two columns at the right side. The first is a so called scale-out scenario,
the second is a scale-up scenario. In this example in the scale-out scenario you need at least 2 nodes for the BW-system
leading to little higher memory requirement as there will be overlapping data in the 2 nodes to run properly.
In the scale-up scenario on the right with 1536 GB of physical memory you only need one node to run the BW-system and
need little less overall memory in HANA.
So it is important to understand that these values are with respect to the desired HW architecture. For the licensing this
has to be taken into account. The best values you can achieve is with the scale-up scenario and as less nodes as possible
to reduce the amount of duplicate data (also system tables distributed to the nodes).
On the selection screen you can set the option of Future Growth Simulation to calculate the memory requirements for the
future. Consider the growth values carefully as they will add up each year of the simulation:
Data Growth simulation for 3 years
Here you can see the results for 3 years assuming a growth rate of 10%. The results are shown for each HW-scenario
discussed above.
3 Further improving the hana sizing

If the HANA sizing results seem too high to fit the customers needs or are exceeding his budget there are further steps
which can be considered for reducing the minimum HANA memory requirement.
If multiple ERP and BW systems are involved in the calculation you can consider doing a System Landscape
Optimisation (SLO) to reduce the total data footprint by merging systems together.
If the customer has a fair amount of “old data” you can consider doing an archiving project in front of the migration to
reduce the needs for HANA in-memory.
Do a general data cleansing and implement a corporate data quality project to get rid of duplicate or outdated data.
The most elegant way (esp. for BW-systems) is to use multiple temperature data tiering to assure only the most recent
and important data is kept in memory whereas warm and cold data is stored externally.
Most promising results will be achieved by combining all methods together but will also lead to the most effort and
expensive pre-project. SAP offers many helpful tools with respect to data quality and data archiving and you will find more
information in this blog: https://blogs.sap.com/2019/11/19/sap-datenbereinigung-und-migration-nach-sap-s-4hana/
Whereas the last proposition seems to be the most elegant, the options for the ERP side are quite limited for now. For BW
there are solutions for each temperature region (i.e. hot, warm and cold data) but for ERP this is limited to hot and cold
data only, and cold data here means archiving. There are technologies available for warm data storage in ERP but they are
not yet implemented (HANA native storage extensions, NSE).
You can find further information of multi-temperature data tiering here:
SAP BW/4HANA Data Tiering Optimization
Help Portal: Data Tiering Optimization (DTO)
SAP Note: 2416490 – FAQ: SAP HANA Data Aging in SAP S/4HANA
SAP JAM: Dynamic Tiering for S/4HANA roadmap
Beside the SAP HANA sizing report you can also use the SAP Readiness Check for S/4HANA and BW/4 HANA Systems to
get a deeper look into the data aging structure of you database SAP Landing Page for S/4HANA Readiness Check
Here you will find additional information on how to use the SAP S/4HANA Readiness Check:
SAP S/4HANA Readiness Check
Alert Moderator
Assigned Tags
SAP HANA
SAP S/4HANA
BW on HANA sizing
BW/4HANA sizing
S/4HANA sizing
SAP ABAP sizing
SAP HANA Sizing
View more... 
Similar Blog Posts 

Applying the Right Sizing Method and Using the Right Sizing Tool
By Sebastian Schmitt Mar 04, 2021
Sizing SAP HANA - by the SAP HANA Academy

By Denys van Kempen Sep 09, 2014
SAP HANA Sizing

By Sushil Aher Jan 17, 2013
Related Questions 
HANA - Post Go-live sizing
By Daniel basis Dec 15, 2020
HANA Sizening for MS SQL Server

By Former Member Jan 17, 2018
quick sizer tool - statistics - help needed

By jennegolla nagaraju Mar 19, 2015
10 Comments
You must be Logged on to comment or reply to a post.
Harika V
August 26, 2020 at 2:03 pm
This is one of the best and the most detailed article I’ve come across for sizing ! Great work
Like 2 | Share
Rilo Naumann | Blog Post Author

August 26, 2020 at 2:19 pm
Thank you so much!
Like 0 | Share
Arif Shaikh
August 26, 2020 at 3:49 pm
Simplified but detailed content. Good one Rilo Naumann

Very Helpful
Like 0 | Share
Taranam Dhindsa
August 27, 2020 at 7:07 am
Well explained . Thank you
Like 0 | Share
Clement Mugner
September 11, 2020 at 8:53 am
Hi Rilo, nice thread. Thanks.
I think it would be interesting to mention that the sizing gives you the size of the memory that HANA requires but that is not equal to the size of the
Hardware you need to order. Because you need to add some memory for the OS (around 5% of physical RAM).
This is valid for the 3 methods (QS and Sizing reports)
Finally for the disk sizing, i would point to this document as necessary follow up once the memory sizing is clear:
http://go.sap.com/documents/2015/03/74cdb554-5a7c-0010-82c7-eda71af511fa.html
Like 0 | Share
Jas Park
January 11, 2021 at 12:51 pm
This is excellent!
Thank you.
Like 0 | Share
AMIT Lal
April 27, 2021 at 12:49 am
Hi Rilo,
Nice blog! Could you please elaborate more on -

"The estimated memory size of business data is useful for a S/4HANA Cloud deployment, as it shows the pure value of business data" When you say
S/4HANA Cloud it means SAP Cloud Edition? How's this calculation runs. Can an on-premise system adopt this number to build?
Like 0 | Share

June 8, 2021 at 10:24 am
Hi Amit,
the cloud deployment can be public cloud or private cloud. No matter the sizing will be the same in general. You also start the sizing report
as usual from an onpremise system - there is not difference.
Like 0 | Share
Patricia Rolón
June 8, 2021 at 9:35 am
Excelent blog!
I have a question: If I run the database reorganization done before running the sizing report can I expect better results from the report?
Like 0 | Share

June 8, 2021 at 10:27 am
Hi Patricia,
yes, the sizing results might be slightly better (meaning less memory needed). It is important to do a data volume management (data quality and
archiving) to maintain best data quality and assure that only really needed and actual data will move into SAP HANA. You dont want old or outdated
data in your HANA database. Also dont forget to clean up the technical data like logging data and usage data (change logs, documentation e.g.) - this
can help a lot in means of HANA DB size.
Like 0 | Share
Find us on
Privacy Terms of Use
Legal Disclosure Copyright
Trademark Cookie Preferences
Newsletter Support

SAP HANA Sizing Essentials - A Quick Guide To HANA Sizing For License Calculation - SAP Blogs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP HANA Sizing Essentials - A Quick Guide To HANA Sizing For License Calculation - SAP Blogs

Uploaded by

Copyright:

Available Formats

3/31/23, 6:24 PM SAP HANA Sizing Essentials – A quick guide to HANA Sizing for license calculation | SAP Blogs

Ask a Question Write a Blog Post Login

SAP HANA Sizing Essentials – A quick guide to HANA

 Like 1. Overview and conciderations

we concentrate on the HANA-in-momory sizing.

1. Column store (contains the business data)

The HANA memory is also used by other processes like

Typical HANA memory distribution

The following questions are important before doing the HANA-Sizing:

1. Does the customer already run SAP-Systems or non-SAP (Greenfield sizing)?

2 Methods of HANA-Sizing

2.1 Quick-Sizer (Greenfield)

2.2 SAP HANA-sizing for ERP systems

See also: http://help.sap.com/disclaimer?site=https://service.sap.com/sap/support/notes/1872170

choice of HANA version to HANA 2.0

and set the

sizing scenario to Suite on HANA or S/4HANA

Selection parameters of Sizing Report

Selecting the sizing scenario

How to read and interpret the report

Sizing Result Main Table

Details of data cleansing calculation

2.3 SAP HANA-sizing for BW systems

Selection Page for BW sizing

Reading and interpreting the results of the BW sizing report

Data Growth simulation for 3 years

3 Further improving the hana sizing

You can find further information of multi-temperature data tiering here:

SAP BW/4HANA Data Tiering Optimization

Help Portal: Data Tiering Optimization (DTO)

SAP JAM: Dynamic Tiering for S/4HANA roadmap

SAP S/4HANA Readiness Check

SAP ABAP sizing

SAP HANA Sizing

Similar Blog Posts 

Sizing SAP HANA - by the SAP HANA Academy

SAP HANA Sizing

HANA Sizening for MS SQL Server

quick sizer tool - statistics - help needed

You must be Logged on to comment or reply to a post.

Rilo Naumann | Blog Post Author

Thank you so much!

Simplified but detailed content. Good one Rilo Naumann

Well explained . Thank you

Hi Rilo, nice thread. Thanks.

This is valid for the 3 methods (QS and Sizing reports)

Nice blog! Could you please elaborate more on -

Rilo Naumann | Blog Post Author

Rilo Naumann | Blog Post Author

Privacy Terms of Use

Legal Disclosure Copyright

Trademark Cookie Preferences

You might also like