Chapter 5: Advanced Administration
When looking to change the metadata of an SAP InfoCube with an index in the SAP NetWeaver BW Accelerator, SAP administrators should know that doing so can actually alter the index itself. When changes are made, any issues in the difference of old and new data are adjusted.
In this section, learn more about what occurs when changes to an InfoCube's metadata are altered. Also learn about performing a recovery within the NetWeaver BW Accelerator, how to do so by importing snapshots to the BW Accelerator system. Find out why indexing isn't possible during a recovery, and why any indexing processes that were running before the event that necessitated the recovery are terminated.
SAP NetWeaver BI Accelerator, Ch. 5
Table of contents:
Understanding the SAP NetWeaver BW Accelerator
Performing RFC connection checks in NetWeaver BW with SAP TREX
Changing InfoCube metadata in SAP BW Accelerator
5.2.5 Impact of Metadata Changes on the Accelerator
If you change the metadata for an InfoCube that has a BIA index, the BIA index may need to be adjusted as well. In most cases, this adjustment occurs automatically as soon as the InfoCube is activated. The system compares the current metadata of the BIA index with the metadata from the newly changed InfoCube, and any discrepancies trigger adjustment actions. If the metadata changes for the Info- Cube are transported to a system, the comparison and the adjustment occur in a post-activation step for the transport.
There are rare cases where the adjustment is not automatic. If you change the structural design of the InfoCube by adding or deleting a key figure or a characteristic, this change requires a complete rebuild of the BIA index. The rebuild is not performed automatically because the process may have a long runtime and impose significant load on the system. Instead, the BIA index is simply deleted. In this case, you need to schedule the rebuild manually to run at a convenient time.
To ensure consistency, the system rebuilds not just a single index but all the master data indexes for the InfoObject, which means all the S, X, and Y indexes. Rebuilding the master data indexes can be a time-consuming process, too, so if the size of the table exceeds a preset limit (the default value is 50,000 lines), the rebuild runs in a separate background process.
If this adjustment process fails for any reason, you can repair the BIA index in Transaction RSRV by running the repair program BIA index adjustments after InfoCube activation. This is equivalent to running program RSDDTREX_ INDEX_ADJUST. The program compares the metadata and then triggers any necessary adjustments. For performance reasons, you should run the program as a background job.
5.2.6 Rebuilding Indexes
If you find that a BI query reads data from the BI accelerator and outputs incorrect data or data that is different from the results returned when the database is read, you should do some preliminary troubleshooting before you approach SAP service experts for help.
First, make sure the problem is not caused by the database. You can do this by running the query twice in Transaction RSRT in debug mode, once on the database and once with the accelerator. If the results are different, make sure the latest database patches are applied, and check for SAP Notes on the patches. If you still have a problem, mention this test result in your customer message to SAP.
To enable SAP experts to solve the problem effectively, you need to tell them both which query delivered the wrong data and all information needed to reproduce the problem. You should specify the row and column of at least one cell that contains incorrect data, together with the name of the key figure and the characteristic values. If possible, you should provide a second query that shows the discrepancy when compared with the first. If data disappear during navigation, you should describe this navigation and create an OLAP trace. It is helpful to reduce the queries to the absolute minimum of selected values. For further details, see SAP Notes 995364, 1060387, and 1095886.
In exceptionally rare cases, BIA indexes can become corrupt and require rebuilding. A set of BIA checks can be activated to check the indexes, for example, to compare the index data with the BI table data or to check that the lists of indexes and tables correspond. If there is a problem with an index, the index can be deactivated, and any individual table within an index can be rebuilt as required to render the index fully functional again. All the functionality for checking, rebuilding, and rechecking the indexes is highly automated.
In Transaction RSRV (see Figure 4.7 shown earlier), you can analyze and repair BI objects such as BIA indexes.
Checks are available for:
- Testing for inconsistencies between the data in the InfoCube on the database and the data in the BIA index — node BI Accelerator Consistency Checks
- Testing whether an accelerator index is running with optimal performance — node BI Accelerator Performance Checks
- Completely or partially building or rebuilding all BIA indexes or a specific BIA index — node BI Accelerator Repair Programs
The exactness and duration of each of these checks vary. For most purposes, you would run data consistency checks from the BI Accelerator Data Consistency Check Center (see Section 5.2.2) rather than from Transaction RSRV.
In the BIA monitor, you can specify that the system is to run a small number of tests on a daily basis. You do this by choosing BI Accelerator _ Execute/Display Index Checks.
Some of the tests work with statistics data. The statistics have to be switched on for the relevant InfoProvider. You make this setting in the statistics properties maintenance screen. On the Data Warehousing Workbench screen, choose Tools _ Settings for BI Statistics.
Transaction RSRV currently includes the following groups of consistency checks, performance checks, and repair programs for the accelerator:
- Consistency checks for master and transactional data
- Consistency checks for metadata
- Performance checks
- Repair programs
These tests can be run separately or combined. There are three predefined combinations of tests:
- Consistency checks (detailed)
- Consistency checks (fast)
To run one or more checks, proceed as described in Section 5.2.2. If a check discovers a corrupt or missing index, one option is to start Transaction RSDDV and rebuild the entire BIA index containing that index.
If the option of rebuilding the entire BIA index requires too much runtime, or perhaps fails in execution for any reason, another option is available to an SAP Service engineer. This is to identify which individual table index or indexes need to be rebuilt and rebuild them separately. This option requires deep understanding of the SAP NetWeaver BI system landscape and is not supported for use by anyone except SAP Service engineers.
You can find out which table index is causing a problem by looking at the indexing logs. Running the BIA Index Maintenance Wizard in Transaction RSDDV generates application logs.
To view the logs, choose the Application Logs wizard button. A dialog box appears. Select the process logs you wish to see and execute. The screen shown in Figure 5.21 appears, with the Object ("RSDDTREX", BIA index), Subobject ("TAGGRFILL", fill BIA index), and External ID fields already filled. Enter any further information, and execute. The indexing logs are then displayed, with colored icons to indicate the success of the indexing steps.
To verify that the BIA indexes now have status green, start Transaction RSDDV, and choose BIA Indexes. Drilling down on an index displays the details shown in Figure 5.22. In this case, all the table index icons are green, and all is well for this BIA index. The flags on the right indicate that some of the master data tables are shared with other BIA indexes.
Finally, to confirm that the indexing was successful, you can check the logs again as follows. Start Transaction SLG1, specify Object "RSDDTREX" and subobject "TAGGRFILL", and execute (the screen is as shown earlier in Figure 5.21). This will display a set of logs with colored icons indicating the success of the indexing actions. If there were problems here and you wished to drill deeper, you could start Transaction SM21 and study the system log.
5.2.7 Performing a Recovery
During a recovery, no indexing is possible, and any indexing processes that were running before the event that necessitated the recovery are terminated.
A BIA recovery involves importing a saved snapshot to a BIA system. Any other data loads to the accelerator are automatically put on hold during the imports.
A restore from an import deletes all the BIA indexes that have been backed up and imports all the indexes from the backup. The new BIA indexes are distributed over the BIA servers as before. After the recovery has completed, you may need to trigger a reorganization of the index landscape.
Once the snapshot is imported, the next step is index adjustment. If an index has not been changed because the snapshot was created (which is checked by comparing timestamps), no adjustment is needed. If the index has changed, the adjustment depends on the index type. Fact index requests can be reloaded (if they have not been compressed), dimension indexes are completely rebuilt (except the package dimension index, which is adjusted), and S/X/Y indexes are completely rebuilt.
You can perform a recovery from the BIA monitor as follows:
- Choose BI Accelerator _ Maintenance Functions _ Backup and Recovery.
- If you wish to estimate how long the recovery process will take, select the relevant snapshot, and choose Simulate.
- Select the snapshot you want to recover, and start the recovery process. The job executes immediately and cannot be scheduled.
- You can view the job log. A new button is displayed indicating that the recovery process is running. To view the log, click the button.
- Check the BIA configuration, the initial BIA logs, and the consistency of the BIA indexes.
To ensure that you are prepared to perform a recovery if necessary, you can simulate a recovery. This can also give you an indication of whether it would be faster to re-index all your data from scratch.
If you like, instead of simulating a recovery to decide whether it would be faster than re-indexing, you can evaluate the following factors:
- Age of the snapshot and how many updates have occurred since it was made
- Degree of parallelism and number of CPU cores of the TREX backup server
- Performance of the storage system for the backups
- Bandwidth between the TREX backup server and the storage system
Before performing a BIA recovery, it may be a good idea to check anything in SAP NetWeaver BI that can affect the status of the accelerator:
- Check the InfoCube data to ensure that the roll-up status is up to date.
- Check that all the master data used in BIA have been updated.
You'll find more downloadable excerpts from books by SAP experts in our SAP chapter download library.