sap hana in-memory db sizing v1 4

SAP & SAP Customer Internal

SAP HANA In-Memory Database

Sizing Guideline Version 1.4 August 2013

SAP & SAP Customer Internal

2012 SAP AG. All rights reserved. 2 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).


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


SAP HANA In-Memory Database Sizing: Summary

1. RAM

2. Disk

3. CPU

RAM = Source data footprint * 2 / 7 * c1)

CPU: 300 SAPS / active user3)

DISKlog = 1 * RAM

DISKpersistence = 1 * RAM2)

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

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


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)



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:

So the total RAM is

RAMdynamic = RAMstatic

RAM = RAMdynamic + RAMstatic

= Source data footprint * 2 / 7 * c1)



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).


Disk Sizing

Disk size for persistence layer:

Disk size for log files / operational disk space:

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.

DISKlog = 1 * RAM

DISKpersistence = 1 * RAM


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.


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

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).

CPU: 300 SAPS / active user


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.


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

sap hana in-memory db sizing v1 4

Documents