Another installment in the serie of BW performance tuning ideas. While not comprehensive, it is intended to increase the knowlegde of BW developers with hints, suggestions, explanations and references to SAP Notes that allows developer to improved BW Performance. In this session we look at 5 different areas.
By Dr. Berg
NOTE: I strongly recommend the book "SAP NetWeaver Business Warehouse: Administration and Monitoring " 2010 edition by Olaf Klostermann and Olaf Klostermann it is 590 pages of really useful info.
Hardware settings | If you want to see how your BW system is setup, goto SA38 and run the program RSPARAM report, it will show you all setting. Just place the cursor on a field in the report and press F1 and you get all details
|
Buffering and slow log-file writes | If you have a very long-time log-file-sync, you should buffer Dimensional IDs (DIMID), System IDs (SIDS) and hierarchy IDs (HIEID) to decrease the time the system spends committing individual records to the NRIV table and syncing the log files. Goto SNRO, click Edit -> Set Buffering -> Main memory try setting this to a higher number (normal is upto 1000, but for a very high number of IDs, you c an set this upto 10,000). Another idea is to split the log and data files on different RAID sets. This may be hard to do on a Storage Area Network (SAN), but for systems with over 40-60ms on each sync, moving the log files can make a significant performance difference (PS!: the log file sync times are listed in your EarlyWatch report as a seperate section).
|
High-Cardinality | When you flag a dimension as “high cardinality” SAP BI will use a b-tree index instead of a bit-map index. This can be substantially slower if the high cardinality does not exist in the data in general. Consider only flagging high-cardinality dimensions if a substantial amount of records exists (more than 8-10 million) or if the system is substantially unbalanced (i.e. 30+%), not the 20% we taught in classes a few years ago...
|
Query | I recommend that developers start looking at queries by using the RSRT transaction and click on the "Performance" tab. And get the list of queries you want to examine. Also use the RSRV checks to see if database patches are current, aggregates are recommended, indexes and statistics are updated and much more. It is a great place to start the analysis. Also, familiarize your self with all performance information in RSRT as well.
|
Parallel queries | To avoid an overflow of the memory, parallel processing is cancelled as soon as the collected result contains 30,000 rows or more and there is at least one incomplete sub process. The MultiProvider query is then restarted automatically and processed sequentially. What appears to be parallel processing, is actually sequential processing plus the startup phase of parallel processing. You can change the default value of 30,000 rows, or change the size of the result set (MPRO_MAX_RESULT) to higher than 5MB for queries with large result sets that are hitting multiproviders with more than one infocube and/or DSO (see notes 629541, 622841, 607164, and 630500).
|
DBA Cockpit | A cool feature in SAP_BASIS Service pack 12, is a new DBA cockpit (DBACOCKPIT). PS! you probably will have to change to the new central scheduling calendar (you can migrate using the DB13C transaction)..
|