Sie sind auf Seite 1von 6

SAP BW Repair Full Request

Venkata Chalapathi Challapalli


OUTOKUMPU Project
Hyderabad
venkata.challapalli@accenture.com
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.
Lets 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."
Lets 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

Das könnte Ihnen auch gefallen