Child pages
  • A Performance Issue With Transaction RSPCM
Skip to end of metadata
Go to start of metadata


Transaction RSPCM has an increased response time or is hanging. There could also be some locks on table RSPCLOGCHAIN for a specific LOGID for a very long time. You might also notice that there are long running jobs like SAP_CCMS_MONI_BATCH_DP or BICCMS_<client>_<timestamp>.

To Recreate The Issue:

Execute transaction RSPCM or schedule the job SAP_CCMS_MONI_BATCH_DP.


The BICCMS_* job is triggered by the main collector job sap_ccms_moni_batch_dp, which gathers information from process chains and requests for CCMS monitoring. This is usually scheduled in the BW productive client. The purpose of the job is to check and evaluate all requests and process chains where the status has been changed since the last run of the job. It gathers all information IDOCs from the source & BW systems, request/deletion information for DTPs and Infopackages etc. Therefore there is a high usage of tables such as EDIDC, RSMONMESS, EDI40 etc. both in BW and in the connected SAP source systems. If the access to those tables is slow, then the problem outlined in the symptom section might arise and the response time will be negatively affected.


  1. The first and most important step to improve performance is to create an index on table EDIDC including the fields MANDT, CREDAT and MESTYP. 
  2. The ALE tables (EDIDC, EDI40 etc) should be reorganized in your BW and also in the connected source systems to improve the performance of the job. 
  3. Perform a request archiving to reorganize all the maintenance tables for the Infopackage & DTP requests such as RSMONMESS and RSBMONMESS. This can be done with the help of the archiving object BWREQARCH, documentation on this is available in the link below:

  1. Apply the recommendations from these notes:  
  • 761734 - Performance of IDoc search in BW load monitor 
  • 706478 - Preventing Basis tables from increasing considerably 
  •   40088 - EDI/IDoc: Deleting and reorganizing IDocs