Repeat Delta Vs Repair request

Hi Gurus,
What is difference betwenn Repeat Delta and Repair request? May i know the in which scenario we go for these options?
Thanks & Regards,
Prabha.

hai Prabha,
Delta Update
A delta update only requests data which has appeared since the last delta.
Before you can request a delta update, you must first initialize the delta process.
A delta update is only possible for loading from SAP source systems.
If a delta fails (status red in the monitor) or the overall status of the delta request has been set to red manually, the next data request will be performed in repeat mode. A repeat request extracts the incorrect or incompletely loaded data from the failed delta request, along with any new data since the original request. A repeat can only be requested in the dialog. If data from the failed delta request has already been updated to the data targets, delete the data from the data targets affected. If you cannot delete the data from the data targets, duplicate data records may be produced when the repeat request is performed.
The concept of Full repair request is " when we r loading data bydelta update from a data source then it will not allow the Full update from the data source. When we r using this option we can extract the data on repair request then the deltas of the data source is not disturb.
Data will come from the data source only.
repaire request is used to get the missing delta records.
In the info pack menu bar scheduler you will get this option Repair Full Request. generally we use this option for ODS. pls read this OSS note :739863
hope this helps
regards
KP

Similar Messages

Repeat Delta in case we loss the data from BWP

Dear Experts
I am facing a critical Problem related to Delta records uploading in BWP server. I have uploaded the Delta records yesterday (16.06.2011) in the Morning from (6.00A.M. to 14.00P.M) and pull the delta records in SAPBW. then in the night due to some reason our BWP server crashed. Now its Up and the data is restored upto 16.06.2011 Morning upto 06.00 A.M. i.e. before the execution of process chains on 16.01.2011 . My Question is
1. If I execute the Process chains today will it breing the Delta records of 16.06.2011 as well (Repeat delta) Automatically or do i have to perform some configration.
2. Whether the Repeat delta is possible only if we make the request RED and not when we loose the data as we have.
Pl advice Urgently........................
Thanks in advance.
Dinesh Sharma

1. delta load done to PSA. records edited and loaded to targets.
2. repeat delta done to PSA. It contains all records from step 1 and any new records written to delta queue. this is deleted.
3. Next day repeat happens. This brings records from step 2 (already has records from step 1) and any new records written to delta queue.
The procedure followed was not correct and hence resulted in duplicates. When a repeat delta is done, the delta records from the previous delta request will be fetched along with any new records that have come into the queue after that.

Repair Request Help

Hi, We are in BI 7.x SP15.
I have a DSO to DSO Data flow and I'm going to delete some data from our Top DSO via selective delete. I then want to reload this data from the lower DSO.
After a selective delete will just a full load of the deleted data replace it correctly and the deltas will continue?
The reason I ask is that I see a reference to "Repair Request" in the selective deletion documentation. Is this just a full with the same selections or something special I have to do in the DTP?
Thanks for any help

Great. This is what I thought. When I do a separate full the delta should continue just fine.
Also, like said earlier if I'm going to reload a full with selections I do not need to do selective delete because they will just overwrite. correct?
Thanks all!

Repeat Delta mechanism for FI-CO & Generic extractor.

Hello Guys,
Can any one please let me know whether there is repeat delta is possible for FI/CO data sources if we miss any daily dela loads.
If its there, how it works.
thanks in advance
peter.

Hi,
Yes, it is possible to repeat the failed delta for FICO extractors. One thing you need to note is that you need to request the delta second time only then you will get records to BW. First time repeat will fetch 0 records.
Hope this helps
Regards.,
Srni

A full repair request

Hello Gurus,
what is a full repair request?
Many thanks,

Hai ,
Q. Repair Full Request
Ans: You can find the option in the InfoPackage. Open up the InfoPackage and press ShiftCtrlF1 or from the menu Scheduler > Repair Full request. You need to check in the box and it will be done.
You can go in for a repair full request when you have missed any delta loads or there are data corruption issues. By doing a full repair load, you can ensure that your data is correct and has good integrity.
With this option you can continue to use your existing delta and not worry about resetting the delta.
But make sure that the ODS is in overwrite mode and not additive. If its additive then you will face the problem of having duplicate data. If this is the case then you have to delete all the contents and then do the full repair request.
Say if your current scenario has init/delta setup to your ODS.
And for some reason you have to do a full load because you missed some data or you have to load some historic data.
Then if you do a full load to ODS then the request will be loaded but do not get activated as full load to ODS once the delta/ init is setup.
So in these scenarios you'll have to go for repair full request option when loading to ODS.
You'll have the same option when loading to CUBE but in cube it doesn't matter as it is possible to do a full load even we had delta/init.
So doing repair full will not disturb your Delta mechanism in your ODS.
OSS Note on Repair Full Request.
Some data is incorrect or missing in the PSA table or in the ODS object (Enterprise Data Warehouse layer).
There may be a number of reasons for this problem: Errors in the relevant application, errors in the user exit, errors in the DeltaQueue, handling errors in the customers posting procedure (for example, a change in the extract structure during production operation if the DeltaQueue was not yet empty; postings before the Delta Init was completed, and so on), extractor errors, unplanned system terminations in BW and in R/3, and so on.
Solution
Read this note in full BEFORE you start actions that may repair your data in BW. Contact SAP Support for help with troubleshooting before you start to repair data.
BW offers you the option of a full upload in the form of a repair request (as of BW 3.0B). If you want to use this function, we recommend that you use the ODS object layer.
Note that you should only use this procedure if you have a small number of incorrect or missing records. Otherwise, we always recommend a reinitialization (possibly after a previous selective deletion, followed by a restriction of the Delta-Init selection to exclude areas that were not changed in the meantime).
1. Repair request: Definition
If you flag a request as a repair request with full update as the update mode, it can be updated to all data targets, even if these already contain data from delta initialization runs for this DataSource/source system combination. This means that a repair 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 and must thus be prepared very carefully.
The repair request (of the "Full Upload" type) can be loaded into the same ODS object in which the 'normal' delta requests run. You will find this request under the "Repair Request" option in the InfoPackage (Maintenance) menu.
2. Prerequisites for using the "Repair Request" function
2.1. Troubleshooting
Before you start the repair action, you should carry out a thorough analysis of the possible cause of the error to make sure that the error cannot recur when you execute the repair action. For example, if a key figure has already been updated incorrectly in the OLTP system, it will not change after a reload into BW. Use transaction RSA3 (Extractor Checker) in the source system for help with troubleshooting. Another possible source of the problem may be your user exit. To ensure that the user exit is correct, first load a user exit with a Probe-Full request into the PSA table and check whether the data is correct. If it is not correct: Search for the error in the exit user. If you do not find it, we recommend that you deactivate the user exit for testing purposes and request a new Full Upload. It If the data arrives correctly, it is highly probable that the error is indeed in the user exit.
We always recommend that you load the data into the PSA table in the first step and check the result there.
2.2. Analyze the effects on the downstream targets
Before you start the Repair request into the ODS object, make sure that the incorrect data records are selectively deleted from the ODS object. However, before you decide on selective deletion, you should read the Info Help for the "Selective Deletion" function, which you can access by pressing the extra button on the relevant dialog box. The activation queue and the ChangeLog remain unchanged during the selective deletion of the data from the ODS object, which means that the incorrect data is still in the change log afterwards. After the selective deletion, you therefore must not reconstruct the ODS object if it is reconstructed from the ChangeLog. (Reconstruction is usually from the PSA table but, if the data source is the ODS object itself, the ODS object is reconstructed from its ChangeLog). You MUST read the recommendations and warnings about this (press the "Info" button).
You MUST also take into account the fact that the delta for the downstream data targets is created from the changelog. If you perform selective deletion and then reload data into the deleted area, this may result in data inconsistencies in the downstream data targets.
If you only use MOVE and do not use ADD for updates in the ODS object, selective deletion may not be required in some cases (for example, if incorrect records only have to be changed, rather than deleted). In this case, the DataMart delta also remains intact.
2.3. Analysis of the selections
You must be very precise when you perform selective deletion: Some applications do not provide the option of selecting individual documents for the load process. Therefore, you must first ensure that you can load the same range of documents into BW as you would delete from the ODS object. This note provides some application-specific recommendations to help you "repair" the incorrect data records.
If you updated the data from the ODS object into the InfoCube, you can also delete it there using the "Selective deletion" function. However, if it is compressed at document level there and deletion is no longer possible, you must delete the InfoCube content and fill the data in the ODS object again after repair.
You can only perform this action after a thorough analysis of all effects of selective data deletion. We naturally recommend that you test this first in the test system.
The procedure generally applies for all SAP applications/extractors. The application determines the selections. For example, if you cannot use the document number for selection but you can select documents for an entire period, then you are forced to delete and then update documents for the entire period in the data target. Therefore, it is important to look first at the selections in the InfoPackage exactly before you delete data from the data target.
Some applications have additional special features:
Logistics cockpit: As preparation for the repair request, delete the SetUp table (if you have not already done so) and fill it selectively with concrete document numbers (or other possible groups of documents determined by the selection). Execute the Repair request.
Caution: You can currently use the transactions that fill SetUp tables with reconstruction data to select individual documents or entire ranges of documents (at present, it is not possible to select several individual documents if they are not numbered in sequence).
FI: The Repair request for the Full Upload is not required here. The following efficient alternatives are provided: In the FI area, you can select documents that must be reloaded into BW again, make a small change to them (for example, insert a period into the assignment text) and save them -> as a result, the document is placed in the delta queue again and the previously loaded document under the same number in the BW ODS object is overwritten. FI also has an option for sending the documents selectively from the OLTP system to the BW system using correction programs (see note 616331).
3. Repair request execution
How do you proceed if you want to load a repair 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. 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."
Another Scenario where we use Repair Full Request
If your data load is delta and now if you are planning to run Full load, then you can go for Repair full request.
Eg: If you have missed data for 3 days and next delta loads are running successfully, in this case if you want to fill data for only particular 3 days, than you can run the statistical setup for that particular data source for 3 days and load it as a full load through repair request.
It is particularly used in the upload of data into the ODS ,if the ODS has already Delta loads.
This is required if want to upload any full uploads(with selection at infopackage or without) to be done to ODS, because ODS does not allow to activate the simple Full uploads if there are delta loads to it.
But make sure that check the option "indicate request as repair" in the Scheduler before you start the IP.
Thanks,
Kiran Manyam

Option in Infopack for Load of Repeat Delta

Hi , I would like to know what option is avilable to load repeat delta in Infopack.
When i run RSA7 , and select by Datasource , There is 28 records in the Repeted Delta Queue.
Thanks

Hi Ashwani,
If a delta load from a datasource fails or is manually marked as 'RED' in the monitor, the next time you run the 'Delta' InfoPackage for that datasource, you will get a message asking you whether you want to repeat the previous delta request since it had failed. This mechanism is provided so that in case of errors during data loads, none of the records are missed out in a subsequent load.

Repeat delta are failing

Hello experts,
I have an imp production issue. We had delta failing in one of LO Cockpit extractor for last 4 days.
Message: Error occurred in the data selection
Job terminated in source system --> Request set to red
Message no. RSM078
I did repeat delta (by changing status to red and deleting requests). But still I get same message.
Please help.
Rita.

SM 37 LOG:
Job started
Step 001 started (program SBIE0001, variant &0000000017045, user ID ALEREMO
Asynchronous transmission of info IDoc 2 in task 0001 (0 parallel tasks)
DATASOURCE = 2LIS_18_I0NOTIF
RLOGSYS    = PRODCLNT200
REQUNR     = REQU_D4VWYY4JTTY9ODFHL16WPLR5M
UPDMODE    = R
LANGUAGES = *
         Current Values for Selected Profile Parameters               *
abap/heap_area_nondia......... 0                                       *
abap/heap_area_total.......... 8588886016                              *
abap/heaplimit................ 40000000                                *
zcsa/installed_languages...... 123ACEFIJKLMNOPSUVc                     *
zcsa/system_language.......... E                                       *
ztta/max_memreq_MB............ 2047                                    *
ztta/roll_area................ 6500000                                 *
ztta/roll_extension........... 2000000000                              *
Call customer enhancement BW_BTE_CALL_BW204010_E (BTE) with 1,491 records
Result of customer enhancement: 1,491 records
Call customer enhancement EXIT_SAPLRSAP_001 (CMOD) with 1,491 records
ABAP/4 processor: COMPUTE_INT_TIMES_OVERFLOW
Job cancelled

What is the use of marking repair request in the scheduler?

Hi !
what is the use of the option repair full request in the scheduler menu item?

Hi Durai,
You can use a request that was selected as a repair request via Scheduler ® Repair Full Request to carry out a full update in any data target. This also applies to data requests that already contain data from an initialization run or deltas for this DataSource/source system combination, and that have overlapping selection criteria.
Nice post by Roberto:
Bye
Dinesh

Repeat delta

How to do "Repeat delta"? Is there any direct option available from BW side for this? If not, from R/3 side using RSA7 transaction when doing "Delta repetition" it is asking for a variant to Save. What does this mean? What are the other input fields that we need to fill in on this screen?

Hi,
You do a repeat delta when the original delta load fails or the delta request gets deleted from the infoprovider.
In this case, mark the request red in the infoprovider and delete it. Run the delta infopackage again. It'll ask you for repeating the delta. Say yes and repeat delta will take place. One word of caution though is if the original delta has failed, make sure you remove the cause of the error before running the repeat delta as that'll fail too if the original cause of the error is not removed.
In terms of repeat delta you don't have to do anything on the R3 side. As mentioned above just follow the steps and rerun the delta infopackage for the repeat delta.
Cheers,
Kedar

What is repair request? when we use this?

Hi all,
what is repair request?
when actually we use this?
Thanks& Regards,
Ravi Alakuntla.

Hi Ravi,
When you find some records missing when deltas are running then instead of going for re-init and again deltas you can go for repair full request giving selection conditions for those missing records, without affecting your delta laods.
Hope it helps,
Sunil.

About "full repair request"

Hello Gurus,
please give me a thorough scenario for leveraging "full repair request", also if briefly sum up the step for those scenarioes,
appreciate very much.
Many thanks.

Usually we do "Repair Full load" when the deltas are active and already present in the data target! Once you perform delta loads you can't do full loads, In this case go for "Repair Full load" option which is similar to "Full load" but it won't disturb active deltas.
Ex. let's say you have deltas running on your target .. for any reason some records in your target are corrupted/deleted selectively/missing .. So you can't get them back from delta loads. In this scenario repair full would be option to get those records .. to do this you have to enter selection parameters in the IP to make sure you will get only the records you wanted from the source and you can cross check again in PSA and then load to the data target!.
Note: if the records in the target are wrong you must perform selective deletion and load selectively by repair full.
PS. You can make a search in SDn this topic has been discussed many times.!
Edited by: Srinivas on Jul 15, 2010 7:08 PM

Repeat Delta problem

Hai,
I have a delta update from 2LIS_02_SGR to an Infocube. For the past 5 days, the pull had failed. To repull that delta, I had to set the QM status to RED and delete the requests from the Infoprovider. But for few requests, the requests were set to RED in the (INFOCOUBE - > MANAGE request) and deleted instead of setting it to RED in RSMO. Now, after i deleting the requests I realized it and then i set the status to RED in RSMO. Now if I repull the data, I get that window that asks if the delta has to be repulled. I clicked on REQUEST AGAIN. But I don't find all the failed delta data to have come into BW. Why is it so?
Regards,
Neha Solanki

Hi Neha,
I suppose that you neede not worry much because system has prompted you the option of repeat delta.
As you have selected request again it will bring the data that should have been pulled in last delta also.
If you would like to cross check the data, i think, you can use some date selections and see the data records in R/3 tables and match them with BW.
Hope this helps.
Regards,
Sagar

Repeat Delta extraction behaviour

Hi experts,
Ive been getting conflicting thoughts on delta extraction behaviour, so I thought Id just ask it out here. Here are two prominent scenarios:
1. Our delta failed on sunday, we execute a repeat delta on monday. It only picks up the sunday failed data, it does not pick up any other new records that came in monday. This is for a generic extractor, R/3 to Cube.
- My understanding is that when we do a repeat delta, it should pick up the failed request + any new records to date. Or does a repeat delta ONLY pick up the failed request and disregards new data? Is the behaviour extractor specific?
2. Our delta failed on sunday, we execute a repeat delta on monday. The request comes up with 0 transferred, we kick of another delta which now picks up everything from the failed request up to the present including new data. This is for 0FI_AR_4.
- Why is it this repeat delta behaviour differs from the first? Is it because this is a FI extractor with inherent behaviour? Instead of picking up the failed request, it picks up 0 records and then a delta is required to pick up all the data.
mark

Hi,
Repeat delta means the data that was collected by the delta queue and not updated to BW vl be updated to the data target., i.e. it picks only the failed request data , not the new ones which are updated in the mean time.
The next delta vl pick up the new records.
It is general to all the extractors except COPA.
For COPA , it updates data based on the time stamp.
Please check the below document for COPA extraction (deltas).
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sapportals.km.docs/library/biw/g-i/how%20to%20co-pa%20extraction%203.0x
Assign points if it helps.....

Repeat delta data issue

Hello guys,
I have a strange issue here. I load say ODS2 from ODS1. When trying to load ODS2 one day, i find and issue and the load is turned red. When i executed the delta IP again, it asked for the repeat of the delta, for which i said yes. I did not delete any datamart status from ODS1. This repeat got me double records than the original request, and now i have doubled records in ODS2. Since ODS2 is on addition, the doubling data issue. Does anyone had this problem? Why the repeat of delta updated double the number of records than what it shud be? will be great if anyone can come up with a clarification.
Regards
Sriram

Hi Sriram,
At First you need to Delete the Request from ODS2,
Question is which request should be deleted. answered below.
In ODS1 --> Note the Request where Repeat of delta has occured. Check the datamart Request of that Repeat Request. This datamark request clearly shows that At what request in ODS2 its updated.
Now your job step by step as below:-
1. Delete request in ODS2 (Please note :request which you had taken in the datamart of ODS1).
2. Delete the Datamart of the ODS1 at the Repeat delta request.
3. Delete Request of ODS1(till where you had removed the datamart for this ODS)
4. Go to reconstruction tab and reconstruct the request which are correct (eliminate failed request)
Please note:- please reconstruct one(1) request and then datamart. Once you do this you will come to know the logic behind.
5. Then Datamart to ODS2.
If its complicated to understand, please call call me
Thanks
Regards
Hari

Repeat delta in BI

Hi,
My delta load worked fine but my PSA load via DTP failed due to an incorrect data.
How can I do another load by scratch and repeat the delta?
Do i need to delete the PSA and turn the delta load to "red" for BI to realize the delta did not happen?
Thanks for your reply.
Cesar

HI,
Select the incorrect request and Manually make it to Red in techinical status and also in manage of Info provider.
Later on delete the request in info provider and also PSA>.
And reschudule the load in using info package tyhen it askds for the repeat of delta.
Select the repeat delta and load till PSA and later on Run DTP.

Repeat Delta Vs Repair request

Similar Messages

Maybe you are looking for