Overview
Aggregates allow you to improve the performance of BEx queries when data is read from an InfoCube. An aggregate is a materialized view on a subset of an InfoCube. It can contain characteristics and navigational attributes and can be restricted to fixed values (F) and hierarchy levels (H). Its purpose is to reduce the amount of data read from the DB during query execution.
A BEx query always tries to use performance-optimized sources by checking the sources from which it can draw the requested data. It checks them in the following order:
OLAP cache
BW Accelerator index
Relational aggregates from the database (not supported when SAP HANA is used )
InfoCubes from the database
So, if there is no cache entry or BWA index available, the system takes proper aggregates in case some exist. When the data in the cube changes, then the aggregates need to get adjusted. The same must be done when there are changes to the master data of affected characteristics (navigation attributes!) and hierarchies. Hence we have the following important processes:
- Activation&Filling
- RollUp - new transactional data (requests) is transferred to the aggregates
- ChangeRun - aggregates are adjusted when there are relevant changes of master data and hierarchies
CSS component: BW-BEX-OT-AGGR
Aggregates used in Queries
When the query is executed, the system checks whether there are proper aggregates (if there is no cache entry or BWA index) available. If yes, the aggregates are used instead of the basis cube. The most convenient way to check whether data is being read from an aggregate, a BW Accelerator Index or an InfoCube is to run the query in the Query Monitor (transaction RSRT) by using a corresponding debug option. There you can also temporarily deactivate the usage of one or all aggregates in order to test them for performance purposes or to analyze data consistency.
For further details check the following example
When is an Aggregate used by a Query ?
Error Analysis
In case a query (or LISTCUBE which can use aggregates as well), which reads data from aggregates, displays incorrect data, it is recommended to proceed as described in the following note
1174503 Analysis for incorrect results using aggregates
If you want to check the consistency of aggregates on a regular basis you can use the transaction RSDDAGGRCHECK, for details please review the SAP Online Documentation
Performing Checks for Aggregates
Transactions and Tables
- Transactions
- RSDDV
- RSDDAGGRCHECK
- LISTCUBE which can use aggregates as well
- Tables
- RSDDAGGRDIR
- RSDDAGGR_V
- RSDDAGGRCOMP
SAP Support Troubleshooting Guideline
SAP Online Documentation
Performance Optimization with Aggregates
SAP Consulting Notes
- 903886 Hierarchy and attribute changerun (BW3x Release)
- 1388570 BW Change Run (BW7x Release)
- 1174503 Analysis for incorrect results using aggregates
- 1053605 Termination 'GET_STATE_OF_AGGREGATES_CR-2-' in change run
- 1983809 Changerun aborts with GET_STATE_OF_AGGREGATES_CR-1-
- 1907954 InfoCube or Attributes are Locked by Terminated Change Run.
- 854092 During initial aggregate fill a COMMIT is eventually needed
- 1085914 Restarting a change run results in error RSDD 85
- 1117724 Change run and condensing (BW 7.X)
- 1326211 BW change run: Repairing a terminated predecessor
- 534630 Parallel processing of Change Run
- 590370 Too many uncompressed request (f table partitions)
- 825927 The BW Changerun: CR_MAXWAIT
- 903886 Hierarchy and attribute change run
- 994005 Poor query performance when using aggregate
Link to this page: https://wiki.scn.sap.com/wiki/x/hwBnFQ