By Dr. Berg
In this second installement of a blog serie on performance tuning, I want to share some of the observations we discussed in the on-line BI performance Q&A today at SAP Insider Forum. We had many great questions and I have summarized a few of the answers for your enjoyment.
You can also meet me at the Meet-the-expert session at the BI 2011 conference in Vegas next week or stop by the vendor session to ask any questions you may have on BI performance tuning.
Some BI Performance hints
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 can set this upto 10,000).
High-Cardinality Flags - When you flag a dimension in the Infocube 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 (star-joins cannot be used with b-trees). 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+%)
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.
Parallel Query Execution - 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 new feature in SAP_BASIS Service pack 12, is a new DBA cockpit (DBACOCKPIT). It has more functions than you had before and you no longer need to use the 'old' codes. They are all available in the new DBA cockpit.
- DB02-Space management,
- DB12-backup,
- DB13/DB13C - configuration,
- DB24-jobs
- ST04-performance,
While I remember: Make sure you also upgrade to latest kernel patch before using the cockpit, or you may get a bunch of error messages (programs missing). PS! you probably will have to change to the new central scheduling calendar (you can migrate using the DB13C transaction).
Further Reading - Best BI Admin book Ever :-)
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. It should be mandatory for all BW developers, basis and system admins.