The Reference Caracteristic of an Exception Aggregation is always invisible in the drilldown. Hence this feature may lead to large data volumes and a high memory consumption:
Query with Exception Aggregation
The query has 13 simple key figures, one uses exception aggregation (MAX) regarding characteristic 0BOOKDATE (see SAP note 1151957 for further details about Exception Aggregation). This means that this reference characteristic is always (invisible for the user) in the drilldown and that in general more data records have to be transferred from the data base to the OLAP engine (DBTRANS). The query result set has 193788 rows:
If you multiply the number of rows with the number of key figures we get 193788*13=2,519,244. This is the number of cells (with key figure values) in the query result which we call FE_CELLS. If you compare this value with OLAP_FE_TRANS you will notice that it is exactly the same value (hence no NULL cells were created and no Zero Suppression or Conditon removed cells again)
Please note that DBTRANS is much larger than the number of rows in the query ! This is caused by the feature Exception Aggregation. It is interesting to compare the runtime statistics with a copy of this query where the exception aggregation was removed:
You can see that DBTRANS is much smaller although OLAP_FE_TRANS (=2.519.244) is equal!
The total memory consumtion of the query with exception aggregation is a bout 690 MB (ST02). If we stop in the debugger after the process block Data Transfer (please see How to check current Memory Consumption) we see that the query needs 650MB at this stage.
In RSRT -> 'Technical Information' we get the following values for the parameters:
- VF_G = 5
- C_SP = 5
If we apply the estimation formula
(VF_G*24 + C_SP*8 + CHARS_DRILL*7) * DBTRANS + 96 * OLAP_FE_TRANS
we get 174*508258 + 96*2519244 = 88MB + 240MB = 328MB. Since the query does not contain many key figures the memory consumption of the SP is only about 100 MB. The SP of the query (see below) without exception aggregation only allocates 40 MB - so less than a half. In general, the estimation formula is not really precise if exception aggregation is used. One reason is that the query is internally split into 2 subqueries (2 read requests, see aslo example below)). Another one that the data records are differently stored in the internal table SP.
The most important point to memorize is that the feature exception aggregation can lead to a much larger value for DBTRANS!
In RSRT -> 'Technical Information' you get an information displayed that this query uses exception aggregation:
Query without Exception Aggregation
A copy of the query from above where the exception aggregation was removed has to process much less data in the OLAP engine.
Query Runtime Statistics
If we add the infoobject 0BOOKDATE (reference characteristic from above) to the drilldown we can find out (by just looking at the query result set) wheter this infoobject generates a much bigger result set. The query displays 314470 rows (which is equal to DBTRANS in this simple case). If we calculate the sum of 314470 and 193788 we get 508258. This is the value for DBTRANS of query with exception aggregation (see above)! Such a query is internally split into 2 subqueries, one handels the key figure with exception aggregation, the other one the remaining key figures. Hence DBTRANS corresponds to the SUM of all transferred records of both subqueries.