HANA Sizing

Reference Sizing Guide

By Dennis Padia
 TABLE OF CONTENTS
1 Purpose ...................................................................... 3
2 Scope ....................................................................... 3
3 Evolution of the Document ........................................................ 3
4 SAP HANA Approach ............................................................. 3
4.1 Overview ................................................................. 3
4.2 SAP HANA Scale-up .......................................................... 3
4.3 SAP HANA Scale Out ......................................................... 4
4.4 SAP HANA Appliance Model .................................................... 4
4.5 SAP HANA Tailored Data Integration (TDI) .......................................... 4
5 Design Overview ................................................................ 6
5.1 Capacity & Sizing ............................................................ 6
5.1.1 Overview .............................................................. 6
5.1.2 New HANA Appliance ..................................................... 6
5.1.3 Migration to SAP HANA Applications ......................................... 11
5.1.4 Standalone HANA Migration ............................................... 17
5.1.5 Sidecar Scenarios ....................................................... 18
6 Type of HANA Deployment ....................................................... 18
7 Scale Up or Scale Out? .......................................................... 21
8 Sizing – Test Case .............................................................. 22
AUTHORS ....................................................................... 26
ABOUT THE COMPANY ............................................................. 26
1 PURPOSE
This document provides the quick guidelines on HANA sizing based on the installation scenario, its method of
deployment. It documents the refinement and explanation of the various scenarios available for HANA.

2 SCOPE
This document covers the sizing requirement of HANA and gives an insight on the strategy that needs to be
adopted in order to properly size the HANA appliance. Scope of this document covers SAP HANA sizing only.
Disaster Recovery capability on HANA Appliance will be covered in the next phases.

3 EVOLUTION OF THE DOCUMENT

This document is a point in time snapshot of SAP HANA based on the current hardware capabilities available in
market. As technologies evolve and further releases of HANA are introduced resulting in new capabilities, this
document will be updated to reflect current capabilities.

4 SAP HANA APPROACH

4.1 OVERVIEW
The SAP HANA Database manages data in a multi-core architecture of data distribution across all cores to
maximize RAM locality by using scale-out (horizontally) and scale-up (vertically) functionality. Along with the
functionality, there are various approach which are offered by SAP like Appliance Model and Tailored Data
Integration (TDI) which customer can opt for based on the requirement and flexibility of IT operation processes.
The key part is to get the HANA Hardware correctly provisioned, otherwise it can be an expensive mistake.

In this design document, we will cover the best deployment options which can be adopted for designing SAP
HANA based on the support provided by SAP.

4.2 SAP HANA SCALE-UP

In SAP HANA Scale-up, we look to build a single or multi-SID System with as many resource as possible. It typically
refers to architectures that use a single, fixed resource controller for all processing. In order to increase the
capacity, attach disk shelves up to the maximum for which the controller is rated. Since only storage shelves are
added when expanding capacity, scale-up architectures offers a very cost-effective capacity upgrade.

The drawback of Scale-up approach is that it can suffer from performance problems when capacity is added and
the controller resources are insufficient for the additional data.
4.3 SAP HANA SCALE OUT
In SAP HANA Scale-out, cluster of smaller SAP HANA systems connects together into one clustered database. As
HANA is shared nothing architecture, so there must be shared storage for data perspective which is delivered
either with a clustered filesystem or a SAN.

Scale-out typically refers to architectures that scale performance and capacity separately or in lockstep by not
relying on a single controller, but instead provide processing power with each unit of disk which guarantees that
performance doesn’t decline when scaling the system.

The pitfall of Scale-out approach is that there is no option to add capacity without adding controllers.

4.4 SAP HANA APPLIANCE MODEL

SAP HANA is a flexible, multipurpose, in-memory appliance built on Intel, Xeon processor that combines SAP
software components optimized on hardware provided and delivered by SAP’s leading hardware partners.

The appliance delivery of SAP HANA is pretty comfortable as it comes with pre-configured hardware set-up and
preinstalled software package which is fully supported by SAP but on the other hand it comes with limitations
regarding hardware flexibility. On using HANA appliances, it may require change in the established IT operation
processes.

4.5 SAP HANA TAILORED DATA INTEGRATION (TDI)

The SAP HANA Tailored Data Integration option, also called TDI, allows customer to use certain parts of their
existing hardware and infrastructure components for the SAP HANA environment. Typically, a SAP HANA
appliance comes with all necessary components pre-configured, as provided by certified SAP HANA hardware
partners. TDI targets the usage of certain hardware and infrastructure components that might already exist in a
customer’s landscape, instead of using the corresponding components that are delivered with a HANA appliance.
Depending on the existing data center layout, the SAP TDI can –

1) Reduce hardware and operation costs by reusing existing hardware components and operation
processes.
2) Migration risks and optimize time-to-value by enabling existing IT management processes for the SAP
HANA implementation.
3) Deliver more flexibility in hardware vendor selection by making the best use of the existing ecosystem.
5 DESIGN OVERVIEW

5.1 CAPACITY & SIZING

5.1.1 Overview

SAP HANA is the game changer in the database innovation. HANA is designed to provide real-time analytics and
transaction processing at lightening speeds, which is possible because of the in-memory technique where all the
processing is done in the memory and actually disk is only used for the persistency.

The critical factor for SAP HANA implementation is the right sizing of the server based on the business
requirement. When we talk about right sizing, it means amount of memory, the CPU processing power needs to
be calculated. SAP has provided various method to achieve the accurate size based on the client requirement.

5.1.2 New HANA Appliance

QuickSizer method is useful for the customers who will be implementing SAP HANA instance as standalone
instance or performing the implementation from scratch with limited details about the data models for SAP BW
scenario or planning to implement Business Suite on HANA.

In QuickSizer, there are three scenarios –

Below table provides the self-explanatory steps in order to get the sizing for the standalone Instance for SAP
HANA for any of the above scenarios.
Description Screenshot

Start the QuickSizer tool:

https://websmp109.sap-ag.de/quicksizer
Create New Project

Choose Standalone HANA

HANA memory sizing is derived from the size

of the tables in the source database. Note
that only tables must be taken into account.
Space for indexes, temporary table spaces
etc. must be excluded. Run the sizing script
attached to SAP note 1514966 to obtain
correct size information from your source
database system catalog.

The number of users is optional.

Specifics for Standalone HANA Input

Enter the number of concurrent users

Enter the source data footprint in GB
Enter the compression factor, i.e. the ratio of
the sizes of uncompressed data tables
(without their indexes) on the source
Description Screenshot
database and the memory requirements of
these tables in HANA. We strongly
recommend using the default value if you do
not have reliable information justifying a
different compression factor.

Output
Description Screenshot
Input

Specifics for SAP NetWeaver BW Powered by

SAP HANA

 Enter the Avg workday & Peak Load time

 Enter the user groups based on the
usage, basically there are
three types of users: Information
Consumer, Business Users, Expert Users Output
 Enter the Data Upload records
 Enter the Row Table Footprint, Column
Tables Footprint and Column
Compression
 Enter InfoCubes details

Enter DataStore Objects

Description Screenshot
Input

Specifics for SAP Business Suites powered

by HANA

Throughput based sizing performed for

Output
implementing the ERP Sales & Service
component of SAP Business Suite.
5.1.3 Migration to SAP HANA Applications

In order to migrate existing system from any DB platform to SAP HANA, SAP recommends below flow as
described below –

SAP Netweaver BW Powered by SAP HANA

For customers who have an existing SAP BW running on a ‘traditional’ database platform and plan migrating to
HANA. ABAP based BW on HANA sizing report (SAP Note 1736976): database platform independent, leverages
BW semantic information, high level of accuracy.

Pre-requisite

Starting with the BW version 7.3 SP05 you can run the SAP BW on SAP HANA DB Platform. In order to migrate
an existing SAP BW system from any DB platform to SAP HANA, SAP recommends using the new ABAP sizing
report /SDF/HANA_BW_SIZING for SAP BW. The sizing report /SDF/HANA_BW_SIZING is a convenient
replacement of the database dependent sizing scripts provided in SAP note 1637145. Major advantages of the
ABAP report as opposed to the sizing scripts –

• Easy to deploy and use – no DB administrator required

• Versatile parameterization – control resource consumption and speed
• Independent of source database compression
• Considers user defined future growth

The report is available with ST-PI 2008_1_7xx SP7. A preliminary version based on ST-PI 2008_1_7xx SP6 as well
as an updated version for SP7 can be obtained from note 1736976. The report requires SAP NetWeaver BW 7.0
SP 1 or higher.
Description Screenshot

Login to SAP BW System and run t-code SE38 >

Enter the report name /SDF/HANA_BW_SIZING
and execute

Input

This is the sample input & output screen for the

ABAP report
Output
SAP Business Suite Powered by SAP HANA

For customer who have an existing SAP Business suite running on a ‘traditional’ database platform and plan
migrating to HANA. ABAP report on HANA Sizing (SAP NOTE 1872170) will provide output on the estimation of
the memory requirement of HANA. The current version of the report is valid for sizing of SAP HANA from SPS7
to till date.

Pre-requisite

The report ZNEWHDB_SIZE can be implemented in your customer namespace. It requires at least SAP_BASIS
620. It is also be available in ST-PI 2008_1_[620-710] SP09 and ST-PI 740 SP00 and above under the name
/SDF/HDB_SIZING. Both reports have the same code and functionalities. The only difference is the installation
procedure. The reports are suitable for sizing of all NetWeaver based products (at the exception of BW).

Before running the report you must:

 Test the report execution in the Development and QA system. The report implementation can be tested
easily on one small table (i.e T000).
 Since the parallelism is achieved via RFC calls to dialog work processes, the dialog timeout parameter
“rdisp/max_wprun_time” must be set high enough. We recommend at the very minimum 3600 seconds
(7200 is recommended). If you run into timeout errors and cannot increase the timeout limit, decrease
the
report accuracy or choose to execute the report on a specific server group where the timeout limit is higher.
 Make sure the database statistics are up-to-date.
 Choose where to run the report. It can run on a recent copy of the production system.
 Plan some long execution time. The runtime varies with the sampling size chosen, the size of the database, the database technology and the
parallelism. The runtime of a full database sizing will exceed 1 hour in most cases.
 The report requires authorization object 'S_ADMI_FCD' with authorization field PADM.
 Check the data store distribution. If you plan to have a special distribution of tables across the Row and Column store, this should be specified in
the report. See question 15 for details.

Description Screenshot

Login to SAP BW System and run t-code SE38 >

Enter the report name /SDF/HDB_SIZING and
execute

Input

This is the sample input & output screen for the

ABAP report
Output
5.1.4 Standalone HANA Migration

This section describes the sizing of the SAP HANA in-memory database as it is used e.g. for replication of ERP
data coming from an SAP ERP System. Other applications running on the top of the SAP HANA may have
application specific sizing algorithms.

Determine the Database Footprint of the data

Memory sizing of HANA is determined by the amount of data that is to be stored in memory, i.e. 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,
we apply a compression factor to determine the size of the RAM needed for HANA.

Description Screenshot

Download “get_size.zip” from SAP

Note 1514966

Attached shell script "get_size.csh" for (DB6 and Oracle based NetWeaver systems) or
"get_db4_nonbw_size.sh" (for DB4 / iOS based systems - please read the attached README
SAP Netweaver Based System
file) can be used to obtain the database footprint of the tables (for DB6 and Oracle based
NetWeaver systems).

Sizing Calculation

SAP has provided the sizing formula based on the output from the sql script. Use the output from sql script to
calculate the RAM size and Disk Size.

RAM = Source data footprint * 2 / 7 * c 1)

Diskpersistence = 1 * RAM 2)
Disklog = 1 * RAM
CPU : 300 SAPS / active user 3)

1)
c = source database specific compression factor
2)
Additional disk space required for backups, exports, shared volumes
3)
Based on a sample query scenario in a side-by-side scenario with moderate size. Scenarios with higher
complexity require scenario specific CPU sizing
5.1.5 Sidecar Scenarios

In order to accelerate existing ABAP applications in ERP, customers can now leverage SAP HANA as the secondary
database (Sidecar) keeping traditional database as primary.
The approaches that can make ABAP applications accelerate by leveraging the optimization techniques through
SAP HANA.

6 TYPE OF HANA DEPLOYMENT

SAP HANA can be deployed in a number of configurations that are approved in varying degree for production
environments (or not approved for production at all).
Multitenant Database Container (MDC)

The Multitenant Database Container deployment type was introduced with SAP HANA SPS 09, and makes it
possible to run several SAP HANA instances on the same hardware in a production environment. It provides an
alternative to a virtualized deployment, which is only production approved in some scenarios, and the MCOS
(Multiple Components One System) deployment, which is not approved for production environments.

Multiple Components on One Database (MCOD)

MCOD deployments are characterized by multiple applications on one SAP HANA system. SAP Support deploying
and running multiple applications on a single SAP HANA production database only for packaged applications and
scenario listed on the “White list” included in SAP Note 1661202. If a particular packaged application or scenario
is not on the "White List", then it is not supported to run together on the same SAP HANA database with any
other packaged application or scenario.

Virtualized

SAP HANA systems can be run on virtual machines with restrictions to the hypervisor (including logical
partitions). In order to get more information on SAP HANA virtualized, see SAP Note 1788665, 2230704 and
2024433.

Multiple Components on One System (MCOS)

MCOS deployments are characterized by multiple SAP HANA systems on one host. This configuration is approved
for production environments as of SAP HANA Support Package Stack (SPS) 09. This is restricted to single host /
scale-up scenarios only. Please keep in mind that multi-SID requires significant attention to various detailed tasks
related to system administration and performance management. In order to get more information about
running SAP HANA as MCOS, see SAP Note 1681092.
Scenarios MDC
In MDC architecture, there is one SAP
HANA System (SID) with numerous tenant
Overview
DB running inside that one SAP HANA
System.
1) The tenant database are by default
isolated from each other in regards to
application data and user management.
Pros
2) Maintanance and Administration of
tenant DB had been simplified as it
consume less resource.
1) As all tenant DBs are part of the
same SAP HANA DBMS, the all run with the
same HANA Revision. So in case of
upgrade for one SAP System, entire HANA
Cons System DB needs to be upgraded.
2) SAP HANA System Replication works
with "all or nothing" approach where all
tenant databases are subject to failover
to another data center.
MCOD Virtualization MCOS
In MCOS deployment, multiple SAP HANA
In virtualization deployment, Hypervisor is
In MCOD deployment, multiple DBMs (SID) running on a single HANA
used to partition SAP HANA Appliance into
application running on one SAP HANA appliance. Each SID act as an independent
smaller partition/VMs. Each VM will act
System database on the respective HANA
independent of the other.
appliance.
1) Each HANA SID will be an independent
1) Using hypervisor, multiple VM can be
database irrespective of which HANA
created on HANA appliance and on each VM we
revision is installed on another HANA
can install different flavor of OS and HANA
SID.
version.
2) In case of upgrade, only a particular
2) HANA HA can also be attained using the
HANA SID can be upgraded without
built-in feature of Vmware HA.
affecting the other HANA SID.
1) Production Support is restricted to
1) HANA on VM has some restriction which SPS09 or higher due to the availability
1) SAP Support deploying and running
can be identified in SAP Note 1788665 of some resource management parameters
multiple applications on a single SAP
2) Creating multiple VMs on one HANA (e.g. affinity)
HANA production database only for
appliance will result in addition resource 2) It utilize more resources and in case
packaged applications and scenario
utilization for VM. if issue arise on multi-DB, SAP or
listed on the “White list” included in
3) Licensing cost for Vmware vSphere per hardware partner may ask you to stop all
SAP Note 1661202
physical processor is also required. but one of the DBs and see if the issue
persists.
7 SCALE UP OR SCALE OUT?
It’s always a confusion among consultant whether to go for Scale-up or Scale-out HANA appliance. In this topic,
I will just brief some important factors that needs to be taken care while working on the designing of HANA
architecture.

The first thing to remember is that HANA systems require a CPU to RAM ratio, which is fixed in production
systems, at 256 GB/socket for analytic use case and 768 GB/socket for SAP Business Suite. If you check the
hardware in market, currently in mainstream Intel systems are available with 4-8 socket. So in a single system
HANA System can up to as below –

Analytics System = Maximum of 2 TB (8 Socket * 256 GB/Socket)

Business Suite = Maximum of 6 TB (8 Socket * 756 GB/Socket)

So considering the above fact, data volume and the future business growth of customers, the most important
thing though is to get production hardware correctly provisioned otherwise it can be an expensive mistake.

Business Suite

It is advisable to “Scale-up” your business suite based on the current generations of Intel CPUs available in
market. With 8 Socket, you can expand your HANA for Business Suite up to 6 TB which can fit 95% of SAP
Customers.

If you are performing migration from any database to HANA, even the data footprints tends to reduce to “one-
third” after moving to HANA. For example, if your database size in current ECC System is 2.4 TB after moving to
HANA data size will reduce to around 800-900 GB.

So it is advisable to first conduct a sizing exercise explained in the above topic to decide what size you need to
today. Also it is not necessary to worry about RAM expansion after 6 TB because you naturally undertake
optimization projects which will reduce memory footprints as you grow.

BW and Analytics

First and the foremost advice for BW and Analytics system is to go for Scale-Up system if you requirement is less
than 2 TB. With BW, you have option of the IQ near line store, where cold data can be stored at very low cost. It
is advisable to implement NLS before considering scale-out as it is much more effective and will increase HANA
performance. With HANA SPS09 there is also dynamic tiering for BW, which allows PSA data to be persisted on
a warm store, further reducing HANA footprint.

But in case if your need is more than 2 TB, go with scale-out system. BW scale-out works extremely well, and
scales exceptionally well – better than 16-socket or 32-socket scale-up systems even.

NOTE - Don’t consider any of the > 8-socket systems for BW or Analytics, because the NUMA overhead of those
sockets is already in effect at 8-sockets (you lose 10-12% of power, or thereabouts). With 16- and 32-sockets, this
is amplified slightly, and whilst this is acceptable for Business Suite, but not necessary for BW.
8 SIZING – TEST CASE
In this section, we will walk through on the test case of HANA sizing that was being adopted for one of the
retailing major and their requirement was to move their ECC, SCM and BW system to HANA from Oracle
database. We will discuss on the key points that are required for proper HANA Sizing –

1) RAM. It’s the only thing that matters.

HANA Database is configured based on the requirement of RAM. So it’s only the RAM which needs to be
figured out as other things will be taken care by hardware vendor with pre-approved sheet from SAP for
each of their appliance and will provision you the Disk, CPU Core, Network based on your input on RAM.

2) Run ABAP Report

As the customer was migrating the system, the first and foremost thing is to implement SAP Note 1872170
for Business Suite on HANA and SAP Note 1637145 for BW on HANA. Implement the latest correction of
/SDF/HDB_SIZING or /SDF/HANA_BW_SIZING report in order to get the result more accurately.

For the sizing of the entire database leave the “list of tables fields empty”, and execute the report in
background.

Once the report is completed, you must analyze the error log and correct them if necessary.
The total estimated memory requirement in this scenario is 1683.5 GB. The report estimates the maximum
memory consumption that would be required to load the selected data in the memory of a server running SAP
HANA. This estimation is done considering 20% of the LOB records stored on disk are required by application
and loaded to memory.

The sub-totals called “Work Space” and “Fixed size” contains all non-data components necessary for running
SAP HANA like –

 Space required for delta stores.

 Space required for merge operations.
 Space required for the metadata catalog, nameserver, statistics server
 Space required for query processing (SQL Cache)
 Result Cache
 Tables not considered by report

The total estimated memory requirement given by the report should not be considered as the final memory
sizing result. Future growth needs to be considered as well.

NOTE – Not all the server memory will be available to HANA. The sizing must take in account the global allocation
limit.
3) Consider Future Growth

The memory sizing estimation described in Step 2 is the initial memory requirement based on the current
database size but the future growth of data needs to be considered as well. Below are the ways to identify
future growth -

 Analyze EWA report and check for the data growth pattern for each month.
 Involve application owner and identify the future business prospect like new project in pipeline, new
region to be added, new interface to be connected.
 Identify whether HANA database is going to be used as a Sidecar besides being the primary database
of the migrated system.
 Future prospect of configuring SDA or connection directly to HANA.

Identifying above facts are important as it helps in size the HANA database better. In our case, we have
identified the data growth of around 60-80 GB per month and the client was not planning to integrate
anything with HANA besides being used as primary database for the system.

We have sized the HANA appliance for ECC System as 3 TB based on the artefacts discussed above. We have
provided the RAM size to the vendor and they have provisioned disk, CPU Core, network based on the same.

4) Type of HANA Deployment

As discussed in Point 1, the requirement of ECC stands out to be 3 TB so the appliance was provisioned as 3
TB RAM on 2 blade server. As per SAP Standard, on one blade server we can have 1.5 TB of RAM/blade for
Business Suite on HANA, whereas for analytic system it is 756 GB of RAM/blade.

So considering the above fact, HANA appliance was configured as 3 TB on 2 blade server. Further increase
on the appliance is possible only when 2 new blades are being incorporated into the appliance which can
further increase the capacity of appliance to 3 TB. So full capacity of the appliance stands out to be 6 TB on
4 blade for business suite on HANA.

ASCS Instance
1 CPU, 4 GB RAM
(FT Enabled)

ECC SAP App

OS RHEL 6.8
ERP 6.0 EHP 08

PAS AAS1 AAS2 AAS3

8 CPU, 64 GB RAM (All Servers) ECC System Replication ECC ECC
Memory – 3072 GB SUSE HaE Cluster Memory – 3072 GB System Replication Memory – 3072 GB
Revision – 122.03 [Automatic Failover] Revision – 122.03 [Manual Failover] Revision – 122.03
[Dedicated N/W for
System Replication]
DATA CENTER 1 DATA CENTER 2
Retailing major usage for BW and SCM was minimum like 128 GB RAM for each system. So it was been
decided to go with multi-SID (MCOS) installation for BW (128 GB), SCM (128 GB) and SolMan (256 GB) on
756 GB RAM/blade appliance. When you choose MCOS option you have to keep in mind that your memory
has been restricted as per global allocation limit but the CPU usage is still shared among the system installed
on the HANA Server.

The idea for choosing MCOS over Multi-Tenant Database Container (MDC) is its feasibility to install
independent version of HANA Database for each system irrespective of having them on the same server.

When you install BW system with any Business Suite, it is BW who decides the RAM size on the appliance as
its CPU/RAM ratio is different to that of business suite. In this case, BW is installed on the appliance sharing
it with SCM and SolMan, its RAM size restricts to 756 GB RAM/blade. Increase in RAM is possible only by
adding the blade to the appliance which can further increase the size to 756 GB RAM/blade. So in total with
4 blade server, we can size server up to 3 TB.

ASCS Instance
1 CPU, 4 GB RAM
(FT Enabled)

BW
OS RHEL 6.7
Multi SID Installation

BW PAS AAS1 ASCS Instance

Memory – 128 GB 2 CPU, 16 GB RAM (All Servers) 1 CPU, 4 GB RAM
Revision – 122.03 (FT Enabled)

SolMan
OS RHEL 6.7

SolMan (ESM) PAS AAS1

2 CPU, 16 GB RAM (All Servers)
Memory – 256 GB
Revision – 122.03 3 CPU, 24 GB RAM (All Servers)

SCM
OS RHEL 6.7

Total Memory – 768 GB PAS AAS1

SAN – 2.5 TB Disk Stg SCM
Memory – 128 GB ASCS Instance
Revision – 122.03 1 CPU, 4 GB RAM
(FT Enabled)
AUTHORS
Dennis Padia, is the SAP BASIS and HANA Consultant at L&T InfoTech. He has completed his Bachelor of
Engineering in Information Technology from Sardar Patel University, Gujarat and has total IT experience of
6.5 Years. During his tenure in L&T InfoTech (2014 - till date) his work revolved around HANA and its Eco
systems (SLT, BOBI, BODS, and BW ABAP on HANA), migration, upgrade.

ABOUT THE COMPANY

Larsen & Toubro InfoTech Ltd. (L&T InfoTech), one of the fastest growing global IT services company, is
ranked by NASSCOM as the 6th largest software & services exporter from India. Its parent company is Larsen
& Toubro Ltd. (L&T), a technology, engineering, manufacturing and construction conglomerate, with global
operations.