"Waiting time until status incorrect" - BI delta loading issue

Hi All,
We have a delta master data load, which happens daily. It runs almost for 40 minutes, there is no extraction happening for first 31-32 minutes and the thousands of records are picked in the subsequent few minutes.
After 30 minutes, the load is momentarity turning into  status 'RED' and the load is picking up as usual. I could see there is a setting for the load in RSMO transaction itself, in Settings tab --> Waiting Time Until Status Incorrect. In this settings time set is 30 minutes.
Now can some help me in changing this setting time value or speed up the loading (i.e. to pick before 30 minutes). This has been happening for the past one week. Any help is highly appreciable, as this job fails unnecessarily in monitoring tool.
Regards,
Shashidhar.

Hi Shashidhar,
I had a performance issue for an infopackage loading from Generic datasource. The reason was identified as Index not being not created for the source table.
These threads may be useful for your issue.
RSC2_QOUT_CONFIRM_DATA  Long Running/Delayed Delta Infopackage
n LUWs to be deleted with function module RSC2_QOUT_CONFIRM_DATA
http://www.sapfans.com/forums/viewtopic.php?f=16&t=237705
Regards,
Hari.

Similar Messages

  • What does the option 'Settings- incorrect waiting time for status' do ?

    Hi All
    We had an infopackage that seemed to be hanging this morning . (Yellow Status) I was advised to access the option 'Settings->incorrect waiting time for status' and set the wait time to 7 minutes (from 7 hours). This changed the status to Red.
    I then re-ran the ipak and reset the ''Settings->incorrect waiting time for status'  to 7 hours. This made the red process go back to yellow and the run time started going up again.
    Can someone explain what is going on. Have I got 2 instances of the same ipak running simulateously. Why did the red one come back to life even thoug I deleted the request in data target for that ipak.
    Thanx
    HKF

    Thanks, Verdi - the first time I enabled,/ or disabled, I hadn't realised what had actually changed, as I think I'm so used to seeing my links open in Safari anyway!

  • Delta load issue in COPA

    Hi All
    We are using COPA datasources and daily delta loads will goingon from source system R/3 without any issues.
    last day the delta load from source system was failed due to some basis problem( non availability of WP) and we deleted that bad request in the DSO and then repeated the failed IP in the process chain,then the delta load was succesful but 0 records has been updated.
    So we are missing that delta records,I guess this is due to the time stamp set in the source system.
    In which table does this timestamp exists and what is the procedure inorder to solve this issue
    How do I need to solve this type of issues.
    Please let us know .,
    Regards
    Shankar

    Hi Shankar........
    I think u hav'nt make the QM status red.......when a delta load will fail............always make the the QM status red before repeating the load...........it will set back the QM status.........and when u will try to repeat the load.....system will ask for a repeat delta...........and a repeat delta will pick all the failed records along with the new records(if any).......
    I think u should do reinit............ie.......
    1)Delete the init flag
    2) Fill the set up table with selection.........did u know which values r missed........any selection criteria..like date.......
    3) Then do Full repair
    4) then delta....
    If u don't know the selection..............then u hav to load data for a selective range.........check ur DSO.....if the Update mode is Overwritten........then no probs.........otherwise there may be duplication of records.........then u hav to do selective deleteion........
    Hope this helps......
    Regards,
    Debjani..........

  • Delta load Issue in the R3 generic datasource

    Hi All,
    We are using a generic extractor which will be extracting from the R3 system through Delta update. Yesterday, the load has taken almost thrice the amount of time when compared to the previous loads and we found that the number of creation/changed records i.e. the delta records that are need to be picked up by the extractor are also quite normal. We were not facing any issue on the load before.
    The job has taken more time while fetching the records from the table "RSOORMPC". We have also checked with the basis team and they confirmed that system performance is not slow during that period. Also, there is no dump or log created in the system for this issue.
    Could you please give your views on this issue why this has occurred??
    For your information, the repeat delta which we had triggered has picked up only 0 records.
    Your suggestions will be verymuch helpful for us as it has happened in the production environment. If you need anymore information please give me a shout.
    Regards,
    Yokesh Kumar.

    Sateesh,
    The extractor is function module based only. Load did not even entered the code which we had written. While calling a standard program itself, the load got stuck.
    Regards,
    Yokesh Kumar.

  • Delta loading issue

    Hello,
    I created a specific datasource based on a standard table in which there is a "changed date" field.
    I used this field to create a delta loading for BW. Unfortunately, a change has been made yesterday after the delta loading and today the delta doesn't load this entry.
    Is it possible to change the current status of the relevant field in order to restart the delta from the day before yesterday or should I suppress the data and launch a new init ?
    Thanks for help.
    Regards,
    Bertrand

    The date of the previous load is stored in the table ROOSGENDLM. You can modify the date with the transaction SE16.
    Regards,
    Fred
    Edited by: FCI on Apr 8, 2009 10:08 AM

  • Master data delta load issue

    Hi Expert,
    We have recently enhanced a Master Data object with 3 fields. These fields are directly mapped from a DSO. When the delta load is done, these 3 fields are not getting the data, while a full(selective) load gets the data and the 3 fields get populated. What can be the reason for this?
    Thanks,
    Anupama

    Hi,
    Then if data already updated to info object through full load, again if you run delta dtp for the same its not fetch any records, so after full load, initiliaze the delta dtp, In DTP in exectue tab you will select processing mode as select option : No data transfer delta status in source is : fetched, aftet that you can run your regular deltas. it will work.
    Regards,
    satya.

  • SAP Mobile Sales 2.0 delta load issue for Sales Orders

    Hello,
    we have used Mobile Sales 2.0 with a Windows app for a while now. Our current issue is that sales reps won't see any historical sales order data on their devices.
    Background
    Due customer requirements, we need to make small changes to customer master data attributes and reload all customers from ERP to CRM. Then we ran delta loads (MAS_PARTNER followed by all other objects) to DOE, in which virtually all 5000+ customer accounts were compared. The delta load ran for about 3 days (some performance bottleneck we haven't located yet).
    During the delta load, data on devices was inconsistent. Accounts were missing and all transaction data disappeared. After the delta loads, all accounts and contacts are OK, save for a few. Data from activities (appointments, tasks) have reappeared, as they should. Only sales orders won't reappear. The sales orders exist in the backend and belong to active accounts and sales reps.
    Settings and troubleshooting so far
    We don't have any limitations for sales orders in CRM Sales Mobile configuration.
    We've run delta loads for all objects in transaction SDOE_LOAD.
    MAS_CUSTOMIZATION etc seem fine.
    We've re-run initial load for sales orders from CRM.
    In the test system, we've even reinitialized the whole CDS database on DOE and on the devices, then re-ran the loads.
    Checked steps suggested in discussion
    SAP CRM 2.0 initial load issue
    Historical sales orders (those created before the master data reload) exist in the backend, but don't show up on the device.
    If I change one of those historical sales orders in the backend, it gets sent to the device.
    If I create a new sales order in the backend or on the device, it is saved and replicated just fine.
    To sum it up, it seems DOE is unable to identify the sales orders relevant for replication.

    First Doubt i got clarify by my self as we can go with Unwired Runtime option .
    But i still have doubt in :
    2. How can i Modifying the Main Menu for iOS.
    i am able to customize the same for windows using files SybaseCRM.Configuration.xml file.
    Same how can i do for iphone/ipad.

  • Delta load issue from DSO to DSO

    Hi Experts,
    We have a scenario where we need to load the delta from DSO to DSO. when we are running delta from DataSource  to DSO it is picking some around 100 records, but when we are running delta from DSO to DSO it is picking some around 80000 records. But in previous deltas it has taken as equivalent to staging DSO only, but in today delta it has different. Could you please give some pointers, why it is happening like this.
    Thanks
    Konda Reddy

    Hi,
    There are no routines in DSO's and transformations also we have not changed, the thing is that in previous deltas it has taken same recoreds as in the staging layer. In between we have done one full load from DSO to DSO, is this makes difference in picking up the delta. And again we done delta then it has taken aroung 80000 records which includes the full load records also. could you please provide some pointers.
    Regards,
    Konda Reddy

  • How to change wait time-- Urgent

    Hi,
    In monitor screen, under status, I am seeing the wait time date as next month date.
    So the technical status is yellow in color though the data is loaded.
    Where can I change this time.
    Thanks in advance

    Hi,
    When changed Timeout time in Info package it will reflect to particular infopackage only .
    If u changed in RSMO tcoe and settings- menutab
    Waiting time upto status incorrect - it will reflect to all infopackages.
    We can maintain  the value in years, months, days,hours,minutes and second also.
    Regards,
    Krish

  • Issue in the Delta load using RDA

    Hi All,
    I am facing an issue while trying to load delta using RDA from R/3 source system.
    Following are the steps followed:
    1. Created a realtime Generic Datasource with timestamp as delta specific field and replicated it to BI.
    2. First I have created the Infopackage(Initialization with data transfer) and loaded upto PSA.
    3. Created a standard DTP to load till DSO and activated the data.
    4. Then created a realtime delta infopackage and assigned it to a Daemon.
    5. Converted the standard DTP to realtime DTP and assigned the same to the Daemon.
    6. Started the Daemon, giving an interval of 5 minutes.
    In the first time, Initialization with data transfer is taking the records correctly. But when I run Daemon for taking delta records, its taking all the records again, i.e. both the previously uploaded historical data and the delta records).
    Also after the first delta run, the request status in the Daemon monitor, for both Infopackage and DTP changes to red and Daemon stops automatically.
    Can anyone please help me to solve these issues.
    Thanks & Regards,
    Salini.

    Salini S wrote:
    In the first time, Initialization with data transfer is taking the records correctly. But when I run Daemon for taking delta records, its taking all the records again, i.e. both the previously uploaded historical data and the delta records). .
    If I understand you correctly you Initially did a full load. Yes? Well next you need to do intialise & after that delta.
    The reason is that if you will select delta initialisation & initialisation without data transfer- it means delta queue is initialised now & next time when you will do delta load it will pick only changed records
    If you will select delta initialisation & initialisation with data transfer- It means delta queue is initialised & it will pick records in the same load.
    As you know your targets will receive the changed records from the delta queue.
    Salini S wrote:
      Also after the first delta run, the request status in the Daemon monitor, for both Infopackage and DTP changes to red and Daemon stops automatically.
    I take it the infopackage has run successfully? Did you check? If it has and the error is on the DTP then i suggest the following.
    At runtime, erroneous data records are written to an error stack if the error handling for the data transfer process is activated. You use the error stack to update the data to the target destination  once the error is resolved.
    To resolve the error, in the monitor for the data transfer process, you can navigate to the PSA maintenance by choosing Error Stack in the toolbar, and display and edit erroneous records in the
    error stack.
    I suggest you create an error DTP for an active data transfer process  on the Update tab page (If key fields of the error stack for DataStore objects are overwrite On the Extraction tab page under  Semantic Groups, define the key fields for the error stack.)  The error DTP uses the full update mode to extract data from the error stack (in this case, the source of the DTP) and transfer
    it to the target that you have already defined in the data transfer process. Once the data records have been successfully updated, they are deleted from the error stack. If there are any erroneous data records, they are written to the error stack again in a new error DTP request.
    As I'm sure you know when a DTP request is deleted, the corresponding data records are also deleted from the error stack.
    I hope the above helps you.

  • Wait time minimum

    I would like to know which the smallest value than I can use  whith the  function wait time and wait time until ... . Is possible use values less then 1ms like microseconds. Because i have a problem in control with a board 6023E a step motor i need send two signals une    for control the direction and other for control the step but this pulses (step) need have  frquencys  larger than 10000Hz

    I'd like to refer you to another thread I was in a while back.  The essentials are:
    1. Use of a 'timed loop' (requires LV 7.1 I think) where the pulsetrain output is the timing source.  This allows iteration speed to be governed at resolutions below 1 msec. 
    2. Timed loops get a very high execution priority, so you'll likely get better consistency than you would with 'Wait (msec)'.  Nevertheless, the timing still won't be guaranteed under Windows.
    3. The example I posted doesn't sound like an exact match for your current app, but does illustrate a few ideas you may be able to use.
    4. The example includes a 3rd counter used to count # pulses and verify correct behavior.  As mentioned, you'll need to get rid of everything related to that 3rd counter since your E-series board only has 2 counters.  Also, I wasn't able to test on an E-series board.  I think it should work there, but can't verify.
    -Kevin P.

  • Wait time/need help

    Hi
    need help
    II used wait time function to wait 5 second before send command to my device , I put this function in while loop so I could display the waiting time until it is reach 5 seconds , it is work in the first run but when I run the VI for the second time it is give me all waiting time , I want it to start from 0 for each run

    I'm glad you solved the problem...
    However, I'm trying to figure out what it is that you are trying to accomplish.
    Why do you make the buttons visible?  Were they made invisible somewhere else?
    Why do you use the property node to assign names to the cancel, and ok buttons?  Were they renamed elsewhere?
    Which VI / subvi are you opening the front panel?  If it is the one I am looking at, you can set that up in the VI Properties, within the Window Appearance section, and select Custom. You can set it to "Show front panel when called" and "Close afterwards if originally closed".
    You can simplify your Rube Goldberg boolean logic by wiring the Cancel and the output of both OK buttons (ORed) to the Compound Arithmetic function (OR).
    To learn more about LabVIEW, I suggest you try looking at some of these tutorials.

  • Repeat delta load

    Dear all,
      my scenario is as follows:
      The last delta was successful loaded into BW system and delta queue was cleared. However, the customer exit program for the datasource was changed after the last successful delta load. I don't want to re-initialize the data load again because of  large quantity of history data. I just want the records in the last delta load to be changed according to the new customer exit. Please advise. Points will be given.
    Thank You.
    Jin Ming

    Hi,
    Delta are still there in queue(RSA7) after delta load. Make sure,In RSA7, Detail icon there you can see repeat delta option which(Today delta+previous delta). And previous delta only deleted from queue,when you perform next delta.
    In simple, Queue contain today delta+previous delta .
    To perform the last delta load again. In BW, in moniter by making the status of last delta load into RED. Delete particular request from datatarget.Now schedule the infopackage, a message window promt you last delta failed. you want repeat it? Press yes.
    Thanks

  • Network/roll wait time is high

    Hi,
    One of my dialog instance is showing high response time at SMLG.
    When i am checking Dialog Overview at RZ20, network response time of this server is very high.
    When i am checking the parts of response time at ST03, roll wait time is always around 70% for this instance.
    (4.7,2003 server, SQL 2000)
    Kindly suggest me to resolve this.
    Regards,
    Gayathry.

    Hai,
    Roll wait time means: During processing of some dialog steps, the user context may be rolled out; for example, during RFCs when the client is waiting for a response from the server. This wait time until the dialog step can continue is called the roll wait time.
    try to check what RFC causes this, somtimes this may lead to rollfile overflow and in turn some background jobs might fail due to rollfile overflow.
    Check SAP Notes:1100926 and 578118.
    Regards,
    Yoganand.V
    Edited by: Yoganand Vedagiri on Mar 12, 2009 1:47 PM

  • Delta loading take more time

    Hi
    the daily delta load from 2lis_03_bf to cube 0ic_c03
    daily its take max 2 hars but to day its still running for 5 hrs not yet finished with 0 from 0 records
    why,
    how can i  get the reason
    In rsa7 its showing 302 records
    Regards
    Ogeti
    Edited by: Ogeti on May 8, 2008 7:47 AM

    Hi,
    I will suggest you to check a few places where you can see the status
    1) SM37 job log (In source system if load is from R/3 or in BW if its a datamart load) (give request name) and it should give you the details about the request. If its active make sure that the job log is getting updated at frequent intervals.
    Also see if there is any 'sysfail' for any datapacket in SM37.
    2) SM66 get the job details (server name PID etc from SM37) and see in SM66 if the job is running or not. (In source system if load is from R/3 or in BW if its a datamart load). See if its accessing/updating some tables or is not doing anything at all.
    3) RSMO see what is available in details tab. It may be in update rules.
    4) ST22 check if any short dump has occured.(In source system if load is from R/3 or in BW if its a datamart load)
    5) SM58 and BD87 for pending tRFCs and IDOCS.
    Once you identify you can rectify the error.
    If all the records are in PSA you can pull it from the PSA to target. Else you may have to pull it again from source infoprovider.
    If its running and if you are able to see it active in SM66 you can wait for some time to let it finish. You can also try SM50 / SM51 to see what is happening in the system level like reading/inserting tables etc.
    If you feel its active and running you can verify by checking if the number of records has increased in the data tables.
    SM21 - System log can also be helpful.
    Also RSA7 will show LUWS which means more than one record.
    Thanks,
    JituK

Maybe you are looking for