Migration Sizing for SAP BW on HANA

Dear SAP Users,

This time I would like to share my experience on BW on HANA migration situation.

As an initial pre requisite it is required to understand the migration sizing who have an existing SAP BW running on a “traditional” database platform and plan migrating to HANA.

The purpose of doing this is to predict resource requirements for a BW system on a SAP HANA database.

The sizing report /SDF/HANA_BW_SIZING is a convenient method to estimate the memory requirements of a BW system after migration to SAP HANA. The report requires ST-PI 2008_1_7xx SP8 and SAP NetWeaverBW 7.0 SP 1 or higher.

Before running the report /SDF/HANA_BW_SIZING, please consider the following:

• In order to run the report in parallel, make sure that for the specified degree of parallelism a corresponding number of dialog work process is available.
• Run the report on up-to-date database statistics.
• Please try to set the dialog timeout parameter ‘’ rdisp/max_wprun_time ‘’ to minimum of 7200 seconds.

Report Selection Screen: SE38 - ‘/SDF/HANA_BW_SIZING’

• Check flag Store output file  to save output to specified file in the al11 directory or it can saved as a text file.
• Specify number of parallel processes to analyze tables. Make sure you have enough free work processes.
• Tables with less than 1MB size can be suppressed in the output (but are still counted for sizing).
• Select precision. Higher precision results in higher sampling rates and higher runtimes. Usually, low precision delivers sufficiently reliable results.
• Specify number of years to be considered for growth and check the flag enable Future Growth calculation.
• Enter value for relative or absolute growth.
• Decide if you want to specify yearly growth as an absolute value or relative to the current size.

Sizing Report Results: Summary:

The result screen of the Sizing Report contains very detailed information on the source system and its corresponding HANA sizing:

• Overview of the size of the source DB, based on sampled data. Here the sizes are based on an ABAP internal representation of the data.
• A summary of the resources that this system at minimum requires when running on a HANA database
• Extrapolated resource requirements in future, based on specified growth rate
• Overall sizes for row and column store tables, both for master and worker nodes.
• Detailed size information per table, including estimated ABAP size based on sample, derived HANA size, and record count. This detailed list can be used to directly determine database tables which should be targeted by housekeeping measures.

Sizing Report Results: How to Read:

SOURCE DB CONTENTS:

• Summary on tables found in source DB
• Size figures reflect sizes of tables as if they were loaded into ABAP internal tables (ABAP size) –based on sample set of records read from each table.

NOTE: This section describes the contents of the source database as derived from data sampling. Also note that indexes, temporary space, etc. of the source DB are NOT reflected here!

Minimum SIZING RECOMMENDATION :

• Minimum amount of memory required to operate given system on a HANA database. This amount includes space for storing database tables as well as space for runtime objects and needs to be physically available on a target landscape (HANA size).

SIZING RECOMMENDATION - FUTURE GROWTH:

• This section shows an estimation on the future growth of the HANA system, based on the specified growth rate. Anticipated growth rate of source system should be specified. Growth is then split among system tables (10%) and tables with business data (90%).

SYSTEM INFORMATION:

• This section shows information on the system on which the sizing report was executed, runtime information and the most important parameters of the report.

TABLE DETAILS:

• Detailed list if memory consumption figures per database table, including non-active and secondary index share (if applicable), but without runtime uplift. Important to identify impact of largest tables and tables subject to housekeeping (ABAP and HANA size).
• Provides details on Row Store and Column store tables. And additional classification of tables w.r.t Write – Optimized DSO’s, Change log of standard DSO’s, PSA tables.

BW on HANA Sizing: Scale Out

If a single HANA node cannot accommodate data due to limited memory, data has to be distributed across multiple nodes (scale-out).

• Master node will handle system load and transactional load: ABAP system tables and general operational data of the BW are stored on the master node. Note that this includes both column store and row store data. DDL statements are executed on this node, global locks are acquired here.
• Worker nodes will handle OLAP queries as well as loading/staging/activation/merging.BW data (master data + cubes/DSOs/PSAs –all tables that have been generated by BW) is distributed across the column stores of all workers. This ensures a balanced utilization of the available CPU and memory resources. Note that no column store data (except system tables) may be stored on the master node.

BW on HANA Sizing: How to Size HANA Systems:

HANA cannot allocate the complete physical memory of each node. Some space must be reserved for the operating system and other services. As a rule, 10% of the first 64 GB and another 3% of the remaining memory will be reserved exclusively for OS purposes.