Hello Everyone –
In our blog “BIA Changes Everything!” BIA BLOG Series, Part I: BIA Changes Everything! the SAP NetWeaver RIG announced we would be publishing several topics with respect to the SAP NetWeaver BI Accelerator. If you haven’t had the opportunity to review the last blog in our series, BIA BLOG Series, Part III: Checking Data Consistency with SAP NetWeaver BI Accelerator, you can find it at: BIA BLOG Series, Part III: Checking Data Consistency with SAP NetWeaver BI Accelerator
Continuing the fourth part of the BI Accelerator (BIA) blog series, I will be addressing the topic of BIA Monitoring and Maintenance.
One key area that is necessary in your systems when monitoring and maintaining your BI Accelerator, is to ensure you have up to date statistics in your BI system. This is very important because you should be reviewing the statistical data related to your queries prior to determining if they should be candidates for BIA. The key to look for is if the queries are spending most of their time in the Data Manager meaning they are spending most of their time reading the database, as opposed to hitting the OLAP Processor which is where calculations and conversions are performed. If you have a query that is performing a significant amount of OLAP processing, then it is quite possible that it is not a candidate for BIA.
Once you have your indexes built in your BI Accelerator, overtime it can happen that the indexes become larger than fact table in your BI system; this can be caused either by compression in your BI system or by the deletion of requests. We recommend that you execute the BI and BIA table comparison job in RSRV on a periodic basis, and when there is a significant deviation, greater than 50% it is time to rebuild your index.
There are several additional RSRV checks available in your BI system that are specific to BIA that should also be utilized to aid in monitoring your systems health, including the BIA alerts, as well as the BIA Indexes with Status and Parts. In order to configure the BIA alerts it is required to logon via the TREXAdmin tool on the BI Accelerator itself and from there you can select which alerts you would like to activate. It is very important that someone is tasked with the role of monitoring these alerts and reviewing your BIA system’s health. On a bi-weekly basis have someone run the BIA Performance-Tests and the Consistency-Checks. Execute Check Sums, Existence of indexes for DB tables, check consistency with random queries, verification of hierarchy buffer and check if there are negative or greater DIMIDs, SIDs, all Meta data checks, and DTP check on a bi-weekly basis as well.
You may also want to consider executing all the above RSRV checks for BIA whenever you apply a new BIA revision, adopting these checks as part of your new testing plan.
Run BIA Index adjustment after InfoCube activation, when a relevant InfoCube has been altered, so on an as needed basis.
In addition to RSRV checks there is also an overall BIA check in transaction RSDDBIAMON2, you select the button system check and this will validate communication and execute a simple functionality test with the BI Accelerator, by way of creating data for an index, filling the index, executing a test query against the created index and then deleting that test index and return the results.
There are two different types of indexes that can be built on the BI Accelerator, the standard and most common index, which encompasses the entire fact table of an InfoCube. There is also what is called a delta index; this type of index is used when there are large volumes of data, and thus a large index. Rather than rebuilding a very large index frequently, you can utilize a delta index with only the changes in data acting as a supplemental index in the BI Accelerator to reduce rollup time. If you choose to use this option however there is one additional maintenance step that must be followed and that is, as the delta index grows in size, it must be merged with the main index in BIA. We would recommend scheduling the merging of the delta index if you choose to utilize option each week to avoid it from growing too large, so simple schedule it over the weekend.
One last administrative recommendation is from time to time you may need to perform an index reorganization or redistribution across your blades. Sometimes this is necessary as certainly indexes do change in size, as do their usage; you can actually launch this capability from the BI Accelerator Monitor, RSDDBIAMON2, select the check box Reorganize BIA Landscape and select the execute button.
The next blog in the series will be entitled BIA BLOG Series, Part V, Aggregates vs. BIA – What’s the trade-off