!--a11y-->
System Response Upon Changes to Data: HPA
Index 
Because, like aggregates, HPA 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 HPA index is later compressed or data is deleted from it, we recommend that you rebuild the HPA index.
Because the data in master data tables (X and Y tables) is stored in indexes on the HPA server, HPA 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 HPA server. In most cases, this is considerably quicker than modifying aggregates.
Since the hierarchy tables are not in the HPA 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 HPA 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, objects aggregates and HPA indexes are determined for selected previously changed InfoObjects. As before, the system first modifies the aggregates in accordance with the changes (see System Response Upon Changes to Data: Aggregate) and then runs the two fast processes described for the relevant HPA indexes:
· The X and Y indexes are filled with the changed records.
· The hierarchy buffer is deleted from the HPA index.
Finally, the system activates the master data and displays the changed aggregates and HPA indexes with the new data for reporting.
With HPA indexes you do not have to compress after rolling up data packages. The data on the HPA server already exists in a read-optimized format.
However, in the following case it may be useful to rebuild the HPA index, although this is not strictly necessary.
A HPA 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 HPA index than in the InfoCube itself and the data in the HPA index is more granular. If the aggregation factor over the compression is large (>1,5), it may be useful to rebuild the HPA index. This ensures that the dataset is also reduced in the HPA index.
If you delete data from the InfoCube selectively, the HPA index has to be rebuilt. When you execute selective deletion, the system automatically deletes the affected HPA 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 regularly rebuilding the HPA index.