Delta queue analysis for actions pre/post patching

Hi,
We are going to patch both R/3 as well as BW. So can you pls advice me any precautions we need to take for the delta queues??
regards,
Jacob

Dear Raghavendra,
Deleting the init request in BW will delete the delta queue in RSA7.
Q. Is it very necessary..
Is it BW upgrade or r/3 upgrade?
No, this is only the hardware migration. BW and R/3 will be same as it is.
Thank you for the quick response,
thanks,
Sanjana.

Similar Messages

  • How to deal with delta queue when importing Support Package/Kernel Patch

    Hi,
    From my experience, when importing a Support Package for an installation, the system will issue an error message and get stuck if this Support Package is about to alter the structures used in delta loads.
    But I would like to double with you if there is possible that the support packet which is going to alter structure, but no error message. If so, the delta data will be lost.
    Do we need to clear down the delta queue every time we import support package?
    Anyway, is there anyone have any suggestions or steps regarding this question?
    Many Thanks
    Jonathan

    Hi,
    Delta queues during support package upgrade
    Its always better to drain the delta queues before an upgrade.
    As a standard practice we drain the delta queues by running the IP/ chain multiple times.
    As a prerequiste we cancel/reschedule the V3 jobs to a future date during this activity.
    The V3 extraction delta queues must be emptied prior to the upgrade to avoid any possible data loss.
    V3 collector jobs should be suspended for the duration of the upgrade.
    They can be rescheduled after re-activation of the source systems upon completion of the upgrade.
    See SAP Notes 506694 and 658992 for more details.
    Page 17
    Load and Empty all Data mart Delta Queues in SAP BW. (e.g. for all export DataSources)
    The SAP BW Service SAPI, which is used for internal and ‘BW to BW’ data mart extraction, is
    upgraded during the SAP BW upgrade. Therefore, the delta queues must be emptied prior to the
    upgrade to avoid any possibility of data loss.
    upgrade preparation and postupgrade checklist
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/472443f2-0c01-0010-20ab-fbd380d45881
    /message/3221895#3221895
    OSS notes 328181 and 762951 as a prerequisites.
    Failure to follow the instructions in those notes may probably result in data loss.
    https://websmp207.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700002662832005E
    /thread/804820
    Effect on BW of R/3 Upgrade   
    How To Tackle Upgrades to SAP ERP 6.0
    /people/community.user/blog/2008/03/20/how-to-tackle-upgrades-to-sap-erp-60
    Start with the Why — Not the How — When You Upgrade to SAP ERP 6.0
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/008dddd1-8775-2a10-ce97-f90b2ded0280
    Rapid SAP NetWeaver 7.0 BI Technical Upgrade
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e0c9c8be-346f-2a10-2081-cd99177c1fb9
     https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c2b3a272-0b01-0010-b484-8fc7c068975e
    Hope this helps.
    Thanks,
    JituK

  • Trouble with Pre/Post Roll tape, before/after segment... what the ****.

    I'm getting alternating error messages...
    "capture encountered a problem reading the data on your source tape. This could be due to a problem with the tape.
    To capture as much of your footage as possible, please capture a clip that ends before this segment, and another one that starts right after it..."
    And then something about Pre/Post Roll tape, basically the same thing as above.

    I'm getting alternating error messages...
    "capture encountered a problem reading the data on your source tape. This could be due to a problem with the tape.
    To capture as much of your footage as possible, please capture a clip that ends before this segment, and another one that starts right after it..."
    And then............
    "Batch Capture: Timecode error: Unable to locate the specified timecode. You may have specified a timecode with insufficient room for a pre/post roll operation."
    Am I doing something wrong here???

  • After recent patch upgrade, BW delta Data loads for 2LIS_02_ITM failing

    Hi All
    We have patched our BW 3.5 system from 16 to 25. After updating patches, I am geetting delta load issues.
    2lis_02_itm and 2lis_02_scl delta loads are taking long long time. Deltas are failing even for 3000  records . some time it is taking 14 hours .  Delta loads are failing  and I am getting below message. Please advise.
    I am still getting below dump and i could not find any errors in
    ST22. Please see below error.
    Processing in Warehouse timed out; processing steps mising
    Diagnosis
    Processing the request in the BW system is taking a long time and the
    processing step Update rules has still not been executed.
    System response
    <DS:DE.RSCALLER>Caller is still missing.
    Procedure
    Check in the process overview in the BW system whether processes are
    running in the BW system under the background user.
    If this is not the case, check the short dump overview in the BW system.
    Thanks
    Pramod

    Hello Pramod,
    Is this load is to load to initial level ODS? If Yes I understand that you have issue in loading but not at activation of the ODS?
    Normally this kind of issue comes during the activation of ODS.
    1. If you are getting this during the data loads, then try to check loading only to PSA first and then from PSA to target? And check how much time that it's taking as this will help to track the issue whether its present in Source or in BW?
    2. If the load is fine till PSA then try loading the same to ODS and then check whether this issue is present or not?
    3. At the same you need to check the source side the system load and the number of processors which are available?
    4. Did you perform the delta queue draining before the stack upgrade in R/3 or not? Normally as a pre-requisite this needs to be done if not then you will have issues in extracting the data!
    5. Finally this can be avoided by having Initwithout data transfer and then performing the Delta loads. BUt for this need to first extract all the data from Source to BW and then take a down time in R/3 for few min and perform this activity so that the Init Timstamp will be reset properly and the Delta should work fine for you.
    Do get back to us with more details.
    Thanks
    Murali M

  • R/3 Patch Upgrde Problem due BW Delta Queue.

    Hi Expert,
    I have extracted all the logistic & delta data in BW to make delta queue emplty. My query is that ,should it delete these queue in RSA7 or it should disappear after extraction.
    In LBWQ there are only two entry MCEX17 & MCEX17_1 , these queue are still there after extraction.what to do these queue ?
    These queues are giving error while upgrading patch.
    2LIS_13_VDITM
    2LIS_13_VDHDR
    2LIS_11_VDITM
    2LIS_11_VDHDR
    2LIS_17_IONOTIF
    Regards,
    Anand Mehrotra.

    Hello Anand ,
    There is no need to delete the queues for the upgrade, you only need to make sure that there is no data in these queues in rsa7 that need to be extracted, if you run the relevant infopackage twice on the BW side then it should clear the data from RSA7 , before doing this please make sure that all data has been updated from lbwq to rsa7 (if using queued delta) and that there is no data in sm13 for the queues. In RSA7 you can double click on the Individual queues and if you check under delta and  delta repeat option for these logistics queues you should find 0 records.
    Best Regards,
    Des

  • Patches with pre and or post patch scripts not executable -- why?

    In my frustration with update manager hangs I have had to kill processes and restart and even manually unjar files and patchadd. Sometimes I run across the error that the pre or post patch scripts are not executable. I have in the past chmod 744 and patchadd then applies the patch. This has happened several times in my latest patch update. I also had a patch ( X11) that implied a lack of entitlement but the manual patchadd showed that the real problem was a missing prerequisite patch.
    My questions are:
    1. is this lack of executable permission on scripts ( pre and post) by design and am I missing the correct procedure?
    2. missing prerequisite scripts? why?
    3. out of frustration --- IS THIS PATCHING UTILITY THE BEST THAT SUN CAN DO?

    Update Manager is sometimes a little flaky, particularly on unpatched systems (as it uses many different utilities). I would suggest that if you are having problems then you should use smpatch instead - it's not really any more difficult to use and is often much quicker.
    If a patch has a script that is not executable that is not a fault of updatemanager, but a fault with the patch itself (being archived with incorrect settings) or possibly your umask setting, which should ideally be globaly set to 0022 prior to patching to prevent problems during extraction and application.
    If updatemanager has complained about a lack of entitlement I would tend to believe that this was the case, check the contents of your entitlement file:
    # cat /var/sadm/spool/cache/entitlement/*entitlement_clientYou may be missing SolarisAllUpdates or other entitlements - please post the output.
    Sun do offer other patching tools, but what is best for one person/company may not be the best for all. There is also the possibility that you don't have it setup correctly - I would ask that you run the attached script and upload the output file generated to our [Support Uploads|http://supportuploads.sun.com/] site.

  • How to delete the data in update queue and delta queue for Queued delta?

    Dear BWers,
    How do i delete the delta queue and update queue data before i fill the setup tables for a extraction based on Queued delta. Please help.
    Thanks
    Raj

    Hi Raj,
    I think you need some ground work for the LO extraction same as others here. Please read the 3 blogs expliciltly created for LIS by Robert Negro.
    /people/sap.user72/blog/2004/12/16/logistic-cockpit-delta-mechanism--episode-one-v3-update-the-145serializer146
    /people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
    /people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
    As well, the OSS 380078 would clear your doubts reagrding the the BW QUEUE mainatinance. 
    Please let me know if these material has been suffecient enough.
    regarda,
    raj

  • Critical issue - delta queues for LIS empty after upgrade BW3.5

    The delta queue in R/3 for LIS sources (S260-261-262) remains empty,
    even after a successful init delta. Hence I cannot extract delta
    records.
    BW3.5
    PI2004.1
    Does the BW upgrade has an effet on the delta queue management in R/3 ?
    The previous configuration BW2.0B PI2004.1 did work fine in that
    respect.
    Laurent Querella
    BI Consultant ALTI

    Laurent,
    from OSS Note 534296 'LBW0: DataSource generation possible for SAP info str.' you can read:
    "(...)it is no longer possible to generate DataSources for info structures (transfer) Snn delivered by SAP (where nnn is between 001 and 500) in the BW interface for LIS info structures (TR: LBW0) in the OLTP. (...)The corresponding DataSources are delivered with the Business Content."
    I think this is the issue...
    However, are you saying that all infostructures are empty ?
    And from where your init is taking data ?
    After an init your delta tables have to be empty...did you empty all these tables before doing your upgrade ?
    Bye,
    Roberto

  • Possibility to register Pre-/Post-Procedures for an SQL Template Handler

    I would appreciate to see the possibility to register pre-/post-procedures for an SQL template handler in ORDS 3.0.
    Why:
    We use Oracle VPD/Row-Level-Security to secure data access. Hence a trigger sets a couple of attributes in the database session context at login time which are then used in static RLS predicates to limit which records the user can see/modify.
    With ORDS 3.0 all sessions are opened under the same technical user (e.g. APEX_REST_PUBLIC_USER), hence all users have the same/no attributes in the session context and could see/modify all data.
    To avoid this situation, I need to set the attributes (e.g. the authenticated user) in the database session context before the actual query/plsql handler is executed.
    Also, resetting the session context after the handler is executed would be good.
    This scenario is in line with scenarios 'One Big Application User' and 'Web-based applications' in http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#DBSEG98291.
    Different solution approach:
    Kris suggested to write a PL/SQL handler where the pre-procedure is called before the business logic procedure/query. This is ok for me as long as I modify data and only need to return no or little data.
    As soon as I need to return a lot of data (e.g. select c1, c19, c30 from t1), this approach will force me to write a lot of code in the PL/SQL handler in order to marshal the c1, c19 and c30 to JSON and put it in the HTTP response.
    But this is the beauty of ORDS - I can simply define a template, write a GET SQL Handler 'select c1, c19, c30 from t1'  and have the data available as REST service, without writing any code to write JSON marshaled data in the HTTP response.

    I tried to log the request at Oracle REST Data Services (ORDS) but I could only start a new discussion: Possibility to register Pre-/Post-Procedures for an SQL Template Handler
    As I mentioned there, the PL/SQL handler approach works for me as long as I have no or only little data to send back to the client (e.g. put/post/delete succeeded or an error message why the call failed).
    If I need to return a lot of data from the PL/SQL handler I would need to, as far as I understand, to marshal the data to JSON and write it to the response body in the PL/SQL handler.
    I don't want to do the marshaling, because ORDS does it better.
    However, this works for me:
    I write a pipelined stored procedure that takes as input the attributes I need to set in the session context. I then can reference it in the SQL handler:
    select * from table(my_pipelined_function(:USER, ....)
    Now the JSON/HTTP response is created by ORDS again.
    I still needed to code a couple of lines, but it is way better than duplicating the functionality already existing in ORDS.
    With the hooks it would be perfect because I would not have to write any code (apart from the procedure to set the session context attributes), just configure the REST services in ORDS.

  • Is there any event callback for "pre/post-register/unregister" object?

    Dear all,
    We noticed that there are rich set of event callback provided by TopLink, including "pre/post-Refresh/Build/Clone/Merge". However, we cannot found any callback method for "pre/post-register/unregister" events. They will be very useful, if we to manage the internal status of register/unregister to indicate whether it is still under the control of TopLink.
    Thanks and regards,
    William

    William,
    Those specific events do not exist. The postClone event is called after an object is registered. This is frequently used to copy non-persistent values from the cached original into the working copy.
    There is also the ability to customize the clone/copy policy used by TopLink in creating the working copies in the UnitOfWork.
    http://download-west.oracle.com/otn_hosted_doc/toplink/1013/DP4/_html/descfg028.htm#sthref3950
    Doug

  • No records in delta queue for 0CRM_SALES_ACT_1 & 0CRM_COMPLAINTS_I

    Hi all,
    we are linking a SAP CRM system 4.0 (patch level 10) with BW 7.0. We have initialized the delta extraction and everything was fine. Data was extracted and we can see the delta queue in RSA7 but no records are added. Users are creating new activities and nothing appears in the delta queue. We have other extractors delta capable which are working fine.
    The main difference is that these two extractors have been enhanced using the Badi CRM_BWA_MFLOW. When we check the extractor using transaction RSA6, records include the information we add in the Badi.
    We think the problem is in CRM because, it does not collect any delta data (queue is always empty). BW is capable to extract when initilitialization. We have tried the early delta initialization and the simple delta initialization.
    Any help will be appreciated.
    Thank you in advance.
    As an extension: we can't see the extractors in the qRFC monitor (trans. SMQ1). We can see there the ones which are working...

    Hi again,
    we finally solved the problem. The thing was that no BDOCS with type BUS_TRANS_MSG were not being generated when creating or modifying CRM activities. Theses datasources need the BDOCS to work. Transaction SMW3_00 had the flag "Do Not Send" set. We unmarked it and everything seems to work now.

  • Using Business Transaction Events for Delta Queue

    I'm trying to implement the white paper on using business events to populate the delta queue.  The question I have is can I do this with the WRPL table?  What business event would this be?
    Thanks in advance,
    Mark

    Hi Amit,
    Thanks for your help.
    I did it, but I need to change data in t_bseg, and when the function ZMFFINFI_INTERFACE_00001030 returns to function OPEN_FI_PERFORM_00001030_E, the data from bseg is replaced for the original data and everything I did is replaced, as if I haven´t done anything.
    Do you know if there some other problem ?
    I looked for a sap note for the function OPEN_FI_PERFORM_00001030_E, but I didn´t find.
    best regards
    Lilian M.M.

  • Red Traffic Light for Datasources Delta Queues

    Hi all,
    Our R/3 source system is connected to our BW system.
    Between the two systems we operated standard logistics datasources delta queues, by filling the setup tables and performing an initial update.
    The datasources delta queues were created and used over a month (according to the RSA7 they all marked with green traffic light).
    Now, we copied the R/3 source system to a new one.
    After doing so, all the delta queues traffic light turned to be red.
    Does anyone can provide a technical explanation/reason to this problem?
    Also, is there something we could do to "save" this delta queue, without needed to delete it and create it all over again?
    Thanks ahead,
    Shani Bashkin

    Hi Eddo,
    Thanks for your help.
    Yes, I'm using the same system name and system id. The new copied system has the same name and id like the productive system.
    Also, it seems like the RFC connection to the BW is lost.
    The question is why?
    Thanks,
    Shani Bashkin

  • How to flush Delta queue for future SAP upgrades/support pack !

    Guys,
    I'm making documentation regards to " How to flush Delta Queues" in case SAP wanted to upgrade the system or any support pack. Please anyone let me know the effective way to flush out the delta queue in step by step methods. I really appreciate your help.

    1.  Run V3 for associated application(s), this will load any potential delta data to the delta queues.
    2.  Run the delta load for each datasource twice.  The second load will clear the delta repeat data so that there should not be any more data in the delta queues defined with the format of the current datasources.
    Does this help?

  • Filtering Setup-Table and same filtering for Delta-Queue needed

    Dear All,
    I'm looking for the best solution to do the filtering for the delta-queue.
    In program RMCVNEUA I'm filtering (excluding specific SalesOrg) data for the setup-table creation. I'm loading these data to the BW system.
    BUT now my issue is, that with the delta-queue I'm getting also data for the SalesOrg I have excluded in the setup-table, as I have no filter for the delta-queue.
    My Question: Where/How to filter by the same criteria the entries for the delta-queue?
    Thanks for your support,
    Peggy
    some more details: Application 11; Queue-Name MCEX11; using 2LIS_11_VAHDR, 2LIS_11_VASTH, 2LIS_11_VAITM, 2LIS_11_V_SSL

    Dear Arvind,
    if there is no way in R/3 the solution must be in BW, but how exactly should that look like in the best/smartest way?
    Let us look in detail at an Example:
    DSO 0SD_O03 is getting data from 2LIS_11_VAHDR and 2LIS_11_VASTH.
    1) For VAHDR I have the chance to delete not needed VKORG already in the InfoPackage, or load first to PSA and than filter in DTP or delete in Startroutine in Transformation.
    2) BUT for VASTH, which has no VKORG information at all, I'm only able to delete the Dataset after it's loaded/activated in the DSO, as the rubbish-Dataset won't have any 0SALESORG. How to do that?
    Thx,
    Peggy

Maybe you are looking for