Chapter 5: Advanced Administration
One of the more common challenges related to the SAP NetWeaver BW Accelerator that SAP administrators face is a broken RFC connection between the blades of the BW Accelerator and the NetWeaver BW system itself. To diagnose these problems -- and in many cases repair them -- administrators can look to the SAP TREX standalone administration tool.
In this section, learn how to create and maintain an RFC connection in NetWeaver BW for the BW Accelerator. Find out how to stop RFC connection problems before they arise by ensuring the TREX alert server performs consistency checks of the connection. Also learn how to make sure the BW Accelerator data is consistent with the InfoCube data in the SAP BI system by using the BW Accelerator Data Consistency Check Center.
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 Exceptional Tasks
As an administrator, you should be able to handle not only the tasks that arise during routine operation of the SAP NetWeaver BI Accelerator, but also certain tasks you would need to perform only in exceptional circumstances. Here we review some of these tasks.
5.2.1 Repairing the RFC Connection
If the RFC connection between the BIA blades and the SAP NetWeaver BI system is broken for any reason, the situation can be diagnosed and in most cases repaired using the TREX administration tool. The tool offers full support for creating and editing RFC destinations, pinging hosts to locate network problems, reporting in detail on any issues that arise, and automatically repairing broken connections.
Alerts are color-coded to highlight any that require manual intervention. In general, red alerts indicate an error status that the tool cannot repair by itself, while yellow alerts indicate issues that the tool can resolve automatically. The red alerts indicate situations that require human action. The yellow alerts will be repaired in the next check run if the RFC check in the alert server is activated (where the check runs by default every 5 minutes).
You can create a new RFC destination in the SAP NetWeaver BI system for the accelerator by using Transaction SM59, as described in Section 4.2.2. The connection type is TCP/IP, and TREX runs as a registered server program. The program ID is unimportant because the accelerator overwrites it automatically with a correct ID.
To ensure that you receive sufficient warning of any RFC problems that may arise, you can check that the TREX alert server is configured to perform regular automatic RFC connection checks and to send you an e-mail if a problem is sufficiently serious.
To handle matters related to the RFC communication between the accelerator and the BI system, choose the Connectivity view in the TREX standalone administration tool, as shown in Figure 5.5.
The view opens to show the Rfc tab with its Current tab showing. The tool indicates any recommended next action by highlighting the relevant button with a different color. In the case shown, the administration tool has not yet connected itself to the BI system, as indicated by the gray (diamond) icon, and the recommended next action is to choose the Connect Admin Tool button.
If the TREX standalone administration tool attempts to connect itself to the BI system, but the required connection data is missing in the accelerator, the tool will show a message highlighted in yellow as shown in Figure 5.6.
The recommended next action is to create a connection. This is indicated by the highlighting of the button you should choose next to create a connection. When you do so, the dialog box shown in Figure 5.7 appears.
This dialog box enables you to create a connection to the specified SAP system on the assumption that a correctly configured RFC destination exists in that system. Within TREX, the connection data you enter in the dialog box is stored in the saprfc.ini file, and the logon data you enter is encrypted and stored in topology.ini.
When you set up an RFC destination, you need to specify whether your accelerator connects to your SAP NetWeaver BI system landscape via local gateways or a central gateway (see Figure 5.8). Each TREX instance has one RFC server process, which spawns as many threads as required.
A central gateway between the local gateways on the application servers and the RFC servers in TREX appears to offer simpler traffic flow because each node at either end communicates with only a single node represented by the central gateway but has the disadvantage that this central node is a single point of failure and can be a bottleneck in a heavy load scenario. For this reason, we recommend the use of local gateways for communication with the accelerator.
In the local gateway configuration, each application server communicates directly through an RFC server with every TREX instance in the BIA landscape, and vice versa. As Figure 5.8 shows, this can give rise to a large number of RFC server threads on each BIA host, but no extra administration is required. The administrator simply leaves the gateway option fields blank when setting up the RFC destination. TREX then starts as many RFC server threads as needed.
If a suitable RFC destination does not yet exist in the target SAP system, you can create one, either in Transaction SM59 or in the TREX standalone administration tool.
If TREX does not find a suitable RFC destination in the target SAP system, the tool prompts you (with highlighted buttons) either to enter into TREX the information about an existing RFC destination that is defined in a connected SAP system (see Figure 5.9) and store the information in the TREX topology.ini file or to create a new RFC destination in a connected SAP system (see Figure 5.10). If you create a new destination, you do not need to enter a program ID because TREX generates one automatically for use at both ends of the connection. Again, the information is stored locally in the TREX topology.ini file. As soon as the destination has been created, a "created successfully" information box appears.
Creating a new RFC destination from TREX as shown in Figure 5.10 is equivalent to doing so in the SAP system using Transaction SM59. Both ways of setting up an RFC destination require the same information.
Connecting the TREX administration tool to the SAP system is just the first step. Once the tool has successfully connected, it determines whether all the BIA blade server hosts can communicate correctly with the SAP system. If not, for example, because an application server has been removed from the landscape or added to it, the tool may display information similar to that shown in Figure 5.11, with error details highlighted in red, other unresolved issues in yellow, and a yellow (warning triangle) status icon for the affected system. The problems highlighted in yellow can be solved by the automatic repair capabilities built into the administration tool. In this case, the tool prompts you with highlighting to choose the Repair All button. Because the RFC check runs automatically in the background, you can simply wait to let the repair run, and check that it has done by clicking Refresh as often as necessary, but clicking the highlighted Repair All button can speed up the repair if you are in a hurry.
Fortunately, the problems shown here were not too serious, and TREX solved them all in seconds, as shown in Figure 5.12. Now the tool shows a green (square) configuration status icon and highlights the connection details in green to indicate that all is well. Generally, the tool offers clear visual feedback in this way to ensure that the administrator knows as exactly as possible what to do next.
The TREX administration tool includes a great deal more functionality for the automatic repair of connectivity issues, but the user experience is always similar to that illustrated here, and an experienced administrator should have no difficulty with it.
5.2.2 Consistency Checks
To ensure that the data in your BIA indexes are consistent with the InfoCube data in the BI system, you can run a variety of consistency checks. The main launch point for such checks is the BI Accelerator Data Consistency Check Center.
From the BIA monitor, choose Goto _ Consistency Checks. This opens the BI Accelerator Data Consistency Check Center. From this center, you can execute consistency checks, schedule these checks, and view the logs of checks that have run (see Figure 5.13).
The BI Accelerator Data Consistency Check Center offers the following tabs from which you can execute the checks:
- Data Comparison
Enables you to compare the contents of each individual table in an InfoCube with the contents of the corresponding index, record by record. This check is only suitable for relatively small tables and indexes.
- Totals in BIA
Enables you to check key figure sums internally by executing a query on the BIA index using all key figures. Then the BI system executes a query for each characteristic and navigation attribute occurring in the InfoCube that aggregates over all key figures. All the characteristics and navigation attributes that exist in the InfoCube are then included individually in the drilldown, and the totals are calculated. The system compares the result with the result of the first query. This test checks the completeness of the join paths to the fact tables. If the test shows that the data is incorrect, you need to rebuild the BIA index and its master data indexes.
- Totals in BIA and DB
Enables you to compare key figure sums on the database against and in the BIA index. The system executes a query for each characteristic and navigation attribute occurring in the InfoCube that aggregates over all key figures on the BIA index and the database. Then it sums individually over all the characteristics and navigation attributes occurring in the InfoCube and compares the results from the database and the accelerator. The runtime of the test can be long. If it shows that the data is incorrect, you need to rebuild the BIA index and its master data indexes.
- Random Queries
Enables you to checks for consistency by executing random queries, reading the data once from the database and once from the accelerator. The results should be the same. However, they can differ if the InfoCube data has been changed between execution of the query on the database and in the accelerator. You can verify the results as described later in this section. To repair the index, you need to rebuild it.
- Index Existence
Enables you to checks whether indexes have been created for all the (relevant) tables in the star schema for the InfoCube. The test is very fast. If an index is missing, the BIA index needs to be rebuilt.
As an alternative to working from the BI Accelerator Data Consistency Check Center, you can run some fast index checks from the BIA monitor. Or you can run the more thorough checks in Transaction RSRV, to check that the indexes are complete and consistent.
To execute one or more sets of automatic BIA index checks in the BIA monitor, choose Index Checks _ BI Accelerator.
This offers the following further options:
- Index Checks Schedule/Deschedule
Toggles the index checks schedule on or off.
- Execute/Display/Change checks
Displays a dialog box inviting you to flag the check set or sets you want to run, and then execute (see Figure 5.14). Once the checks have run, the results are displayed. In the run shown in Figure 5.15, 11 checks ran smoothly, and no red or yellow alerts were generated.
The default set of index checks currently includes three checks. Check 1 looks at the size of delta indexes for BIA indexes, check 2 compares the size of InfoCube fact tables with their fact indexes, and check 3 looks at the relation between tables and indexes. The checks run quickly and provide useful information about performance and consistency. They can also be found and run in the analysis and repair environment (Transaction RSRV, see Section 5.2.6).
To execute selected elementary or combined checks in Transaction RSRV, drill down in the check set tree displayed on the left side of the screen to find the accelerator checks that you wish to run and double-click on them. This causes their names to appear on the right side of the screen (see Figure 5.16). Alternatively, you can drag them to the right and drop them there. Then, for each check on the right, you need to set the relevant parameters (this generally means specifying the InfoCube or InfoCubes to be checked). To do this, click on the lines at right to open a dialog box (see Figure 5.17) where you can enter the required values. When you are ready, choose Execute and wait for the results (see Figure 5.18). These are displayed as a detailed list with a colored icon for each line to show at a glance whether all went well.
When to Run Checks: A Matrix
With so many checks, so many indexes to check, and so many possible reasons to run a check, it may seem impossible to follow a regular plan here. However, a little preparation can help. Draw a matrix with checks and reasons to run checks as its columns and rows, and then fill it out for yourself in view of your index landscape and your own priorities.
Table 5.1 shows a possible matrix. Here the 6 consistency checks listed below the matrix are numbered in the column heads and mapped to the 13 reasons to run checks listed in the rows. Check 1 is a query load generated by the RSTT trace tool described in Section 5.4.3, and checks 2–6 are listed with brief descriptions in Section 5.2.2.
As an example of how to read this matrix, the dots in it specify that after a roll-up or a change run, you plan to run the checks 2–6, and after hardware changes or performance shortfalls, you plan to run checks 1, 4, and 5.
The pattern of dots in this matrix is just an example, and as an administrator, you should plot your own matrix. Ideally, you should also insert more detail, for example, by adding a line specifying how often in the routine case you plan to run the check and a line indicating approximately how much time on average the check takes to run.
|Rebuild all indexes||√||√||√||√||√|
|Usage of delta index||√||√||√|
|Repair master data index||√||√||√||√||√||√|
|1. Transaction RSTT generated query load
2. Compare data in BI tables and accelerator indexes
3. Check sums of key figures of accelerator queries
4. Check for consistency using random queries
5. Check existence of indexes for DB tables
6. Check definition of logical index
This check compares the contents of each individual table with the contents of the corresponding index, record by record. It is only suitable for tables or indexes that do not contain a large amount of data, such as dimension tables, certain S tables, and X and Y tables. Fact tables are normally too large for this check. If a table contains 10,000 records or more, it is not checked.
This check first executes a query on the BIA index, which is aggregated using all key figures, then includes all the characteristics and navigation attributes that exist in the InfoCube individually in drilldowns, and calculates the totals. The results are now compared to check the completeness of the join paths to the fact tables.
This check executes highly aggregated queries and compares the results from the database with those from the BIA index. For large InfoCubes, the runtime may be long.
This test checks whether all the (relevant) indexes for a given InfoCube have been created on the BIA server. Its runtime is very fast. If the test reveals that an index is missing, the BIA index needs to be rebuilt.
This check executes random queries without persisting them. The system reads the data once from the database and once from the accelerator, and then compares the results. If the results differ, an error message is output.
You can leave all other values unchanged. If the results are the same as from the check, you need to rebuild the BIA index.
When queries are executed in hierarchies, the hierarchy nodes are expanded to the relevant leaves and the expansion saved in a temporary index in the accelerator. The hierarchy buffer manages expanded hierarchies according to an LRU (least recently used) algorithm.
This check compares the definitions of each of the table indexes in a BIA index with the current versions of the database tables. It checks whether the number, name, and type of the table fields in the database match the definition for the index on the BIA server. If you do not specify an InfoCube, the system executes the test for all InfoCubes that have a BIA index.
The system checks the logical index of a BIA index. The logical index contains the metadata for the BIA index, such as the join conditions and the names of the fields, and may change if the InfoCube is changed. If you do not specify an InfoCube, the system executes the test for all InfoCubes that have a BIA index.
The system checks whether BIA indexes contain indexes that have the status unknown. This only occurs in exceptional cases when the Commit Optimize call terminates during indexing. Because in this case it is not clear whether the previously indexed data is available, the affected indexes are rebuilt in repair mode.
Displaying and Changing a Check Set
To display an existing check set, select it from the input help for the Check Set ID field (see Figure 5.20). You can change the parameter values of the selected check set and save it again. The Check Set ID stays the same.