Question:
Hi,
I understand from documentation that compression of Infocube would result in superior performance improvements in report execution time.
I would like to here from experts, about the impact of infocube compression ? Is it advisable ?? After the compression, is it possible to delete the date from infocube, if required ?
Would appreciate, your thoughts and views.
Thanks
BW SMALL
Answer:
hi,
according to my understanding if the requests are compressed then it is impossible to delete the individual request.
regards,
warrior
Answer:
When loading data into the InfoCube, it is possible to insert entire requests at the same time. Each of these requests has its own request ID, which is included in the F fact table in the packet dimension.
This enables you to examine these particular requests.
An advantage of the usage of request IDs is that you can subsequently delete complete requests from the InfoCube and/or of its aggregates.
A disadvantage is that usage of request IDs can lead to duplicate appearances in the F fact table of the same data record (where all characteristics are the same except for the request ID). This is not an
error but does increase the volume of data unnecessarily, and also reduces performance in reporting, as the system has to aggregate using the request ID every time a query is executed.
You can collapse or compress an InfoCube by deleting the request IDs in order to conserve memory or improve reporting performance. (i.e. these request IDs have value zero). During this procedure, the selected requests of the F fact table with request ID '0' are moved to the E fact table and afterwards
deleted from the F fact table.
_________________
Truth alone triumphs.
Answer:
Hi Suji,
Would the compression increases the performance ? Are there any measurements ?
BW SMALL
Answer:
.. Also, the F table is partitioned by request so if you have lots of small delta loads you can end up with lots of small partitions. And, the F table is optimised for loading whereas the E table is optimised for querying -- so even after a full update it may be beneficial to compress the cube.
I've never tried to measure any change in performance, I doubt that it is often very significant.
Answer:
Hi Small,
I have done a lot of compression on my cubes and with great improvements.
But it depends on how large the cube is,
the type of data you load,
is the cube partitioned,
and are you using aggregates.
If the cube has lots of changes to its transactional data, then you can have a great benefit of compression.
If you load unique records you will not have any.
If you use aggregates and youre queries hit them, you will not have
better performance, because aggr are usually compressed by default.
And you will only experience better performance when you do not hit an aggr.
You will also experience better performance in general management of the cube. Like deleting a request and counting the E- and F-table.
Rollup times sould also increase becase the F-table is smaller.
Use partition, the E table is a lot faster than the F is beacuse it is partitioned either on fiscal period or calendar year/month,
where as the F-table is partitioned on Request no. And that makes it slow.
Search SAP notes and test before you compress.
There are many notes on errors during compression.
Best Regards
- Rasmus