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
|2049519||Problems during data load due to reduced requests||consolidation of important notes and corrections|
|2146472||FAQ for Report - RSSM_REDUCE_REQUESTLIST, RSSM_EXPAND_REQUESTLIST and RSSM_RED||consulting|
|2000002||FAQ: SAP HANA SQL Optimization||FAQ|
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
- 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
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