The BW Background Management, Logs and Tools screen offers you the following checking and conversion programs:
After running the report, system performance improves when the same request selections are found. This check is always performed when a new request is to be generated. Without mapping the selections to hash values this can take several minutes.
This report must
To improve performance when displaying requests (in InfoProvider administration, for example) and loading data, in SAP NetWeaver 7.0, the administration information for requests is stored in special tables (RSSTATMANPART and RSSTATMANPARTT for InfoProviders and RSstatmanpsa and RSstatmanpsaT for PSA tables). This allows quicker access to the information. These quick access tables are part of the status administration that makes managing requests easier. The reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA write available request information for existing objects to the new tables to enable quicker access. They also fill the status management tool with the existing data. These reports primarily serve to transfer existing data to the new administration tables. The request information for newly loaded requests and objects created after the upgrade is automatically written to the new table.
It might be necessary to execute the reports again after the upgrade if the request status is inconsistent.
It is mandatory that these reports be executed after an upgrade. They are also required in order to archive request administration data.
If you are running a BW system as a content development system, inconsistencies might occur between the A and D versions of the InfoPackage and between the shadow version and cross-reference table RSSHIPDVERS. You can display and report this and other inconsistencies of InfoPackages with the report RSSM_SHIPDVERS_CLEANUP.
Executing Checking and Conversion Programs after an Upgrade to SAP NetWeaver 7.0
You are on the BW Background Management, Logs and Tools screen (transaction RSBATCH). Perform the following steps in the given order:
With the report, internal tables are built for each request. These tables contain the various selections of the request and mark each of them with a 40-character hash value.
The hash values for the selections are stored in the RSSELDONE (field SEL_HASH, data selections) and RSREQDONE (fields META_HASH - miscellaneous meta selections, TCP_HASH - third-party selections, LDT_HASH - InfoPackage texts, RULE_HASH, routines, UIC_HASH - data target selections) tables.
Afterwards entries for each hash value are generated in the following tables:
If a new request is now generated, the system first maps the selections of this request using hash values and then checks whether the new hash keys SEL_HASH and TCP_HASH are already in table RSHASHMAP as a triplet. If this is the case, there has already been a request with these selections and the system transfers the InfoPackage ID from the RSHASHMAP table. If this is not the case, a new InfoPackage ID is generated and entered into the RSHASHMAP table. The six new hash values are entered in the RSHASHCTRL and the RSHASHDATA tables, if they are not already entered. Table RSHASHTYP is for a later version.
We recommend that you provide these reports with as many resources as possible.
When you execute check and conversion programs, the system checks the status of all requests for the selected objects, changes or includes entries as required, and deletes the entries for deleted requests.
For large systems with hundreds of InfoProviders (and a similar number of PSA tables) as well as hundreds of thousands of requests, both of these reports can take several hours to run, even if many jobs are executed in parallel.
The report is executed directly and, after the check, shows whether the reports for creating hash values and for building fast access tables executed correctly or if further actions are necessary.
Executing Checking and Conversion Programs if the Request Status is Inconsistent
After an upgrade, you should execute the reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA again if the contents of tables RSSTATMANPART or RSSTATMANPSA or the status or information for the request were inconsistent. Incorrect traffic lights or deleted requests might still be displayed in the administration of the InfoProvider. Note that the reports should only be executed if there are inconsistencies, and not periodically.
In this case proceed as described above. Specify whether you want to check status management. This check is only recommended if the reports have already been executed. It is also useful if you find inconsistencies in the status management for the requests, for example if the system continues to display deleted requests in InfoProvider administration or displays the incorrect request status even after the reports have been executed.
Checking and Repairing BI Content InfoPackages
You are on the BW Background Management, Logs and Tools screen (transaction RSBATCH).
If you also want to examine all the InfoPackages in the shadow table RSLDPIOSH, but not in the table RSSHIPDVERS with the report, select Check Shadow InfoPackages.
The result list shows the A version, D version, and shadow version as well as whether there is an RSSHIPDVERS entry. If this entry is missing, an empty field is displayed. The column Repair to be Performed describes which repair would be necessary.
Once you have performed the general checks, you can hide various symptoms, such as Find shadow InfoPackages without D (and SHIPDVERS entry) from the display by choosing Set Filter.
If there are A and D entries, but no RSSHIPDVERS entries, for a D entry, the system tries to find a suitable shadow InfoPackage with an identical name and selection.
After a successful repair, the system displays the suitable shadow InfoPackage in the column Shadow Version of InfoPackage.
If the repair was not successful, the system displays an input-ready field with question marks. You can enter a suitable shadow InfoPackage here. This InfoPackage is entered in table RSSHIPDVERS. If you make no entry and are not in a content development system, the D version of the InfoPackage is deleted. If you make no entry and are in a content development system, a new suitable shadow InfoPackage is created from the A version with a new RSSHUIPDVERS entry.