Friday 16 March 2012

Aggregates Performance


1) Compression related issues:

Do Have a look at the following note:

590370
Too many uncompressed request (f table partitions)

That will explain why some processes on partitioned objects take longer the more partitions the system has.

And then execute SE38 report RSORAVDV variant. 

This will show you all table that have too many partitions. If these are F tables, you need to massively compress the cubes to less than 30 partitions. And you must do so regularly, because this is very important.


2)Summarization factor of aggregates:


Usually Summarization factor of 10 or more is taken as fine.



3)RSRV test:On cube


Also Transaction RSA1 -> Cube -> Manage -> Performance , Check Aggregate Indexes


To check the InfoCube index consistency on other cubes, call transaction  RSRV -> 'All Elementary Tests' -> 'Database'.

Double-click "Database

Indices of an InfoCube and Its Aggregates" and enter the corresponding InfoCube.


To correct the problems, choose "Correct Error" and then "YES" in the popup. 

If this does not solve the problem, check SAP Note 401242 and consider scheduling report SAP_INFOCUBE_INDEXES_REPAIR.

4) To reduce the runtime of the change run, you can distribute adjustment of the aggregates across several work processes running in parallel. 

Refer to SAP Note 534630.

5) Finally (critical setting for performance):

Check in RSCUSTV8 transaction the current Delta limit and Block size set.

If there is no delta make it to 20% and please have a look at the detailed information mentioned there in help for these settings.

Have a look at note:
903886
- Hierarchy and attribute change run

No comments:

Post a Comment