SAP HANA In-Memory Database

Sizing Guideline
Version 1.4 August 2013

SAP & SAP Customer Internal

DISCLAIMER

Sizing recommendations apply for certified hardware only. Please contact

hardware vendor for suitable hardware configuration.

Note that HANA is constantly being optimized. This might have impact on
sizing recommendations, which will be reflected in this document. Therefore,
check for the latest version of this document and the note.

Note that the sizing guideline in this document refers to SAP HANA In-
Memory Database only. Additional applications running on top of HANA (e.g.
Business Information Warehouse, etc.) are not covered in this document (see
note 1637145 for details on sizing BW on HANA).

2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 2
SAP HANA In-Memory Database Sizing Elements

SAP HANA sizing consists of

Memory sizing for static data

Memory sizing for objects created during runtime

(data load and query execution)

Disk Sizing

CPU Sizing

2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 3
SAP HANA In-Memory Database Sizing: Summary

1. RAM
RAM = Source data footprint * 2 / 7 * c1)
2. Disk
DISKpersistence = 1 * RAM2)

DISKlog = 1 * RAM
3. CPU
CPU: 300 SAPS / active user3)
1)
c = source database specific compression factor (where applicable see page 7)
2)
Additional disk space required for backups, exports, shared volumes - see pp. 8f
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 see pp. 10f
2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 4
Memory Sizing: Static Data

Memory requirements for static data is derived from the database footprint of
the corresponding tabes of the source database system

Database footprint in source system must be determined using database

specific catalog information (e.g. in Oracle: dba_segments; in DB2:
syscat.tables).
Database specific scripts and more details on how to determine the database
footprint can be found in note 1514966.

Average compression factor database table size : HANA memory = 7 : 1

Note that this compression factor refers to uncompressed database tables,

and space for database indexes is to be excluded.

RAMstatic = Source data footprint / 7 * c1)

1)
c = source database specific compression factor (where applicable see page 7)
2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 5
Memory Sizing: Runtime Objects

Additional memory required for objects that are created dynamically

when loading new data
when executing queries

We recommend to reserve as much memory for dynamic objects as for static

objects:

RAMdynamic = RAMstatic

So the total RAM is

RAM = RAMdynamic + RAMstatic

= Source data footprint * 2 / 7 * c1)

1)
c = source database specific compression factor (where applicable see page 7)
2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 6
Memory Sizing: Remarks

Compression in source database

The sizing scripts attached to note 1514966 do NOT take into account reduced sizes of the
source data due to database intrinsic compression except the one for DB6, where
compression factors for each table are contained in the database dictionary. This script
delivers correct results also for a compressed database.

If the source database other than DB6 is compressed, you have to adjust the results of the
scripts by a database compression factor. Your DB administrator should be able to help
obtaining this factor.

Unicode vs. Non-unicode database

Migration to HANA is only possible from a unicode system, so the sizing scripts assume a
unicode enabled source database. If the scripts are executed on a non-unicode database,
we recommend to add an uplift (usually, a disk space uplift for Unicode migration of 50% is
assumed).

2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 7
Disk Sizing

Disk size for persistence layer:

DISKpersistence = 1 * RAM

Disk size for log files / operational disk space:

DISKlog = 1 * RAM

Note that this only covers disk requirements for the database files. As with
any database system, additional space must be reserved for
Backup
Exports
Executables

We recommend reserving approximately another 2-3 times the RAM value for
these purposes.
2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 8
Additional Disk Sizing - Details

Disk space is required to persistenly store data that is kept in memory.

The space to be provided must be capable to hold:

Space for at least one process image in case of software failure (1x)
Space for one data export (1x)
Shared volume (across multiple nodes) for Executables, other
data visible for all nodes (up to 1x)

The firsttwo components are essential to provide support.

Note that any backup data must NOT be stored in this space, but should
rather be moved to external storage media.

2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 9
CPU Sizing Based on moderate side-by-side Scenario

Sizing approach similar to user based CPU sizing of BW and BWA

Maximize query throughput by multiuser scenarios with queries of different

complexity out of delivered content, 10-20 million records

Assumptions:
- three different query complexity classes
- three different user profiles (click rate, query complexity)
- same distribution of user classes and query complexities as in BW

Normalization to query throughput per core resp. active user per core

CPU: 300 SAPS / active user

Note that the CPU sizing has to be adjusted so that the server load does not
exceed 65% in average (i.e. to obtain the maximum number of users per
server, the absolute server SAPS capacitiy has to be multiplied by .65).
2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 10
CPU Sizing Complex Scenarios

Influencing factors for additional CPU requirements in more complex query

scenarios:
Data volume
Resource requirements for queries increase linearly with amount of records that have to be
processed.
Query complexity
Queries with computationally expensive operations (e.g. large number of calculated
attributes / key-figures, large number of key-figures to be aggregated) or complex
parallelized execution plans (e.g. a massive number of analytic views underneath a union
node) will take more resources than the sample content queries used in the basic CPU
sizing. Consequently, the CPU sizing has to be adapted accordingly.

What if query complexity of a customer scenario does not match or cannot be

compared with the sample side-by-side scenario?
Run throughput tests with customer specific data and queries to derive sizing
Request expert sizing (chargeable service) through CSN component SV-BO-REQ.

2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 11
Example

Extract from sizing script output:

....
ZZYPLANRES .0625
ZZYPLANRESALL .5
ZZYPROT .0625
ZZYTRACE .0625
----------
sum 186348.438

Table footprint of source database: 186348 MB = 182 GB

Assumption: source DB compressed by factor 1.8

RAM = Source data footprint * 2 / 7 = 182 GB * 2 / 7 * 1.8 = 94 GB

Diskpersistence = 94 GB * 4 = 376 GB
Disklog = 94 GB

2012 SAP AG. All rights reserved. SAP & SAP Customer Internal 12