Early Delta Initialization

[Former Member]

I want to restart and add fields to some of my LO extractors and to turn on some new ones.

The three of particular interest are 2LIS_11_VAHDR, 2LIS_11_VAITM & 2LIS_11_V_SSL.

I have been using 2LIS_11_VAITM for some years and the other two I am going to start using from scratch. 2LIS_11_VAITM I want to add new fields to so i'm planning on doing a new init and reloading.

In the past we have gone to great lengths to sort out filling the set up table and avoiding down time etc. Using mirror systems etc.

However I was looking into using the Early Delta Initialization option. All three of these datasources are capable of using this. My understanding of this is that I can run the fill set up table without needing any down time if I use this option.

The process roughly being:

Run an init without data on an IP with the Early Delta Init flag set.

Clear the set up tables and then fill the set up tables (on the live productive system e.g. NO DOWNTIME)

Run a full load IP.

Start the collection Job.

Run the Delta IP.

Question 1 - Is the above theory correct?

But I've also been reading that having these datasources set to Queued Delta would make the early delta process pointless but i'm not understanding why - I've read several discussions / blogs / notes (505700 / 753654 and more) on the matter but I'm still not understanding why this is the case.

Question 2 - Can I do early delta init with Queued delta and if not why not (in easy to understand words as Ive read a few things already and not fully understood!).

Thanks

Joel

[Former Member · Accepted solution]

Hi Joel,

I see the confusion here. First of all, with early delta initialization also you will be required to stop the posting during setup table fill up. Please check the last statements on Note 505700.

Now, why early delta initialization is useful in direct delta update and not in queued delta because of following reasons - Lets understand the methods first in conjunction with Early Delta initialization and delta methods.

1. Direct Delta: Here documents are posted directly from application to delta queues. This is why we need downtime from the start of initialization till the completion of initialization request when we need to load any datasource into BW system. 

There is a specific difference of delta pointer set in this method i.e. at what point the delta pointer is set in RSA7.

Lets say we have to fill setup table and then initialize the datasource.

Without 'Early Delta Initialization' - Following process will be followed.

Down time start -> Fill setup table -> Initialize Datasource -> Complete the initialization request -> Delta Pointer Set in delta queue -> downtime end. (notice no need of V3 update job)

We have long downtime because we should not have any delta data in delta queues before our initialization is complete so all postings must be stopped. Also delta queue must be green to capture delta records which does not happen until the end of successful delta Initialization.

With 'Early Delta Initialization' -

Down time start -> Fill setup table -> Initialize ('Early Delta') Datasource Start-> Delta Pointer Set in delta queue -> downtime end -> Complete the initialization request

Here in this case the system is released to users as soon as the Initialize datasource is started. And while the initialization is happening in BW system the records are getting stored in Delta Queue of source system.

So early delta initialization is actually mechanism where you will have delta queues/postings along with Initialization request running. It does not mean that you can initialize the datasource in sometime past. You will still need a downtime to fill setup tables in all cases.

2. Queued Delta: In this method you have a concept of extraction queues where the application data is stored temporarily until you run the collection jobs after which data is moved from extraction queue to delta queues.

Now in this method you just have to stop the collection jobs while you fill the setup tables. So here the datasource initialization will be something like this:

Stop V3 Jobs -> Down time start -> Fill setup table -> Initialize Datasource (without data transfer) -> Downtime End -> Start Initialization (repair full) and V3 Jobs. -> Let complete the initialize info pack -> Run normal delta.

So in this case early delta initialization does not really make a difference because you are able to post the data in source system while the initialization is running in BW system. And hence there is no advantage of it.

Now coming to your questions:

Question 1 - Is the above theory correct?

Run an init without data on an IP with the Early Delta Init flag set.

Clear the set up tables and then fill the set up tables (on the live productive system e.g. NO DOWNTIME)

Run a full load IP.

Start the collection Job.

Run the Delta IP.

Now here as you are talking about collection jobs so I am assuming that you have queued delta, then you don't need early delta initialization as it will not make a difference. You just have to follow procedure something like above in point 2. So you will still need a downtime. Sorry.

Question 2 - Can I do early delta init with Queued delta and if not why not (in easy to understand words as Ive read a few things already and not fully understood!).

You can do early delta initialization in Queued delta however it will not have any significance. For this please refer above explanation. Early Delta initialization is mainly for direct delta method and not benefit of queued delta.

Please let me know if there are any questions.

Thanks

Amit

[Former Member · Accepted solution]

The big problem then is that the jobs to fill set up tables takes many many hours. For example I have a number range filling on the QA system at the moment and so far it has taken 24 hours.

[Former Member · Accepted solution]

Yes, I understand but unfortunately you will need the downtime during setup table fill up. You will have to break the ranges into several pieces and then load in parallel.

You can refer to SAP note 753654 for the recommendations from SAP. You may also research a bit more on scn for others recommendations.

Thanks

Amit