Failed to clean up BI delta queue before applying enhp1

Experts: Happy Holiday!
During applying enhp1 on BI7.0, we get the error that BW delta queue was not clean up before starting enhp1:
1) I remember I did do the clean up per the guide, why it complains? Should I do it in certain way?
2) how to fix it at this stage?
Thanks a lot!

The XXXX_XXXX is the data source for which the data belongs.  Chances are that this is data in the delta queue (RSA7) or "Delta Repeat" data (ie. delta data from the last extract).  Running the delta extract for the datasource twice should remove this.  If not, check the date of the data in the Queue.  If it is old and you are sure you have extracted all your data, then have your Basis Team delete this queue in SMQ1, you will not lose any data.
How to prevent any new data from entering the queues?  Make sure you run your V3 collection jobs and delta extracts after all user processing has been finished (ie. just before you lock the system prior to installing the upgrade).  Also, make sure all V3 collection jobs are not scheduled.
Tip:  After the upgrade, replicate your data sources and try the delta extracts manually to insure they work.  Do not schedule the V3 collection jobs until you are sure all your delta extracts work.  If there is an error, you can fix without losing any data.
The only risk is to datasources where the upgrade changes the structure of the datasource (ie. add/remove fields).  If you have customized the datasource by adding an Append Structure, then the upgrade will take care of this.  If the datasources do not change, the then format of the data will remain the same and you will have no issues.  Your Basis/Upgrade Team should be able to determine which datasource structures have been changed so that you are aware of potential risks.
Hope this helps.

Similar Messages

  • Emptying Delta queues before filling a setup table

    How do I empty the delta queues?  I want to carry out this task just prior to filling a setup table.  Thanks

    Hi Sekhar,
    Thanks for that, I was on a flight anyway, just got home.  I was thinking on the plane about the previous point that you mentioned wrt the collection run.  I think I understand the point that you were trying to make is this a correct understanding
    1) System is locked
    2) Do a collection run - the reason for this is that there may be postings which have not been placed on the RSA7 queue since the last collection run
    3) Do Delta load twice
    Does that make sense.  The points that you have raised otherwise, I will post a question otherwise on the steps I will look to take just to get confirmation I am not missing anything

  • Question about Note 886102 - Empty the delta queue of the connected SAP source systems

    Dear expert
    I'm doing the system refresh from ECC PRD to QAS using the hot backup of PRD
    Before i start the database restore i was told to do the following step since this ECC has connection with one BW system
    -----------------------Step -----------------------------
    2.17 SAP note 886102 scenario C3
    Empty the delta queue for all of the connected BW systems.
    Execute all delta info packages two times on BW side, to clean up the delta queue in the source system. This is needed, because BDLS cannot rename the still available LUW-s in the qRFC queue.
    ----------------------Step-----------------------
    But unfortunately i missed to execute this step
    And the Q11 is now retoreing the backup of the database
    My quesion
    1. what will be bad consequence due to not execute this step? any way to makeup this error?
    Best regards,

    Hi Kate,
    The probably issue which I could forsee is data getting wrongly updated into production if RFC connection from ECC to BW is not stopped.
    Solution here could be to disable or deletethe RFC connections between ECC and BW before starting the SAP system at database level.
    delete from sapr3.rfcdes where rfcdest = '<name>';
    Once the system is up and running you can recreate them if required.
    Also before starting SAP set the number of batch processes to 0 on the profile at OS level so that any released jobs don't start as soon as SAP is up.
    Once the SAP system is up execute BDLS and change the logical system name.
    Hope this helps.
    Regards,
    Deepak Kori

  • Impact of database upgrade in Bw delta queue

    Hi Gurus,
    We are going to upgrade the R/3 oracle database. I suppose that it have an impact in the BW delta queue, and that before the upgrade the logistics queues should be uploaded to BW.
    I'm right? exits some note or some checklist about wihch activities should be performed in BW due to the database upgrade?
    Thanks in advance for your help.

    Hi,
    This speaks about support pack upgrade. But i think this also applies for DB upgrade too.
    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
    thanks,
    JituK

  • R/3 Delta queue during 3.5 upgrade

    Greetings Experts,
    We're upgrading from BW 3.1 to 3.5, and the documentation calls for clearing the R/3 delta queue before the upgrade.  My first question is...how do I do this?  If I run all of our delta loads to clear the queue, they will start filling up again almost immediately.  Do I have to cancel all my delta loads, then reinitialize after the upgrade?
    Also, should I time clearing the delta queue with the BW 3.5 upgrade, or should I time it with the upgrade to the PI 2004 in the R/3 system?
    Thank you very much

    Hi,
    I am still in doubt if it is necessary to stop the productive work in the R3 system during the upgrade or if it is enough to stop the collector jobs (RMBWV3*) and empty the delta queues?
    If the R3 system would be up then the MCEX queues would be filled during the upgrade. So there would be entries in LBWQ but no entries in RSA7.
    Has onyone left the R3 system in production mode during the upgrade?
    Thanks,
    Timo

  • R/3 Delta queues in support package upgrade

    Hi gurus,
    Our team needs to apply a support package upgrade to our BI 7.0 (without an upgrade in R/3 source system).
    Do I need to worry about SM13 and RSA7 in my source system R/3 or just my data marts inside 7.0?
    Or do I need to empty R/3 delta queues before BI upgrade to prevent data loss?
    Best regards,
    Enric

    You may wish to take a look at below for few insights -
    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
    https://forums.sdn.sap.com/click.jspa?searchID=10299818&messageID=3221895
    Hope it Helps
    Chetan
    @CP..

  • 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

  • Issue with Delta Queue

    Dear All,
    We have scheduled Delta Q on developement and it was working fine.
    But on Quality side all the jobs for Application 11 are failing while application 13 are running successfully.
    Please help on the same immediately.
    Regards,
    Sohil Shah.

    Hi Sohil,
    It seems that you have changed the structure of the datasource. When you change the structure of the datasource you have to make sure that there is no data in the delta queue or SMQ1 queue of the target system before you transport it.  Delete the data from the delta queue and SMQ1 queue and reintialise the datasource.
    Let me know if you have any doubt.
    Regards,
    Viren

  • ODS Delta Process, DataSource and Delta Queue

    Hi to all,
    loading data from a SAP source system into SAP BW 7.0 via generic 3.x datasource causes problems.
    Here is a short description:
    The data flow is from a source table using a generic extractor into a target ODS in full update mode.
    Update rules should move data from table structure into ODS structure in this way:
    Source table structure
    CustKey1     Key2     
    13386          C23     
    13386          B14     
    13387          A13
    13387          E25
    ODS structure
    CustKey1     col1     col2     
    13387          A13     E25     
    This works pretty well - as long as all records with the same CustKey1 are transfered in the same data package. Data Browser (SE16) shows the situation in ODS-"New data" view  (data is not activated):
    Request    Data_packet_number     Data_record_number      CustKey1
    112            000003                  1.061              0000013386
    112            000004                      1              0000013386
    112            000004                      2              0000013387
    There are two records for CustKey1 0000013386 with
    data record 1.061 in data packet 000003   and
    data record       1 in data packet 000004.
    The obove constellation is the cause for errors in the ODS Delta Queue and subsequent data processing.
    I think there may be one solution to solve the problem by changing the Delta Process of the Data Source.
    The properties are:
    - Record type: Full, delta, before, after images
    - Delta type: Delta from delta queue or from extractor
    - Serialization: No serialization, serialization of request, serialization of data packages
    But how can I change these settings? Transactions RSA2 RSO2 RSO6 RSO8 don't do this.
    What is the right delta process to use?
    I have tried changing the delta process generating several 3.x datasources with the following delta processes (see table RODELTAM)
    - " " (Full-upload)
    - AIE
    - ADD
    Unfortunately with no effect.
    Who can help?
    Regards
    Josef
    Edited by: Josef L. on Mar 20, 2009 7:44 PM

    hi venkat,
    whenever you load a delta from ods to cube , whatever the data changed in ods since last delta will be updated, hence from you case, both req1 and req2 will be loaded to cube.
    Assign Points if useful
    Ramesh

  • Delta package not fetching all records from Delta queue in r/3

    Hello,
    I have loaded Goods Movement Data using 2LIS_03_BF datasource into my BI system.
    The Delta has been initialized and everyday the delta is being moved from r/3.
    I observed that when I execute my delta package not all delta records are fetched into PSA from r/3.
    For Ex: Before starting my delta package I checked in SMQ1 of my R/3 system and see that there are around 1000 records.On executing the delta package I see that the record count is reduced from 1000 to 400 in SMQ1.On executing the delta package again I get the remaining 400 records into my PSA.
    Shouldn't the delta package get all records from the queue on single execution??
    Is there some setting to define the nr of records to be loaded?
    I'm confused with this behaviour.Please help me understand this behaviour.
    Thank You.

    Hello,
          First thing: the data is not transferred from the SMQ1 queue, rather the data is transfered to BW from the RSA7 Delta queue. You need to check the number of records present in the RSA7 queue.
    Since SMQ1 is involved, i think you are using the unserialized V3 update method. In this method, when data is first written to the application tables, it is first transferred to the SMQ1 update queue,then via a job to the LBWQ extractor queue and then to the RSA7 delta queue. So the number of entries that you see in the SMQ1 queue are not the number of entries that have to be transferred to BW but rather the records that are waiting to be transferred to the extractor queue in LBWQ. Similarly, in LBWQ, the number of entries displayed here are not the no of entries that are going to be transferred to BW, they are the no of entries that will be transferred to the delta queue RSA7 when the next v3 update job runs.
    If you want to check the number of records that will be transferred to BW, select the datasource in rsa7 and then click on the display data entries button.
    Hope this helps.
    Regards.

  • 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

  • BW Upgrade - Down time - Delta queue

    Hello Experts,
    We are in the process of upgrading the BW system from 3.1 to BI7 but not the R3.
    Do we need to drain the delta queue from R3 before the upgrade or we can only go ahead about the BW Delta queue only?
    As per the note: 506694, its talks about the BW alone when we are performing the BW upgrade but not R3.
    Also let me know whether we need to take R3 down time when we do the BW upgrade alone?
    Thanks
    Raman

    Dear Kedar,
    Can we perform the left out steps directly in production? As per my understanding there wont be any issues if we perform the left over steps in production.as this will checks for the consistency check alone.
    Interestingly I tried checkcing this program(RSUPGRCHECK).. for the infoobjects in my dev system. its trying to activate some of the infoobjects as well.
    It showed a message like this: Activate all Dictionary objects ( 1422 )
    I tried checking the number of objects in the system using RSDIOBJ.. where I can see that there are 2600 objects are in A version.!!
    Does this message tells that this program has activated this many number of the infoobjects out of 2600?  I tried this after the upgrade in the D.
    Can you please clarify me on this.?
    Final Question: How much period that we need to maintain the Down time in R3. Is it till the Upgrade starting from the PREPARE and till the end of the Post Upgrade activities and the Unicode? I will close this thread after this.
    Many thanks again..
    Raman
    Edited by: Raman R on Aug 28, 2008 3:16 PM

  • Logical System name in RSA7 Delta Queue wrong because of BW System Change

    Hello All,
    we changed our BW System landscape. Before we had one BW development system (System ID: DBW) and now we are using BW development system (System ID: EBW).
    Now we face the problem, that in our R/3 system in the delta queue the wrong / old development system is written (DBWCLNT100), but instead of this there should be EBWCLNT200.
    Has anyone of you got a clue where we can change this?
    BR
    Ilona

    Hi,
    hope you can do the client copy function to transfer the things from one client to other client no.
    before doing the operation. please read the oss note carefully
    Please refer to Note 552711 - FAQ: Client copy - subsequently See Note 557132 for further information.
    and also check these threads
    Remote Client copy error
    how to do remote client copy ?
    Regards
    Harikrishna N

  • 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

Maybe you are looking for