Delta Initialization vs Delta Update

We're having some issues with performance when loading our GL cube. What I would like to do is perform many delta initializations, each delta inititialization containing one month/period.
My confusion is in the fact that the last time I attempted this, when I subsequently went to run my delta UPDATE the same selection criteria was automatically inserted into my delta update.
So for example my INIT may look like this;
REQUEST1: Selection = 001.2005
REQUEST2: Selection = 002.2005
etc........etc...
REQUEST12: Selection = 012.2005
Next the UPDATE info package seems to inherit the same criteria... doesn't this mean it will not update anything beyond that criteria??
I'm just wondering if it is possible to do an incremental initialization and still be able to enable delta updates for future periods?
Thanks!

Hi Patrick,
The delta update will load the data as per the selections made in the Init run. A delta requested after several initializations, contains the sum of all the successful initial selections as a selection condition. This selection condition can then no longer be changed for the delta.
Take a look here for more info:
http://help.sap.com/saphelp_nw04/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/content.htm
Hope this helps...

Similar Messages

How to catch Delta Initialization and Delta Update in a Function Module

Hi Experts:
I'm developing a FM to extract data from R3. I wonder if anybody knows how to catch when i'm making a delta initialization and a delta update in my FM, because i have different parameters and routines from each one.
Thanks in advanced.
Points for helpfull answers.

Hi,
Keep one dummy date field in the structure. Make this dummy date field as delta enabled field. When you do Init load this date field value will be blank and next time when you do load it will have the last upload (in this case init load) date. You have to write a code before open cursor as below:
      LOOP AT s_s_if-t_select INTO l_s_select.
                              WHERE fieldnm = '(dummy date field name)'.
         l_date = l_s_select-low.
      ENDLOOP.
l_date will have the last upload date. This you can use to select the delta records from the table or for the further processing.
If you want to check the value during Init or delta load, go to RSA3 and debug it(Don't use F - Full load. Use I or D in the update field).
Hope this helps.
PB

Delta Initialization for infocube 0FIAR_C03

Hi Frends
We r uploading data to infocube 0FIAR_o03 with infosource 0fi_ar_4.and subcequently to infocube 0fiar_c03. first time we r loading data with delta initialization then delta uploading.one typical problem we r facing here that.yesterday we have changed 3 records in our quality clint and delta loaded for same.the no of records transferd yesterday was zero.we have also checked same in transaction rsa7 there was no record with our data sorce.again today we have checked with transaction rsa7. the no of records was zero. but when we have loaded with delta update mode.there are 3 records in delta extraction(yesterday change records)
pl let me know some hints on this
Awaiting ur early reply/
Thanks & Rgds
Tukuna

Tukuna,
On which filed you have created Delta.
1. If delta field is Date (Record Create Date or change date), then use Upper Limit of 1 day.
This will load Delta in BW as of yesterday. Leave Lower limit blank.
2. If delta field is Time Stamp, then use Upper Limit of equal to 1800 Seconds (30 minutes).
This will load Delta in BW as of 30 minutes old. Leave Lower limit blank.
3. If delta field is a Numeric Pointer i.e. generated record # like in GLPCA table, then use Lower Limit. Use count 10-100. Leave upper limit blank. If value 10 is used then last 10 records will be loaded again.
Hope its help.
Thanks
Ramu

Early Delta Initialization option in Production system

Hi Experts,
I have seen some threads related to Early Delta initialization in this forum. I have a question regarding this option.
To minimize the downtime/block users in the R/3 production system during set up tables fillup I would like to use the Early delta option. Please give your suggestions on the following procedure:
For Sales Orders, billing and Deliveries
1. Initialize Early delta in the BI system.
2. Go and fill setup tables
3. Do a full load to BI
4. Run delta job in R/3 (LBWE)
5. Run delta job in BI Info package
Do we miss any documents in this process for e.g. during set up tables fill up changes to existing documents or newly created sales orders.
I feel we won't miss. All changes will be reflected in Delta queue. And even newly created orders also will be coming to delta queue.
Please let me know if I am wrong.
Thank you.

Need Clarification on this thread,
According to my understanding, during the filling of set up table if a user does any posting, then the data available in BW will be incorrect.
am i right?
In your sequence the 4th step
4. Run delta job in R/3 (LBWE), this means you are using queued or unseriallized v3 update.
Early delta iniliazation essentially of no advantage because, as conventional initialization procedures, you can readmit document
postings after successfully filling the setup tables.
can anybody clear my doubt. is it possible during setup table filling user can post a document.
I know the documents will be collected in the queue. But the data loaded to bw will be incorrect right?
Regards,
Anand.
Edited by: araj123 on May 26, 2010 11:41 AM

Extraction, Flat File, Generic Data Source, Delta Initialization

Extraction, Flat File, Generic Data Source, Delta Initialization
I have couple of questions regarding data extraction.
1.     If you have Data Source a Flat File e.g. Excel file I know that you have to create Data Source at BW side. How do you upload updates, by selecting Delta Update when executing next Data Load? Do you ever u201Cconvertu201D this Excel file into Application Tables to become SAP Source 
2.     Can you please give me example of situation where you had to create Generic Data Source? What is difference between Time Stamp, Calend. Day and Numeric Pointer. Which one is most common to select?
3.     I read somewhere that Generic Data Source does not have Setup Table. I thought that you have to have Setup Table in order to load transaction Data otherwise you will lock the Application Tables. Where am I going wrong im my thinking please?
4.     What are steps in terms of IP before, under and after Delta Initialization. I belive that you can do two ways:
Full Update - Initialize Delta Process (without Data Transfer) u2013 Delta Update or
Initialize Delta Process (with Data Transfer) u2013 Delta Update
Am I right? What is most common method and why?
5.     If you want to add a filed in Data Source after 6 month using it, you want to do it without re-init Delta Queue. You add field in RSA6, then provide info for ABAP to populate new filed (info u2013 name of Data Source, Extract Structure, field added, name of Application Table which contains the field). How does it work now as there is no SetUp table it has been deleted after Initialisation? How does Delta Queue know that it is going to receive data which has been expanded by one field or it may does not need to know at all?
THANKSSSSSSSSSs

Hi,
1. If you have Data Source a Flat File e.g. Excel file I know that you have to create Data Source at BW side. How do you upload updates, by selecting Delta Update when executing next Data Load? Do you ever u201Cconvertu201D this Excel file into Application Tables to become SAP Source
Once you create Datasource for A flat file extraction then it is file source system specific hence you cont change to Application table source Data source
In info package you can change the source as application server instead of desktop no need to change the DS
2. Can you please give me example of situation where you had to create Generic Data Source? What is difference between Time Stamp, Calend. Day and Numeric Pointer. Which one is most common to select?
When we don't find any standard extractor then we can go for Generic(if i want information sales along with finance information in a data source then generally we dont get standard one hence we can go for generic DS)
Check the below link for More about generic DS .
http://wiki.sdn.sap.com/wiki/display/BI/Generic+Extraction
for Delta capturing you can use
Timestamp(if the table has time stamp filed so it can stamp the last changed record in that table hence it is easy to get delta based on the time stamp)
Calday- (If the table doesn't have the Timestamp filed then search for Calday where you can stamp the delta based on the date when documents are changed )
Numericpointer : If the table doesn't above both then we go for this option where you can the numeric value change stamp )
3. I read somewhere that Generic Data Source does not have Setup Table. I thought that you have to have Setup Table in order to load transaction Data otherwise you will lock the Application Tables. Where am I going wrong im my thinking please?
Generic datasource nothing but we extracting data directly from the database table without any interface between the application/systems
4. What are steps in terms of IP before, under and after Delta Initialization. I belive that you can do two ways:
Full Update - Initialize Delta Process (without Data Transfer) u2013 Delta Update or
Initialize Delta Process (with Data Transfer) u2013 Delta Update
Am I right? What is most common method and why?
Correct
5. If you want to add a filed in Data Source after 6 month using it, you want to do it without re-init Delta Queue. You add field in RSA6, then provide info for ABAP to populate new filed (info u2013 name of Data Source, Extract Structure, field added, name of Application Table which contains the field). How does it work now as there is no SetUp table it has been deleted after Initialisation? How does Delta Queue know that it is going to receive data which has been expanded by one field or it may does not need to know at all?
Once you add the new field to structure(DS) you will get the data as on date onwards not historical data hence what is the concept of setup table ( delta records come from the Delta Que not from the setup table )
If you want histaric data to new field then you need to setp table deletion ...etc...
Hope it is clear..
Regards,
Satya

Delete the initialization of delta on open hub table

HI Gurus
I have loaded data from cube to open hub table using DTP with full update, later on i have loaded the data using a DTP with delta update. Now i am thinking that delta has been initialized on the open hub table, so now want to delete the initialization of delta on the open hub table. It would be great if some one could send me the response.
Thanks
Rohit

Hi Sam,
If I understand you correctly,
You have removed your Initialisation by going InfoPackage --> Scheduler --> Initialization Options for Source --> Removed the Request
Then you did Init without Data Transfer
Then you have the option from init withoout Data transfer to Delta in InfoPackage and Loaded the Data.
Check in the Process Chain the InfoPackage you have mentioned in the selections may pointing towards Init load instead of Delta.
Sudhakar.

How to Use Early Delta Initialization

Hi BW Experts,
We are in BI 7.0 Version. Only for Reporting we are using BI 7.0. For modeling, still we are using BW 3.1C only.
We want to use Early Delta Initialization. But this is in Disable Mode in our system
I am getting the following Messages:
"Extractors supporting early delta initialization are not available before plug-in (-A) 2002.1"
"You cannot execute an initialization simulation together with an early delta"
Please can anyone give me the suggestion.
Regards
Anjali

Hi,
you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the updating of data in the source system. You can only execute an early delta initialization if the DataSource extractor called in the source system with this data request supports this..Use the Early Delta Initialization indicator in the InfoPackage if you want to avoid a period when no updates can be made (no document processing and update) in the source system while the delta process is being initialized. In some applications (such as LO Cockpit), an update-free period is nevertheless needed to fill the setup tables. In such cases, the update-free time is merely reduced. If you want to carry out early delta initialization, the update in the source system can continue and the data can be written to the delta queue while the initialization requests are being processed. Note: DataSources that support early delta initialization are available as of the release Plug-In 2002.1. The field ZDD_ABLE (characteristic value = X) for table RSOLTPSOURCE (in BW) or ROOSOURCE (in the source system) indicates whether a DataSource can support early delta initialization.Not always on our systems an important downtime is possible in the initialization process during the reconstruction and the delta init request (just thinking when you need to ask a billing stop period...a real nightmare in some company !)
For this reason, as of PI 2002.1 and BW Release 3.0B, you can use the early delta initialization to perform the initialization for selected datasources (just checking in infopackage update mode tab if this function is available): in this way you can readmit document postings in the OLTP system as early as possible during the initialization procedure..In fact, if an early delta initialization infopackage was started in BW, data may be written immediately to the delta queue.
But, if you are working with the queued delta method, using early delta initialization function doesnt make sense: as described before, its the same method definition that permits to reduce downtime phase.
But leaving aside that, dont forget that, regardless of the update method selected, its ALWAYS necessary to stop any document postings (for the relevant application) during setup tables recompilation run

When are init entries done in source system?And early delta initialization?

Hi Friends,
Q1) When are the init entries done in source system?
If INIT entries are done when I run INIT that means:
If my setup job finishes at 6AM and I run the INIT at 1 PM will I loose all data between 6AM and 1PM?
If INIT entries are done when I run setup table i.e. when setup table load finish then
If my setup job finishes at 6AM and I run the INIT at 1 PM...it will load data till 6AM
and after that data would bere there in Delta queue. So, this is ok...as no loss of data.
Q2) I have read on help.sap that "With early delta initialization, you have the option of writing the data into the
delta queue or into the delta tables for the application during the initialization request in the source
system. This means that you are able to execute the initialization of the delta process (the init request),
without having to stop the updating of data in the source system."
Does this mean when I run INIT at 1PM, no V1 updates will happen for that DS in Source System?
If Yes, that means I should always (when users are online) run INIT with early delta initialization
during times when users would be online?
Thanks!

Hello,
You will find the answers to the questions that you ask and the correct procedure to follow in the SAP note 602260.
Best Regards,
Des

Early delta initialization

Hello Gurus,
What are the scenarios we use Early Delta Init.
Is it available for Logistics datasources.
Full points to right answers.
Thanks in advance.

hi BW,
check this
http://help.sap.com/saphelp_nw2004s/helpdata/en/80/1a65dce07211d2acb80000e829fbfe/frameset.htm
Early Delta Initialization
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the updating of data in the source system. You can only execute an early delta initialization if the DataSource extractor called in the source system with this data request supports this.
Extractors that support early delta initialization were delivered with Plug-Ins as of Plug-In (-A) 2002.1.
You cannot run an initialization simulation together with an early delta initialization.
yes, it's available for logistics - oss note 505700, you can cross check the infopackage.
hope this helps.
505700-LBWE: New update methods as of PI 2002.1
g) Early delta initialization in the logistics extraction:
As of PI 2002.1 and BW Release 3.0B, you can use the early delta initialization to perform the delta initialization for selected DataSources.
Only the DataSources of applications 11, 12 and 13 support this procedure in the logistics extraction for PI 2002.1.
The early delta initialization is used to admit document postings in the OLTP system as early as possible during the initialization procedure. If an early delta initialization InfoPackage was started in BW, data may be written immediately to the delta queue of the central delta management.
When you use the "direct delta" update method in the logistics extraction, you do not have to wait for the successful conclusion of all delta Init requests in order to readmit document postings in the OLTP if you are using an early delta initialization.
When you use the "queued delta" update method, early delta initialization is essentially of no advantage because here, as with conventional initialization procedures, you can readmit document postings after successfully filling the setup tables, provided that you ensure that no data is transferred from the extraction queue to the delta queue, that is, an update collective run is not triggered until all of the delta init requests have been successfully posted.
Early Delta Initialization

EARLY DELTA INITIALIZATION IN LO COCKPIT

HI EVERYBODY,
SORRY FOR ASKING A SILLY QUESTION --BUT I REALLY NEED AN EXPLANAITION
WHAT IS EARLY DELTA INITIALIZATION????(can we select this method the same way we do for Delta init)
I KNOW THAT BEFORE DOING DELTA WE WILL DO DELTA INITIALIZATION.
I HAVE READ A WEBLOG OF ROBERTO IT WAS WONDERFUL BUT I GOT STUCK WITH THIS EARLY DELTA INITIALIZATION. AND ABOUT DOCUMENT POSTINGS.
DOES THIS MEAN THAT BEFORE GOING FOR DELTA INITIALIZATION (i mean before filling setup tables ) DO WE NEED TO SHUT DOWN THE INSTANCE ON OUR OLTP --so no transaction data will be updated to the extract structure.
WHAT IS FREE DOCUMENTS POSTING PHASE
THANKS AND REGARDS
NEELKAMAL
Message was edited by: neelkamal moganti

You can find the option for Early Delta Init in the InfoPackage on the Update tab. Using this option, the source system update can continue and data can be written to the delta queue while the initialization request is being processed.
Early Delta Intialiation is the process in which we run the init of delta and load the delta queue in parallel.
Generally when we do Initialization we need to stop transactions in R/3 system till the initialization is completed if we do Early delta initialization we don't have to stop posting of transactions in R/3 even when we are doing initialization. Please see this for more explanation
Early Delta Initialization
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the posting of data in the source system. The option of executing an early delta initialization is only available if the Data Source extractor called in the source system with this data request supports this.
Assign points if it helps...
regards,
ashok

Need for locking system for delta initialization (BW-R3-LO)

Hello all,
Could someone please help me with the following,
Please be kind, don't get impatient for the lengthy post
1. Do we need to lock the system (or posting-free the system) to do early delta initialization or not? If yes, please explain me how that work?
2. Someone somewhere mentioned that early delta initialization is not preferable compared to normal delta initialization, even though early delta initialization is advantageous. Why is that so?
3. Imagine, while scheduling Queued Delta Init or un-serialized V3 delta Init, if I choose certain end date and time (say, 10pm, 12-31-2007) for the records, then all the records till that point would be loaded to setup tables and all the records after that point of time will be moved to extraction queue or update tables. My question is, if this is true why would we ever need to lock the system during setup tables filling?
    If you say the records after that particular time and date (10pm, 12-31-2007) will not be collected in extraction queue and update tables, why don't we do the following
             a). say, I do full load with end date and time (10pm 12-31-2007)
             b). Next, I do delta init with start date and time (10pm 12-31-2007) (this time I lock the postings)
         If we do this way, we can actually reduce the down time of the system. Is my conclusion right?
         If you say it's not practicable as some transactions' saving time differs from time stamp and some transactions' delta is even measured by pointer.......if this is the case we can use Delta offset. What do you say about this?
4. How this scenario differs to early delta initialization?
Your responses would be greatly appreciated
Thank you

Hello,
1
>
curious maven wrote:
> Do we need to lock the system (or posting-free the system) to do early delta initialization or not? If yes, please explain me how that work?
No,you don't need to lock the Source System which is the advantage of Early Delta Init.
With early delta initialization, you have the option of writing the data into the delta queue or into the delta tables for the application during the initialization request in the source system. This means that you are able to execute the initialization of the delta process (the init request), without having to stop the posting of data in the source system. The option of executing an early delta initialization is only available if the DataSource extractor called in the source system with this data request supports this.
[Business Information Warehouse 3.0 Overview Presentation|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/9a0e9990-0201-0010-629b-dc2735cb9c81]
2
>
curious maven wrote:
> 2. Someone somewhere mentioned that early delta initialization is not preferable compared to normal delta initialization, even though early delta initialization is advantageous. Why is that so?
Early delta is not supported by all the extractors. See Lo Extraction
3
>
curious maven wrote:
Imagine, while scheduling Queued Delta Init or un-serialized V3 delta Init, if I choose certain end date and time (say, 10pm, 12-31-2007) for the records, then all the records till that point would be loaded to setup tables and all the records after that point of time will be moved to extraction queue or update tables. My question is, if this is true why would we ever need to lock the system during setup tables filling?
>
>     If you say the records after that particular time and date (10pm, 12-31-2007) will not be collected in extraction queue and update tables, why don't we do the following
>
>              a). say, I do full load with end date and time (10pm 12-31-2007)
>              b). Next, I do delta init with start date and time (10pm 12-31-2007) (this time I lock the postings)
>
>          If we do this way, we can actually reduce the down time of the system. Is my conclusion right?
>
>          If you say it's not practicable as some transactions' saving time differs from time stamp and some transactions' delta is even measured by pointer.......if this is the case we can use Delta offset. What do you say about this?
This is applicable to Generic Delta where you can set the Safety Interval (Upper Limit and lower Limit) for the extractor based on ALE Pointer, or Time Stamp or Calendar day.
If you excute a extractor with early delta init, during the setup table fill, the delta records will be directly written to the delta queue. The delta management handles these functionality.
[How to Create Generic Delta|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/84bf4d68-0601-0010-13b5-b062adbb3e33]
[SAP BI Generic Extraction Using a Function Module|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a0f46157-e1c4-2910-27aa-e3f4a9c8df33]
4
>
curious maven wrote:
How this scenario differs to early delta initialization?
If you do a Init without Early Delta init, then the user cannot post new documents and you have to either schedule in the weekend or request for a Source System downtime.
But if you use Early delta , then you don't need the source system down time and the user can post new records during the init, which will be written to the delta queue directly.
[How to Minimize Effects of Planned Downtime (NW7.0)|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/901c5703-f197-2910-e290-a2851d1bf3bb]
[How to Minimize Downtime for Delta Initialization (NW2004)|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5d51aa90-0201-0010-749e-d6b993c7a0d6]
Thanks
Chandran

Initialize the delta load

Hi BW Experts,
I have question...
1. There is a ODS01 which feeds many data targets.
2. We created a ODS02 which also will be loaded by this ODS01. The update type would be DELTA.
3. We created a INFOCUBE01 which will be loaded by the ODS02. The update method would be FULL UPDATE.
4. The first time (later on i didnt get this msg) when i went to the infosource for the 8ODS02 and tried to create a infopakge to load the full update of the INFOCUBE01, i got a msg that " THERE IS NO ACTIVE DELTA INITIALIZATION FOR THIS DATASOURCE".
The details of the msg is:
Procedure
You have to initialize the delta load for a DataSource before you are able to load the delta data from it.
If you want to load deltas only for the purposes of testing, or you do not require any initialization data (because you have already uploaded it using a full upload, for example) use an initialization simulation.
This way, only the init. entries you require are made in the control tables of the source system, and a 'dummy' entry appears in the Monitor, setting the load status to green.
No data is in fact loaded, however, and the initialization takes only a few seconds to complete.
Does this mean i have initialize the delta load in the ODS02 or the INFOCUBE01.
How do i do that ?
(I actually did few full loads then i was informed that it would be a delta load from the ODS01 to ODS02,
within the infopkg for ODS02, I selected the Delta update next time, and did start immdtly, then check the monitor, it displays no records)
I'm little confused with this initialization, and in what cases would i do it.
Would you please help...
Thank you,
Tia
Message was edited by: Tia Ismail

1. so, you are saying for the ODS02, do a full load first.
2. Then do a "Initialize delta process".
3. Then do a "delta process".
I had partially tried this, I did a full load first in one infopackage, then created another infopackage trying to do a "Initialize delta process". I get a msg as following:
Diagnosis
Deltas have already been loaded for the init. selection of request REQU_3ZEHH34LV68LVHAWT75TJVIF8. A second initialization is therefore not possible with these selection conditions.
Procedure
If you want to carry out a new initialization, you have to choose selections that do not overlap.
If you want to repeat the init. for the same selection, you have to delete the delta queue in the source system, and restart the delta process.
Choose the menu entry 'Init. Selections in the Source System' from the Scheduler.
Any thoughts...
Thank you,
Tia

"There is no active delta initialization for this IS/ QS/Data Source."

Hi Friends
I am getting this error message while running the infopackage.
" There is no active delta initialization for this IS/ QS/Data Source."
Start Infopackge zpak_xxxxxxx.
There are 2 infopackages aand one ODS Activation brefore this inpackage(it is being updated by that ODS).
Could you please help me in solving this issue.
Thanks.
B V

There is no active Init to ur DS is in place. And hence u need to take an Init.
Try to maintain different IP's one is for the Init and other one is for the Delta.... the one in the PC will be holds good for the Delta..
Try create an Init IP if its not there already and then proceed with the load... if there is no data in the target data target as of now.....
If u have data on the target but some one has deleted the Init flag then u need to check whether all the requests has got posted to the target data target or not.. if not u need to take care of the action accordinly with the initi-Withoutdata transfer and then proceed with the Deltas...
thanks
Hope this helps

Delta Initialization

When performing a delta initialization load on my COPA cube it seems that it runs all day and then dies in the middle of the night. However, if I enter a selection of 1 month and load 1 month at a time I can easily load the entire cube in a short amount of time. It doesn't make sense to me. Maybe there's an answer to that problem but my real question is this;
If I have many DELTA INITIALIZATIONS, each for a particular month/period, do you think I will then have any issues with my DELTA UPDATE loads that I will schedule for each night? Is it or is it NOT recommended to do my loads this way?
Thanks!

Hi Patrik,
You can very well do this. You can do multiple initialisations in your case, but only thing you need to take care of is the Selections used should be mutually exclusive, i.e. no overlapping selections are allowed among the inits. In your case, if you are going to use month as selection criteria, it shdn't be a problem.
Say, you are initilising the data for 2004, month by month(Jan, then Feb, then March and so on...). You delta after initialization will extract the data for complete 2004, ofcourse, only the changed records after that.
The Delta extraction after all intialization will consider all the conditions used in the initializations.
Thanks & regards,
Sree

ODS to ODS initialization and delta

Hi All BW Gurus,
We have recently started our BW implementation for COPA module and after successfully loading all the historical data, started running into issues with delta loads. Here is the scenario. R/3 --> PSA --> ODS1 --> ODS2/Cubes. Even though ODS1 and ODS2 are exactly the same, the reason for having ODS2 was to restrict drill down reporting to transaction level detail only for the last 6 months of data. The other advantage (I think) was to do a direct update instead of going through all the logic in the start routine again.
R/3 --> PSA --> ODS1 has been succesful so far with the full loads, initialization and delta updates. Full loads from ODS1 to ODS2 and Cubes have been successful too. Once we triggered initialization without data transfer from ODS1, it errors out with a message that ODS2 already has a full update and hence we cannot trigger an initialization. Researching OSS notes, found a note (689964) for the same issue but the solution was to change all full request loads to repair requests and then trigger the initialization. At the same time they mention that we could end up with other issues with this procedure where we might have duplicate records or even loose data if we ever have to run initialization again.
Any one face this issue? Solutions or work arounds?
Thank You.
Shri

Hi Sreedhar,
It would have been simplar to have followed the OSS 689964 by changing the full loads to repair requests. I ve done it in our production boxes and have not faced any issues yet. If an administrator takes good care of his dataloads then why would a question of duplicate records come in to picture.
But since data has been deleted from ODS2 already, you could follow the step1 and step2 as mentioned, it would work. If you see the Selection Criteria completely greyed out, then please right click on the Infopackage and choose the CHANGE option, this will enable the selection criteria for that Infopackage.
But if you ask my suggestion I would advice you to load the ODS2 using Full Loads from ODS1 and then use the OSS to change full to Repair Full, then run an Init Without Data transfer.
Hope this helps.
Thanks and Regards,
Praveen Mathew

Delta Initialization vs Delta Update

Similar Messages

Maybe you are looking for