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

Question

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

Answer 1

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