BW on HANA optimisation answers

  • View
    117

  • Download
    11

Embed Size (px)

Text of BW on HANA optimisation answers

Color

BW on HANAPerformance Optimisation Ajay Kumar Uppal

Copyright 2014 Hewlett-Packard Development Company, L.P.

Copyright 2014 Hewlett-Packard Development Company, L.P. #

1

BW on HANA : Scale-Up Versus Scale-Out ConfigurationScale-Out Configuration for BW on HANAScale-Up Configuration for BW on HANACapacity Ramp-Up, Flexibility, ScalabilityCan 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 beyondAlready Available Not Certain. At mercy of SAP. Business Downtime during Capacity Ramp-UpZeroEqual to Migration Time ~ > 18hoursCosts associated with Capacity Ramp-Up No Project Fees Has to be done as a Migration ProjectInstalled based >95% of customers < 5% of customersLargest Production Instance Size> 60 TB 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

Copyright 2014 Hewlett-Packard Development Company, L.P. #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

Copyright 2014 Hewlett-Packard Development Company, L.P. #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 GuideOptimization 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 reasonsOptimization 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

Copyright 2014 Hewlett-Packard Development Company, L.P. #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

Copyright 2014 Hewlett-Packard Development Company, L.P. #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

Copyright 2014 Hewlett-Packard Development Company, L.P. #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.