System Response Upon Changes to Data: BI Accelerator Index
Since, like aggregates, BI accelerator indexes are affected by changes to master data, they are also affected by hierarchy/attribute change runs.
If an InfoCube that forms the basis of a BI accelerator index is later compressed or data is deleted from it, we recommend that you rebuild the BI accelerator index.
Hierarchy/Attribute Change Run
Since the data in master data tables (X and Y tables) is stored in indexes on the BI accelerator server, BI accelerator indexes, like aggregates, are affected by changes to master data. However, in contrast to aggregates, the fact tables do not contain the current data for the master data. Therefore, you do not have to run the potentially time-consuming delta calculations that you have to run for aggregates. Instead, you only transfer the changed records from the master data tables and change them in the indexes on the BI accelerator server. In most cases, this is considerably quicker than modifying aggregates.
Since the hierarchy tables are not in the BI accelerator index either, there is no pre aggregation on specific hierarchy levels, as is the case with aggregates. Again, calculation and modification is unnecessary. However, as with the BI hierarchy buffer, some views of hierarchies that occur in queries are stored on the BI accelerator server as temporary indexes so that they can be reused. If the hierarchy is changed, these temporary indexes have to be deleted.
The system changes both the master data and the temporary hierarchy indexes during the hierarchy/attribute change run. In this process, the aggregates and BI 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 and then runs the two quick processes described for the relevant BI accelerator indexes:
- The X and Y indexes are filled with the changed records.
- The hierarchy buffer is deleted from the BI accelerator index.
Finally, the system activates the master data and displays the changed aggregates and BI accelerator indexes with the new data for reporting.
With BI accelerator indexes you do not have to compress after rolling up data packages. The data on the BI accelerator server already exists in a read-optimized format.
However, in the following case it may be useful to rebuild the BI accelerator index, although this is not strictly necessary.
A BI 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, more data is contained in the BI accelerator index than in the InfoCube itself and the data in the BI accelerator index is more granular. If compression results in a large aggregation factor (>1.5), it may be useful to rebuild the BI accelerator index. This ensures that the dataset is reduced in the BI accelerator index too.
If you delete data from the InfoCube selectively, the BI accelerator index has to be rebuilt. When you execute selective deletion, the system automatically deletes the affected BI accelerator index.
When you delete a data package (that is not aggregated) 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. Therefore, more entries exist in the index than in the table of the InfoCube. If you regularly delete data packages, the number of unused records increases, increasing memory consumption. This can have a negative affect on performance. In this case you should consider rebuilding the BI accelerator index regularly.