Init+delta in BW, subsequent delta in BI - upgrade issue

We are upgrading to BI patch 16 from BW 3.5.
Our BW dataload flows are - R/3 extractor to ODS via infopackages (PSA and then data target option), then to the infocubes via infopackages (same option).
In BI, data come to PSA via infopackages, then to DSO via DTP. From DSO data go to the infocube using DTP (no PSA). For DTP we use 'Get data by Request' option and extraction mode is delta.
We already have deta loaded in the system in BW. Daily process chains load delta records. We would like to continue the process by doing just the delta load in BI (without deleting old records and doing a new init in BI).
What happened is, delta load to DSO went fine after the upgrade. However, when loading to the cube DTP started to bring back all old data to the cube (past init and delta records) duplicating data in the cube. After first run subsequent run to the cube goes fine, bringing just the delta records.
What set up are we missing for the infocube so that we can continue with delta loads in BI after upgrade from BW?

Delta Load to DSO must have been fine due to Overwriting updated option in the transformation which will not cause duplication of data.
However, executing the DTP to the Cube will fetch all data from the Source as the previous data was not loaded using the DTP.
To prevent this you should have a pseudo Delta DTP
Or
There is some new feature for DTP - something like " Donot fetch data set the delta pointer " - You may use that if available.
Remember to run the DTP " N " number of times if you have N number of requests in the source if you have checked the feature " Get data by Request " .
After all requests have been marked as fetched by the Delta DTP - Remove the filter.

Similar Messages

Does "Init without data transfer" creates delta queues?

Does "Init without data transfer" creates delta queues?

Hi,
Yes, Once initialization successful for particular source system, you can see entry at Delta Queue(RSA7).
Hope it Helps
Srini

Init Load,Historical Data Load & Delta Load with 'No Marker Update'

What is the difference b/w Compression in Inventroy cube while Init Load,Historical Data Load & Delta Load with 'No Marker Update'???
please help for this quesy..
Thanks
Gaurav

Hi Gaurav,
I believe you will find the answers here...
[http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/e0b8dfe6-fe1c-2a10-e8bd-c7acc921f366&overridelayout=true]
regards
Pavel

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

Is it mandatory to delte all the previous delta request.

Hi Gurus,
I got strucked up with the following issue. Please help
We have two infocubes called regional and global cubes.
We are loading data from regional infocube in to global info cube through delta update.
But the values did not tied up. so I ran the INIT and loaded the data succesfully. Now Is it mandatory to delte all the previous delta request which are already loaded in to the global infocube.

Hi,
You need to delete the data from cube and need to do init accrodingly load the data.
Thanks & Regards,
Ramnaresh.

Generic Deltas vs. LO Deltas

Dear All,
I am learner of SAP BI/BW I have one query mentioned below
1) I would like to know the difference between Generic Deltas vs. LO Deltas u2013 when we used to prefer both the Deltas.
2) When did you go for Function module and let me know the real time scenario which you faced.
Regards,
Divyesh

Hi..
1) I would like to know the difference between Generic Deltas vs. LO Deltas u2013 when we used to prefer both the Deltas.
Generaic datasource is something which you create when the standard ones doesn't fulfill your requirement.....
To make it delta enable you should select some delta specific field.......which will work as a timestamp.......which will record the changes based on which the new or changed records (delta records) will get fetched......
You have to do the init......and then you can execute the delta.......
Here you are directly fetching data from some Application table, view, Infoset........
Or if the logic is complex..........means you have fetch data from multiple table you can go for a Function Module......
Now...LO deltas are different........here Set up table is mandatory..........because it cannot access data directly from the Application table......
First, you have to fill the set up table..........then run the init.........once the init is done..........after that changes will automatically get recorded in the Delta queue........but here also once catch is there........
Different Update modes are there...........if it is a Queued delta or Unserialized V3 update ..........then the changes and new records will get stored in the Extraction Queue(LBWQ) and Update table (SM13) respectively............then you have to schedule the Collective run in LBWQ to pull the records in RSA7..............only in case of Direct delta changes will directly get recorded in RSA7........
2) When did you go for Function module and let me know the real time scenario which you faced.
if the logic is complex..........means you have fetch data from multiple table you can go for a Function Module......
For an example..........for FI logic is quite complicated.........business specific.......if you just create a view it will not fulfill the requirement.........you will have some business specific logic..........
So in this case you have to go for a FM......
Regards,
Debjani....

Generic delta has problem with delts pointer time stamp

Hi All,
We have generic delta data source with Delte pointer as Time stamp. We have not used any safety limits. We are loading the data to DSO and using Additive delta. But the problem is when delta flag is set, there might be a case where some records still being inserted to table with lower time stamp. These records are not being fetched in next delta.
We are planning to keep a safety upper limit of 5 min so that those records can not be missed. But we have a doubt as it is a Additive delta duplicate records will be loaded. If we make the delta to 'new status to changed records', it is going to work?? Any other things we have to check when we make this changes??
Thanks
Haaris

Hi
If you had selected additive delta then you can load data to DSo with addition mode only. No overwrite possible.
If you want to select new or changed status then you can load to DSO with overwrite mode only.
Additive or changed delta depends on your requirement because if you want to add data to the DSO then you can go ahead with additive otherwise you have to use DSO with overwrite mode only.
You can either give safety upper limit or lower limit but if you give safety lower limit then you can only load data to DSO with overwrite mode because there could be some duplicate records.
Hope it clarifies.
Regards
Sadeesh

Delta get once and delta request wise?

hi friends,
what scenerio we use delta get once and delta by request at DTP in BI 7.0? i studied many threads, i didnt understand , get delta once some snapshot like? what is the meaning?
can u give me any example , its great?
regards
ss

Indicator: Only Get Delta Once
Source requests of a DTP for which this indicator is set are only transferred once, even if the DTP request is deleted in the target.
Use
If this indicator is set for a delta DTP, a snapshot scenario is built.
A scenario of this type may be required if you always want an InfoProvider to contain the most up-to-date dataset for a query but the DataSource on which it is based cannot deliver a delta (new, changed or deleted data records) for technical reasons. For this type of DataSource, the current dataset for the required selection can only be transferred using a 'full update'.
In this case, a DataStore object cannot usually be used to determine the missing delta information (overwrite and creation of delta). If this is not logically possible because, for example, data is deleted in the source without delivering reverse records, you can set this indicator and perform a snapshot scenario. Only the most up-to-date request for the DataSource is retained in the InfoProvider. Earlier requests for the DataSource are deleted from the (target) InfoProvider before a new one is requested (this is done by a process in a process chain, for example). They are not transferred again during the DTP delta process. When the system determines the delta when a new DTP is generated, these earlier (source) requests are seen as 'already fetched'.
Setting this indicator ensures that the content of the InfoProvider is an exact representation of the source data.
Dependencies
Requests that need to be fetched appear with this indicator in the where-used list of the PSA request, even is they have been deleted. Instead of a traffic light you have a delete indicator.
Get Data by Request
This indicator belongs to a DTP that gets data from a DataSource or InfoPackage in delta mode.
Use
If you set this indicator, a DTP request only gets data from an individual request in the source.
This is necessary, for example, if the dataset in the source is too large to be transferred to the target in a single request.
Dependencies
If you set this indicator, note that there is a risk of a backlog: If the source receives new requests faster than the DTP can fetch them, the amount of source requests to be transferred will increase steadily.
Source : https://forums.sdn.sap.com/click.jspa?searchID=5462958&messageID=3895665
Re: Diff between Only Get Delts Once and Get Data by Request
Check this blog as well : /people/community.user/blog/2007/06/21/sap-netweaver-70-bi-data-transfer-process-with-147only-get-delta-once148

What is the difference between qued delta update and serialized delta upda

what is the difference between qued delta update and serialized delta update?

Hi Ks Reddy,
Queued Delta:
In case of Queued delta LUW's are posted to Extractor Queue (LBWQ), by scheduling the V3 job we move the documents from Extractor queue to Delta Queue(i.e. RSA7) and we extract the LUW's from Delta Queue to BW side by running Delta Loads. Generally we prefer Queued Delta as it maintain the Extractor Log which us to handle the LUW's which are missed.
Direct Delta:
In case of Direct Delta LUW's are directly posted to Delta Queue(i.e. RSA7) and we extract the LUW's from Delta Queue to BW side by running Delta Loads. If we use Direct Delta it degrades the OLTP system performance because when LUW's are directly posted to Delta Queue (RSA7) the application is kept waiting untill all the enhancement code is executed.
Non-serialized V3 Update:With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
https://websmp102.sap-ag.de/~sapdownload/011000358700007535452002E/HOWTOCREATEGENERICDELTA.PDF (need id)
http://help.sap.com/saphelp_bw33/helpdata/en/3f/548c9ec754ee4d90188a4f108e0121/frameset.htm
Business Intelligence Performance Tuning [original link is broken]
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
How to load data
/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
Delta Types and methods;&#57245;
Hope this helps.
****Assign Points if Helpful*****
Regards,
Ravikanth

How to reprocess delta records during subsequent update of data targets

Hi,
I have an ODS which sends in delta records to a cube above it. Now there is a data load, happening monthy from a flat file, which was successful upto the ODS, but failed in the cube due to one invalid record. How do I reprocess this data load after correction of the invalid records in the source flat file?
The method I currently follow is to delete the failed request from the cube and then do a selective delete of records from the ODS and then reload the last data after correction.
Is there a better way to just reprocess the last load from the flat file?
Thanks & regards,
Nikhil

Hi Bhanu,
Thanks for the response. I will explain a bit more in detail. Suppose there are 5 records coming in from the flat file - now 4 of those records are correct and one has invalid data.
All 5 records get loaded to the ODS successfully but in the cube we have a function module which works on the data and aborts the entire data package if it finds even one invalid record. So nothing gets loaded into the cube at all.
Now if we correct the one invalid record and then reload into the ODS - it will just send this corrected record over to the cube and we will miss out on the other 4 records which were originally correct since the ODS does not detect them as changed.
If we delete the request from the ODS (rather than doing the selective delete) then it disables the delta in the ODS asnd we have to reinitialise everything - which we cannot afford to do in a production environment.
Hope the problem is a bit more clear now.
I was looking for some way to just resend all the five records - with the one corrected record to the cube without going through this selective delete process sinc eits too cumbersome and we run the risk of messing up with actual data ina production environment.
Thanks for the help,
regards,
Nikhil

Problem with subsequent deltas after converting Full requests to Repair.

Hi All,
We are working on changing an existing system from loading from multiple extractors directly to a cube to loading each extractor to its own DSO and then combining the data in a 'consolidated' DSO and then on the the cube.
To avoid downtime in the production system when we do the cut-over we have decided to do full loads of historical data up to Sept 2007 and then do delta loading from then on.
So the steps so far have been:
1) Full load of data to low-level DSO's. to 09 2007.
2) Full load of data to 'consolidated' DSO.
3) Convert Full requests in consolidated DSO to Repair Full Requests (see SAP Note 689964).
4) Initialise Without Data Transfer to the 'consolidated' DSO.
5) Delta Initialise from 10 2007 from the source system to the low-level DSO's.
6) Delta from low-level DSO to consolidated DSO.
My problem is with step 6 - no records are loaded into the consolidated DSO after delta load of data to the low-level DSO - the load process runs correctly but tells me that there was no data available.
Can anybody see if there is a problem with my approach - I thought this was the correct way to convert from full loading to delta loading ?
A Merry Christmas and a Happy New Year to you all
Graham

Hi Siva,
Thanks for the reply.
I understand that there is only an active table with a write-optimised DSO - but delta processing should still be possible at the request level
(SAP Help on Write-Optimized DataStore Objects http://help.sap.com/saphelp_nw2004s/helpdata/en/b6/de1c42128a5733e10000000a155106/frameset.htm)
Since write-optimized DataStore objects do not have a change log, the system does not create delta (in the sense of a before image and an after image). When you update data into the connected InfoProviders, the system only updates the requests that have not yet been posted.
In my case the 'new' request loaded into the DSO have not been loaded into the connected InfoProvider, so it should be processed.
Regards
Graham

Deleted bad delta and former good deltas form data mart to targets(5)?

Hi experts,
My process chain failed in continues for 5 days due to DSO activation issue. On further analysis I found a bad request with status red on july 3rd and their is no psa to fix it.
I deleted the bad request that is loaded on july 3rd with status red and all the god requests with status green on july 4th,5th,6th,7th and 8th.
The data load is going from data mart to 5 different targets (3cubes and 2 DSO's) and i deleted the requests listed above with all the 5 targets.
Know When I try to run new delta it is saying that 'new delta is not possible and asking for the previous deltas'
What to do know? Should I delete the init and reinit with out data transfer and load my new delta? I am affraid that I may loose data if i do this.
Thanks in advance.
Sharat.

Murali,
I have the failed delta in the targets (3cubes and 2 ods). I deleted the bad delta and the former good ones after july 3rd from all the five targets by verifying the technical name of the requests in the targets.
How should I proceed know?
Can I do a full repair request and new delta? or delete the init and reinit without data transfer and do a full repair and a new delta?
Please let me know. Thank you for your help.
Sharat.

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

Direct Delta behaviour in a BI 7.0 Upgrade

Hi all,
We are in an BI Upgrade process and a doubt raises regarding DIRECT delta.
Scenario:
The BW 3.1 will upgrade to BI 7.0 but the R/3 4.7 will remain the same.
There are some r/3 logistics extractors with DIRECT delta enabled.
Considering the Upgrade best practices is recommended to stop the V3 process in r/3 side, but the Direct Delta has no V3 process, so, which are the reccomendations for upgrade process considering DIRECT-DELTA ?
Can R/3 Direct-delta remain active during the BI Upgrade or should we stop the current delta and re-initialize 'without any data' after upgrade ?
Best Regards,
Mauro.

Kedar,
Most of the cases, the BI Upgrade process takes from 2 to 4 days, so is very difficult to keep the productive r/3 system sttoped for the logistic processes.
Our plan is :
     1) block the users in r/3 side until the delta queue has been emptied.
     2) load from r/3 to BW all Delta data from delta queue.
     3) make sure all delta load were made and the QM status are green in the BW side.
     4) unblock the users in r/3 side after the step 3. (Delta queue is free to new postings)
     5) initialize the PREPARE phase for BI migration.
     6) Execute the Upgrade
     7) Restablish the r/3 source system
     8) Execute the delta loads from r/3 (to obtain the delta data since step 4)
Do you think that will it work ?
Regards,
Mauro.

Delta not generated in case of Actual Goods Issue date change in R3

Hi Gurus
In our implementation in BI Production server we are using 2LIS_12_VCHDR and 2LIS_12_VCITM
extractors where in R3 Deliveries are created first and then the PGI is done. While in BI Extractions As the data comes first time without any issue but when the PGI is done the PGI date Tech Name (WADAT_IST) gets updated in the R3 system but in RSA 7 too this delta is not getting generated. can any one tell the probable reason.
We are stuck there Early help needed.
Thanks
Shivani

Hi Shivani,
did you manage to solve your problem?
We are facing a similar issue:
- We also have both datasources active: 2LIS_12_VCITM and 2LIS_12_VCHDR
- In R/3 the following steps happened: A delivery was created and the record has issued to BW --> In PSA a request with status of good issue movement = A (correct!).
- Afterwards in R/3 the delivery has been picked and then, after 1 second, issued.
- This time the requests on the two datasource look different: in 2LIS_12_VCITM it seems like the good issue delta comes before the picking delta, so the result is that the delivery is read as still open (status of good issue movement = A Not correct!). In 2LIS_12_VCHDR, instead, is all correct: the last record in PSA refers to the good issue delta.
Change documents order in R/3 is correct, but it is not the same as the sequence in PSA of 2LIS_12_VCITM.
Can anyone help me?
Thanks in advance
Roberta

Init+delta in BW, subsequent delta in BI - upgrade issue

Similar Messages

Maybe you are looking for