If you want to use a BI accelerator index with an InfoCube when you execute a query, you first have to create and activate a BI accelerator index and fill it with initial data.
The system performs the following steps in order to create an index on the BI accelerator server and make the data visible.
The name of the index is generated from the System ID and Table Name: <<system ID>>_<<table name>>. The system deletes the first forward slash from the table name and replaces the second with a colon.
- Create: For a table, the system creates the index on the BI accelerator server in accordance with the table properties. The system also determines how many parts the index is to be split into, depending on the present size of the table.
- Index: The data is transferred and written to a temporary file on the BI accelerator server.
- Prepare optimize: The data in the temporary file is formatted (compressed, coded and so on) as required for search and aggregation. Depending on how the index is distributed, this step can take longer than the indexing step.
- Commit optimize: The previously optimized data is made visible. If you perform rollback for an index, the system rolls back the data to the last commit optimize.
Example: Log messages for individual steps
|Index 'BR8_BI0:XCOORDER' created for BI accelerator index|
|Index 'BR8_BI0:XCOORDER' filled for BI accelerator index (records written ...)|
|Prepare optimize for BI accelerator subindex 'BR8_BI0:XCOORDER'|
|Commit optimize for BI accelerator subindex 'BR8_BI0:XCOORDER'|
The logs for the initial fill/indexing of a BI accelerator index are in the application log under object "RSDDTREX", subobject "TAGGRFILL".
You can activate and fill BI accelerator indexes for different InfoCubes simultaneously.
However, overlaps may occur if several indexing jobs try to index the same master data tables simultaneously. In this case, the first job locks the table and performs indexing. The other jobs see the lock and schedule the indexing run to take place later. If no new data is loaded in the meantime, the system simply checks that indexing was performed successfully by the competing job. This step is necessary to avoid the system setting a BI accelerator index to "active" when the index is not actually available on the BI accelerator server because the job was terminated.
The subsequent jobs try a total of five times to start the indexing process or determine the status of the index. If this is not possible due to a long-running process or termination, the system terminates the entire indexing process for the BI accelerator index and notes the InfoCube affected by the lock process. You have to wait until the current program has finished or the error has been fixed before restarting the indexing process.
Example: Log for initial indexing with competing processes
|Load to index for table '/BI0/SVC_PAYM2' locked by competing job|
|InfoCube of competing process: 'ZBWVC_003'|
|Lock for table '/BI0/SVC_PAYM2'. Job will be restarted later|
|No new data for index of table '/BI0/SVC_PAYM2'|
|BI accelerator index for InfoCube '0BWVC_003' filled successfully|
If a process is terminated by the user or the system during the initial data fill, you can restart the process by choosing the Continue Filling option in the corresponding dialog box of the BIA index maintenance wizard
If indexing is terminated when the Commit Optimize is called, this is more problematic. After the Commit Optimize has been called, the data is visible and you can no longer perform rollback. This process is normally very quick and has an extremely low error rate. However, if indexing is terminated at the point at which the Commit Optimize is called, the status of the index is "unknown" to the system since the system does not know whether data is already visible. The system does not know whether the termination occurred after or just before the commit optimize ran on the BI accelerator server. To clarify the status of the index, you have to analyze the termination message and the status of the index carefully; you cannot automate this analysis. Therefore, when restarting the process, the system normally re-indexes indexes that have status "unknown" and notes records them in the log. The fact index is the exception: Since this is usually the largest BI accelerator index and re-indexing it takes a long time, the system does not automatically re-index the fact index. Instead the system terminates the process and gives the index status "unknown". In cases like this, it may be useful to analyze the log message and repair the index manually.