Page tree
Skip to end of metadata
Go to start of metadata


To explain the concept and reasons behind compressing requests in InfoCubes


InfoCubes should be compressed regularly.

Uncompressed cubes increase data volume and have negative effect on query/reporting & aggregate build performance.

If too many uncompressed requests are allowed to build up in an InfoCube, this can cause unpredictable & severe performance problems.

When you compress, a query will read one accumulated line of records as opposed to reading each record.

How it works

During upload of data, a full request will always be inserted into the F-fact table. Each request gets its own request ID & partition (Database dependent) which is contained in the 'package' dimension. This feature enables you, for example, to delete a request from the F-fact table after the upload. However this may result in several entries in the fact table with the same values for all characteristics except the request ID. This will increase the size of the fact table & number of partitions (DB dependent) unnecessarily & consequently decrease the performance of your queries. During compression, these records are summarized to one entry with the request ID '0'. Once the data has been compressed, some functions are no longer available for this data (for example, it is not possible to delete the data for a specific request ID).

As the packet dimension is stripped out, you lose the ability to delete requests in the monitor

Compressing adds up records in the cube, thus saving space therefore less records



Q: Can I kill a compression? 

Ans: Yes, you can kill the compression. There is no worry for data integrity. Any requests fully compressed up to now will remain compressed. Any request mid-compression will be rolled back. Subsequent compression of the same InfoCube will be from the beginning again.

Q: Should I compress my non-cumulative (NC) InfoCube?

Ans. Compression of Non cumulative InfoCubes are mandatory. Non cumulative Key Figures don't maintain data in the InfoCube but the value is calculated at the run time of the query.

Q: What happens to the data in a compression?

Ans. the data moved from the F-fact table to the E-fact table.

Related Content

Relevant Notes

SAP Note 407260 FAQs: Compression of InfoCubes

SAP Note 1584120 RSM1489 Compression not necessary; no requests found

SAP Note 1522494 (DTP) Requests can not be compressed

SAP Note 407260 FAQs: Compression of InfoCubes

SAP Note 590370 Too many uncompressed request (f table partitions)


SAP Note 834829 Compression of BW InfoCubes without update of markers

Related Documentation