Full repair or Delta Init?

Hi Experts
I need your suggest
a)
Sometime we need made a re-load one month, and Im using a 'full repair'; but this give me errors (duplicate or missing records) where users are working in R/3 at the same time.  Other posibilite is a 'full load' + 'delta init with out records'.   Which is better in this case? 
b) People say than after use a 'full load' you lose the init flag and is necessary made a init again.
In this case a made a 'full load' for 001.2008, and 'full repair' for 002.2008; and the init flag / delta load seemed ok. Is this possible? 
c) When use a 'full repair', (with selection scope = 001.2008), how does it work?  read from R/3 again or repeat the delta loads for the month specified in the selection, in the infopackage?
Thank you in advance!!

Hello,
Pls see these links
data extraction via combination of full + init updates
How to load init -delta requests when full load already exist
Full Upload and Init Delta Load
Thanks
Chandran

Similar Messages

  • Generic Delta: Init, Full Upload and Deltas...

    Dear All,
    Last week on 10.04.2014 I've created "Generic DataSource with Generic Delta" and used CalDay as Delta-Specific Field and lower limit kept to blank and upper limit to 1. On 11.04.2014 I've initialized the Delta with Data Transfer using Process Chain: Time 1:15 p.m (Note: Posting was on)
    see below screen shot:
    Result: Process Chain was scheduled to immediate and it executed and initialized the delta and brought records as well. See below screen shot of RSA7:
    Q: 1: Why generic delta current status is 10.04.2014, as I'v scheduled delta through process chain on 11.04.2014 @ 20:50: and why Total column is showing 0 records? Even I've checked Display Data Entries with Delta Repetition, but could not find any records?
    Following is the InfoPackages which I created for Delta Loads and used in another Process Chain for Delta scheduled (daily @ 20: 50).
    Following is the DTP used into Delta Process Chain:
    On 12/04/2014 when I checked my InfoCube, and found that same number of records being loaded again despite InfoPackage and DTP were created as Delta, see screen shot:
    On 12/04/2014 See below PSA table:
    On 14/04/2014 when I checked InfoCube and I saw deltas being loaded successfully: see below screen shot:
    On 14/04/2014 see below PSA table:
    On 14/04/2014 see below RSA7 BW Delta Queue Maintenance screen shot:
    Q: 2: Why am I unable to load the Delta records on the day(11/04/2014) when I initialized it with Data and why same number of records being loaded again on 11/04/2014?
    Q: 3: On 11/04/2014, around 1:15 p.m I've initialized Delta with Data successfully and the same day (11/04/2014) was my first load of delta records (Time: 20: 50), could this be a problem? as the posting period was on when I initialized and I tried to load the delta on the same day?
    Q: 4: Why the pointer is showing me Current Status: 12/04/2014 today and this time around I can find last delta records from "Display Data" option with Delta Repetition?
    Q: 5: Have I missed something in the design or data flow?
    Q: 6: How can I verify deltas records accuracy on daily basis; is it from RSA3?
    or How can I verify daily deltas with ECC delta records?
    Q: 7: What is the best practice when you load full data and initialized delta and schedule deltas for Generic DataSources with CalDay as delta specific field?
    I will appreciate your replies.
    Many Thanks!!!
    Tariq Ashraf

    I clearly got ur point.....But
               If i have situation like ....." I loaded the LO data from R/3 with Init delta......then i loaded 5 loads of delta too.......due to some error in data now i am trying to load all th data......In this case if i do Full upload it is going to bring all the data till 5 th delta load .......If i do Init delta again it is going to bring the same data as full upload..........In LO while loading both Full load or delta init load we need to lock R/3 users....I believe we can load delta even after full upload by using "Init delta without data transfer"............So that wont be the barrier....then what is the difference or how should i figure out which load should i do.............If i am wrong please correct me.......
    Thanks

  • Full Repair/Init/Delta & LO Cockpit Information required

    Hello
    I'm pretty new to BW and I'm starting to dig a bit more now into the deeper stuff now.  I've created Cubes with Extractor from R/3 and now I'm interested to understand more the LO Cockpit various specificities.
    For a better understanding, let's establish a scenario as --> Activation of R/3 SD Billing --> BW --> DSO --> Info Cube
    Ok, first, let me start by explaining what my understanding is.
    First, I need to go into R/3, t-code LBWE, and under the "13: SD Billing BW", activate the extractors I'm interested in (Header & Item as an example in my scenario).  I'm also assuming that the default fields within the extractors are suiting my needs so no adjustments needed for now.  I should also schedule a job here that will create records in the Waiting Queue on a daily basis.
    Next, I need to fill the setup tables from the t-code SBIW; I enter a date in the future, it runs for a while, then I get my data prepared.  In the setup table, it included all the existing R/3 invoices as of now right? (1)  Let's say there are new invoices created minutes after I've created the setup table, they will be sent to the Waiting Queue as soon as the document are created or will the schedule job created earlier will post them to that Queue? (2)  If the job send them to the Waiting Queue, where are sitting the pending documents before being sent then? (3)
    Now, on my BW system, once the Data Source have been replicated, what do I need to create and execute to be able to proceed with a Delta process? (4) I know I have to create a u201CInitu201D package 1st but have no clue why except that itu2019s needed for me to be able to create a u201CDeltau201D  package afterwards.  Technically, what does the u201CInitu201D package really does? (5)  What is the reason to have a u201CInit without datau201D and u201CInit with datau201D, I mean, I know literally what it means but again, why would I choose one over the other? (6)
    Iu2019d also like to understand the concept behind a "Full Repair" request, which I have no clue what the purpose is.  I guess there some of these properties (Full Repair, Init) determines where to get the data on the R/3 side; Setup Tables or Waiting Queue? (7)
    Please, provide clear respond (Donu2019t assume I know what youu2019re think of ) on my questions (identified by a bold number) and don't hesitate to provide a long one if needed to; it's better to provide more information than not enough
    Thank you in advance for all of your help!
    P.s. I'm working with BI 7.0.

    Hi.....
    So if I understand properly, whenever I run the init, it toggle a flag on my source system (R/3) which means that all changes performed in the invoices are going to be sent in the Delta Queue? Until I run an Init, changes are not written anywhere (Other than internal SAP tables/structures required by R/3 Invoices processes).
    If so, does this means that I could loose some transactions from the time I run the creation of the setup tables and the time I execute the Init on my BW system? Let's say I create the setup table today and execute the init only tomorrow; all invoices that have been created by this time won't be tranferred to BW?
    yes,suppose you create a set up table today....and ron the init tomorrow........in between many new recordsmay come.......but those new records will not be in the set up table.......since those transaction happenned after the filling of the set up table........and new records only goes to Delta queue after you run the init.......
    I have to admit that it's hard for me to "Suppose" i did not want to do an init; what would be a good reason not to? I understand that both Init types will toggle the "Init" flag on but still can't figure appropriate business scenarios for both types
    Suppose your Delta mechanism is corrupted.......for which you need to do a full repair......I mean first ,you have to delete the existing init flag.........second, you will fill the set up table .......third,you will load the records by Full repair......then 4th step will be running init without data transfer..only to set the init flag..........it will not pick any records.............then delta.......
    Init with data transfer picks all the previous records......we cannot give any selection..............for selection we have to use Full repair.........then init without data transfer..............generally for Transaction data we will go for Full repair..........bcoz otherwise number of recordswill be very huge........and there may be duplicate records..................
    Another thing we want to say........we do full repair we mainly use for ODS.........it is just like Full upload.........in case of infocube we can use full upload instead of full repair.........but in case of ODS full repair is must............since ODS does'nt support Full upload and Delta upload parallely........otehrwise ODS activation will fail........
    Then again you hav to use the Program : RSSM_SET_REPAIR_FULL_FLAG  to convert full upload request to full repair request.....
    Hope this helps....
    Regards,
    Debjani.......
    Edited by: Debjani  Mukherjee on Nov 7, 2008 10:45 PM

  • 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.

  • 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

  • Duplicate Records in Infocube : Full Repair without DSO is possible ?

    Hello Gurus,
    I have a critical situation in BI production. we have more then 3 years of data in inventory infocubes (PSA->ODS->CUBE). everything was working fine till december 2010. after that in January 2010 and March -2010 we were getting double records in infocubes. in this scenarion we don't have ODS in between.
    The solution which i find is delete all data from Jan -2010 till today in infocube and also from PSA. on R/3 side delete set up tables and fill setup tables for Jan-2010 to Mar-2010. and create a infopackage for Full Repair request .  but i have below questions for these solution
    (1) For Full Repair Info Package or Full Repair Request we don't need to delete INIT request .. correct me if i am wrong.
    (2) For full repair request do we need to run Initialize Delta With Out Data Transfer first and then we have to do Full Repair ?
    (3) If we don't have DSO in these scenario then also can we solve this with full repair request ?
    Regards,
    Komik Shah

    Hi Venu,
    We have data in PSA since 13/04/2010 because the process chain was failing since last 15 days. so  didn't get new records in PSA also. we are using BI 7.0.
    Whole scenario is like this.
    Data is there in Inventory Cube since last 3 year. but no body monitor the process chain since last 15 days and no body analyze any reports after dec-09. now they Analyze the report in April-10 and for some months they are getting Double records. process chain was  failing since last 15 days and the reason behind that was  INDEXING as well as wrong records in PSA.
    So, My plan was to delete data from Jan-2010 to April-2010 and fill setup tables between Jan-2010 to april.2010. i will get data into PSA. but when i will load data to cube. i will get double records whether it's a full repair or not .
    Regards,
    Komik Shah
    Edited by: komik shah on Apr 30, 2010 12:38 PM

  • Full upload then delta?

    Hi all,
    We have a scenario where the ODS object contains 2 billion records.
    we want to load this data in to new cubes.
    Since we have huge data:
    -can we go for delta init and then subsequent deltas?
    -Can we go for a full load (by time selections in the infopackage) and then can we define a delta?
    What would be the ideal solution since ODS contains 2 billion rec
    Regards
    Naveen

    Hi Bhanu
    Let me know weather I am right:
    1. I create a info package and run with the option Init   with out data transfer
    2. Create several infopackages with selection options (based on time) and run with repair requests
    eg if i have data from  2005 - till date then I create 5 infopackages. the first 4 info packages are restricted each for 3 months and the 5 or last info package for 2006-tilldate
    After al these jobs
    Now I create a new infopaackage with delta loads for future data ?
    Let me know ny suggestions
    Best Regards
    Naveen

  • What happend to past delta data if we delete Delta INIT from Cube? safe ?

    Hi Friends,
    we have a cube where delta data is loaded daily from ODS.
    So, cube have many delta requests and data is compressed.
    Now have some problem and need to delete Delta INIT from this Cube and run fresh delta INIT again into Cube from ODS. Is that safe ?
    If we do this...is there is any problem with past delta data availble in the Cube?
    Please confirm..
    Thanks
    Tony

    Hi,
    I told you to check this before deleting the init as it very tough to manage it after that.
    Now those delta request are missed and I dont think can be retrieved without doing a full repair with proper selection.
    If you do a new init then there should be no request without a check for data mart status??
    So you found it before deleting the init??Then you should not have deleted the init as I told earlier.
    The only option is too reload the whole histroy again if you are not able to load it through selections in infopackage.
    First do a selective deletion from the cube for the same selections and then schedule the full load for those selections from DSO.make sure these selections cover the whole scenario.
    You cannot do anything else now to correct it.
    If you data is not huge in cube then delete the whole data and reload it.
    Schedule multiple loads from the DSO at the same time through different infopackages.
    this will save time as weill will do the loads in quick time.
    Thanks
    Ajeet

  • Change load full data to Delta

    Hi!!
    In the past, we load Full data for a customized DataSourece. Now I changed the DataSource to load delta datas.
    This data source was connected a ODS and when I tried to initialize delta process I received the error message. "Full updates already available in ODS 0SAL_DS01 ; Cannot update init./delta".
    Someone know, How can I Initialize Delta Process?
    Regards,
    Cesar G. Batista

    Hi.............
    ODS does'nt support Full upload and delta upload parallely..........suppose a ODS is getting loaded with delta upload...........then if u do a full upload.........then ODS activation will with this error...........then u have to convert full upload to full repair...........
    Go to SE38 >> Program : RSSM_SET_REPAIR_FULL_FLAG...................this program also exists in 3.5.............check it properly............
    Check SAP note 689964 ........
    Hope this helps........
    Regards,
    Debjani.........

  • Change from Full load to delta load.

    Hi Gurus,
    I have one ODS object which is extracting data from r/3 system.this ODS object is getting loaded on a daily basis,& it's having heavy volume data (takes almost 8 hours to load).
    Now I want to change the load mode of that ODS from FULL load to Delta Load
    How can I do that ?
    I tried to do* Init without data transfer* from source to this ODS obejct , but while activation it's saying Full load is already loaded so no init
    I want to change the load mode of that ODS object without deleting the data,as it takes lot of time to load the total data.
    Is there any way to that??
    Plz help.Thanks in advance.
    Regards,
    Kironmoy Banerjee.

    RSSM_SET_REPAIR_FULL_FLAG.
    1 more question,if run that function module,will it change the existing loads in Repair full mode?
    or it will load the total data again.
    If you run RSSM_SET_REPAIR_FULL_FLAG Program and give ODS name etc.. it will turn all Full loads to Repair full mode.
    Steps:
    1. Run that function module.
    Run Program RSSM_SET_REPAIR_FULL_FLAG
    2. give ODS,data source name.
    Yes
    3 it will change the existing load to repair full load,
    Yes
    4.Init without data transfer. (i am not sure if this step is required or not.)
    Yes
    5.delta load.
    Yes
    Thanks
    Reddy

  • 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

  • 0HR_PY_1_CE - Delta init with time limitations

    Hallo everyone,
    I want to use the Content-Extractor 0HR_PY_1_CE to transfer payroll data into SAP BW in delta mode.
    As the source system is running payrolls for a very long time allready, I would like limit the data by time. Pittily the extractor does not support filtering by time in delta mode. (Found this on SAPs help pages and also tried to set start and enddate ... no luck as assumed.)
    So I had a look at the source systems customizing, but the only setting regarding a time frame for extraction I found is the one for PT-data. (Transaction SBIW -> Settings for Application-Specific DataSources (PI) -> Human Resources -> Define Time Frame for Transfer)
    Within the PY-Customizing there is no option to limit the extraction interval.
    Is there any other way to limit the extraction to a specific time frame when loading data via 0HR_PY_1_CE?
    Thanks a lot in advance and regards
    Chris
    Edited by: Christian Baum on Jul 27, 2010 12:15 PM

    Hi Yuvaraaj,
    thanks for taking the time to answer my question.
    For time selection I use the extractors default datafields: BEGDA and ENDDA.
    Pseudo-delta might be an option IF the two fields you mention are processed in the extractors selection logic. I actually don't know and would need to take a closer look on the extractors programm logic.
    Anyway my goal is to stay as close to SAPs standard as possible.
    Pittily the extractor does not support filtering by time in delta mode. (Found this on SAPs help pages and also tried to set start and enddate ... no luck as assumed.)
    I had another look at [SAPs documentation for 0HR_PY_1_CE|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/6a/cccc6015484464b25605375a5db965/content.htm] and have to recall the statement above.
    As there is no restriction mentioned about delta and time selection there must be a way to pass a time frame when initializing the delta.
    I tried the following:
    1. I startet an Infopackage in full mode with the follwing filter criteria: BEGDA = 01.10.2009; ENDDA = 31.10.2009
    The extractor dilivers ~60000 records; their inper is allways 10.2009. -> Selection worls fine
    2. I started an Infopackage in delta init mode and exactly the same selection criteria as the full mode Infopackage and i receive millions of records whichs inper is spread over several years.
    So the time selection is definitely not working in delta mode.
    Are there any customizing settings I missed in the OLTP system?
    Regards
    Chris

  • How to move full repair data from DSO1 (soruce) to DSO2(target)?

    Hello experts,
    I doing full repair for po in first level ods, Do i have to move this data from first level ods to second leve ods? or the daily nightly delta from first leve ods to second level ods will take care of it?
    If i have to load the data from first level ods to second level ods how to do it?
    do i have to delete the data first from first level ods before i do the full repair for the po? or just run the infopackage for the po's with the full repair option checked?
    note:we don't use dtp here to load data from bi to bi here.
    Thanks in advance.
    Sharat.

    Delete the first level and second level DSO' s data and set a full repair in the infopackage. the delte will take take all data to second level as ur deleting the data from second level.

  • Delta Init DTP DSO- Cube loads all requests

    Hi,
    i've loaded several Full Request to a DSO (Datasource 2LIS_02_ITM).
    I had to to fragment it to 3 months per Full load because otherwise the data volume was too much for the rollback segment.
    Now i want to load these requests from the DSO to a Cube.
    I created a Delta DTP and selected the "All new data by request" option.
    The DTP starts as a Delta Init but selects all open requests at once and crashes with a "ORA-01555: snapshot too old..." error.
    As a workaround i created several Full DTPs that only load part of the data but i really want to understand why the Delta Init doesn't work as expected and documented (to load request by request in a new process).
    thanks
    Carsten

    Hemant Khemani wrote:>
    > Please check if you have selected the option "Get All New Data Request by Request" in the Delta DTP.
    > If you have selected this option then the delta DTP will select only one request (oldest - yet to be updated to the target) from the DSO.
    That's the option i've selected.
    When monitoring the DTP-Request i see in the head data that all requests from the DSO are selected at once.

  • Regarding full repair

    Hello All,
    I have a situation here, is as follows,
    I did init without data transfer for a perticular sale organization now I want to do full repair for that sale org from R3 (LIS_13_VAITM).
    My question is do I need to fill setup table for full repair or not required.
    Please reply ASAP.
    Thanks,
    Suneel

    Hi Patil,
    U have to fill setup table for missing sales org.
    before that delete existing data in setup table.
    After filling setup table,Run full update with repair.
    Thanks,
    Vijay sekhar reddy.

Maybe you are looking for