Troubleshooting in BW-Based ABAP Statistics Data Reporting 
The uncompressed statistics data which is written in an ABAP system (ABAP statistics records or ASR) contains very detailed information about each process step in this system. You can analyze this data, for example, in the transaction STAD or STADWD (Analyze ABAP Statistics Records).
This data from managed systemen is aggregated for various SAP Solution Manager reporting applications, and saved im the Solution Manager BW by the Extractor Framework, because the volume of the uncompressed data would be too great to be stored in a central BW. These aggregates are comparable with the analysis views in the System Load Monitor (transaction ST03). There are, for example, aggregates which contain special information about RFC activities, and aggregates for dialog response time distribution. The collected aggregates are used in analyses of various applications, such as:
There are default configuration settings for compressing ASRs. These settings are always a compromise between minimizing data collection system load and memory requirement, and saving the greatest level of detail of data for reports. For a normal managed system use profile, the default configuration, which ensures the data basis for all reports delivered by SAP, is to be recommended. It is however possible, in special cases, that the system load caused by transferring ASR aggregate data to BW is too great, and you have to change the configuration settings. This process tells you how to recognize such a situation and change the configuration settings responsible.
Prerequisites
One or more of the following applies:
The performance of reports based on ASR data is poor, or they time out.
The BW tables in which ASRs are saved are very large (you can check their size with the program SMBI_ASR_BW_ANALYZE, which is explained in Check ASR Aggregate Table Size and Structure).
There are performance problems when processing ASR data (writing and reorganizing), or extraction takes longer than an hour, so extractions run in parallel, because data is loaded hourly. This can again cause DB deadlocks and crashes.
Ensure that too high data volume really is the cause of the problem. To preclude other problems, in the Solution Manager Administration work center, under Infrastructure, choose BW: Reporting, and check the Self-Checks of the scenario System Reports (see Self-Monitoring of BW-Based Reporting).
Process
Troubleshooting
If your systems display one of these symptoms, one or more managed systems are probably being used in an unusual way. The memory required by ASR records is reduced very differently by aggregation, depending on use.
Example
In a system with one instance, 100 users run 10 programs daily. This creates 1.000 new (aggregated) statistics records a day.
In a system with 10 instances, 10.000 users and 1.000 programs used (which is not unrealistic, for example in systems with high RFC use) already creates 100.000.000 aggregated data records.
Use the program SMBI_ASR_BW_ANALYZE to determine the data volume from the managed systems. Details of how to use the program are under Check Table Size and Structure of ASR Aggregates. This information will help you to adjust the ASR statistics data aggregation configuration settings.
Changing Configuration Settings
You usually reduce the system load caused by transferring and aggregating ASR, by allowing less information flow into the aggregation, by discarding some data in the aggregation. You can, for example, discard the user names. If 100 users are regularly active in a system, discarding the user names reduces the data by a factor of up to 100.
ASR reports are not reliable if aggregation information which is in the default configuration, is discarded. Check whether you need affected reports, before you change the extraction parameters.
How to change extraction settings is described under Change ASR Aggregate Extraction Settings.
Example
An example of a problem, from diagnosis to resolution, is presented under Example of Changing the Extraction of an ASR Aggregate.