System Response to Data Modifications: SAP BW Accelerator Index

Hierarchy/Attribute Change Run

Since the data in master data tables (X and Y tables) is stored in indexes on the BW Accelerator server, BW Accelerator indexes are affected by changes to master data in the same way as aggregates. Unlike aggregates, fact tables do not contain the current data for the master data. You therefore do not have to run the potentially time-consuming delta calculations required for aggregates. Instead, you only transfer the changed records from the master data tables and change them in the indexes on the BW Accelerator server. In most cases, this is far quicker than modifying aggregates.

Since the hierarchy tables are not in the BW Accelerator index either, there is no pre-aggregation on specific hierarchy levels, as is the case with aggregates. No calculation or modification is necessary here either. As with the BW hierarchy buffer however, some views of hierarchies that occur in queries are stored on the BW Accelerator server as temporary indexes for reuse. If the hierarchy is changed, these temporary indexes have to be deleted.

The system changes the master data and the temporary hierarchy indexes during the hierarchy/attribute change run. In this process, the aggregates and BW Accelerator indexes for the relevant objects are determined for the previously changed InfoObjects that are selected. As before, the system first modifies the aggregates in accordance with the changes (see System Response Upon Changes to Master Data and Hierarchies). It then runs the two quick processes described for the relevant BW Accelerator indexes:

• The X and Y indexes are filled with the changed records.

• The hierarchy buffer is deleted from the BW Accelerator index.

Finally, the system activates the master data and displays the changed aggregates and BW Accelerator indexes with the new data for reporting.

Compression

You do need to compress BW Accelerator indexes after rolling up data packages. The data on the BW Accelerator server already exists in a read-optimized format.

In the following cases however it might be useful to rebuild the BW Accelerator index, though this is not actually necessary.

A BW Accelerator index is created for an InfoCube that is not aggregated, or a large number of data packages are later loaded to this InfoCube. If you compress this InfoCube, there is more data in the BW Accelerator index than in the InfoCube itself, and the data in the BW Accelerator index is more granular. If compression results in a large aggregation factor (>1.5), it might be useful to rebuild the BW Accelerator index. This also ensures that the dataset is reduced in the BW Accelerator index.

Non-cumulative InfoCubes, that is InfoCubes with at least one non-cumulative key figure, should still be reconstructed in large intervals after compression. We recommend this especially if the time to calculate the markers at query runtime is large.

Deleting Data

If you delete data from the InfoCube selectively, the BW Accelerator index has to be rebuilt. When you execute selective deletion, the system automatically deletes the affected BW Accelerator index.

When you delete an (unaggregated) data package from an InfoCube, the index for the package dimension table is deleted and rebuilt. The facts in the fact index remain but are "hidden" because they are no longer referenced by an entry in the package dimension table. There are therefore more entries in the index than in the InfoCube table. If you regularly delete data packages, the number of unused records increases, thus increasing memory consumption. This can have a negative impact on performance. You should then consider rebuilding the BW Accelerator index on a regular basis.