Performing SAP HANA Sizing

Objective

After completing this lesson, you will be able to perform SAP HANA sizing

General Concept of Sizing SAP HANA

Business Example

Your company has decided that all SAP Business Suite and SAP BW systems will be migrated to the SAP HANA database. It is your task to investigate what is the best method to deploy the SAP HANA database systems, that is, to deploy as an SAP HANA appliance or to deploy following the SAP HANA tailored data center integration (TDI) approach.

Sizing of the SAP HANA database revolves mainly around the main memory size. The required memory to hold the dataset base in memory is determined from the size of the source database.

SAP HANA compresses the data stored in memory. The compression rate depends on the used scenario, so you cannot estimate the amount of memory needed. A memory sizing must always be performed using the Quick Sizer for SAP HANA, or the SAP HANA sizing reports and SAP Notes.

Hint

If you are interested in how SAP HANA compression works, see SAP Note 2112604: FAQ – SAP HANA Compression.

Based on this memory value, you can choose a hardware configuration. The SAP HANA database system can be deployed as an SAP HANA tailored data center integration (TDI) or as an SAP HANA appliance setup. In both cases, you can choose a fitting hardware from the catalog of certified hardware.

Note

The following information refers solely to the sizing of the SAP HANA database server. Depending on the scenario, the sizing of other components, such as the SAP ABAP application server(s), must be considered separately.

When sizing an SAP HANA database, the sizing approach depends on the implementation scenario used by the customer. The possible sizing approaches are as follows:

  • Customers new to SAP applications and SAP HANA can use the Quick Sizer to size the required memory for an SAP HANA system. This method can also be used for existing SAP customers who want to perform a greenfield implementation.
  • Customers who want to migrate their existing SAP NetWeaver based systems to run on SAP HANA can execute a sizing report, which calculates the required memory. For non-SAP NetWeaver based systems, you use the sizing method described in SAP Note 1514966.
  • Any system that is large or complex requires sizing from an SAP sizing expert.

An SAP expert sizing is required in the following scenarios:

  • Consolidating multiple ERP source systems into one ERP system on SAP HANA.
  • Carving out ERP functionality from the source system to the ERP on SAP HANA system.
  • Migrating a high-volume legacy system to SAP HANA.

Overview of SAP HANA Tailored Data Center Integration (TDI)

Appliance vs TDI

In an SAP HANA on-premise deployment, SAP HANA runs on dedicated hardware. The on-premise SAP HANA is deployed through the following offerings:

  • SAP HANA appliance combines SAP HANA software components on proven hardware provided by hardware partners. This approach is valid for Intel-based hardware platforms only. While this approach is simple, it has limitations for hardware flexibility and compliance with existing IT operation processes. Therefore, SAP HANA tailored data center integration is offered as a new option to provide customers with greater flexibility.

  • SAP HANA tailored data center integration (TDI) provides the customer with more flexibility regarding the hardware components required to run SAP HANA in the data center. Leveraging this approach, customers will have the following benefits:

    • Reduce hardware and operational costs by reusing existing hardware components and operation processes
    • Mitigate risks and optimize time-to-value by enabling existing IT management processes for SAP HANA implementations
    • Have more flexibility in hardware vendor selection by leveraging the existing ecosystem

In short, SAP HANA tailored data center integration helps you to stay within your IT budget, shortens implementation cycles, and allows better consumption of hardware innovations to drive the adoption of SAP HANA.

SAP does not offer any formal certification of a given SAP HANA tailored data center integration infrastructure. Instead, SAP certifies hardware components together with its SAP HANA hardware partners, and requires customers to only use these certified configurations for SAP HANA tailored data center integration.

Use the official SAP HANA Hardware Directory to verify that your compute nodes and storage systems are listed there with the exact same bill of material as the compute servers of certified SAP HANA appliances but without storage.

The installation of SAP HANA needs to be performed by a person who possesses a valid SAP Certified Associate - Database Administrator - SAP HANA (C_DBADM_2404) or newer.

SAP HANA hardware partners and their employees do not need this certificate. However, companies, or their employees, who are sub-contractors of SAP HANA hardware partners must be certified to perform HANA software installations.

Note

IBM provides a process to support mapping of the SAP sizing to a hardware or partition configuration that meets the sizing needs of the customer. For more information, see SAP Note 2055470: SAP HANA on POWER Planning and Installation Specifics – Central Note.

Tailored data center integration can reduce hardware and operations cost by reusing existing hardware components and processes.

Note

Tailored data center integrations offer freedom and flexibility, which also leads to the customer’s increased responsibility for the system, ranging from the installation up to running the landscape.

SAP HANA Tailored Data Center Integration General Requirements

SAP and our SAP HANA hardware and software partners will support SAP HANA tailored data center integration system configurations if they use the following guidelines:

  • Use of certified hardware: Only servers listed in the Certified and Supported SAP HANA Hardware directory are supported. These are the same servers as for SAP HANA appliances.
  • Use of certified storage: Only storages listed in the enterprise storage tab of the Certified and Supported SAP HANA Hardware directory fulfill the requirements for data throughput and latency, and are supported by SAP.
  • Installation performed by an SAP HANA certified person: The person who installs SAP HANA needs to have a valid certification. Current valid C_DBADM_xxxx certification can be found on the SAP Learning web site.

Tailored Data Center Integration Storage Requirements

For certification, each storage vendor must file in a vendor-specific configuration guide. This guide explains how to configure the storage for optimal collaboration with SAP HANA. The storage vendor provides the guide to the customer.

Read the storage white paper attached to SAP Note1900823 - SAP HANA Storage Connector API carefully.

Use the SAP HANA Hardware and Cloud Measurement Tool for Tailored Data Center Integration to check your storage KPIs. You can do this every time you change your storage configuration.

Note

Customers should consider involving SAP Digital Business Services to perform a SAP HANA Go-Live Check prior to going productive.

SAP HANA Tailored Data Center Integration Enterprise Network Requirements

With the introduction of tailored data center integration with enterprise networks, SAP supports hardware setups, which comply with the prerequisites mentioned below:

Network Segmentation – All networks need to be properly segmented, and can be connected to the same core/backbone switch. SAP recommence to use the following zones setup:

  • Client zone - used by the SAP HANA clients like application servers, data sources, and BI clients.
  • Internal zone - used for the communication between the SAP HANA worker nodes (inter-node communication).
  • Storage zone - used for reading and writing to the enterprise storage, and for writing backups to the backup infrastructure.

The minimum bandwidth requirement for Ethernet is ≥ 10 GbE for the Internal and Storage zone.

The minimum bandwidth requirement when using Fibre Channel for the enterprise storage is ≥ 8 GbF.

Note

Network security and segmentation is a function of the network switch vendor and must be configured according to the specifications of the switch vendor. 

Apart from that, no further approval by SAP is required. SAP does not introduce any certification of network components for tailored data center integration setups. Customers should consider involving SAP Active Global Support to perform an SAP HANA Go-Live Check prior to going productive.

Important Documents and Tools

Sizing Method for the SAP HANA Tailored Data Center Integration

Sizing an SAP HANA Tailored Data Center Integration Setup

Sizing an SAP HANA tailored data center integration setup consists of three main steps, as follows:

  • RAM sizing for static and dynamic data

  • Disk sizing for the persistence storage

  • CPU sizing for the queries and calculations

The three sizing steps are explained in the following sections.

DRAM Sizing for Static and Dynamic Data

The first step to sizing an SAP HANA tailored data center integration system is to perform a memory sizing. Depending on the use case, you would use the following resources:

When performing the first initial SAP HANA memory sizing, it is good practice to use both methods. The Quick Sizer and the SAP Notes determine the required SAP HANA memory size in two different ways. When both values are similar, you know that you did not make any mistakes.

Sizing for Suite on SAP HANA

The report /SDF/HDB_SIZING is regularly updated and improved, so always check the SAP Notes for newer versions of the report. Due to the continuous update of the report /SDF/HDB_SIZING, the screenshots shown in this section might be outdated.

Always check SAP Note 1872170 - ABAP on HANA sizing report (S/4HANA, Suite on HANA...) for the current version of the report /SDF/HDB_SIZING.

Sizing for SAP BW/4HANA

The sizing notes describe the memory sizing (column, row store, and additional components), the disk sizing for data and log files, and the CPU sizing. Some additional information is attached to some of these SAP Notes.

Note

The ZNEWHDB_SIZE report runs with a low system load. Depending on the size of your Suite on SAP HANA system, it takes up to eight to twelve hours or more. Therefore, we recommend that you test the report in your consolidation system before loading.

Static Versus Dynamic Memory Requirements

Distinguish between the static and the dynamic RAM requirement as follows:

  • Static Data Memory Requirements

    The static RAM requirements refer to the amount of main memory that is used for holding the table data. Static memory sizing of SAP HANA is determined by the amount of data that is to be stored in memory. Specifically, this figure relates to the amount of disk space covered by the corresponding database tables, excluding their associated indexes.

    Note that, if the database supports compression, the space of the uncompressed data is needed. Based on this amount of data, a compression factor is applied to determine the size of the RAM needed for SAP HANA.

  • Dynamic Data Memory Requirements

    Additional memory is required for objects that are created dynamically when new data is loaded, or queries are executed. Because we recommend reserving as much memory for dynamic objects as for static ones, calculate the total RAM by multiplying the static RAM by two.

In an SAP HANA virtualized environment, you should also consider the following SAP Notes:

In a scale-out environment, you should also consider the following SAP Notes:

Sizing SAP HANA Storage Requirements

SAP HANA is an in-memory database, which stores and processes the bulk of its data in-memory. Additionally, it provides protection against data loss by saving the data in persistent storage locations.

For further storage sizing recommendations, follow the guidelines described in the SAP HANA Storage Requirements white paper attached to SAP Note 1900823 - SAP HANA Storage Connector API.

Persistent storage distinguishes between the data volume and the log volume. In the data volume of SAP HANA, a copy of the in-memory data persists by writing changed data to the data volume. The log volume ensures the recovery of the database with zero data loss in case of faults. SAP HANA records each transaction in the form of a redo log entry.

Disk Space Required for the Data Volume

Whenever a savepoint or a snapshot is created, or a delta merge operation is performed, data is written from memory to the data volume located at the mount point /hana/data/<sid>.

The recommended size of the data volume for a given SAP HANA system is equal to the calculated results from the sizing reports. Use the net data size on the disk plus an additional free space of 20%.

The figure, Determining the Data Volume Size, shows an example sizing report result for Suite on HANA. The sizing report shows the net data size on disk. To determine the required SAP HANA data volume size, add 20%. This 20% of additional space is required during delta merge operations, because the affected tables are temporarily duplicated on disk for a short period of time.

Also include the anticipated year-on-year growth, for example, 15% per year for the next three years. This would lead to a factor of 1,52 (= 1,153) that needs to be added to the Sizedata equation.

During the migration of a non-SAP HANA database to SAP HANA, the system may temporarily need more disk space for data than calculated in the sizing phase. With Enterprise Storage, this is not considered relevant for the overall storage sizing, because the storage system can provide that additional space, if required.

Disk Space Required for the Log Volume

The minimum size of the log volume depends on the number of data changes occurring between two SAP HANA savepoints, which, by default, are created every five minutes. The more data changes that are executed by write transactions in that period, the more redo log segments that are written to the log volume under /hana/log/<SID>. When sizing the log volume, consider the following points:

  • The redo log must not be overwritten before a savepoint entry is available in the data volume, otherwise, the SAP HANA database may be unable to restart.

    Situations may occur where the writing of a savepoint is delayed. For example, delays occur if a high workload must be processed during a database migration process in an environment with slow input/output between the source and target (SAP HANA) database. In such cases, as long as the savepoint has not been written to the data volume, the amount of redo logs in the log volume continue to grow until all log segments are full.

  • If the parameter LOG_MODE = NORMAL is set, the redo log must not be overwritten before a backup takes place. Therefore, keep some extra space available for situations where incidents or faults may interrupt the backup process. That extra space allows system administrators to fix and finish the backup process before the log volume runs full.

Determining the Log Volume Size

There is no direct correlation between the SAP HANA database size and the required log volume size. Nevertheless, we recommend using the formula in the figure, Determining the Log Volume Size, because it is based on best practice and experiences with productive SAP HANA installations. Unlike the formula for the data volume, it is calculated depending on the total memory requirement (RAM).

Examples of log volume size are as follows:

  • 128 GB system ≥ Size log volume = 64 GB

  • 256 GB system ≥ Size log volume = 128 GB

  • 512 GB system ≥ Size log volume = 256 GB

  • 1 TB system ≥ Size log volumemin = 512 GB

  • 2 TB system ≥ Size log volumemin = 512 GB

  • 4 TB system ≥ Size log volumemin = 512 GB

Note

For systems with more than 512 GB of in-memory database size, the previous formula represents a minimum value. As of today, based on the experience made with productive SAP-internal SAP HANA installations, this value is considered sufficient for each SAP HANA use case. Nevertheless, as described previously, as the amount of data stored in the log volume depends on the workload processed, there may be situations where this value is not sufficient for log volume sizing.

Disk Space Required for SAP HANA Installation

All binary, trace, and configuration files are stored under /hana/shared/<SID> for a single-host configuration.

Note

The documentation and configuration parameter files refer to the /hana/shared/<SID> file system as the installation path or the mount point sapmnt.

The /hana/shared/<SID> file system can be set up as a shared file system, or as a local file system. The advantage of setting up /hana/shared/<SID> as a shared file system is that it makes the conversion from a single-host system to a multi-host system easier.

For single-node SAP HANA systems, the minimum recommended disk space for /hana/shared/<SID> is shown in the figure, Determine Share Single-Host Size, with a maximum of 1 TB.

The following are examples of single-node SAP HANA installation sizes:

  • Single-node 128 GB ≥ Sizeinstallation = 128 GB

  • Single-node 256 GB ≥ Sizeinstallation = 256 GB

  • Single-node 512 GB ≥ Sizeinstallation = 512 GB

  • Single-node 1 TB ≥ Sizeinstallation = 1 TB

  • Single-node 2 TB ≥ Sizeinstallation = 1 TB

  • Single-node 4 TB ≥ Sizeinstallation = 1 TB

Determining the Share Scale-Out Size

For a multi-host (scale-out) system all binary, trace, and configuration files are stored on a shared file system that is exposed to all worker nodes of an SAP HANA system in the file system /hana/shared/<SID>. In the installation path (sapmnt), additional space is required per worker node for the writing the traces files of a scale-out SAP HANA database system.

Experience with productive SAP HANA installations shows that the bigger the size of the SAP HANA database, the more traces that are written. Therefore, the calculation is based on the total memory requirement (RAM).

For scale-out SAP HANA systems, the recommended disk space for /hana/shared/<SID> depends on the number of worker nodes. Disk space of 1x worker node RAM is recommended for every four worker nodes in a given scale-out system.

The following are examples of scale-out SAP HANA installation sizes:

  • 3 system, 512 GB per node ≥ Sizeinstallation = 1x 512 GB = 512 GB

  • 4 system, 512 GB per node ≥ Sizeinstallation = 1x 512 GB = 512 GB

  • 5 system, 512 GB per node ≥ Sizeinstallation = 2x 512 GB = 1 TB

  • ...

  • 9 system, 512 GB per node ≥ Sizeinstallation = 3x 512 GB = 1.5 TB

  • ...

  • 3 system, 1 TB per node ≥ Sizeinstallation = 1x 1 TB = 1 TB

  • 4 system, 1 TB per node ≥ Sizeinstallation = 1x 1 TB = 1 TB

  • 5 system, 1 TB per node ≥ Sizeinstallation = 2x 1 TB = 2 TB

  • 9 system, 1 TB per node ≥ Sizeinstallation = 3x 1 TB = 3 TB

Note

In a scale-out system, a node can also have the role Standby. A node with the role Standby does not require any additional disk space as it will take over the data and log volumes of the failed node.

Disk Space Required for Backups

A complete data backup contains the entire payload of all data volumes. The size required by the backup directory not only depends on the total size of the data volumes, but also on the number of backup generations kept on disk, and on the frequency with which data is changed in the SAP HANA database. For example, if the backup policy requires you to perform complete data backups daily and to keep those backups for one week, the size of the backup storage must be seven times the size of the data area.

In addition to data backups, backup storage for log backups must be reserved to provide the possibility for a point-in-time database recovery. The number and size of log backups to be written depend on the number of change operations in the SAP HANA database.

Technically, it is possible to store the backups of several SAP HANA databases in a central shared backup storage. But if several backup or recovery processes run in parallel, this impacts the overall data throughput of the given backup storage. That is, if the backup storage cannot guarantee a constant level of data throughput once the number of parallel processes exceeds a certain number, backup and recovery processes can slow down significantly.

Backup Strategy: All Full Backups

Code Snippet
1234
 28x 2.50TB = 70TB
 28x 0.25TB =  7TB + 
---------------------------------
Backup size = 77TB

Backup Strategy: Weekend Full Backups, Workdays Incremental Backups

Code Snippet
12345
 4x 2.50TB  = 10.0TB 
24x 0.05TB  = 1.2TB 
28x 0.25TB  = 7.0TB + 
--------------------------------- 
Backup size = 18.2TB

Disk Space Required for Exports

Sometimes, the database content is needed for a root cause analysis of problems. For this purpose, sufficient disk space must be provided to hold the binary exports. In most cases, it is not necessary to export the entire database content for root cause analysis. Therefore, it is sufficient to reserve storage space of about two times the size of the largest database table.

Network Requirements

Network sizing typically focuses on the bandwidth, which is typically described in gigabits per second (Gbit/s).

Customers often also create an Admin zone to handle the communication between virtualized devices (for example, hypervisor failover), administration hosts (such as SAP HANA Database Cockpit), and boot servers.

When you deploy SAP HANA as an appliance, "network connectivity" is provided for the internal and storage zones. The client zone and admin zone are within your responsibility.

Should you deploy SAP HANA using the tailored data center integration approach, the recommendation for internal zone and storage zone is minimum 10 Gbit/s.

For more information on network configuration in SAP HANA, including sizing recommendations, read the SAP HANA Network Requirement.

Database CPU Sizing

The CPU requirements for migrating to SAP HANA standalone are difficult to anticipate, as there is no real reference against which to compare. Therefore, the sizing referred to previously has the following formula: 300 SAPS per active user / 0.65 for a CPU utilization buffer. An active user is one that consumes CPU power at a given point in time. In sizing, customers often overestimate the (overlapping) activity patterns of their end users. Some end users also may perform complex or less intensive calculations on the database level.

Consider this recommendation as an initial estimate that needs verification. The more users there are on the system, the less likely it is that this formula will be accurate. The decision of whether you invest time into further CPU analysis depends upon the risk of reaching CPU limits. SAP HANA servers with two sockets, for example, deliver about 60,000 SAPS.

If you want to verify the CPU requirements, a test with the top five to ten SAP HANA transactions can be helpful, either within a single user test or a load test.

Sizing Method Quick Sizer for SAP HANA

SAP HANA database can also be sized using Quick Sizer. For more information, see Quick Sizer.

The Quick Sizer calculates the following:

  • CPU

  • Disk

  • Memory

  • Input/output resource categories

It calculates these based on throughput numbers and the number of users working with the different SAP solutions in a hardware and database-independent format. Sizing is an iterative process that continuously brings together customers, hardware vendors, and SAP. So, for example, direct links to SAP hardware vendors facilitate the tendering procedure.

For an initial sizing recommendation using the Quick Sizer, follow the steps shown in the figure, Quick Sizer Tool. For sample configurations, see SAP Standard Application Benchmarks.

In the Quick Sizer, multiple predefined scenarios can be selected. For example, the following scenarios can be selected:

  • SAP Business Suite powered by SAP HANA
  • SAP S/4HANA
  • SAP BW/4HANA
  • Standalone SAP HANA
  • SAP S/4HANA Cloud

For each of the scenarios, the expected compression of the data is different.

Sizing Method for the SAP HANA Appliance

The result of the memory sizing is the basis for the hardware recommendation for an SAP HANA system. If you decide to buy an SAP HANA appliance, check the SAP HANA Hardware Directory list where you will find all hardware that has been certified or is supported. You don’t need to consider storage and CPU sizing for an SAP HANA appliance, because they are included in the certified appliance offering.

Caution

Applications other than the SAP HANA database software must not be installed on the database server, except for scenarios that are explicitly supported by SAP. This is discussed in the lesson Illustrating Deployment Options.

To calculate the memory requirements, use the following SAP Notes:

SAP HANA Appliances

An overview of the available and certified SAP HANA appliances can be found on the SAP HANA Hardware Directory.

Caution

It is mandatory to begin with SAP HANA 2.0 computing nodes with at least an Intel Haswell CPU or later. See SAP Note 2399995 - Hardware requirement for SAP HANA 2.0.

Sizing recommendations apply for certified hardware only. Contact your hardware vendor for suitable hardware configuration. The SAP HANA development team is constantly optimizing the SAP HANA database. We recommend that you always check the latest documentation and SAP Notes when performing an SAP HANA memory sizing.

Sizing Method for SAP HANA Non-NetWeaver

Sizing Method for Non-NetWeaver

The SAP Note 1514966 - SAP HANA 1.0: Sizing SAP In-Memory Database describes the sizing of SAP HANA in a non-NetWeaver scenario, for example, when the data is coming from an external data source and SAP HANA is used to model and analyze that data. Do not use these sizing rules for sizing SAP BW/4HANA, Business Suite on SAP HANA systems, or SAP S/4HANA as they will produce incorrect values.

Additional Remarks

For various SAP HANA scenarios, native and third-party technologies provide features to displace data not frequently used either for the SAP HANA persistence or for other database management systems. If such a technology is used, this is considered in the main memory sizing. The following are examples:

  • SAP HANA Native Storage Extension (SAP Note 2775588) and Data Aging in SAP HANA (SAP Note 2816823)

    SAP HANA native storage extension is a general-purpose, built-in warm data store in SAP HANA that lets you manage less-frequently accessed data without fully loading it into memory. SAP HANA native storage extension adds a native warm data tier to an SAP HANA database, managing page-loadable warm data in the SAP HANA database with expanded disk capacity, and an intelligent buffer cache to transfer pages of data between memory and disk.

    It integrates disk-based database technology with the SAP HANA in-memory database for an improved cost-to-performance ratio, while complementing other warm data tiering solutions such as SAP HANA extension node and SAP HANA dynamic tiering.

    However, it is important to note that SAP HANA native storage extension does not interfere with the existing data aging functionality of SAP HANA. It neither replaces data aging nor changes any aging processes and access in SAP S/4HANA. The SAP S/4HANA data aging tables still remain under the full control of SAP S/4HANA and they must not be changed as any changes to the database tables outside of SAP S/4HANA may result in SAP S/4HANA failure.

  • Non-active data concept for SAP BW/4HANA and Nearline Storage Solutions (SAP Note 1767880 and SAP Note 2165650)

    Large SAP BW systems contain large amounts of data that are no longer, or rarely, used. However, they remain in the system, for example, historical data, keeping data for legal reasons, and so on. This data is called nonactive data. An implementation for SAP BW/4HANA allows for the displacement of nonactive data if the main memory bottlenecks use a last-recently-used concept. This concept improves main memory resource management, which has positive effects on hardware sizing for a large amount of nonactive data. For more information, see SAP Note 1736976. In addition, nearline storage solutions could be used to store cold data, which can also help to reduce the memory amount.

  • SAP HANA Smart Data Access 2.0 (SAP Note 2352696)

    SAP HANA smart data access lets you access remote data via SQL queries as if they are local tables in SAP HANA. You don't need to copy the data into SAP HANA first. This capability provides operational and cost benefits and supports the development and deployment of the next generation of analytical applications, which require the ability to access, synthesize, and integrate data from multiple systems in real-time, regardless of where the data is located, or what systems are generating it.

  • Deprecated: SAP HANA 2.0 Dynamic Tiering (SAP Note 3414255)

    SAP HANA dynamic tiering is an optional add-on to the SAP HANA database for managing historical data. Its purpose is to extend SAP HANA memory with a disk-centric columnar store (as opposed to SAP HANA’s in-memory store) for managing less frequently accessed warm data. Warm data has relaxed performance requirements compared to highly active "hot" data. Data in the extended store is on line, and available for both queries and updates. Although it is possible to add dynamic tiering to small SAP HANA databases, dynamic tiering is targeted at SAP HANA database sizes of 512 GB and larger, where large data volumes begin to necessitate a data lifecycle management solution.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn