PURPOSE
Request-archiving is used to to archive reduce the size of administration and log tables e.g. RSMONMESS, RSSELDONE which can grow extensively if lots of requests are loaded into the system. All tables which are affected by the request archiving procedure can be found in transaction 'AOBJ' for the archiving object 'BWREQARCH'.
Main issue was that it was not allowed to delete requests from the administation and log tables as during some action like calling the manage screen of an infoprovider the system determines the status of the uploaded request. If something is missing the system change the status of the request to 'RED' , that also means that the data and also all furhter request are not released for reporting.
Archiving a requests allow a reduction of the administatrion and log table size and therefore improve actions performed on requests and in the affected infoprovider, save memory space on the database, without affection the status set by the system.
Archiving request administrator tables should be scheduled periodically. At the beginning it could be necessary to archive the records more often until the system notice that there are no data available for archiving anymore. Issue is that only about 10.000 requests can be archived per execution (see below)
The archives belonging to BWREQARCH must be kept and the corresponding archive files should NEVER be deleted. Certain processes (delta load, initialization, etc) which results the change of the status of an archived requests will automatically reload the requests from the archive.
Documentation
Online documention: Help Request archving
Important notes
| SAP NOTE | SHORT TEXT - remark |
|---|---|
| 1812238 | „Archive File Not Accessible” in SARA (no backup available) |
| 950612 | P9; request archiving: Archiving multiple requests as initial |
| 2177801 | provides report RSREQARCH_DTP_CONDENSE_LOGS in order to delete after the 'normal' archiving, more records of table RSBMONMESS_DTP, RSBMREQ_DTP, and RSBMLOGPAR_DTP, correction of SAP Note 2239379 should be available |
| 2346654 | report RSREQARCH_CHECK_DEL_OBS_MESS |
TABLES
RSREQARCH, RSREQARCHCTRL, RSREQARCHDATA, RSREQARCHDEL, RSREQARCHMON, RSREQARCHREORG contain administration, control and status information needed for request archiving.
TRANSACTION
SARA or RSREQARCH can be used to WRITE, DELETE or MANAGE the request archiving process
WRITE
Report RSREQARCH_WRITE can be used to archive requests. Thereby, the minimum number of request to be archived can be adjusted. By default, this is 1000 and should not be smaller since lots of archives are created otherwise. However, the maximum number of requests is limited to 10.000 (hard-coded) in order not to make the archives too big. Additionally, SM12-locks are necessary for the requests to be archived, so that they cannot be changed during that time. Therefore, one has to make sure that the SM12 lock table can hold a little bit more than 10.000 locks.
exctract from SAP note 950612
....
The program for choosing the requests to be selected proceeds as follows: In ascending order, it selects from the most recent request to all requests in the field "Selection date of requests" that have not yet been archived (if this selection remains empty, all requests are selected). The system then checks whether this request is older than the monthly selection in the field "Requests Older than". This filed must contain at least a "1" for a month. Months are always calculated with 31 days. The request that you may want to archive is then checked against the three radio buttons "Only Archive New Requests",
"Only Archive Reloaded Requests" and "Archive All Requests". If the button "Only Archive New Requests" is set, requests that were archived once before but were then reloaded from the archive are not archived again. If the button "Only Archive Reloaded Requests" is set, ONLY those requests that have already been archived once and reloaded again are archived. The button set to "Archive All Requests" archives all the requests that are not currently archived, regardless of whether these were already archived once and were reloaded again or not. We recommend that you set the button "Only Archive New Requests" for initial archiving because after several months you can check whether archived requests had to be reloaded again. For example, this is necessary for a reconstruction from the Persistent Staging Area (PSA). There is still the parameter "Min. Number Requests" An archive is only created if the report finds at least this number of requests that it can archive. The report collects the first 10,000 requests that meet the criteria and archives them. The report then stops. This guarantees that an archive does not have too many requests. Caution: You must save all requests that you want to archive in transaction SM12. This means that an enqueue lock is set for each request before it can be written to the archive. Therefore, you must set the BW so that at least 12,000 enqueues can be set or created at the same time.
If there is not enough memory for the enqueues (not enough can be allocated), then the process hangs. Ensure that the profile parameters enque/table_size and abap/shared_objects_size_MB that you choose are large enough (10...100 MByte).
.....
Table RSREQDONE
=================
For requests which have been archived a flag will be set in the header table RSREQDONE in field 'ARCHIVED'.
From table RSREQDONE no entry will be archived or deleted as this is the header table for the creation of requests in a BW system.
DELETE
After having performed the WRITE phase of the archiving it is necessary to have a "request-deletion phase". It is recommended to start the deletion program 'RSREQARCH_DELETE' automatically after teh write phase because it is not possible (for example, with a reconstruction process) to access the request as a runtime error occurs.
RELOAD
Request-information can be reloaded from the archive by means of report RSREQARCH_RELOAD or from transaction RSREQARCH or from Transaction SARA. Additionally, it is possible to "semi-automatically" reload the data (a pop-up has to be clicked before) if request information is again needed in the request monitor. Then, the single pieces of information for this particular request are reloaded. Moreover, if for example the PSA process has to access an already archived request again to update the protocol or the monitor entries, this request is than reloaded automatically. This is done with function module RSSM_RELOAD_REQUEST_FROM_ARCH.
TRANSACTION RSREQARCH
In this transaction you can manage all your request archiving runs. You can create, monitor, display requests, check the selection criteria,... and addtionally reloading can be carried out.
The following are the most important fields for the monitoring table:
- Archive Status
- Number of request in the archive
- Number of request in the archive not yet reloaded
- Number of reloaded requests /they are still in the archive but also been loaded back to the database
- Size in Byte of the archive in bytes: how big is the size of archive
- Size of requests in archive already reloaded
Possible values for the field Archive Status
- 'X' means that archiving is successful, data in the original database tables have been deleted and the archive can be reloaded.
- 'R' means that the archive is being reloaded.
- ' ' means that the reload has been finished. In this case the field Number of request in the archive not yet reloaded will be 0.