GRC
HR
SCM
CRM
BI


Article

 

How to Properly Size an SAP In-Memory Database

Use SAP Notes and Sizing Tools to Determine SAP HANA’s Hardware Requirements

by Sebastian Schmitt | SAPinsider, Volume 15, Issue 3

July 1, 2014

To fully benefit from SAP HANA, customers must correctly size the hardware required to support the in-memory technique that drives its powerful performance. This article provides an overview of how to properly size for SAP HANA, including an explanation of how sizing for SAP HANA is different from sizing for traditional databases, the different sizing approaches supported by SAP, and how to apply these approaches when sizing for SAP HANA-based implementations.

 

Many SAP customers are switching to SAP HANA to take advantage of its real-time analytics functionality and its ability to perform transactional processing at lightning speed. These capabilities open up an array of opportunities for the business, but to fully benefit, customers must correctly calculate the sizing requirements for SAP HANA to support the in-memory technique that drives its powerful performance, and to ?minimize future maintenance costs. 
 
This article provides SAP IT and business users with an overview of how to properly size for SAP HANA. It starts with an explanation of the key performance indicators (KPIs) used for SAP HANA sizing, and how sizing for SAP HANA is different from sizing for traditional databases. It then outlines the two different sizing approaches — initial sizing (for new solution implementations) and delta sizing (for changes to existing solution implementations) — supported by SAP, and how to apply these approaches when sizing for SAP HANA-based implementations.

Note: This article primarily focuses on SAP Business Suite and SAP BW, but there are many other products that are also powered by SAP HANA. SAP offers specific sizing guidelines and recommendations for these products at service.sap.com/sizing.

 

Key Performance Indicators for SAP HANA Sizing

Sizing calculations for determining a system’s, solution’s, or database’s requirements are based on certain KPIs. The three main KPIs used to size for SAP HANA are memory space, CPU processing performance, and disk size.

Memory

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. In addition to the main memory required for storing the business data, temporary memory space is needed to operate the database management system — to support complex queries or data that is needed for buffers and caches, for example.

CPU

Sizing for SAP HANA includes unique requirements for CPU processing performance. The CPU behaves differently with SAP HANA compared to traditional databases. The processing engine for SAP HANA is optimized to operate very complex queries at maximum speed, which means that many of these queries are processed internally and in parallel, and most of the data is stored in a column-based format. This architecture not only might lead to a higher CPU demand compared to traditional databases, it also requires planning for a lower average utilization to ensure that there is enough headroom for the database to process queries sufficiently fast.

Disk Size

An in-memory database still requires disk storage space — to preserve database information if the system shuts down, either intentionally or due to a power loss, for instance. Data changes in the database must be periodically copied to disk to ensure a full image of the business data on disk, and to preserve the current state of the database and all of the data entered in the persistence layer. In addition, a logging mechanism is required to log changes and enable system recovery. To accommodate these requirements, there always must be enough space on disk to save data and logs.
 
Let’s now take a look at the two main approaches that use these KPIs for sizing ?SAP environments: initial sizing and delta sizing.

Initial Sizing vs. Delta Sizing

SAP distinguishes between two types of sizing: initial sizing and delta sizing. With an initial sizing, the sizing is being done from scratch for the first time for a completely new installation of SAP software. With a delta sizing, there is a productive SAP solution already running, and the sizing is being performed for new functionality or a migration to a new database, for instance. SAP offers tools and methodologies, including support specific to SAP HANA, for both approaches.
 
Initial sizing is typically questionnaire-based, and addresses peak load and average load in terms of business processes, user numbers, and data retention times. For the most widely used solutions, this questionnaire takes the form of the web-based Quick Sizer tool, which is a free self-service cloud application (available at service.sap.com/quicksizer) used by customers, partners, and SAP’s own consulting, sales, and support organizations in about 35,000 projects annually to help determine hardware needs for a variety of SAP offerings.1 The results of the questionnaire indicate the net disk space, main memory, IOPS, and CPU (measured in SAPS2) required for the implementation.3 
  
To facilitate delta sizing, SAP provides database-specific scripts, ABAP reports, and SAP Notes. The reports estimate the maximum memory consumption of the database if migrated to SAP HANA.

 

Note: In addition to the Quick Sizer tool, SAP Notes, scripts, and ABAP reports, SAP offers an SAP HANA decision tree (available at service.sap.com/sizing) to help customers determine which sizing procedure to follow for their applications. The tree provides an overview of the different available SAP HANA-based applications, and the right way to size these applications.

 
Next, you’ll see how to perform proper initial and delta sizing for running SAP solutions on SAP HANA, using SAP Business Suite powered by SAP HANA as an example. I’ll also highlight some key considerations to keep in mind when performing sizing for SAP Business Warehouse (SAP BW) powered by SAP HANA and a standalone SAP HANA implementation. 


Initial Sizing for an SAP Business Suite Implementation on SAP HANA

For a new implementation of SAP Business Suite directly on SAP HANA, you can size your needs with the Quick Sizer tool. To facilitate SAP HANA sizing, Quick Sizer includes a section called “SAP In-Memory Computing” that provides sizing questionnaires tailored to different types of solutions (see Figure 1). To perform sizing for SAP Business Suite powered by SAP HANA, follow the guidelines provided in SAP Note 1793345. 

Quick Sizer questionnaires for SAP HANA sizing

Figure 1 — Quick Sizer questionnaires for SAP HANA sizing

Let’s walk through the steps required to use Quick Sizer for a new implementation of SAP Business Suite powered by SAP HANA.

Step #1: Create a New Project in Quick Sizer

Start Quick Sizer and create a new Quick Sizer project. Then complete the “SAP Business Suite powered by HANA” questionnaire. The questionnaire offers two different approaches for performing the sizing: user-based sizing, which determines sizing requirements based on the number of users in the system, and throughput-based sizing, which bases the sizing on the items being processed. The throughput-based approach is recommended, since it allows you to define more variables, such as business objects used, peaks and averages, and the retention times of the business data.
 
Figure 2 shows the specifications entered in Quick Sizer for an example throughput-based sizing performed for implementing the CRM Sales component of SAP Business Suite. In this example, the assumption is that three million sales orders with 10 line items will be processed each day from 9am to 6pm. It also indicates that business data remains in the database for 12 months (“Mon.”). These specifications determine the amount of data in the system that is driving the calculation of the main memory required for SAP HANA.

Specifications for an example throughput-based sizing using the Quick Sizer tool

Figure 2 — Specifications for an example throughput-based sizing using the Quick Sizer tool

Step #2: Get the Results and Apply the Sizing Rules

Click on the Calculate result button and Quick Sizer will determine the system resources required to support the new solution based on the entered parameters. Figure 3 shows the results for the example scenario. The results that are relevant for calculating the SAP HANA-?specific requirements are the estimated disk space (for calculating the memory requirements) and the estimated database SAPS (for calculating the CPU requirements).

Quick Sizer results for an example throughput-based sizing

Figure 3 — Quick Sizer results for an example throughput-based sizing

 
Using the Quick Sizer results, calculate the sizing requirements by applying the sizing rules for SAP Business Suite on SAP HANA that are outlined in SAP Note 1793345:

  • Calculate the memory requirements for SAP HANA using the estimated disk space (303 GB in the example). SAP’s current recommendation is to take half of the size of the disk-based database; include a safety buffer of 20%; and add 50 GB fixed size for code, stack, and other services. Using the example Quick Sizer results, this calculation would look like the following:
    • 303 GB / 2 * 1.2 + 50 GB = ?232 GB SAP HANA memory
  • Calculate the CPU requirements for SAP HANA using the estimated database SAPS (1,000 in the example). To fully support the parallel processing capabilities of SAP HANA and enable optimal response times for analytical applications, SAP recommends a factor of three to four times more CPU power for SAP HANA than for disk-based databases. Using the example Quick Sizer results, this calculation would look like the following:
    • 1,000 database SAPS * 4 = ?4,000 SAP HANA CPU SAPS
  • Calculate the disk space requirements for SAP HANA. For SAP Business Suite powered by SAP HANA, SAP recommends using half ?of the required disk space that is needed for SAP Business Suite for disk-based databases:
    • 303 GB / 2 = 151.5 GB SAP HANA disk space

 

Note: SAP expects no changes concerning CPU, memory, and network requirements for the ABAP application server, which means that the existing hardware and network infrastructure can still be used.


Step #3: Get the Right Amount of Hardware

Once you have calculated the correct values for memory, CPU, and disk space to support your implementation needs, you can check ?for sample configurations at www.sap.com/benchmarks. You can also contact a trusted hardware vendor that can work with you to evaluate your sizing calculations to determine which of their offerings are suited to your configuration requirements.

 

Note: Before purchasing hardware, consider also evaluating a new KPI called single computing unit (SCU) performance. SCU refers to the processing power of a single computing unit within a system. Hardware that has good SCU performance helps ensure faster process response times. More information about SCU performance can be found in SAP Note 1501701.

To learn more about on SCU performance, see “Do You Have the Right Hardware for Your SAP Solution?” by Sebastian Schmitt in the July-September 2012 issue of SAPinsider


Initial Sizing for Other Types of Solution Implementations on SAP HANA

In addition to sizing for an SAP Business Suite implementation on SAP HANA, the Quick Sizer tool can be used for the initial sizing of SAP BW powered by SAP HANA and the standalone SAP HANA product. To facilitate these types of implementations, the respective Quick Sizer questionnaires contain questions and algorithms specific to those particular scenarios.  
 
For an implementation of SAP BW powered by SAP HANA, the sizing procedure is analogous to sizing SAP BW systems for a traditional RDBMS environment. The Quick Sizer questionnaire enables you to specify the size of InfoCubes ?and Data Store Objects, along with average and peak load times, user groups, data upload information, and row and column footprints and compression, for example. The difference is that the results are converted into SAP HANA results by Quick Sizer automatically.
 
For a standalone SAP HANA implementation, the memory sizing is derived from the size of the tables in the source database. Only tables are considered for sizing purposes; space for elements such as indexes and temporary table spaces must be excluded. To obtain the correct size information from your source database, run the sizing script attached to SAP Note 1514966. Using this information, in the Quick Sizer ?questionnaire, enter the number of concurrent users, the source database footprint in GB, and the compression factor. Note that specifying the number of users is optional. If you enter a user number, Quick Sizer verifies that the CPU requirements are met by certified hardware configurations.
 
Next, I’ll look at how to perform a proper delta sizing for a solution migration to SAP HANA, again using SAP Business Suite as an example. I’ll also highlight some key considerations to keep in mind when migrating SAP BW to SAP HANA.

Delta Sizing for an SAP Business Suite Migration to SAP HANA

Performing delta sizing for SAP Business Suite powered by SAP HANA means that you are sizing for a migration of an already productive SAP Business Suite solution to SAP HANA, without changing the core business processes and without changing custom code. To facilitate this sizing for an SAP Business Suite migration, SAP Note 1872170 implements an ABAP report, which runs on non-SAP HANA systems, that estimates the memory space requirements for the database tables of SAP Business Suite ?powered by SAP HANA systems.
 
Let’s walk through the steps required to size for a migration to SAP Business Suite powered by SAP HANA.

Step #1: Run the Sizing Report

SAP Note 1872170 includes detailed instructions for running the ABAP-based sizing report. Be sure to read the FAQ document attached to the note.
 
The sizing report runs on SAP_BASIS 620 and above, and is independent of the source database provider. The report can be used for sizing all SAP Business Suite products as well as all SAP products that run on SAP NetWeaver (with the exception of SAP BW; more on this shortly). It analyzes the size and the data volume of all tables in the source database and estimates the memory space requirements by accounting for:

  • Distribution of tables to row/column store
  • De-clustering/de-pooling
  • Differences for secondary indexes
  • Compression of the legacy database ?and Unicode conversion (if a conversion ?is required)
Step #2: Interpret the Results of the ?Sizing Report

The sizing report estimates the maximum memory consumption that would be required to load the selected data in the memory of a server running SAP HANA just after the migration. Figure 4 shows the output of an example sizing report. Once you have checked the results and the plausibility, you can start analyzing the result.

Example sizing report output

Figure 4 — Example sizing report output

As you can see from the example, the maximum total memory requirements would be about 1,188 GB. The 50 GB fixed size for code, stack, and other services is already included. In contrast to the initial sizing method, which required a manual calculation, this calculation is performed automatically by the report.
 
This automatic calculation is not enough, however. To correctly size for the SAP HANA migration, you also need to anticipate the year-on-year growth. Let’s say that you anticipate 10% yearly growth for the next three years, for example. ?This leads to a factor of 1.33 (1.1^3). For more information, see the FAQ document attached to SAP Note 1872170.
 
Once the calculations are complete, you will know the required memory size of your machine.


Delta Sizing for Other Types of Solution Migrations to SAP HANA

In addition to supporting an SAP Business Suite migration to SAP HANA, SAP provides help with delta sizing for migrations to SAP BW powered by SAP HANA.
 
SAP BW powered by SAP HANA provides organizations with a solid data foundation to capture, store, transform, and manage data in a scalable, enterprise-ready data warehouse. An SAP BW system can be migrated from any database platform to the SAP HANA in-memory database. To facilitate this migration, SAP provides an ABAP-based sizing report that analyzes the data volume of existing SAP BW systems (based on data samples), including:

  • Obtaining a list of tables from the ABAP dictionary
  • Separating tables into row store and column store
  • Computing the overall SAP HANA memory requirements

This sizing report comes with SAP Note 1736976, which includes background infor­mation and documentation for how to run the report.

Sizing Prepares You for the Next Level

Sizing for SAP HANA is no more complicated than sizing for applications on traditional databases. SAP provides a range of tools and methodologies to guide this undertaking for standalone implementations of SAP HANA, as well as implementations of SAP Business Suite, SAP BW, and other applications that are based on SAP HANA.
 
With the right determination of the sizing KPIs and guidance provided by SAP, your organization will be able to benefit from the opportunites ?SAP HANA offers to take your business solutions to the next level.

 

1 For more information on the Quick Sizer tool, see “Spending Too Much on Hardware?” by Sebastian Schmitt and Dagmar Kirsamer in the October-December 2009 issue of SAPinsider. [back]

2 SAP Application Performance Standard (SAPS) is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. More information is available at www.sap.com/benchmark. [back]

3 Note that the questionnaire results do not take into account resource requirements for backups and high availability, for example, nor do they give recommendations for scale-up or scale-out configurations. The hardware configuration is the responsibility of the technology partners and customers for on-premise deployments. [back]

An email has been sent to:





 

Sebastian Schmitt
Sebastian Schmitt

Sebastian Schmitt (sebastian.schmitt@sap.com) joined SAP in 2007 after studying at the Universities of Cologne, Cáceres, and Barcelona. He has been a member of the Performance and Scalability team since 2008, and is responsible for hardware sizing from a product management perspective and for the cooperation of SAP and hardware vendors in the area of sizing.



More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ