Activating and Filling HPA Indexes 

Use

To use a HPA index for an InfoCube when executing a query, you must first activate it and then fill it with data.

Prerequisites

You have created a HPA index (see Creating HPA Indexes).

Features

Indexing Process by Table/Index on the HPA Server

The system performs the following steps in order to create an index on the HPA 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 HPA 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 HPA 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 back to the last commit optimize.

Example: Log messages for individual steps

	Index 'BR8_BI0:XCOORDER' created for HPA index
	Index 'BR8_BI0:XCOORDER' filled for HPA index (records written: ...)
	Prepare optimize for HPA sub-index 'BR8_BI0:XCOORDER'
	Commit optimize for HPA sub-index 'BR8_BI0:XCOORDER'

You find the logs for the initial fill/index of a HPA index in the application log under object “RSDDTREX“, subobject “TAGGRFILL“. In HPA index maintenance, choose  Logs to display the application log.

Competing Processes During Indexing

You can activate and fill HPA 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 to run later. If no new data is loaded in the meantime, the system simply checks that the indexing was performed successfully by the competing job. This step is necessary because otherwise the system could set a HPA index as “active” when an index is not actually available on the HPA server because a 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 HPA index and records the InfoCube with the locking processes. You have to wait until the current program has finished or the error has been resolved 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'.
	HPA index for InfoCube '0BWVC_003' filled successfully.

Ability to Restart Processes

If a process is terminated either by the system or by a user while a HPA index is being activated or filled, you can restart it by choosing the restart option (Continue) in the corresponding dialog box.

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 fast 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 took place on the HPA server. To clarify the status of the index, you have to closely analyze the termination message and the status of the index; you cannot automate this analysis. Therefore, when restarting the process, the system normally re-indexes an index that has status ”unknown” and notes this accordingly in the log. The fact index is the exception: Since this is usually the largest index of a HPA 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 again and highlights the index with status “unknown“. In this case it can be useful to analyze the log message and repair the index manually.

Activities

...

       1.      Select the HPA index that you want to activate and fill.

       2.      Choose Activate/Fill. The system creates an active version of the HPA index.

Activating

System Response

Result

First the system creates the indexes for the tables in a dialog process and creates the “logical” index with the metadata on the HPA server. This step may take a few minutes if the individual tables are very large and have split indexes on the HPA server. The more parts into which the index is being split, the longer the activation step. For more information about split indexes, see Technical Information About the HPA Engine.

When the HPA index has been activated successfully, the system changes the status display in the object version column to .

       3.      The Filling the HPA Index dialog box appears. Determine whether you want to execute filling/indexing in a dialog or background (batch) process.

Only choose the dialog option for InfoCubes with a very small dataset because when you execute in dialog mode, you cannot perform indexing in parallel.

       4.      If you schedule filling/indexing in background processing, the dialog box for determining start date values appears. Enter the required data.

Filling/Indexing

System Response

Result

The system reads the HPA-relevant data for each table from the database and indexes it on the HPA server, depending on the settings, in parallel using (asynchronous) RFC. After each block, and when it reaches the end of the data, the system calls a Prepare Optimize and a Commit Optimize. Master data tables S/X/Y tables: If the index of a table has already been created and filled by another HPA index, only those records that have been added in the meantime have to be indexed (read mode/fill mode “D“ during indexing).

When the HPA index has been filled/indexed successfully, the system changes the status display in the object version column to . The HPA index is available and can be used for queries.