SAP HANA Sizing: An Comprehensive Guide

Introduction

In today’s data-driven world, businesses are dealing with massive volumes that demand effective processing and analysis to stay competitive. And this is where SAP HANA, an in-memory database management system, plays a critical role in this process. It is a revolutionary technology that empowers businesses to process and analyze massive amounts of data in real time. However, successful SAP HANA implementation requires careful consideration of hardware and software requirements for optimal performance. This process is known as SAP HANA sizing.

Traditional SAP Sizing

Traditional SAP sizing focuses on determining hardware requirements for both the SAP application and its database, taking into account the expected workload. It involves analyzing factors such as user concurrency, database size, and peak transaction volumes to find the right hardware configuration.

SAP HANA Sizing

In contrast, SAP HANA sizing is tailored specifically to the SAP HANA database, designed for high-performance SAP applications. It considers memory and CPU requirements unique to the HANA database and anticipates workload demands.

Due to the distinctive architecture and performance characteristics of the SAP HANA database, it requires a different approach than traditional SAP sizing. SAP HANA sizing often involves a more detailed analysis of the database and application workload to ensure top-notch performance and scalability.

In this article, we’ll explore the what are best practices in greenfield, brownfield, and Bluefield projects in terms of SAP HANA sizing and how to perform accurate sizing to achieve the desired results. In this article, we’ll explore the factors affecting SAP HANA sizing and how to perform accurate sizing to achieve the desired results.

Overview

The concept of sizing, from a customer’s perspective, involves translating business requirements, including business throughput and user concurrency demands, into the corresponding hardware prerequisites.

SAP development sizing is essential for several compelling reasons:

a) Optimizing Hardware Requirements

Firstly, it empowers businesses to determine the precise hardware requirements needed for optimal performance. This, in turn, guarantees the seamless and efficient operation of the SAP application, avoiding potential downtime and other technical issues.

b) Estimating Total Cost of Ownership (TCO)

From the standpoint of SAP development, sizing helps businesses accurately forecast the total cost of ownership (TCO) of the application. By gaining a comprehensive understanding of hardware requirements, companies can assess the costs tied to acquiring and maintaining the requisite equipment, software licenses, and ongoing support.

c) Creating Accurate Sizing Models

To create accurate sizing models, businesses must consider several factors:

• The specific type of SAP application
• The number of users, and
• The expected usage patterns.

It’s essential to use realistic assumptions when creating sizing models to ensure that the resulting guidance is accurate.

d) Establishing Sizing Recommendations

Ultimately, the goal is to establish sizing recommendations for each application. This sizing process aids customers in determining the essential resources for an application while taking into account their business needs, encompassing aspects such as:

• CPU
• Memory
• Data growth on disk
• Disk I/O
• Frontend network

e) Sizing Vs Configuration

It’s worth emphasizing that, “sizing” is not configuration”. Sizing and configuration are two distinct processes. While sizing determines the required system resources, such as CPU, memory, data growth on disk, disk I/O, and frontend network, it’s the responsibility of hardware vendor or infrastructure service provider to configure the actual system. Their role is to ensure that the system landscape aligns with the hardware requirements established during the sizing process.

Understanding SAP HANA Memory

SAP HANA, as an in-memory database, places memory at the core of its operations. To grasp how SAP HANA functions, it’s vital to comprehend how it requests, manages, and utilizes this critical resource. This understanding becomes especially pivotal when sizing SAP HANA, as memory sizing involves preemptively determining the required memory to run specific workloads on an SAP HANA database.

In a standard SAP HANA appliance, the resident memory component of the operating system and any other active programs generally remains under 2 GB. This leaves the majority of the memory to be allocated specifically for the use of SAP HANA.

Memory Allocation Dynamics

• In SAP HANA, the code acquires memory from the current memory pool whenever it’s required for temporary computations or table growth.

• If the current pool falls short of meeting the demand, the SAP HANA memory manager intervenes by requesting additional memory from the operating system and reserving it. Consequently, the virtual memory size of SAP HANA processes expands.

• However, it’s important to note that when temporary calculations are completed or a table is dropped within SAP HANA, the memory previously in use is released and returned to the memory manager. Notably, this memory recycling process occurs seamlessly within SAP HANA without any external notification to the operating system.

Following are the crucial memory areas:

SAP HANA Deployment & Sizing Methodology

• SAP HANA database can be deployed as:
  • SAP In-Memory Appliance (SAP HANA)
  • SAP HANA Tailored Datacenter Integration (TDI) System

• SAP HANA sizing is about:
  • Memory sizing for static data.
  • Memory sizing for objects created during runtime (data load & query execution).
  • Disk sizing.
  • CPU sizing.

• Sizing of SAP HANA is based mainly on required main memory size, which is determined by amount of data that is to be stored in memory. Data is compressed in SAP HANA. It’s challenging to estimate the amount of memory required since the compression factor depends on the used scenario.

SAP In-Memory Appliance

SAP HANA stands as a versatile, data-source-agnostic appliance, offering customers to analyze vast volume of real-time data.

• It operates as a hybrid database, seamlessly integrating row-based, column-based, and object-based database technology. It is meticulously designed to harness the full potential of modern multi-core/CPU architecture, thus optimizing parallel processing capabilities.

• When SAP HANA is delivered as an optimized in-memory appliance in collaboration with the leading hardware partners of SAP. Hardware components, including storage and CPU, are bundled with the certified appliance, simplifying procurement and reducing compatibility concerns.

• Sizing of SAP HANA appliance is based on the required main memory size, serving as the foundational parameter for determining the sizing of other server components.

• Memory sizing is determined by the amount of data is to be stored in the memory, ie the amount of disk space occupied by the database tables (excluding their associated indexes).

• Based on the workload and data storage analysis, SAP experts use their experience to recommend a hardware configuration for the SAP HANA system.

• The recommended hardware configuration undergoes rigorous benchmark testing, ensuring it aligns with the the performance and scalability demands of the SAP system. To locate hardware options consistent with your memory sizing results, you can refer to the SAP HANA Hardware Directory.

• Use the below reference SAP Notes to calculate the memory requirements:
  • SAP Quick Sizer tool (for initial sizing)
  • SAP Note 1514966: SAP HANA: Sizing SAP In-Memory Database
  • SAP Note 1637145: Sizing for SAP BW on HANA
  • SAP Note 1736976: SAP BW on HANA Sizing Report.

SAP HANA TDI

• SAP HANA TDI (Tailored Datacenter Integration) is an deployment option for SAP HANA that allows customers to use their own hardware infrastructure to host SAP HANA system, providing greater flexibility and control over the deployment process.

• In this deployment, customers are responsible for procuring and configuring the hardware infrastructure according to SAP’s guidelines and certification criteria.

• TDI offers flexibility in terms of deployment options, including on-premises and cloud environments, based on the chosen hardware.

• TDO deployments are suitable for organizations looking to maximize their existing hardware investments, customize SAP HANA, and manage their hardware preferences and budget considerations, as long as they meet SAP’s certification and sizing criteria.

• The three main stage of SAP HANA TDI sizing are as follows:
  1. RAM sizing for static and dynamic data
  2. Disk sizing for persistence storage
  3. CPU sizing for queries and calculation

Before deploying SAP HANA, its crucial for every customers to determine the required memory size by leveraging tools like SAP Quick Sizer or SAP Notes.

RAM Sizing

Static Data Memory Requirements

The static memory requirements refer to the amount of memory used to store table data. It is determined by the size of the data to be stored in memory, which is dependent on the disk space occupied by the corresponding database tables, excluding their associated indexes.

Dynamic Data Memory Requirements

When new data is loaded or queries are executed, additional memory is required for dynamically created objects.

Determine Static + Dynamic RAM Requirements

To determine the total RAM requirement for SAP HANA, first calculate the uncompressed data volume using the tools provided. Then, apply the compression factor from the sizing notes attachment. Finally, multiply the result by 2 because it’s recommended to have: RAM _dynamic = RAM _static

Disk Sizing

SAP HANA distinguishes two types persistence storage: data volume and log volume. Data volume stores a copy of in-memory data by writing changed to it. The log volume is responsible for recording each transaction in a redo log entry to ensure the recovery of database with zero data loss in case of any failure.

Disk Space for Data Volume

• Whenever a snapshot or savepoint is created, or delta merge is performed in SAP HANA, the data is persisted from memory to data volume which is located at /hana/data/<SID>.

• Recommended size of the data volume of SAP HANA system is determined by the results of sizing reports.

• Use net data size on disk plus an additional free space of 20% (i.e Size _data = 1.2 x Net data size on disk).

• In the above report, the net data size on disk is 1.3 TB, our anticipated memory requirement would be 1.6 TB, considering 20% additional free space.

Disk Space for Log Volume

• The amount of data stored in the log volume is dependent on the workload processed.

• The minimum size of the log volume in SAP HANA depends on the number of data changes that occur between two savepoints, which are created every 5 minutes by default. The redo log segments are written to the log volume located at /hana/log/.

• During log volume sizing in SAP HANA, two factors needs to be taken into account:
  • The redo log must not be overwritten before a savepoint entry is available in the data volume; otherwise, the SAP HANA DB will be unable to restart.
  • If LOG_MODE = Normal is set, the redo log must not be overwritten before a backup takes place. Therefore, it is recommended to have some extra space available for situations where incidents or faults may interrupt the backup process. This extra space allows the system admin to fix and finish the backup process before the log volume runs full.

• For [system <= 512 GB], then Size _{redo log} = 1/2 x RAM
• For [system > 512 GB], then Size _{redo log} = 512 RAM

CPU Sizing

Determining the necessary CPU requirements for transitioning to a standalone SAP HANA system is a tricky task, as there are no benchmarks to compare against.

To estimate the required CPU sizing, the formula used is: 300 SAPS / active user.

• Note that, to achieve the maximum number of users per server, it is important to adjust the CPU sizing such that the server load does not exceed 65% on average. This means that the absolute server SAPS capacity should be multiplied by 0.65.

• Active users refer to those who use CPU at any given time, with their activity patterns often overestimated during the sizing process. Some users may also perform more or less intensive calculations on the database level.

• This is only a preliminary estimate and should be verified, particularly when more users are added to the system. For example, SAP HANA servers with two sockets can provide about 60000 SAPS. It is recommended to conduct tests on the top 10 SAP HANA transactions with either a single user or a load test to verify CPU requirements.

• For example:
  • Number of active users: 500
  • Calculated SAPS = 500 * 300 = 1,50,000
  • Add extra 65% SAPS = 1,50,000 * 0.65 = 97,500
  • Total SAPS = 1,50,000 + 97,500 = 2,47,500

Choosing the Right Sizing Approach

Selecting the appropriate SAP sizing methodology stands as a crucial decision in ensuring the success of your implementation project. The three primary methodologies are Greenfield, Brownfield, and Bluefield.

• Greenfield is starting from scratch, building a new system without any legacy data or processes.
• Brownfield is migrating an existing system to a new platform or upgrading it to a newer version of SAP.
• Bluefield is a hybrid approach that combines elements of both greenfield and brownfield, allowing for the creation of a new system while retaining some legacy data and processes.

The choice of methodology depends on several factors:

• Scope of the project
• Business objectives
• System complexity
• Business requirements

Careful consideration and analysis of these factors can help determine the most suitable methodology for a given project.

Greenfield Sizing

In the realm of SAP HANA implementations, the greenfield sizing methodology involves designing and configurating an SAP HANA system from the scratch, with no pre-existing data or processes.

• In this methodology, the implementation team has complete control over the hardware and software used to build the SAP HANA system.

• The journey of greenfield sizing begins with comprehensive analysis of the business requirements, setting the stage for subsequent decisions.

• Determining the system’s size and scale, selecting the appropriate hardware and software components, and configuring the system to meet the specific needs of the business.

• Sizing a greenfield system demands a thorough examination of various factors including:
  • Data Volume
  • User Expectations
  • Workload and Performance
  • Application and Use Cases

• Configuration is only part of the equation. Rigorous testing and validation are crucial to ensure that the SAP HANA system aligns seamlessly with the business requirements.

• Finally, beyond implementation, ongoing monitoring and maintenance are vital to ensure that the SAP HANA system continues to sustain peak performance and reliability over time.

In a nutshell, SAP HANA Greenfield sizing is akin to building a customized, high-performance engine from scratch. It’s a methodology that empowers businesses with precise control, scalability, and tailored solutions, ensuring that their SAP HANA system is finely tuned to their unique needs and aspirations.

Sizing Approach

Greenfield sizing for SAP HANA offers three distinct approaches: Initial sizing via Quick Sizer, Sizing Guidelines and Expert Sizing.

1) Initial Sizing Using Quick Sizer

• The first step in greenfield sizing process involves using Quick Sizer to perform initial sizing of SAP HANA system.

• Quick Sizer a proprietary tool developed by SAP using proven sizing methodology. It translates business requirements into hardware requirements.

• It is equipped with a structured questionnaire designed specifically for SAP applications. This questionnaire serves as a compass, guiding you through the process of evaluating your system’s needs.

• It excels in determining the hardware requirements, taking into account various factors such as number of users, data volumes and expected system performance.

• By engaging in this initial sizing with Quick sizer, you establish a fundamental baseline for the hardware requirements essential to your system’s success.

2) Sizing Guidelines

When Quick Sizer falls short in providing the precise sizing you require for your SAP application, sizing guidelines and SAP Notes step in to ensure the perfect fit for your specific needs.

• Every business is unique. Sizing guidelines help you align your SAP HANA system with your specific requirements. Whether you’re running data warehousing operations or analytics tasks, these guidelines offer invaluable insights on how to fine-tune your system.

• These guidelines go beyond generic recommendations. They dive deep into the nuances of your chosen use case, providing step-by-step instructions for customization.

• Here are few practical steps:
  1. Assess: Figure out what you need for your SAP product.
  2. Check SAP Notes: Look at relevant SAP Notes for more guidelines.
  3. Customize: Adjust your system based on the guidelines, considering things like volume, user and performance.
  4. Test: Make sure your system works as expected.
  5. Improve: If needed, fine-tune your setup based on real-world results.

• By adhering to these guidelines, you guarantee that your SAP HANA system aligns perfectly with the specific demands of your business, offering an optimal and seamless user experience.

3) Expert Sizing

Expert sizing is recommended for more complex or customized SAP HANA implementations.

• In simpler terms, expert sizing becomes essential when your SAP HANA implementation is anything but standard.

• This involves engaging with SAP experts who can provide more detailed analysis and recommendations on the hardware and software requirements for the SAP HANA system.

• This specialized approach takes into account a multitude of factors, ensuring that your system aligns perfectly with your specific business goals.

• Here’s why expert sizing stands out:
  • Tailored Analysis: SAP experts delve into the specifics of your SAP HANA system, considering the unique applications and use case it will support.
  • Future Proofing: Anticipating the growth of your business is crucial. Expert sizing takes this into account, providing recommendations that ensure scalability and longevity.
  • Customized Solutions: Your SAP HANA system should be as unique as your business. Expert sizing crafts recommendations that are precisely tuned to your requirements.

• Expert sizing isn’t a one-size-fits-all solution; its a dynamic process. Here’s how it typically unfolds:
  • Consultation: Engage with SAP experts to discuss your SAP HANA implementation, goals, and specific needs.
  • Detailed Analysis: Experts conduct a thorough assessment, factoring in the complexity of your applications and use cases.
  • Custom Recommendations: Based on the analysis, you receive tailored recommendations for both hardware and software requirements.
  • Future-Ready: Expert sizing ensures that your SAP HANA system is not just ready for today but also for the growth you anticipate.

• When Quick Sizer and sizing guidelines fall short, expert sizing steps in. It’s the tailored, forward-thinking approach that ensures your SAP HANA system is primed for success in an ever-changing business landscape.

Brownfield Sizing

Brownfield sizing refers to the process of determining the hardware requirements for migrating an existing SAP system to the SAP HANA platform.

• This approach is aptly known as “brownfield” because it involves upgrading an existing system rather than implementing a new one from scratch.

• It is all about thorough analysis. It considers several factors, including the current database size, the number of users, the types of workloads and the expected growth.

• The primary goal of this sizing is to ensure that the hardware infrastructure is adequate to seamlessly support the migration to SAP HANA while delivering optimal performance for the upgraded system.

• Precise sizing can help organization avoid performance bottlenecks and costly upgrades down the line.

• Brownfield sizing isn’t a one-size-fits-all solution. It’s a systematic process that involves following steps:
  • Assessment: Begin by evaluating your existing SAP system, taking into account the size of your database, user numbers, and workload types.
  • Growth Projection: Consider how your organization is expected to grow and how this will impact your SAP HANA migration.
  • Sizing Recommendation: Based on your assessment and growth projections, you’ll receive tailored recommendations for the hardware requirements needed for a seamless migration.

Brownfield sizing is your roadmap to a successful SAP HANA migration. By carefully analyzing your existing system and future growth, you can ensure that your hardware infrastructure is up to the task, guaranteeing optimal performance and cost-effective operations.

Brownfield Sizing: SAP Suite on HANA (SoH), S/4HANA

When it comes to productive sizing of SoH (Suite on HANA) and S/4HANA, especially in brownfield scenarios, there are two distinct yet straightforward approaches to consider:

1) Quick and Easy

This first approach is quick and simple, and it involves a direct approach that serves as an initial rough evaluation.

a) Calculate the memory requirements

• If you want to have first ballpark estimate of SAP HANA memory, its a good idea to first check the size of your current database (using SAP standard monitoring tools).

• For example: the estimated disk space of SAP HANA is found to be 303 GB.
  • SAP currently recommends taking half of the size of the disk-based database, include a safety buffer of 20%, and add a fixed size of 50 GB for code, stack, and other services.
  • So translating this into formula would be:  303 GB / 2 * 1.2 + 50 GB = 232 GB (SAP HANA memory).

b) Calculate the CPU requirements

• If you want to estimate SAP HANA CPU requirement, then you should identify the current CPU consumption of database processes (using SAP monitoring tools)

• For example: the estimated SAP HANA database SAPS is 1000.
  • SAP recommends using three to four times more CPU power for SAP HANA than disk-based database, to fully utilize its parallel processing capabilities and achieve optimal response times for analytical applications.
  • So this calculation translates to: 1,000 database SAPS * 4 = 4,000 SAPS

c) Calculate the disk space requirements

• To determine how much HANA disk space you’ll need, you’ll need to consider the size of your net data on disk as well as the disk space required for Delta Merges. When a delta merge takes place, the relevant tables are duplicated on disk for a short period.

• To calculate the necessary disk space for merges, you need to add up the sizes of the two largest tables, including this value in your calculation.
  • On top, you should add 25GB for the space required by the statistics server, HANA metadata, etc. The final calculation looks as follows:
  • So this calculation translates to: HANA disk space (Total Net Disk Space) = (Net Data Size anyDB + Disk Space for Merges) / 4 (compression) * 1.2 (20% safety buffer) + 25GB

After you have determined the appropriate amounts of memory, CPU, and disk space needed to meet your implementation requirements, contact a trusted hardware vendor. Work with them to evaluate your sizing calculations and determine which of their offerings best suit your configuration needs. Additionally, explore sample configurations on www.sap.com/benchmarks.

2) Sizing Report (for Suite on HANA, S/4HANA or ABAP-based system)

The sizing report approach give a more accurate sizing) Follow the SAP Note 1872170, which provides the ABAP sizing report to size ABAP based systems

Scenario:

You are running an ABAP based system:

• Want to size memory and disk requirements for Suite on HANA, S/4HANA or any ABAP-based system planned to run on HANA at the exception of BW system.

Sizing Report:

• Report /SDF/HDB_SIZING is available with SAP Note 1872170.
• Execute the report in background mode, to have report for all the tables. For small range of tables or single table you can run the report in foreground mode.

Pre–requisites:

• Run on SAP_BASIS 620 and higher.
• Minimum ST-PI 740 SP02 or 700/712 SP12 (recommended to have the latest one).
• Set parameter “rdisp/max_wprun_time” to 7200 secs.
• Database statistics must be up-to-date to have a reliable sizing result.

Functionality:

• Estimates the maximum memory consumption of the database, if migrated to SAP HANA.
• Is independent of the source database provider.
• Considers distribution of tables to row and column store.
• Considers differences for secondary indexes.
• Considers compression of legacy database.
• Provides sizing projections, based on the actual sizes in legacy system, as well as an estimation of how much memory footprints can be reduced, using functionalities that HANA will enable.
• Reads total number of entries of each table is read from database statistics.
• Reads random sample of data from every tables in the system.
• Out of average size per column and total record count, the uncompressed size of column is calculated. To uncompressed size an average compression factor is applied to get estimated size in HANA.

How to install the sizing report?

Decoding Excerpts of Sizing Report

• The initial installation requires a minimum of 1.317 GB of HANA memory. However, if the customer performs some initial data cleansing, the estimation can decrease to 753 GB.

• Kindly note that the total estimated memory requirement provided in the report should not be treated as the final memory sizing result. You should also consider other factors:
  • Not all server memory will be available to HANA, the global allocation limit factor should also be taken into account by the sizing.
  • Its crucial to anticipate and accommodate enough space for future growth, to prevent overload or insufficiency.
  • Keep in mind that the report is making an estimation, not an exact forecast.

• Estimation for all non-data components required for running SAP HANA are labelled under the sub-totals “Work space” and “Fixed size”.

Brownfield Sizing: SAP BW on HANA (BoH), BW/4HANA

Scenarios

You are running SAP BW system:

• Want to migrate your “traditional” (anyDB) database to SAP HANA (ie SAP BW powered by SAP HANA).
• Want to convert your SAP BW system into an SAP BW/4HANA.
• Want information about hardware resources required to migrate to SAP HANA.
• Want information about the sizing report to execute.

Sizing Report

• The ABAP based BW on sizing report (/SDF/HANA_BW_SIZING) to migrate SAP BW on anyDB to SAP HANA is now available with SAP Note 2296290: New Sizing report for BW/4HANA.
• Earlier this same report (until version 2.2) was available and maintained with SAP Note 1736976.
• From version 2.2 onwards, SAP will no longer maintain the SAP Note 1736967 after report version 2.2. Any further enhancements and added functionality to this report will only be available in the above new sizing report.
• This SAP Note is applicable to both SAP BW/4HANA and SAP BW powered by SAP HANA.
• You can execute the report via SA38 or also schedule as a background job via SM36.

Pre-requisites

• ST-PI 2008_1_700 SP 12
• ST-PI 2008_1_710 SP 12
• ST-PI 740 SP 2
• Recommended to upgrade ST-PI to latest SP.

Functionality

• Provides much better accuracy of sizing results.
• Automatically handles source database compression.
• Applies compression factors specific to table type.
• Takes into account the impact of non-active data on sizing.
• Report obtains list of tables from ABAP dictionary (table DD02L).
• Segregation of tables in row store and column store.
• Data that is stored (or supposed to be stored) in dynamic tiering is taken into account.
• Generates significantly more detailed results, facilitating to select an appropriate hardware configuration.
• Computes future resource requirements based on yearly growth, whether relative or absolute (on demand).

Sizing Verification

Summary

Useful Resources

• SAP Note 2296290: New Sizing Report for BW on HANA
• SAP Note 1799449: Sizing report ERP on SAP HANA database
• SAP Note 1637145: SAP BW on HANA: Sizing SAP In-Memory Database
• SAP Note 1736976: Sizing Report for BW on HANA
• SAP Note 2610534: HANA BW Sizing Report (/SDF/HANA_BW_SIZING)

HANA Sizing FAQs