SAP Netweaver Business Intelligence BI / BW

Symptom

You have a data target into which many requests have already been loaded (scale 10000) or for which you expect a large number of requests in future.
Loading data or activating requests for an ODS object and/or displaying the request list in the administration of the data target slows down over time.
Other terms

RSSELDONE, RSLDTDONE, RSREQDONE, package, time out, RSMONICDP, RSICCONT,
RSREQICODS, RSSTATMANPART, RSSTATMANPARTT, RSSTATMANSTATUS,
RSSTATMANREQMAP
Reason and Prerequisites

You have a data target with a large number of requests.
Since certain information of all requests is required in a data target for the actions described above, a relatively large number of entries must be read and processed in different tables.
As a result, the processing times become longer and longer.
Solution

1. You can alleviate the situation to some extent by tuning. According to Note 48230, some of the database statements can be accelerated by parameter changes. See also Note 601612.
The following is an alternative option:
2. The idea here is to load the data of the affected data target (referred to from now on as A1) into one copy, so that you now only have one large request in this copy. Proceed as follows:
a) Create an identical copy A2 of your data target A1 with all data flows (update rules, connections to the export DataSource of the data target).
b) If A1 is used as an InfoProvider (for queries): Create a MultiProvider that contains both InfoProviders A1 and A2, or change existing MultiProviders containing A1 so that they contain A1 and A2 with the same characteristic and key figure identifier to ensure that consistent reports are still possible when the MultiProvider is used for processing. Copy the queries from A1 to the MultiProvider (for example, using transaction RSZC). Components into which these queries are embedded may also need to be adjusted accordingly (for example, Workbooks or Web Applications).
c) Create an update rule from A1 to A2 with the identical assignment of the characteristics and key figures.
d) Stop all delta updates in the source systems which affect A1.
e) Load any deltas that are still in the source system into A1.
f) If A1 is an ODS object, activate all requests that have not been activated yet.
g) Update all requests that are not yet updated from A1 into connected data targets (if available), but not do not update them into A2 yet.
h) Load all data from A1 to A2 with a full upload without selection criteria.
i) As soon as all the data has been loaded successfully from A1 to A2, completely delete the data in A1.
j) Perform a delta initialization for the connected DataSources for A1 without data transfer (if they are DataSources that supplied A1 in the delta method).
k) Switch on the delta updates in the source system again and supply the empty A1 data target with the deltas again.
l) In future, the connected data targets must be supplied from A2. For this you must carry out a delta initialization (as described for step j)) without data transfer for the connected data targets from A2 and load into these data targets from A2 in the future.
m) Execute steps d) to k) each time the performance of the A1 data target becomes too slow.
Note the following: You can continue to supply the data targets behind data target A1 from A1, if you cannot wait when supplying the downstream data targets, until the data is in A2. However, then you must supply all new data targets with an Init simulation once the A1 data target content has been fully deleted.
We recommend that you carry out this process once a month or once a week. However, if you were to do this on a daily basis, it is unlikely that the A2 data target would ever contain too many requests.