SAP BW Repair Full Request
Venkata Chalapathi Challapalli OUTOKUMPU Project Hyderabad
[email protected]
1.Introduction
As we can work with IniIt, Delta and Full loads most frequently in our regular data loads, some times we may need to make use of Repair Full Request too. We may get following questions when we are think about Repair Full Request first time. Why we are using Repair Full Request if we have Full Load and delta option? By doing Full repair request will it effect the existing delta mechanism in our ODS/InfoCube? In what scenarios we will use Full Repair request? This white paper will explain these entire questions. First we will take one scenario and start of understanding it.
2.Scenario: We are having one ODS Object: ZFIGN_O1 and this object is already used for reporting in production environment. This ODS object is updating the data from the InfoSource: 0FI_AP_4 as a regular delta update. As part of client requirement, we need to add a new field: 0CREDITOR to this existing ODS Object: ZFIGN_O1 and needs to populate the data for the particular Company Code: 6600. Since the field: 0CREDITOR is already present in the DataSource/InfoSource: 0FI_AP_4, our job is easy to add it in to our existing ODS Object: ZFIGN_O1. Now question is, how can we fill the data for this newly added field: 0CREDITOR? Do we need to do Re-InIt or Is there any other optimized way to full fill this requirement? (Please note that all the data fields are updating the data in to ODS with Update Type: Overwrite .)
Solution: After analyzing the above scenario, Repair Full Request is the best option to complete this requirement to load the data. By doing Repair Full Request will not disturb our ODS InIt/Delta mechanism. After completing Repair Full Request, we can continue with our regular delta loads in our existing ODS Object with out having any problem. More over, we can able to save our load time by doing Repair Full Request for this particular Company Code in our scenario without disturbing the existing delta set up.
How do we proceed to load a repair full request into the data target?
Go to the maintenance screen of the InfoPackage (Scheduler), set the type of data upload to "Full", and select the "Scheduler" option in the menu -> Full Request Repair -> Flag request as repair request -> Confirm.
Let’s click on Data Selection tab and give Company Code as 6610 and schedule the load.
Update the data into the PSA and then check that it is correct. If the data is correct, continue to update into the data targets."
Let’s confirm Repair Full request by selecting the check box as shown in the fig.
After execution of Repair Full Request, Manage screen of ODS Object is as shown bellow.
3.Facts about Repair Full Request Via the Scheduler menu we can indicate a request with full-update mode as Repair Full Request. This request can be updated into every data target even if the data target already contains data from an initialization run or delta for this Data Source/ source system combination, and has overlapping selection criteria Full repair preserving our delta selections. We can go for a repair full request when we have missed any delta loads or there are data corruption issues. By doing a full repair load, we can ensure that our data is correct and has good integrity. With this option we can continue to use our existing delta and not worry about resetting the delta. While performing Repair Full Request, make sure that the ODS is in overwrite mode and not additive. If its additive, then we'll face the problem of having duplicate data. If this is the case then we have to delete all the contents and then do the full repair request.
A repair full request can be updated into all ODS objects at any time without a check being performed. The system supports loading by repair request into an ODS object without a check being performed for overlapping data or for the sequence of the requests. This action may therefore result in duplicate data (In case of update type is Additive) and must thus be prepared very carefully. Before we start the Repair request into the ODS object, make sure that the incorrect data records are selectively deleted from the ODS object if any. Deleting the request from Scheduler->init options for source system, will allow us to Re-Initialize. This will reset the delta. When we do a full Repair load, the delta is not reset. Repair full request is only used when we need to do a full load to an ODS that already contains the Init request from the same datasource. If we do a simple full load, then in this case we will get errors in request activation. But in case of cube it doesn't matter as it is possible to do a full load even we had delta/init . If we do not flag the full load as repair full request we cannot activate the ODS data request. If we want to activate the request in ODS, we have to use a program RSSM_SET_REPAIR_FULL_FLAG.
4.Conclusion
In conclusion we can say that for several reasons (errors in the source system - in the application component, in the user exit, in delta queue, or wronged partial initializations, lost records for extractor errors and so on...) we can realized that in BW we missed some records. Now, if we are loading on a cube, we have no problem since on a cube we can load init and full (from the same datasource) together. But in ODS we cannot do it (since the system thinks that if we already are managing a flow with a delta mechanism, it doesn't make sense to takes data from a full too, in order to avoid data duplication.) For this reason a full repair request has to be done!
References OSS Note 739863 'Repairing data in BW' https://www.sdn.sap.com http://help.sap.com/
6
