Info Package-'Repair Full Request'

Hello,
   In the info package o the scheduler menu there is an option 'Repair full request' what is this for.Could you please give when i can use this option
Thanks

Hello
How r u ?
very important regarding deltas.
Regarding updating data in the enhanced fields
Data can be loaded to a data target even if the data target already contains data from an init load or delta for this DataSource/ source system combination and has overlapping selection criteria.
This option is very useful when doing a full load to an ODS. If you don't mark a full load as Repair when loading to an ODS, you will not be able to do an Init for it.
refer this:
http://help.sap.com/saphelp_nw04/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/content.htm
Best Regards....
Sankar Kumar
+91 98403 47141

Similar Messages

  • 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

  • How to delete repair full request

    Hi,
    There was a delta load scheduled in background. By mistake before the delta load a repair full load with particular company code selection was run. So after the delta load, data is duplicated in the system. Now the request is compressed. I want to delete this repair full load request from the ODS. Please let me know step by step solution for this.
    Thanks.

    Hi,
    from where u r loading data into cube from ODS or R/3. if u run a repair full load then it will not check the data mart symbol although it is successfull so the next delta will brings data again, so u have to run init with out data transfer to make deltas 0 in source. this happened in ur case .
    but the cube is compressed so u cant delete data request based
    is there any PSA there if there is PSA then u can use REVERSE POSTING from PSA this will brings key figure values with - values so the records will be nullified
    in manage of the cube -> select that repair full request -> click on monitor button -> u can find an icon in the top(psa request symbol with red mark) click on that and execute.
    if there is no PSA then u have to do selective deletion.
    assign points if it helps,
    thanks,
    pavan.

  • DTP Questions: Delete overlapping requests;  Repair Full Request

    Hello,
    I'm new with the DTP concept in BI 7.0.
    It is clear to me how DTP is working for normal loads like: full, delta, delta without data transfer etc.
    But I don't see where I can specifies "Delete overlapping requests". Is this still possible in a DTP, or is it only possible by creating a Process Chain and insert the process-type "delete overlapping requests" ?
    Also I have a question about "Repair Full request" using DTP.  Is this option still possible ? Or do I have to create a DTP with extraction-mode = Full => Extraction from Active table.  => Is delta than still working ?
    Thanks for your input,
    Wim

    <b>But I don't see where I can specifies "Delete overlapping requests". Is this still possible in a DTP, or is it only possible by creating a Process Chain and insert the process-type "delete overlapping requests" ?</b>
    This option is available <b>only in Process Chains</b> when u use DTP's.
    /people/community.user/blog/2007/06/21/sap-netweaver-70-bi-data-transfer-process-with-147only-get-delta-once148
    /people/community.user/blog/2007/06/21/sap-netweaver-70-bi-data-transfer-process-with-147get-data-by-request148
    <b>Also I have a question about "Repair Full request" using DTP. Is this option still possible ? Or do I have to create a DTP with extraction-mode = Full => Extraction from Active table. => Is delta than still working ?</b>
    Full Load was made Repair Full to Initialize if loading an ODS but however you dont need to worry abt the same in Netweaver 7.0 as DTP is taking care of the loading from PSA to DSO.
    Initialization can be done after a full load as the load is <b>only till PSA</b> ( At Datasource Level ).
    DTP doesnot require any initialization.
    U can jst do a Delta DTP after a Full DTP to a DSO or u can even start with a Delta DTP directly.
    For the first time  -> Delta DTP = Full DTP !!

  • Add new key figs or characteristics and "Repair full request"

    Hi Gurus, here are my questions
    1.If I add new key figs or characteristics(which are not Key fields) to ODS and Cube containing tons of data, Will the transport for structure changes fail due to presence of data?
    2.The extractor to the ODS which inturn is feeding the cube, is delta enabled. So the newly added objects wont have entries for historical records. If I change this extractor to "Repair full request" after adding the new fields, will the new fields then get populated?
    3. After the "Repair Full Request" activity, Can I change the Infopackage setting back to delta update mode?
    Thanks for the help in advance!!
    Simmi

    Hello Simmi,
    1. Transport should go fine. As you are not changing the key fields, it should not cause any problem even if data is present.
    2. Yes. But make sure what data you want to laod. As with full repair, system is not going to check for duplicate data. The responsibility lies with you.
    3. Sure. if you mark the full load as repair, the delta settings will be unaffected.
    Hope it helps.
    Regards,
    Praveen

  • How to change full fudate as a repair full request.

    Hi experts,
    As per my requirment i want to run repair full but i ran full update so i need to change this full update to repair full, can any one help me.
    Manythanks in advance
    David

    [Tab Page: Updating modes|http://help.sap.com/saphelp_nw04/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/content.htm]
    [Repair Full request |Repair Full request;
    [Repair Full request |Repair Full request;
    [Repair Full Request... |Repair Full Request...;
    hope this may solves your issue

  • What is full request? and repair full request?

    Hi experts,
    please let me know what is full request? and repair full request?

    Hi Suman,
        Delta loading not possible if FULL requests already available in ODS from same datasource & souce system combination, In order to delta's FULL requests should be changed to Repair FULL full requests. Then system allows Deltas.
    <a href="http://sapbwneelam.blogspot.com/2007/09/how-to-do-delta-loads-after-full-loads.html">Repair Full Request</a>
    Hope it Helps
    Srini

  • Hi,  Explain about Repair full request

    Hi explain about repair full request and one more how many max no of partitions we will do

    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.
    SAP Note Number 739863 - Repairing data in BW
    REGARDING PARTITION
    IF BASED ON 0CALMONTH THAN 12+2
    IF BASED ON 0FISCPER3 THAN 122 OR 162 ( DEPEND ON VARIANT)
    Thanks
    Tripple k

  • What is the major advantage of Repair full request?

    Hi gurus
    What is the major advantage of Repair full request?
    Thanks in advance
    Raj

    Full Repair request is used when:
    1. During delta upload you have skipped some records and want them in your data target.
    2. When the delta load was not correct and you make a selective deletion and fetch the data for the same selection without disturbing the delta update.
    3. When at times you fail to have even full upload, then mark the request as repair request and you can get the full upload..(I have faced such a scenario)
    Assign points if useful.
    Regards
    Gajendra

  • I would like to know about repair full request.

    i would like to know about repair full request.

    Check the following :
    Repair full request
    Delta loading not possible if FULL requests already available in ODS from same datasource & souce system combination, In order to delta's FULL requests should be changed to Repair FULL full requests. Then system allows Deltas.
    Repair Full Request

  • Diff between init with data transfer and repair full request

    hi,
    i have observed that even in the new flow we are doing init without data transfer and then repair full request
    if i do init with data transfer also i can achieve the same?
    i want to know why we need to do this ,do we have any advantage of doing init without transfer and repair full request?
    please suggest me

    Hi Venkat,
    A repair full request is loaded in cases where you get erroneous records or where there are missing records which you want to load. In such cases, a repair full request for the selective records can be loaded and is the most efficient way to correct the data, since you won't be required to load the entire data once again. Also you acheive the desired result without disturbing the delta. (You are not required to do an init w/o data transfer after a repair full, people just do it a a precaution)
    However, repair full requests should only be loaded to infoproviders with update mode 'overwrite'. Otherwise, if the InfoProvider, its very probable that you might double the value of the key-figures due to rows being added twice - in case of an InfoProvider with update mode 'Additive'. So, if your InfoProvider is additive, you will need to delete the entire data and do an 'init with data transfer' to avoid corrupting the data. (Note: you can do a repair full request for an additive infoprovider in case of lost records or if you can delete erroneous records with selective deletion.But you have to be careful with the selections lest you inadvertently load other records than required and corrupt the data)

  • ECC table for Repair Full request

    Hello experts,
    Is there any tabale at ECC side to set an indicator when we are doing Repair Full request for a DataSource.
    Thanks a lot,
    zakir.

    No.
    Repair full flag for a request is set in BW side only.

  • Regarding Repair Full Request

    Hai
    Can anyone explain in detail "when and in which scenarios and how REPAIR FULL REQUEST funcationality is used ....
    Please tell me with example urgently...
    I Will assign the points
    Thanks \
    BYe
    MOHAMMED

    HI,
    FULL REPAIR.................
    Full repair load is only relevant for ODS objects when you need to do a full load from a datasource which has been initialised. 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 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.
    Please go through the following thread where a similar problem has been discussed.
    Re: Repair Full Request
    Nice post by Roberto:
    full repair request
    repair full request
    -Shreya

  • What is repair full request?

    Hi,
    What is repair full reuqest and how it can be done. Please explain the process.
    Regards,
    Magic...

    Hi
    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.
    This request can be updated into every data target even if the data target already contains data from an initialization run or delta for this Data Source/ source system combination, and has overlapping selection criteria."
    You will find this request under the "Repair Request" option in the InfoPackage (Maintenance)
    menu.
    SAP Note Number 739863 - Repairing data in BW

  • Selective deletion and repair full request!!!

    Hi,
    I have one DSO which is receiving deltas from Std extractor and is also serving deltas to many data targets (Both DSO and Infocubes)
    Now there comes the need of deleting data in DSO by means of year ( selective deletion )
    I know that i need to adjust the data flow from DSO to other data targets myself!!
    So after doing selective deletion in DSO, can i update datatargets ( of 3.5 version ) with full update so that data is adjusted in correct format for the subsequnet data targets?
    or is there any better option??

    Hi Sujith,
    Difference between Repair Full and  Full Load ;
    1. When we want to pull the history data from the source system(SAP R/3) for the first time till yesterday and trigger / enable the Delta load.
    For Eg; for your client,when the implantation was done ,when the GO Live started, all the history data(sales,Material,Finance etc) would have pulled from the source systems into BW system and enabled the delta load from next day.
    Note: In this scenario ,We use Full Load only for the one time.
    2. In most of the scenarios we will use Full Load for the master data (Daily Load). In few scenarios we will use Full Load for the transaction Data Loads. For Eg: in case if there are no changes happening in transaction data daily (like sales data) ,then we go for Full Load for transaction Data Load also.
    3. If someone has deleted the data in the data target by mistake which was loaded using 'Full Load' ,then we can go for re-loading the lost data using the same normal 'Full Load' option. In this case if you are using a DSO in between PSA and Infocube then if you don't use the selection parameters(Company Code,Profit Center, Sales Organization etc) for the lost data ,then also it's fine. Because DSO has overwrite option. In case ,if you don't have DSO,then you have to use the selection parameters on infopackage/DTP level depending on from which level you are trying to get the data back. i.e Source System or PSA.
    4. We have scenario where the data which was loaded using DELTA load has been deleted from the data target, OR due to DELTA load failure the data didn't get loaded into the data target. Now,we want to get the lost DELTA data back into the target. In this case we can go for using both 'Repair Full' and also 'Full Load'. but depends on the below conditions;
    If we want to use 'Full Load' to get the lost DELTA data,then we should block the users in source system(SAP R/3) from posting the data,and clean up the delta queue . Then stopping the daily process chain in BW system which will bring the DELTA data. Then we can use' Full Load' option.
    But, If we don't want to disturb the daily DELTA load and if we don't want to block the users in source system, then we should use 'Repiar Full Request". Using this option, the daily DELTA load will not get affected.
    Please let me know you are clear with my points.
    Regards,
    Asha

Maybe you are looking for

  • ShowPopupBehavior: pop-up does not stay open

    I'm using an <af:showPopupBehavior> component with the triggerType set to "focus" inside an <af:inputText> to display a stylized tooltip. It works fine when I use the mouse to give the text field focus, but when I tab into the text field the pop-up b

  • How to use EL in JSP

    Hi, I am trying to use EL in JSP,as EL syntax is ${first.secondvalue},but whenever i write this in my program and i run it,it is showing like this only not the value which it has to show. I think that EL is not being enabled in my jsp. I write <jsp-p

  • DDNA 11.1.3.5 Template - Adding an Application

    Can anyone shed some light on how to add an applications settings to be migrated using Desktop DNA 11.1.3.5 The Install guide says to use the 'Add Option' button in the Template Editor but from what I can see all that does is adds a meaningless item

  • MOTU Interface Issue: Audio Not Reading In Host Software

    Greetings. I'm in need of help. I'm using my MacBook Pro for live studio recording and it receives audio from a MOTU UltraLite Mk3 Hybrid Interface via Firewire cable. The Audio Reads in the System Preferences Sound Input Level Monitor But Not in Hos

  • Using the OS X Lion USB Thumb Drive, could I install it on more one than machine??

    I want to buy the OS X Lion USB Thumb Drive. But I need to install it on more one than machine, could I do this??