Activating and Filling SAP BW Accelerator Indexes

Use

If you want to use a SAP BW Accelerator index when executing a query, you first have to create and activate a BW accelerator index and fill it with initial data. To do this, you need to use BWA index maintenance (see Indexing BW Data in SAP BW Accelerator). Additional technical information about these processes is provided in the following documentation.

Note

During indexing, the system takes account of the global BWA indexing settings. You can call these using the BWA Monitor. For more information, see Monitoring BWA Indexes.

Process

Indexing Process by Table/Index on the BW Accelerator Server

The system performs the following steps in order to create an index on the BW accelerator server and make the data visible.

Note

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 BW 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.
Indexing: The data is transferred and written to a temporary file on the BW 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.

	Index 'BR8_BI0:XCOORDER' created for BW accelerator index
	Index 'BR8_BI0:XCOORDER' filled for BW Accelerator Index (records written)
	Prepare optimize for BW Accelerator subindex 'BR8_BI0:XCOORDER'
	Commit optimize for BW Accelerator subindex 'BR8_BI0:XCOORDER'

The logs for the initial fill/indexing of a BW accelerator index are in the application log under object "RSDDTREX", subobject "TAGGRFILL".

Competing Processes During Indexing

You can activate and fill BW accelerator indexes for various InfoProviders at the same time.

Overlaps may occur though if several indexing jobs try to index the same master data tables at once. In this case, the first job locks the table and performs indexing. The other jobs recognize this 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 BW accelerator index to "active" when the index is not actually available on the BW accelerator server because the job has been 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 BW 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.

	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'.
	BW accelerator index for InfoCube '0BWVC_003' filled successfully.

Restarting Processes

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 cannot be rolled back again. This process is normally very quick and has an extremely low error rate. If indexing is terminated at the point where the Commit Optimize is called however, 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 BW accelerator server. To clarify the status of the index, you have to analyze the termination message and the status of the index carefully. This analysis cannot be automated. When restarting the process, the system therefore normally re-indexes all indexes with status "unknown" and records them in the log. The fact index is the exception: Since this is usually the largest BW accelerator index, and re-indexing it takes a long time, the system does not automatically re-index the fact index. The system terminates the process instead and gives the index status "unknown". In cases like this, it may be useful to analyze the log message and repair the index manually.