When you archive request administration data, you store administration and log information about requests in an archive and thus improve the performance for actions concerning requests.
When you display a request in the extraction monitor or in InfoProvider administration, the system checks the completeness of the administration tables of the scheduler and the log tables of the extraction monitor (tables RS*DONE and RSMON*). If the entries for the request are not complete or are missing from the table, the system gives this request the status red. Since the system uses the administration data of the request to dynamically determine the request status, this administration data is required. If the system gives a request the status red because it cannot find the administration or log information, the technical and QM statuses are reset in all the targets that were filled by this request. This may result in a termination, or in the queries that were defined for the affected InfoProviders displaying obsolete data, or no data at all. Therefore, you cannot delete entries from these tables.
The administration tables in the scheduler and the log tables in the extraction monitor increase with each new request from BI. This in turn affects the performance.
If you now store the administration and log information about requests in an archive, totals records are kept in the relevant tables in the BI system. This prevents the status of the request from being changed to red because information is missing, and allows you limit the table size of the administration and log tables RS*DONE and RSMON*. This improves the performance for actions performed for the request and in the affected InfoProviders and saves memory space in the database without affecting the status set by the system.
For certain functions and processes that access requests, you have to reload request administration data from the archive to the BI administration and log tables.
More information: Reloading Request Administration Data
It is currently not possible to archive request administration data for data transfer processes.
To avoid reloading data from the archive unnecessarily, we recommend that you only archive request administration data for requests that are more than three months old and will probably not be processed again.
The archiving concept for request administration data is based on the SAP NetWeaver data archiving concept. The archiving object BWREQARCH contains information about which database tables are used for archiving, and which programs you can run (write program, delete program, reload program). You execute these programs in transaction SARA (archive administration for an archiving object).
In addition, you can manage archiving sessions for requests in archive management in the Administration functional area of the Data Warehousing Workbench. You can also execute various functions for the archiving sessions here.
If you performed an upgrade from SAP BW 2.x or 3.x to SAP NetWeaver 7.x:
Reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA have been executed at least once for all objects. We recommend that you execute the reports in the background.
The following functions are available for archiving the request administration data:
The header table of the requests, table RSREQDONE, is not archived. It contains one record for each request. This record also contains information about the status of the archiving.
Request data is archived from the following tables:
Table |
Changes upon Archiving |
RSSELDONE |
One record remains in the table for each archived request; further records for the same request are deleted after archiving. |
RSLDTDONE |
Entries for the selected request are deleted after archiving. |
RSDELDONE |
Entries for the selected request are deleted after archiving. |
RSHIEDONE |
Entries for the selected request are deleted after archiving. |
RSRULEDONE |
Entries for the selected request are deleted after archiving. |
RSMONMESS |
Entries for the selected request are deleted after archiving. |
RSMONRQTAB |
Entries for the selected request are deleted after archiving. |
RSMONFACT |
Entries for the selected request are deleted after archiving. |
RSUICDONE |
Entries for the selected request are deleted after archiving. |
RSTCPDONE |
Entries for the selected request are deleted after archiving. |
RSCRTDONE |
Entries for the selected request are deleted after archiving. |
RSMONICTAB |
Entries for the selected request are deleted after archiving. |
RSMONIPTAB |
Entries for the selected request are deleted after archiving. |
Here you can:
● Execute the write program for archiving request administration data
● Execute the program for deleting archived administration data belonging to the requests from the database table
● Display an overview of the archiving session
● Execute the program for reloading archived request administration data of a complete archiving session into the database tables
Here the system displays the archiving sessions for archiving object BWREQARCH. Here you can:
● Go to the archive administration for the archiving object BWREQARCH (transaction SARA)
● Display requests with archived administration data for an archiving session
● Display the selections for an archiving session
● Reorganize archiving sessions
● Compare archiving sessions
● Delete archiving sessions from the archive administration in BI if they no longer contain administration data for the request
● Reload archived administration data for individual requests back into the database tables