TOP-10 BI 7.

x Performance Tuning Tricks

Lately my team and I has been working on performance tuning efforts for BI7.x customers. Much of the performance issues are due to technical configuration and some fixes are rather simple. In this blog, I will attempt to address the top10 simplest and most common performance tuning issues I see at companies. Also, join me at the BI 2011, conference on March 15-18 in Las Vegas, or on June 7-9 in Amsterdam, where I will be presenting more in-memory processing options with BWA and BO Explorer. 1. BEx Flags in conformance layer DSOs Often many DataStore Objects are flagged as 'reportable', even when not being used for reporting. For all these objects, the system generates SIDs during data loads which increases the load time. By removing this flag, the system will not spend processing time on SID generation, resulting in faster data loads. 2. Outdated Database Statistics Database statistics are used by the database to route queries. Best practices is to refresh these when large data loads are done, or on a periodic basis. If the statistics are not up to date on many cubes or the data sample size is small the optimizer at the database level may use inefficient routing of queries, causing poor database performance. You should refresh the statistics on a weekly basis with an adequate sample size (20% is default). Don't refresh every day! 3. Invalid Database Indexes Maintaining valid Database indexes for infocubes is critical for faster data reads. This is a problem for infocubes with a high-cardinality flag set (causes the index type to change from bitmaps to b-tree). Check this in RSA1->Manage IC>Performance tab and repair these indexes in RSRV for impacted infocubes. 4. Infocube Partitioning When data in infocubes becomes very large (more than 40-100 million records), it is very important to have both physical and logical partitioning of these objects to have good load and read performance. Maintain physical partitioning by a time characteristic like 0FISCPER or 0CALYEAR and consider implementing logical partitioning of the objects as standard design principle. 5. Infocube Compression In infocubes, data requests are often not compressed regularly and there are uncompressed requests that are several months old, some with large data load sizes. This leads to increased load and index processing times due to large Ftables. Consider compressing the requests periodically to reduce the F-table size. 6. DSO secondary Indexes Often there are no secondary indexes defined for DSO objects. This frequently lead to slower table lookups in ABAP code used in transformations or update rules if the lookups do not use the primary index. Review table lookups in all ABAP code modules and implement secondary indexes as necessary. 7. DSO Parallel Activation As data stores are loaded and data is activated, the size of the data store and the number of requests become important for data activation time. Large DSOs with more than 100 million records and lot of load requests increases data activation time. These DSOs should be partitioned to reduce the size and number of requests for faster activation times. There are also known activation issues when parallel activation is attempted on very large DSOs (see: note 634458 'ODS object: Activation fails - DEADLOCK' and 84348 'Oracle deadlocks, ORA-00060 ORA). 8. Little use of Line Item Dimensions in InfoCubes Line item dimensions are basically fields that are transaction oriented. Once flagged as a line item dimension, the fields are actually stored in the fact table and have no table joins. The result in improvements to query speeds for cubes not in BWA. Companies should explore the use line item dimensions for fields that are frequently conditioned in queries. 9. No Use of BWA Face it: the time when we are using spinning magnetic disks are coming to an end. They are simply too slow. With BWA 7.2 out next month, you also can move multiproviders in-memory (join indexes inside BWA). You also can move some of the calculated key figures (BI analytical engine process intensive operations) inside BWA. If you don't have it yet, you need to budget for this asap! 10. Wrong Query Read-Modes There are three query read modes that determines the amount of data to be fetched from a database and sent to the application server: 1. Read all data - All data is read from a database and stored in user memory space 2. Read data during navigation Data is read from a database only on demand during navigation and 3. Read data during navigation and when expanding the hierarchy - Data is read when requested by users in navigation Picking the right read mode makes a big difference!!

More Other performance tuning areas that did not make this 'short list' include:

1. OLAP/ MDX Caching and parameters 2. Aggregates 3. Reduction of OLAP processing time 4. Network analysis 5. Server Sizing 6. Request reductions 7. Simplified data architecture 8. Poorly written transformation (ABAP multi-selects and spaghetti code) 9. Incorrect process chain scheduling and de-coupling 10. Kitchen-sink / "Swiss army knife" objects