Data from one request is stored with its own request identity in the F table. This has the advantage that you can easily check and delete single requests. But in general identical data (with the same combination of DIMs except Package Dimension) is stored multiple times in the F fact table. Hence, the data volume may increase more than necessary with time.
TASK of CONDENSOR
Data records of requests are aggregated and stored in the E-fact table with the requestID=0. Hence the compressed data is stored in the E-table, the uncompressed requests are stored in the F-table. Compression has in general the following advantages:
- less amount of data in the fact tables
- in case ORACLE is used this also means that we have less partitions in the fact table (see Note 590370)
- shorter query runtime
- if the data is stored in the E table, you can also improve the query performance with the help of the feature 'partitioning'
In case you compress more than one request the system handles one after the other (in a row) and carries out an 'commit' in between. As a consequence the condensor doesn't have to carry out a rollback for all requests if the process terminates. Roughly we have the following processing steps/logic:
- Loop over ReqestIDs
- Update/Insert of E fact table
- Delete corresponding entry of package dimension (logical deletion)
- End Loop
- Delete (Drop) requests of fact table (physical deletion)
- Compress Aggregates (if exist)
Please see note 407260 for further details.
- Long Running Compression - Help for Error Analysis
- Zero elimination
- Marker update for inventory cubes (non cumulative key figures) - see note 1548125 'Interesting facts about Inventory Cubes'
- Error message "Compression not necessary; no requests found for compressing"(RSM1 489) - see 2121399 and Compression and DataMart: Example , this issue sometimes is also fixed by running report RSBDELTAREPAIR too.
SAP Support Troubleshooting Guideline
SAP Online Documentation
SAP Consulting Notes
List of notes/KBAs: