Repair Load!

Hi Guys,
   I have 3 cubes which are being loaded from ODS1, deltas run every day thru process chain.
   now i have added a new ODS2 and want to load data from ODS1 to ODS2 without disturbing the deltas.
   Here is what i have done so far, i have loaded data from ODS1 to 2 by doing a repair full load but
   i have forgot to include this new ODS2 to the delta infopackage and today the deltas ran fine into the
   3 cubes, now i tried to run the delta just to the new ODS2 but i got 0 records loaded into ODS2.
   Is it because today's deltas already ran and no delta records are available to load into ODS2? if so
   what are my options to bring in the delta's into ODS2 and run the deltas daily into 3 cubes and ODS2
   without any issues???
Thanks in advance.

Hi Geni,
You are loading process is internal BI environment.
As you said, as for your old architexure loading is done from ODS1 to 3 cubes.
Now we added ODS2 to the existing architexure.
One thing i would like to remind i.e, Concept of Data Marting. Steps to be fallowed in this process.
1). Delete the loaded requset from 3 cubes.
2). Unselect Data Mart status of ODS1 , this is mandatory.
3).Then start loding process i.e Info package. It will update your latest delta records from ODS1 into the (3 cubes + ODS2).
If u r query resolved please give points.
Thanks & Regards,
Kotesh.

Similar Messages

2LIS_13_VDITM u0096 Full Repair Load

I will be creating an InfoPackage to carry out Full Repair Loads. Due to memory restrictions (which are currently being looked at) I will be using selections based on created on dates to extract the Data.
How can I avoid duplication of data in the ODS since it already contains data, especially if I have to rerun the package again? For example I get a dump if the selection sizing is too large and causes a memory dump. Thanks

As the automatic deletion of similar requests can only be applied when updating InfoCubes, you have to avoid the duplication of records by using the correct primary key for your ODS and the correct update method of key figures.
It might be easier to delete the ODS data.

Delta Load is not pulling any data....Need to Run Full Repair EVERYTIME ? ?

Dear Experts,
Today again I need your help gurus.
The Delta load is running everyday but its not getting any data to BW form CRM. But when the User raises an issue regarding the data , I pull the data by Repair Full load by some Selection ( Same selection of Delta + Transaction No ).
The selection(For Full Repair Load ) is only the Transaction No and the Sales Organization.
The selection for the normal Delta is Sales Organization ( 0CRM_SALORG ) 50000609.
But I am confused about the issue.
Kindly put some light on this issueu2026
Thanks,
Sanjana

Hi Sanjana:
Have you applied any SAP Note to fix this problem? Please check if the SAP Note below helps you in solving this issue.
Note 788172 - "CRM BW adapter: No data in delta with parallel processing"
Regards,
Francisco Milán.

Diff b/n Repair full and Full load

Experts
Please explain diff b/n Repair full request and Full load.
If I do Repair full request instead of Full load ,is there any problem in the data ?
Many thanks
Manoj

Hi Manoj,
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.
The difference between a Full Load and a Full Repair load is only evident in the case of loading to an ODS (to which you are also loading Init and Delta from the same datasource). If you ODS has the Init request active and you load a Full request, the data will not be activated. You should always use a Full Repair request when you want to load a full load to the ODS. For a cube it does not make a difference as the sequence of data loads is in important in a cube.
If you have accidentally not marked the request as a repair request, you can convert is using SE38 > RSSM_SET_REPAIR_FULL_FLAG
Hope this helps...

Full Load" and "Full load with Repair full request"

Hello Experts,
Can any body share with me what is the difference between a "Full Load" and "Full load with Repair full request"?
Regards.

Hi......
What is function of full repair?? what it does?
How to delete init from scheduler?? I dont see any option like that in infopackage
For both of you question there is a oss note 739863-Repairing data in BW ..........Read the following.....
Symptom
Some data is incorrect or missing in the PSA table or in the ODS object (Enterprise Data Warehouse layer).
Other terms
Restore data, repair data
Reason and Prerequisites
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.
And also search in forum, will get discussions on this
Full repair loads
Regarding Repair Full Request
Instead of doing of all these all steps.. cant I reload that failed request again??
If some goes wrong with delta loads...it is always better to do re-init...I mean dlete init flag...full repair..all those steps....If it is an infocube you can go for full update also instead of full repair...
Full Upload:
In full upload all the data records are fetched....It is similar to full repair..Incase of infocube to recover missed delta records..we can run full upload.....but in case of ODS does'nt support full upload and delta upload parallely...so inthis case you have to go for full repair...otherwise delta mechanism will get corrupted...
Suppose your ODS activation is failing since there is a Full upload request in the target.......then you can convert full upload to full repair using the program : RSSM_SET_REPAIR _ FULL_FLAG
Hope this helps.......
Thanks==points as per SDN.
Regards,
Debjani.....
Edited by: Debjani Mukherjee on Oct 23, 2008 8:32 PM

Full Repair to a cube

Hi,
I had to do a full repair load to cube. But the keyfigures are being updated through routines, in "ADDITION" mode.
So if i do a full repair, will the keyfigure values get doubled or say incorrect ?
If yes, then how this has to be handled ?
Regards,
Raj.

Are you doing a full repair to load missing data of a delta or to correct a delta from a past date?, i either cases if your request is not compressed you can delete that request and reload all the data as per the request.
The other option as mentioned earlier is selective deletion of the data you are uploading.
Hope this helps

Data loading after field enhancement.

Dear all,
We are using BI7.00 and in one of our data source, a new field has to be enabled. Our people are under the impression that without downtime, the previous data which is available in the Target and the PSA can have values for the new field also.
I could not perceive the possibility. Experts suggestion required in this regard. Can you kindly provide answers for the following questions.
1) Can enhancement be done to the data source without deletion of setup table?
2) Can the delta queue be as it is without stopping the delta pull process i.e., the process chain and the background jobs.
3) If the field is enhanced, can the value of the field be loaded to all the data which is previously loaded to the PSA and the Target.
Request Experts to provide apt solution so that field enhancement can take place without disturbing any of the data loads.
I went through the forum posts and was able to find something about export data source and Loop back principles - these suggests that my requirement is possible.
I do not know the process. Can experts provide step by step suggestion to my query.
Regards,
M.M

Hello Magesh,
1)Enhancement cannot be done if there are records in the set up tables.
2)When an enhancement is done...delta queue also needs to be empty...so you will have to stop the collective running jobs...lock the system and empty the delta queue by scheduling the delta package twice....then only the transports to production will go succesful.
3)Until you fill the set up tables again and do a historial loads...the old values for the new added field will not appear..
If you just do an init without data transfer and schedule new delta loads...then the new added fields will contain values from that day and changes to them...previously loaded values to BW will remain as it is...to have the values for newly added fields you need to load the history through full repair loads by filling the set up tables first.
Follow the following steps to load only the new values for the added fields
1)Lock the system
2)schedule the collective update job through job control so that all the records are in the delta queue and no records or LUW are left in LBWQ for that data source.
3)Schedule the delta infopackage twice so that even the queue for repeat delta is also empty.
4) do the transports and then delete the old init and do a new init without data transfer.
5)schedule the normal delta.
To have history for the added fields
1)Lock the system and
2)Delete the old init and clear the LBWQ from LUW's
3)Do the transports
3)Fill the set up tables and do init without data transfer for the data source.
4)Unlock the system
5)Do the full repair loads to the BW data targets
6)Schedule the delta loads.
Thanks
Ajeet

0FI_AR_4 extractor loaded data doesn't match ECC

Hi all.
I load data through 0FI_AR_4 into 0FIAR_O03 DSO and 0FIAR_C03 by several FULL loads (closed fiscal periods) and Initial Delta. When I check amounts in BI and ECC using fbl5n I get these figures:
2 542 230 491,77 in BI
2 542 229 491,77 in ECC
As you can see data almost the same except the fact what in BI it is 1000 more.
I got more amount differences by Dunning Level.
I have no idea why. Any ideas?

If you did the history loads then a init no data txf when the users where still posting data then yes you will get balance differences at a dunnign level
This is because the concept of closed fiscal periods as I explained in another of your posts has absolutely no concept within AR (yes you can close periods for NEW Postings) - when you dunn a customer you will dunn outstanding requestys in a prior period - thus the full loads didnt pick this up
Of course you could have thought all this through and arranged downtime when you did you history loads and then tht init
Normally for a AR4 take on after productive start you do a init no data txf - then history repair loads not the other ay around - because the change documents for prioe periods will never come through

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

Some records missing while full repair from datasource 2LIS_11_VAITM

hi friends,
we are using the datasource 2LIS_11_VAITM. If we run a full repair with a selection ., say for a particular dealer, some document numbers are missing. even if we run a full repair without any selection, same thing happens.
we couldnt able to spot out where the records are getting filtered. is there any way to check the datasource for any filterations.
can anyone tell from which tables the data is flowing to this datasource.

Hi.
fill the set up table first for the application 11 for the selections which you want to get pulled in BW.
A full repair load for a LO data source is pulled from a set up tables and a full repair will pull whatever is in set up tables.
So fill the set up table for the values which you want to be pulled into BW first.
I think right now your set up tables do not contain those records which you want in BW.
Then verify in the t-code RSA3 for the selection and see if you are able to see those records there.
if its showing up in RSA3 then schedule a full repair and it will show up in BW then.
The major underlying table are VBAP,VBAK.you can verify the values from there.
Do not forget do delete the set up tables before filling it.
Thanks
Ajeet

Initial load flag

Hello!
I would like to separate records (apart from later deltas) that come with initial load to infocube.
To be precise for 2LIS_12_VCITM --> 0SD_C03.
Any idea apart from creating new rules and filling a special field with init/delta flag?
Tnx Gorazd

Hi,
Everything depends what is the reason, you want to seperate this load.
I can propose you 2 solutions
1) Loading without any transformations (1:1 mapping with data source)
Data flow:
Data Source -> Acquisition layer DSO (1:1 mapping) -> Infocube (1:1 mapping)
2) Loading with transformations
Data flow:
Data Source -> Acquisition layer DSO (1:1 mapping) -> Propagation layer DSO (put all transformation here) -> Infocube (1:1 mapping)
Using one of these scenario makes you sure that in case of any "repair" load you can just pull delta for further layes instead of deleting and doing full reload.
Regards,
Dariusz Lewandowski

Data load error in 0EC_PCA_1

Dear all,
In the data source 0EC_PCA_1 during delta load, on one day the load has failed in the PSA due to TRFC connection problem. Subsequently loading on all other days had taken place.The load had failed on 17.04.2008 - subsequent load had been updated to the cube.
Now when data reconciliation is done, there seems to be mismatch in the data. Can anyone clear my following doubts.
1) if data (delta) is failed on a particular day, the subsequent correct loads will fetch the failed data also or not.
If the data (failed) will not be fetched during the subsequent loads then how to load that particular delta alone to the cube.
Kindly provide steps and also the pricipal involved in the delta load mechanism.
Experts help expected.
Regards,
M.M

Dear Mr. Simon,
Thank you on the onset for the prompt reply and sorry for the late response. The principle in which the 0EC_PCA_1 data source works had been explained by you. In case of data load failures you had suggested to do repair load in the ODS.
My problem is that the load has failed in the PSA. Is it the cause of the missing data. i.e., if data load (delta) has failed on a particular day the subsequent day's correct load will not capture the left over delta that has failed - this is where i am bit confused on the genral priciple of the delta load mechanism.
Can you kindly suggest methods with steps to do reload in case the data load to the PSA will not capture the left over failed delta?
Your inputs and updation will be very helpful. Kindly also try to explain the delta mechanism.
Regards,
M.M

Regarding Data Loads

Hi Gurus,
I want to know in which Real time scenario's we 'll use "Repair Full Request", Initialization w/o Transfer", early delta initialisation and when we can perform "selective deletion". I know these things theoritically but i don't know when and how we can use thesethings in Real time...
Please help me and i'll assign the points...
Regards
Ravi

Hi ,
Just to add more information ,
Full repair load is only relevant for ODS objects when you need to do a full load from a datasource which has been initialized. If you have done an Init, and then do a simple full load, the request will not activate, that's why the repair full load option works here. For the cube also you can mark the request as repair, but in any case it will load to the cube. The only thing you need to remember is that this will not do the job of removing some records and replacing them with the repaired data.
You can selectively delete from the cube, and then do a full load with the reqd selections.
Look at OSS Note 739863 'Repairing data in BW' for all the details!!
Go for Repair Full Request. In order not to disturb your delta selections you need to do the repair full load. After your repair full load you can continue loading deltas normally.
Create a new InfoPackage and mark this as Repair and then choose full upload and execute. There is no repair flag for deltas. and we will not be losing any deltas.
generally we will go for intilization with out data transfer , suppose say you have load which goes to many targets. that load got failed in one target, now you think you are in situation to run init for that target, but ideally you have to run init for all the targets, to avoid this ew generally do initilization for the particular target where you required and after that you run init without data to all the targets to avoid delat failures..or you have loaded to full load and you need to run initilization then this time we prefer inti with out data than with data to save time
we will go for selective deletion when compressed or if you have huge amount of data and you need to delete some of the request, then generally we prefer selective deletion instead of deleting entire data
Regards,
mallikarjun

Delta load related

Hi experts,
I have changed the data source for 0CRM_SRV_PROCESS_H and now I want to move it to production, but in production already we have delta pull for 0CRM_PROH ODS.
When this change will take place how do I restore delta pull??
Regards,
Priyanka Joshi

to fill the new field you will have to do init with data transfer or init without data transfer and full repair requests.
If you want to load all the history again then after transports do a new init with data transfer..If the amount of data is not huge or do init without data transfer and do full repair loads so that you can manage the data loads.
Since the loading is going to be for the whole history again therefore I dont think you need to lock the system.The only problem could be the records getting created at the time of init.
So you amy need to lock the system only for the time you do an init without data transfer.

EXACT DIFFERENCE BETWEEN FULL LOAD AND REPAIRFULL LOAD?

HI Champ,
Can anyone explain me the exact difference between full load and Repairfull load?Give e some senario where we can go for this?Please.....
10zin

Hi,
Full repair can be said as a Full with selections. But the main use or advantage of Full repair load is that it wont affect delta loads in the system. If you load a full to a target with deltas running you again will have to initialize them for deltas to continue. But if you do full repair it wont affect deltas.
This is normally done we when we lose some data or there is data mismatch between source system and BW.
Check the OSS Note 739863 'Repairing data in BW' for all the details
Symptom
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."
Refer.
Repair full request
Re: Repair full request
Steps to perform repair full request
full repair request
repair full request
Re: Repair Full Request
Thanks,
JituK

Repair Load!

Similar Messages

Maybe you are looking for