Compressing requests in InfoCube

[Former Member]

Hi all,

I recently had a discussion with my teamlead reagarding compression of requests in an infocube.

Currently all our requests are uncompressed, which is not the best for performance as we know

We have data of 2005 and 2006 in this specific cube, but have to do a lot of corrections in 2006. So we decided, just to compress the requests for 2005.

So if we compress just a certain number of requests in one cube, we will have a F-table and an E-Table.

Now we have doubts if this will result in better performance or if our performance will even get worse, because we have to read both tables every time.

Any Suggestions?

regards,

Torsten

/edit

Data is loaded daily

Message was edited by: Torsten

[Former Member · Accepted solution]

Hi Torsten,

I assume that you understand the concept behind compression. Each Data load process in an InfoCube is uniquely identified using a request ID.

Using request ID's can have the effect that a data record with the same content (where all characters are the same except for the request ID) appears more than once in the fact table. The result is an unnecessary increase in the data volume, which reduces performance in Reporting, since every time a query is executed, the system accesses data via the request ID.

During compression, the compressed data records are moved from F fact table to E fact Table. And new records are stored in teh F- fact table.

In standard practice, you need to leave some requests uncompressed. Because, once the data is compressed, it can no longer be deleted from the InfoCube using request IDs.

Compared to your previous design of not compressing any request ID's, your present design wuld definitely increase the performance of the system. Once you are sure that the data requests for 2006 have no inconsistent data, you can compress those request id's too. So, don't worry, your performance will not be hampered by compressing some requests and leaving some requests uncompressed. This is the normal practice we have been doing with all our data requests.

Hope this helps.

Regards,

Sumana

[kumar_gudiseva2]

In your case, you could realize most benefit by doing both cube partitioning by calmonth & compression.All 2005 data will be in their partitions & it helps in query performance(by pruning as long as you have calmonth as selection criteria in your query).

You could do partitioning only when cube is empty (I am assuming you have not yet partitioned your cube).

Kumar Gudiseva.

[Former Member]

hi,

compressing is the better choice for u cauz compressing result in better performance as well less no of request id are there

[Former Member]

Hi,

if u decide to compress the req's for 2005

surely it will improves the reporting performance (if ur using reports based on 2005 yr data).

why dont u compress 2006 data

as of my knowledge u need to compress the data as soon as possible after loading data into cube once after confirming that the loaded data is valiadeted

go ahead...

folow this link

http://help.sap.com/saphelp_nw2004s/helpdata/en/ca/aa6437e7a4080ee10000009b38f842/frameset.htm

-Shreya

[Former Member]

For sure compressing the whole cube would be better, but we want to keep the possibility of deleting requests.

And my teamlead is very uncomfortable with selective deletion.

[Former Member]

In General.. it should Increse the performance..

May be it also depends on the following scenarious..

1) If you are querying on documents of 2005 ( Should be fast)

2) If you are querying on documents of 2006 ( Should be fast)

3) If you are querying both 2005 and 2006.. may be logically have more time with above..

I do not have much experience in Compression.. so let us wait for more replies..

regards,

Hari

[Former Member]

Hi Torsten,

When you compress records fo the whole year (generally) no of records will be much lesser than with request ids ( before compression)

when once executes query, my understanding is , it accesses data from view based on both the table. So performance should improve.

hope it helps

regards

vikash