Monday, September 3, 2012

Restoring lost data from a delta request


Note 691721 - Restoring lost data from a delta request

Summary
Symptom
A delta request does not contain all data or contains corrupt data. It is not the latest delta request since the error was not recognized immediately.
Other terms
Repeat; inconsistent
Reason and Prerequisites
The cause of the problem is not known for certain.
Solution
As a solution, reinitialize the delta process (for Logistics: refer to note 602260 for more information).
If you can determine the relevant time period exactly, you can also partially rebuild the Logistics applications with a selective delta initialization. The exact process depends on the selection conditions used for the rebuilding (OLI*BW transactions) and on the fact whether you can delete data selectively in the BW system. For other applications, the possibility of rebuilding depends on the fact whether you can delete data selectively in the BW system and whether the data is available in the source system (refer to note 739863 for more information).
In general, you can proceed as follows:
1) Determine the cause of the problem. The data you want to load into the BW system must be available, correct and complete in the source system.
2) Stop all entries in the source system which can generate data for the relevant applications. This affects users and, possibly, automatic processes.
2a) For Logistics: Stop the update, that is, deactivate the execution of the RMBWV3nn report (where nn is the application number). Since the delta queue is deleted in a later step, you must prevent that the system tries to transfer data from an extraction queue to the delta queue during this step. Otherwise, the data would be lost.
3) Using a delta request, load the data from the relevant delta queue. If multiple DataSources are affected, load deltas for all DataSources.
4) Delete the delta initialization on the BW system. CAUTION: Data that is located in the delta queue at this time will be lost irrevocably. Refer to note 380078, question 1, for an explanation about the number in the "Total" column in transaction RSA7.
5) Delete the data selectively in the data targets for the relevant time frame. Bear in mind that dependencies may exist, for example, in datamart scenarios.
6) Perform a delta init simulation (delta initialization without data transfer) with the previously used selection conditions but without the time period deleted selectively.
7) Rebuild the statistical data selectively so that exactly the relevant data is retrieved. Refer to note 602260 for important information about the scheduling. This step is not performed for non-Logistics applications.
8) Perform an actual delta initialization (delta initialization with data transfer) for the selectively deleted time frame. The relevant data is transferred to the BW system.
9) Once all delta initialization requests have a "green" status, verify in the source system that the INITSTATE indicator is set to 'X' in the ROOSPRMSC table of the relevant DataSource. Now, entries can be made again in the source system and the RMBWV3nn update report can be scheduled again if necessary. If the indicator is not set, contact SAP Support and do not perform any other steps in the system until the problem is eliminated.

Bear in mind that this is a workaround which may not always work. Check the entire procedure in a test system.
Refer to note 739863 for a description of a second solution which you can use as an alternative to the selective rebuilding of data in the BW system.

No comments:

Post a Comment