sap hana in-memory db sizing v1 4
DESCRIPTION
Sap Bw on Hana Sizing v1 7TRANSCRIPT
-
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).
-
2012 SAP AG. All rights reserved. 3 SAP & SAP Customer Internal
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. 4 SAP & SAP Customer Internal
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
-
2012 SAP AG. All rights reserved. 5 SAP & SAP Customer Internal
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. 6 SAP & SAP Customer Internal
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)
1) c = source database specific compression factor (where applicable see page 7)
-
2012 SAP AG. All rights reserved. 7 SAP & SAP Customer Internal
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. 8 SAP & SAP Customer Internal
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
-
2012 SAP AG. All rights reserved. 9 SAP & SAP Customer Internal
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. 10 SAP & SAP Customer Internal
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
-
2012 SAP AG. All rights reserved. 11 SAP & SAP Customer Internal
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. 12 SAP & SAP Customer Internal
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