Page tree
Skip to end of metadata
Go to start of metadata

WHY necessary

The number of requests in the data target (request list) influences the processing time for various actions on requests. There are various actions on requests where information is required (especially from status management) for all requests in a data target and a large number of entries must be processed in different tables. With increasing number of requests the performance can be descreasing for  different action on a specific infoproivder.

SAP Online Documentation

Request Housekeeping

SAP notes:

2049519Problems during data load due to reduced requestsconsolidation of important notes and corrections
2000002FAQ: SAP HANA SQL OptimizationFAQ


WHAT has to be considered? 

Only 'non-transparent' requests can be deleted from a infoprovider.  That means for:

cubes: the requests must be compressed

standard DSO: the requests msut be physically deleted from the changelog

write-optimized DSO: the requests must be archived


Further prerequisite:

  • deleted request has to be older than one month
  • more than 1000 of these requests exist without gaps
  • only the requests that were retrieved from all data targets (by DataMart) or were updated from all delta DTPs can be removed from the request list.
  • only requests up to the oldest delta requests that were loaded to this data target can be reduced. If the data target to be reduced is provided with delta requests from several delta sources, then these delta sources have to have transferred all their source requests; otherwise a delta source that has not transferred anything to the data target for months/years blocks the reduction of the request list.

The latest 4 requests cannot be reduced as they severs as a safety interval.

WHICH programs or transaction can be used? 

transaction: RSREQREDUCE (available for BW 7.4 SP5)

This transaction provides you an overview of your infoproviders and additionally determines for which infoprovider a reduction of requests is recommended. Further you can easy evaluate and schedule reduction jobs for a specific or mass reduction from that transaction. Another feature which could be usefull, not only for the request-list reduction, is that you can maintain a specific datatarget and get the information:

  • status information about the datatarget, e.g how many requests are available, what is the newest requests, datamart status, compressed status...
  • delta into the datatarget direct jump to e.g. DTP in order to upload missing deltas manually
  • delta from the datatarget direct jump to several objects like DTP, target infoprovider... possible



RSSM_REDUCE_REQUESTLIST for infocubes, standard DSO and WO-DSO

RSSM_EXPAND_REQUESTLIST reload request list

RSSM_AUTODEL_REQU_MASTER_TEXT for master and text infoprovider. Only the administration information and status manager information will be deleted.


WHAT technically happens?

The requests are deleted from the original tables and will be saved with the same name + _SAVE2

RSICCCONT                                       RSICCONT_SAVE2

RSMONICDP                                       RSMONICDP_SAVE2

RSODSACTREQ                                 RSODSACTREQ_SAVE2

RSREQICODS                                     RSREQICODS_SAVE2

RSSTATMANPART                             RSSTATMANPART_SAVE2



Reduction executions are stored in table RSREQREDUCE

The reduced request list decreases the time that status management requires to process the following processes:

  • Processing of data transfer processes (DTPs) or InfoPackages
    • Generating a delta DTP request (list of source requests and target requests is evaluated)
    • Closing a delta DTP request: (water levels in the source and in the target are evaluated)
  • Activating data in DataStore objects
  • Compressing, rolling up InfoCube data



1 Comment

  1. Does this activity can be performed on Real Time infocubes?