- While traditional sizing approaches focus on CPU performance, the main driver for SAP HANA sizing is memory. Because SAP HANA is a main memory database, essentially all business data (e.g., master and transactional data) resides in the main memory, which leads to a higher memory footprint compared to traditional databases.
- The bash and sudo packages must be installed. Sudo must be version 1.7.6p2 or above. Run sudo -V to check the version. Python version 2.6.x or 2.7.x must be installed. RHEL/OEL/CentOS 6.x only: Ensure the util-linux-ng package is up-to-date by running yum update util-linux-ng.
- Sap Hana Max Database Size
- Hana Db Swap Size
- Sap Hana Database Size
- Hana Database Size Query
- Hana Database Size Calculator
- Hana Database Size
After a database crash, a sap hana tenant database can rollback to a consistent point in time, out of elements and data stored on disk. Monitoring data size on disk is important for several reasons. First hard disk memory space maintenance has to be done or host server may come across space shortage at some stage.
It is vital to size your SAP HANA hardware correctly to realize the maximum benefit from your investment and reduce your long-term total cost of ownership. Inadequate and over-provisioned sizing of SAP HANA could lead excess capacity and bloated hardware while under-provisioning can cause unexpected delays which will increase the cost of operational performance.
For the most part, sizing of SAP HANA database is based on the main memory which is determined by the amount of the actual data stored in memory. Since the data is compressed in HANA and the compression results depends on the used scenario, it is not easy to guess the amount of memory needed for sure. Therefore, the memory sizing for SAP HANA should be performed using SAP Quick Sizer tool, relevant SAP notes and SAP sizing reports.
Depending on the SAP HANA deployment, sizing approach would be different.
SAP Quick Sizer
For SAP HANA greenfield implementations, it is necessary to size the memory using the SAP Quick Sizer tool. The Quick Sizer calculates CPU, disk, memory and I/O resources based on the throughput numbers and can help you translate business requirements into technical requirements. For greenfield sizing, complete the following steps:
- Access the Quick Sizer tool (SAP HANA version)
- Create a sizing project – input your customer scenario data into Quick Sizer and it will display the results.
- Check for sample configurations and find the appropriate hardware configurations on SAP Standard Application Benchmark: http://www.sap.com/solution/benchmark.html
- Provide the project name to your hardware vendor and they will be able to propose an appropriate hardware configuration.
- If you are unable to find the right sizing for your SAP product in the Quick Sizer tool, consult the sizing guidelines and SAP notes (details below)
Simply fill the online questionnaire based on business-oriented figures and the results you obtain can help you select an economically balanced system that matches your company’s business goals. This is especially useful for initial budget planning.
Sizing BW on HANA
For systems that are migrated to SAP HANA, if the migration is from an SAP NetWeaver based system, use the sizing reports provided by SAP:
For BW on HANA migrations, use the following SAP notes:
- SAP Note 1637145 – SAP BW on HANA: Sizing SAP In-Memory Database
- SAP Note 1736976 – Sizing Report for BW on HANA
These two SAP notes explain the sizing approach of SAP BW system on SAP HANA including the sizing report and guidelines. The sizing here includes the memory sizing (column, row store and additional components) and disk sizing for data and log files. Note that the report could run up to 8-12 hrs depending on your system so it would be better to run it on a non-Production system first.
Below figure shows an example sizing report result for SAP BW on SAP HANA memory:
Sizing Suite on HANA, S/4HANA
For Suite on HANA migrations, use the following SAP notes:
- SAP Note 1793345 – Sizing for SAP Suite on HANA
- SAP Note 1872170 – Business Suite on HANA and S/4HANA sizing report
These two SAP notes describe the approach for Business Suite system on SAP HANA and SAP S/4 HANA. There is also a sizing script and guideline attached to these notes. See below for an example sizing report for Suite on SAP HANA memory:
After getting the memory sizing results via sizing reports described in the above SAP notes, check SAP HANA Hardware directory for hardware that matches your memory sizing results. For now, you don’t need to worry about storage and CPU sizing as they are already included in the certified SAP HANA appliances.
Sizing SAP HANA for non-NetWeaver approach
If the migration is from a non-SAP NetWeaver data source, you can use the approach described in SAP Note 1514966 – SAP HANA 1.0: Sizing SAP In-Memory Database. This SAP note explains the sizing of SAP HANA in a non-NetWeaver scenario, for instance, if the data is coming from an external source for SAP HANA to process and analyse. These sizing rules should not be used for sizing SAP BW or SAP Suite on HANA or SAP S/4HANA sizing.
General sizing approach for SAP HANA (for the non-NetWeaver approach) is basically determining static and dynamic memory requirements. The static memory requirement is related to the amount of main memory that is used for holding the table data which is the amount of disk space covered by the corresponding database tables (indexes not included). It is required to calculate the uncompressed data volume that is to be loaded into HANA using the tools attached to SAP Note 1514966 and apply the compression factor from the attachments to the sizing notes.
Additional memory is required also for objects that are created dynamically when new data is created or queries executed. Simply multiply static memory requirement by two as it is recommended by SAP to size dynamic memory same as static memory.
Sizing SAP HANA for Tailored Data Center Integration (TDI)
If you are planning to build SAP HANA system based on SAP HANA TDI (Tailored Data Center Integration) approach by using the available hardware or to reuse existing hardware to reduce hardware cost, you must become TDI certified and meet SAP HANA storage requirements. TDI follows the approach of SAP sizing and mapping to authorized servers, network and storage.
Sizing SAP HANA TDI consists of three main steps:
- Memory sizing for static and dynamic data
- Disk sizing for persistence storage
- CPU sizing for transactions, queries and calculations
As the first step to sizing SAP HANA TDI system, you should perform a memory sizing. Depending on the use case, you can use SAP Quick Sizer and/or above SAP notes for sizing Suite/BW on HANA. IBM also provides a process to support mapping of the SAP sizing to a hardware configuration that would meet your sizing demands. For more information, see SAP Note 2055470 and 2188482.
See below for more details about Disk and CPU sizing.
Disk Sizing
Persistent storage distinguishes between the data volume and log volume. In the data volume, basically a copy of the in-memory data persists and changed data is written to the data volume. The log volume is required to ensure the recovery of the database with zero data loss in case of a failure, so each transaction in SAP HANA is recorded as a redo log entry.
The recommended size of a data volume is equal to the calculated results from the sizing reports. Use value “Net data size on disk” and an additional free space of 20%. The figure shows an example sizing report result:
As you can see the sizing report, net data size on disk is calculated around 1.3TB. In this case, our minimum requirement for “data” volume would be around 1.6TB, considering the additional 20% free space.
During the migration of non-HANA DB to SAP HANA, the system may require a little more space than the actual calculated net data size on disk, but with enterprise storage, that is not considered relevant for the overall storage sizing
The minimum size of log volume depends on the number of data changes occurring between two SAP HANA savepoints which is by default created every five minutes. More data changes happening during this time means more redo logs are generated in the log area. When sizing the log volume, you need to consider following points:
The redo logs must not be overwritten before a savepoint entry is available in data volume. This might cause SAP HANA system unable to restart. During the migration process, a very high workload needs to be processed, so it would be better to allocate extra disk space for the log volume in case of regular redo log backups fail for some reason during the migration.
The result of memory sizing usually determines sizing of the log area. If the total memory requirement is less than 512GB, log area should be at least half of the total memory requirement. If your system requires more than 512GB memory, you should at least allocate 512GB (preferably a little more) for the log area.
For single-node SAP HANA installations, the recommended disk size requirements for /hana/shared/<SID> is same as the total memory required:
For scale-out SAP HANA installations, the recommended disk size requirements for /hana/shared/<SID> depends on the number of worker nodes. Per each worker node of a scale-out system, a disk space of 1xRAM per 4 worked nodes required.
For example;
3+1 system, 512GB per node, total disk size = 1x512GB = 512GB
4+1 system, 512GB per node, total disk size = 1x512GB = 512GB
5+1 system, 512GB per node, total disk size = 2x512GB = 1TB
The size required for backup directory depends on your backup policy and backup frequency, but it must be larger than total size of data and log area.
CPU sizing
CPU requirements for migrating to SAP HANA standalone system are difficult to anticipate as we have no real references against which to compare. Therefore, the sizing refers to the following formula:
- 300 SAPS per active user by 65% for a CPU utilization buffer
An active user that consumes CPU at a given point of time. In sizing, it is usually overestimated the overlapping activity patterns of the end users. Some end users may also perform more or less intensive calculations on DB level. Consider this recommendation as an initial estimation that needs verification, the more users on the system the less likely the above formula would be accurate. SAP HANA servers with two sockets, for example, can deliver around 60000 SAPS. If you want to verify the CPU requirements, a test with the top 10 SAP HANA transactions could be really helpful either with a single user test or load test.
Now you should be able to describe the sizing of memory, persistence and CPU and what needs to be taken into consideration for sizing an SAP HANA server. Go ahead and run the SAP Quick Sizer, give it a try 🙂
Have any questions about sizing SAP HANA? Leave a comment below.
References and further reading:
Sap Hana Max Database Size
SAP Note 1514966 – SAP HANA 1.0: Sizing SAP In-Memory Database
SAP Note 1793345 – Sizing for SAP Suite on HANA
Hana Db Swap Size
SAP Note 1872170 – Business Suite on HANA and S/4HANA sizing report
SAP Note 1637145 – SAP BW on HANA: Sizing SAP In-Memory Database
SAP Note 1736976 – Sizing Report for BW on HANA
SAP Note 2055470 – HANA on POWER Planning and Installation Specifics – Central Note
SAP Note 2188482 – SAP HANA on IBM Power Systems: Allowed Hardware
If you liked this post, you might like these relevant posts:
Feel free to share.
How much space do I need in a SAP ERP powered by HANA environment compared to a ERP on a traditional RDBMS environment?
In general a customer could expect a compression factor of 3 to 5 based on the customer results, although this can of course vary in every case.
In order to maximize the potential of the HANA in-Memory processing SAP recommends to double the size of the Hardware memory based on the size of the compressed data volume.
Please see this SAP Note for general recommendations for Suite on HANA sizing:
For the migration of existing Suite on HANA systems, SAP provides an ABAP report which estimates the memory space requirement based on the size of the current database tables (LiveCache is currently not supported). The ABAP report takes into account de-clustering, de-pooling, LOB's ((Large OBject) datatypes) and indexing. The report also allows a filter setting to select individual tables for example for a selective SAP HANA Live sizing for example just for FI or SD in a side car scenario.
Please see this SAP note for script to run the sizing report on SoH. In the attachment of the note is a comprehensive FAQ.
For the initial sizing of new implementations and for new customers, please use the SAP HANA Quick Sizer
If you want to use the SAP HANA data mart features, please see this SAP Note for SAP HANA data mart sizing script:
Sap Hana Database Size
For a sidecar scenario: SAP LT sizing guide
What is the impact on the database size when converting a non-Unicode compliant DB to a Unicode compliant DB as prerequisite for migrating ERP to ERP on HANA?
Hana Database Size Query
Migration to HANA is only possible from a Unicode system, and the sizing script in http://Service.sap.com/sap/support/notes/1872170 will consider if the source databse is already Unicode enabled or not.
If you use this note, there is no need to apply an additional factor to the result of the report. The result provided is taking in account the Unicode
conversion.
Other useful sizing notes:
- SAP Note 1698281 - Assess the memory consumption of a SAP HANA System
- SAP Note 1661202 – Support for multiple applications on SAP HANA
- SAP Note 1666670 – Multiple SAP HANA DBs on one appliance
- SAP Note 1788665 - SAP HANA running on VMware vSphere VMs
Overview of all available sizing documentation:
Hana Database Size Calculator
Service Marketplace: http://service.sap.com/sizing
What are the biggest SAP HANA hardware configurations available?
Please see the Certified SAP HANA Hardware Directory for details and up-to-date information
Hana Database Size
In addition to the listed HW configurations, SAP will also certify additional configurations as required by customer scenarios. Please check with your hardware vendors and SAP Account Executive in case you are interested in any other configuration than listed in this SAP HANA Hardware directory:
The speed of development of HANA hardware is impressive, considering that in 2010 the biggest In-Memory hardware available was 2TB of memory with 512GB per node. At SAPPHIRE 2012, hardware partners presented a 16 node HANA system with 16TB Memory with 1TB per node. At TechEd 2014, SGI Silicon Graphics presented a 6TB single node system.
SAP showcasedin 2012 a custom SAP HANA system with 1 PetaByte of raw data:
From which hardware vendors are HANA systems available?
Please see for latest information: Certified SAP HANA Hardware Directory