cancel
Showing results for 
Search instead for 
Did you mean: 

Considerations/Effect to Compress Aggregates on uncompressed Infocube

Former Member
0 Kudos

Hi all,

We have an InfoCube with about 420 requests and loading daily; we have 2 important aggregates working currently.

  • We have neither InfoCube nor Aggregates Compressed.

  • We want to compress Aggregates only.

  • What are exactly the benefits taking this action?

  • Is there any additional considerations we have to take into account?

Hope you can help me.

Bernardo

Accepted Solutions (1)

Accepted Solutions (1)

Naga_P
Active Participant
0 Kudos

Hi,

Q1. We want to compress Aggregates only.

On BW/BI, we have to compress both the Aggregates and the Infocubes. We do not have any option to compress only the Aggregates. This is mainly because these two objects (Infocubes & Aggregates) would always have synchronized data.

Q2. What are exactly the benefits taking this action

The first benefit is it improves the query performance, if we have many changes recorded (for the same document) through several requests. By compressing, all these multiple records will be summarised into one single record and thus becomes easy.

However, once compressed, we cannot delete individual requests, if we have any problems identified within one or more of the compressed requests. This will be a big concern, if you are expecting to correct data errors in individual packets.

rgds

Naga

Former Member
0 Kudos

Hi Naga, thanks for your support,

You said:

Q1. We want to compress Aggregates only.

On BW/BI, we have to compress both the Aggregates and the Infocubes. We do not have any option to compress only the Aggregates. This is mainly because these two objects (Infocubes & Aggregates) would always have synchronized data.

Now, looking other InfoCube, selecting management options, on the "Requests" tab, I can see the following cols:

Request ID --> values

Request for Reporting Available --> ok

Compression status in InfoCube --> EMPTY

Compression status of Aggregate --> OK

Datamart status of the request --> empty

Rollup status (in InfoCube and in the Aggregates) --> OK

... and so on...

As I can see (please correct me if I'm wrong) "Compression status of InfoCube" without any value means that no compression was made for infocube. However, the column for "Aggregate compression status" indicates that it has been made before.

So, I think that it is possible compress Aggregate independently of Infocube Aggregation, please confirm if it is right and if -it's possible- additional considerations about this.

Thanks a lot again!

Bernardo

Former Member
0 Kudos

Hello Bernado,

you are correct, the aggregates can be compressed, even if the cube is not compressed.

To find out, if compressed aggregates are of any help to you just consider what this implies:

"To compress" in the context of SAP BW/BI infocubes is to remove all request references and sum up all key figures with same characteristic setting in all dimensions. As a result you profit from compressing, if you know that the key figure content is updated by an DSO/ODS. Then you will have less entries and the cube gets smaller.

If your requests always deliver new data without updating old one, a "compression" doesn't shrink the cube at all and may result in performance disadvantages. This is because in some database environments uncompressed requests can be queued in parallel, while compressed cubes can only be queued once (unless partitioned...but let us keep this out).

Back to the compression of Aggregates: Usually aggregates are compressed. In the compression process a primary key is created, which makes it much easier to update the aggregates. So compression of aggregates improves the "rollup" performance of the aggregate. It does decrease the "delete request" performance, because if you delete a request in the uncompressed Infocube you have to rebuild the aggregate. Rebuilding is much faster then. In fact, in this case I would recommend to disable the aggregates, delete the request and then rebuild the aggregates.

Hope this helps,

Jürgen

Edited by: Jürgen Kirsch on Sep 29, 2008 6:46 PM

Answers (0)