To attain good performance for a query on non-cumulative InfoCubes, you should take note of the following:
Compress all requests in the non-cumulative InfoCube, or at least most of them.
The performance of a query based on a non-cumulative InfoCube depends heavily on how the InfoCube is compressed. If you want to improve the performance of a query of this type, first check - insofar as this is possible - whether the data in the InfoCube should be compressed. You should always compress data when you are sure that the request affected will not need to be deleted from the InfoCube.
Use as few validity-determining characteristics as possible.
The number and cardinality of the validity-determining characteristics heavily influences performance. Therefore, you should only define characteristics as validity-determining characteristics when it is really necessary.
Time Restrictions in the Query
As far as possible, restrict queries based on non-cumulative InfoCubes to time characteristics.
The stricter the time-based restriction, the faster the query is generally executed, as the non-cumulative is reconstructed if the number of times is smaller.
Time Drilldown in the Query
If you no longer need the average, split a query on a non-cumulative InfoCube (which contains both key figures with LAST aggregation and key figures with AVERAGE aggregation) into two queries.
With non-cumulative key figures with the exception aggregation LAST, the time characteristic included in the drilldown makes a difference to performance. If, for example, both Calendar Day and Calendar Month are included in the InfoCube, drilldown by month is faster than drilldown by day, because the number of times for which a non-cumulative has to be calculated is smaller.
For the other types of exception aggregation (average, average weighted with factory calendar, minimum and maximum), this rule is not valid as in these cases, the data is always calculated on the level of the most detailed time characteristic first before exception aggregation is performed.
Hide the totals row in the query when not required.
Depending on the type of aggregation being used, the calculation of totals rows can be very time-consuming.