BW on HANAPerformance Optimisation

Ajay Kumar Uppal

BW on HANA : Scale-Up Versus Scale-Out Configuration 

Scale-Out Configuration for BW on HANA  

Scale-Up Configuration for BW on HANA

Capacity Ramp-Up, Flexibility, Scalability

Can be Ramped-Up easily to almost 200 TBs and this configuration allows maximum flexibility and scalability. Limited scalability.

Capacity Ramp-Down Available   No Provision. SAP Certification for Ramp-Up from 1TB to > $4 TBs and beyond Already Available  

Not Certain. At mercy of SAP.

Business Downtime during Capacity Ramp-Up Zero  

Equal to Migration Time ~ > 18hours

Costs associated with Capacity Ramp-Up No Project Fees  

Has to be done as a Migration Project

Installed based >95% of customers   < 5% of customersLargest Production Instance Size > 60 TB   <4TB

Architecture, Operations and Support

Multi-node System(s) with more parts. Calls for little extra management effort as compared to Scale-Up. Allows better flexibility.

Single Node. Calls for less management and support effort. But incase of failure of Single Node the only fall back is DR.

Table Re-distribution

May call for table(s)- re-distribution once or twice a year and this can be done during planned maintenance.

Little to no need as everything is stored on Single Node.

Reliability

Higher reliability and a spare node can be provisioned in case 1 node goes down.

Low Reliability . If the Single Node goes down , the entire system fails.

BW on HANA: Performance OptimisationI am prepared to share in brief some items that certainly result in performance optimization

• Data Storage Object (DSO) activation is a critical step in process of transferring data from source systems to the business warehouse. We has achieved activation times that are 54 times faster than the previous process.

• Faster DSO activation makes data available more quickly, supports more-frequent loading of data, and more-frequent updates for availability closer to real-time.

• It speeds the flow of data from source systems

• Conversion of In-memory objects where by the extended star schema will be slimmed and dimensions will be realigned and provide scope for Re-architecting some data flows without disruption.

• Suggest Data Volume Optimization strategy to maintain system clean and green

• In a tool-supported post-migration step InfoCubes can be selected and converted to SAP HANA-optimized objects

Housekeeping is the single most significant contributorSAP HANA Data Volume Management Tasks (Sample Template)

Priority Action Description Deadline Startegy

High Define retention times for PSA records individually for all DataSources and delete outdated data. After BW on HANA Live NA

High Schedule periodic batch job for deletion of outdated entries from table ODQDATA_F After BW on HANA LiveHigh Enable the non-active data concept as suggested in SAP Note 1767880 After BW on HANA LiveHigh Archive / move to NLS old/unused data from the DSOs and InfoCube After BW on HANA Live

High End to End Review with Philips Team and recommendations regarding the top BW Schema Tables After BW on HANA Live

High Frequent Review and Check on HANA DB parameter settings After BW on HANA LiveHigh Check whether power save mode is active. For more information, see SAP Note 1890444 After BW on HANA LiveHigh Weekly Check for HANA DB trace settings After BW on HANA LiveHigh Review and Propose a Best Practice for backup procedure Ongoing

High At least a Weekly Review and Monitoring on the recommendations for the alerts generated in the HANA DB system After BW on HANA Live

High Use report RSDRI_RECONVERT_DATASTORE to convert HANA- optimized DSOs back to classic objects. Since from BW 7.3 SP5 Standard DSO’s will support on HANA Schema Algorithm After BW on HANA Live

Medium Consider partitioning for tables that are expected to grow rapidly in order to ensure parallelization and adequate performance. After BW on HANA Live

Medium Propose and Suggest for re-partitioning tables that are expected to grow. HP recommend that you re-partition tables before inserting mass data or while they are still small. After BW on HANA Live

Medium Review, test and implement SAP basis and memory management parameter recommendations to Avoid OOM (Out of Memory )Issues After BW on HANA Live

Optimization 1 : Recommendations to reduce data footprint on HANA Database : As a thumb rule, at least 45-50% of the SAP HANA memory should be reserved for the SQL computations, SAP HANA services, Analytics and other OS related services. The rest can be occupied by the actual data in different column and row stores. Frequent check for BW on HANA system on the memory occupied with data and the rest is left for computations. This will adversely affect the performance as it will increase the number of unloads for different tables from memory to disk which further deteriorates the performance. This obviously will lead to high memory peaks in SAP HANA. In keeping the monitoring we can always keep BW on HANA system in line with Best Practices. Optimization 2 : Provider proposes frequent analysis of HANA database configuration, review of HANA DB parameters, CPU frequency settings and trace settings. Analyzing the objects with high number of records for table partitioning should be considered if these tables are expected to grow rapidly in the future. Optimization 3: To reduce the data footprint in the HANA database, review and implement the recommendations: • Keep Track of the size of the top may be 30 PSA tables and assess the Data Retention Policies . • Cold/Warm data can be unloaded to Disk. • Define retention times for PSA records individually for all DataSources and delete outdated data. Start with

the largest PSA tables   

BW on HANA project: additional questions

Optimization 4 : Delete the outdated entries from table ODQDATA_F be scheduling the periodic batch job ODQ_CLEANUP as suggested in SAP Note 1836773. Recommendation: Table ODQDATA_F is part of the operational delta queue. Refer SAP Note 1836773 (How to delete outdated entries from delta queues - SAP Data Services) and delete the outdated entries from this table using the batch job called ODQ_CLEANUP. Once a day a cleanup process removes all outdated entries from the delta queues so they do not fill up. This is a regular batch job and can be maintained as such. With the ODQMON transaction the job and the retention interval can be configured. In transaction ODQMON, choose menu Goto -> Reorganize delta queues, Schedule a job for reorganization, e.g. ODQ_CLEANUP_CLIENT_004By default the job is scheduled each day at 01:23:45 system timeIf needed adapt the start time and frequency in transaction SM37If needed adapt the retention time for recovery (see F1 help for details)Optimization 5 : Enable the non-active data concept for BW on SAP HANA DB, review and implement the code corrections contained in SAP Note 1767880 - Non-active data concept for BW on SAP HANA DB.After implementing the code corrections, follow the manual steps to ensure that the unload priorities of all tables are set correctly.This would ensure that Persistent Staging Area tables, change log tables, and write-optimized DataStore objects are flagged as EARLY UNLOAD by default. This means that these objects are displaced from the memory before other BW objects (such as InfoCubes and standard DataStore objects). 

BW on HANA project: additional questions

Optimization 6: Understand and review the CPU type, CPU clock frequency, and the hosts. If the CPU clock frequency is set too low, this has a negative impact on the overall performance of the SAP HANA system. Usually the CPU clock frequency should be above 2000 MHz. Optimization 7: If an inappropriate trace level is set for SAP HANA database components, a high amount of trace information may be generated during routine operation. This can impair system performance and lead to unnecessary consumption of disk space. Recommendation: For production usage of your SAP HANA database, we recommend setting the trace level of all components according to the recommendations in the table above. Background: Traces can be switched in the 'Trace Configuration' tab of the SAP HANA studio Administration Console

 Optimization 8: Largest Non-partitioned Column Tables: There are objects with high number of records (more than 300 million). This is not yet critical with regard to the technical limit of SAP HANA (2 billion records), but table partitioning should be considered if these tables are expected to grow rapidly in the future.Recommendation: Consider partitioning for tables that are expected to grow rapidly in order to ensure parallelization and adequate performance. We recommend that you partition tables before inserting mass data or while they are still small.

BW on HANA project: additional questions

Optimization 9 : Largest Partitioned Column Tables (Records : Consider re-partitioning tables that are expected to grow. We also need to look at re- partition tables before inserting mass data or while they are still small.For more information see SAP Note 1650394 or refer to the SAP HANA Administration Guide  Optimization 10 : Largest Column Tables in terms of delta size The separation into main and delta storage allows high compression and high write performance at the same time. Write operations are performed on the delta store and changes are transferred from the delta store to the main store asynchronously during delta merge. The column store automatically performs a delta merge according to several technical limits that are defined by parameters. If applications require more direct control over the merge process, the smart merge function can be used for certain tables (for example, BW prevents delta merges during data loading for performance reasons Optimization 11 : Memory Utilization Details for HANA ServicesThe following table shows the memory usage of the SAP HANA engines (services) and is only a snapshot of the time of the download collection.Different aspects of the memory consumption of the HANA database are highlighted: "Physical Memory Used by Services" corresponds to the "Database Resident Size" in the SAP HANA studio and can be compared with the resident size of the service in the operating system. The sum of "Heap Memory Used Size" and "Shared Allocated Size" roughly corresponds to the memory usage of the SAP HANA database, which is shown in the SAP HANA studio as "Database Memory Usage".The difference between the "Database Memory Usage" and the "Resident Database Memory" can usually be explained by the "Allocated Heap Size".

BW on HANA project: additional questions

Optimization 12: Reducing Table Sizes All tables located in the row store are loaded into the main memory when the database is started. Furthermore, row store tables cannot be compressed as much as tables located in the column store. Therefore, we need to keep the row store as small as possible. RSDDSTAT* data BW statistical data saved in the RSDDSTAT* tables are located in the row store. Since new data is continuously loaded into the Business Warehouse (BW), the amount of statistical data is always increasing. Therefore, it is essential to keep the statistical tables as small as possible, which also provide information about the performance of your queries. Recommendation: Reduce the number of records saved in the RSDDSTAT* tables. Consider the following:When you maintain the settings for the query statistics, deactivating the statistics is the same as activating the statistics internally with detail The settings on the "InfoProvider" tab page affect the collection of statistical data for queries, as well as the settings on the "Query" tab page (transaction RSDDSTAT). For Web templates, workbooks, and InfoProviders, you can decide between activating or deactivating the statistics only. If you did not maintain settings for the individual objects, the default setting for the object is used. If you did not change the default settings, the statisticsare activated. You can delete statistics data using report RSDDSTAT_DATA_DELETE or using the corresponding graphical interface accessible via transaction RSDDSTAT. 

BW on HANA project: additional questions

Optimization 13 : Conversion of InfoCubes and DataStore Objects After an upgrade to SAP NetWeaver BW 7.30 SP5 or later with SAP HANA, all DataStore objects and InfoCubes remain unchanged. In a tool-supported post processing step (transaction RSMIGRHANADB or report RSDRI_CONVERT_CUBE_TO_INMEMORY), DataStore objects and InfoCubes can be selected and converted to SAP HANA-optimized objects.All InfoCubes should be converted to fully benefit of the advantages provided by SAP BW powered by HANA DB. On the other hand, we do not recommend converting DataStore Objects as the advantages of the converted objects can be achieved without modifying the DSOs.Optimization 14 : SAP HANA-optimized DataStore ObjectsBackground: All advantages of HANA-optimized DataStore Objects are now available for standard DSOs too, which renders conversion unnecessary. While HANA-optimized DSOs will still be supported in the future, we do not recommend converting DSOs but, rather, reconverting any existing HANA-optimized DSOs back to classic objects.Starting with BW 7.30 SP10 (BW 7.31 SP09, BW 7.40 SP04), converting classic DSOs to HANA-optimized DSOs will not be possible anymore. SAP HANA-optimized DataStore objects cannot be included in an SAP BW 3.x data flow. If you want to optimize a DataStore object that is part of a 3.x data flow, you first have to migrate the actual data flow.Furthermore, an SAP HANA-optimized DataStore object cannot be populated directly with real-time data acquisition (RDA). The 'unique records' property does not provide any performance gain. In addition, theuniqueness check is not performed at all in BW; instead, the uniqueness is checked by an SQL statement (DBMS exit).Never Generate SIDs: SIDs are never generated. This option is useful for all DSO that are used (only) for further processing in other DSOs or InfoCubes as it is not possible to run a query directly on this kind of DSO.  

BW on HANA project: additional questions

Optimization 15 : SAP HANA-optimized InfoCubes With SAP HANA-optimized InfoCubes, the star schema is transferred to a flat structure, which means that the dimension tables are no longer physically available. Since no dimension IDs have to be created for the SAP HANA-optimized InfoCubes, the loading process is accelerated. The accelerated insertion of data in SAP HANA- optimized InfoCubes means that the data is available for reporting earlier. Optimization 16 : Analytic Indexes - Analytic indexes can be created in the APD (transaction RSANWB) or they can be an SAP HANA model published in the SAP BW system. If you want to use SAP BW OLAP functions to report on SAP HANA analytic or calculation views, you can publish these SAP HANA models to the SAP BW system (transaction RSDD_HM_PUBLISH). Optimization 17 : MultiProvider QueriesFor MultiProvider queries based on SAP HANA, the standard setting for the “operations in BWA” query property (transaction RSRT) is “3 Standard”. However, if the MultiProvider consists of a mixed landscape (there are SAP HANA-optimized as well as non-converted InfoProviders underneath), performance problems might occur.Recommendation: If you are running queries on top of MultiProvider containing SAP HANA-optimized InfoProviders, as well as standard InfoProviders, either: Convert all InfoProviders to SAP HANA-optimized orAlways we need set it to S-standard and Mode 3  Last But not the Least : Always remember to test and make a full system backup before implementing any changes in a productive environment. 

 

BW on HANA project: additional questions

Performance testing – QueryImpact of current run time- using Scale-Out BW on HANA

Less than 10 s

10s to 30 s 30s to 60s More than 60s

020406080

422

40

73

2 10 725

Query before & after BW on HANA

move per typeAvg BeforeAvg After

Type of query

Tim

e (s

)

Less than 10 s

0.00

3.00 3.62 1.6

5Tim

e (s

)

Data-Load results: 'Customer' 12TB BW on HANA PoC

Application Impacting / longNumber of

loads ImprovementA2A Long running load 1 78%CL SCM Impacting load 1 95%CORE 1 Long running load 1 15%Master data Long running load 1 87%One PI Long running load 1 91%PDS Impacting load 1 98%POS Impacting load 1 89%QXP Impacting load 2 91%SCM Dashboards Impacting load 3 81%SMART - SRM Impacting load 3 57%SMART - VBM Impacting load 1 88%

Long running load 2 66%VIPP LI Impacting load 3 64%VIPP PH Impacting load 2 45%

Long running load 4 71%

BPC results from recent 'Customer' 12TB PoC

Input Layouts

Reports