When running a steady-state BI implementation you certainly spend a lot of time loading data from your source systems to make them available in your reports and for interfaces. Since the timely and correct loading of data is critical to the success of a BI implementation the monitoring of the load process is vital.
See below a few tools and transactions, which I commonly use to get an overview (and drill down to the details) of the status of the BI loading. If you are interested how to troubleshoot an individual load, please check my previous post ‘How to Check a BI Load‘.
ST13 – Analysis and Service Tools
Use BW-TOOLS and from there process chain monitoring. This should give you a good overview of what chains are currently running, how long they took and if anything is going wrong (RED). If necessary you can drill down from the overview into the details of the meta and process chains.
SM66 – Global Work Processes
Look for the resource allocation (CPU, memory) and check for long running processes (time column), also check the status if the program is still doing something or if it is waiting for something (reason column). Check for processes, which your BI background user started (see the value of BW_USER in table RSADMIN) as scheduled process chain processes will be owned by this user.
SM37 – Job Overview
Look for cancelled jobs and check the job log if there is anything concerning. Cancelled jobs are either shut down by the system (used too many resources), the user (manual stop) or due to a failure condition (short dump). The failures should be investigated and corrective action should be taken if necessary.
ST22 – ABAP Runtime Errors
If you have jobs / processes dying due to short dumps you should see them here. Again, look for your BI user and look at any short dump, which looks funny (some experience is needed to pinpoint critical issues). Look at short dumps with the same description / similar cause occurring in a short window of time.
RSDDBIAMON – BWA Monitor
If you are using BWA, check the alerts and look for BWA warnings and errors, especially if you get issues in the roll up steps (some of these can also be checked via TREXADMIN – TREX Administration). I have experienced a few issues lately, where the roll up in BWA died, but the termination was not updated in the process chains.
These situations are difficult to detect until the next process chain runs and fails due to locks (drop index, create index, load into data target), which are still held on the data providers by the previously started roll up. The fix is to start the roll up manually. This will clean up the index and release the lock afterward.
