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 muchHi,
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,
EnricYou 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
JonathanHi,
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 -
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 PMhi 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
RajHi 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 ALTILaurent,
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
RamanDear 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
IlonaHi,
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
-
I want to upgrade my 2007 Mac desktop to 10.5 Leopard. I am currently running on 10.4.11. When I put the leopard disk into the drive all it does is make a weird noise and then spits the disk right back out. It doesn't do this with any other discs, on
-
I can't buy any music because it tells me that my session has timed out!
When it comes to confirme=ing my details - it always tells me that my session has timed out even though I have gone through all the pages so quickly!!
-
Although photo appears beautiful on phone screen, when reviewed in gallery, half the picture has a large line going through it. Any ideas? I went to VZN and they replaced my first new phone 3 days ago for this same issue.
-
Error installing patch 9654983 on HPUX RAC 11.2
Hello, I'm doing a new installation of a *11.2.0.1 GRID* on a HPUX Itanium 11.31 but having the following error when aplying patch 9654983: Running make for target client_sharedlib Make failed to invoke "/usr/ccs/bin/make -f *ins_net_client.mk* clien
-
I'd like to update the ISO 4.2.1 on an old iPod Touch to ISO 7. Can't find "Software Update" option under General Setting. Where might I look for the option to slightly upgrade the ISO for this device?