Compressing InfoCubes

Use
When you load data into the InfoCube, entire requests can be inserted at the same time. Each of these
requests has its own request ID, which is included in the fact table in the packet dimension. This makes it
possible to pay particular attention to individual requests. One advantage of the request ID concept is that
you can subsequently delete complete requests from the InfoCube.

However, the request ID concept can also cause the same data record (all characteristics agree, with the
exception of the request ID) to appear more than once in the fact table. This unnecessarily increases the
volume of data, and reduces performance in Reporting, as the system has to aggregate using the request
ID every time you execute a query.

Using compressing, you can eliminate these disadvantages, and bring data from different requests
together into one single request (request ID 0).

This function is critical, as the compressed data can no longer be deleted from the
InfoCube using its request IDs. You must be absolutely certain that the data loaded into
the InfoCube is correct.

Functions
You can choose request IDs and release them to be compressed. You can schedule the function
immediately or in the background, and link it to other events.

Compressing one request takes approx. 2.5 ms per data record.

With non-cumulative InfoCubes, compression has an additional effect on query performance. Also, the
marker for non-cumulatives in non-cumulative InfoCubes is updated. This means that, on the whole, less
data is read for a non-cumulative query, and the reply time is therefore reduced.

If you run the compression for a non-cumulative InfoCube, the summarization time (including the time to
update the markers) will be about 5 ms per data record.

If you are using an Oracle database as your BW database, you can also carry out a
report using the relevant InfoCube while the compression is running. With other
manufacturers’ databases, you will see a warning if you try to carry out a report using an
InfoCube while the compression is running. In this case you can only report on the
relevant InfoCube when the compression has finished running.
If you want to avoid the InfoCube containing entries whose key figures are zero values (in reverse posting
for example) you can run a zero-elimination at the same time as the compression. In this case, the
entries, where all the key figures are equal to 0, are deleted from the fact table.

Zero-elimination is permitted only for InfoCubes, where exclusively key figures with the
aggregation behavior ‘SUM’ appear. You are not permitted to run a zero-elimination with
non-cumulative values in particular.

Activities
For performance reasons, and to save space on the memory, summarize a request as soon as you have
established that it is correct, and is no longer to be removed from the InfoCube.