Skip to Content
author's profile photo Former Member
Former Member

Explain Direct Update

Hi All

Expain ..

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Posted on Jan 05, 2008 at 01:44 PM

    Hi ,

    Direct delta.

    When a Document is posted it first saved to the application table and also directly saved to the RSA7 (delta queue) from here it is being moved to BW.

    so u can understand that for Delta flow inR/3 Delta queue is the exit point.With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.

    Queued Delta

    When a document is posted it is saved to application table, and also saved to the Extraction Queue ( here is the different to direct delta) and you have to schedule a V3 job to move the data to the delta queue periodically and from their it is moved to BW.With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.

    *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.

    V1 - Synchronous update

    V2 - Asynchronous update

    V3 - Batch asynchronous update

    These are different work processes on the application server that takes the update LUW (which may have various DB manipulation SQLs) from the running program and execute it. These are separated to optimize transaction processing capabilities.

    Taking an example -

    If you create/change a purchase order (me21n/me22n), when you press 'SAVE' and see a success message (PO.... changed..), the update to underlying tables EKKO/EKPO has happened (before you saw the message). This update was executed in the V1 work process.

    There are some statistics collecting tables in the system which can capture data for reporting. For example, LIS table S012 stores purchasing data (it is the same data as EKKO/EKPO stored redundantly, but in a different structure to optimize reporting). Now, these tables are updated with the txn you just posted, in a V2 process. Depending on system load, this may happen a few seconds later (after you saw the success message). You can see V1/V2/V3 queues in SM12 or SM13.

    V3 is specifically for BW extraction. The update LUW for these is sent to V3 but is not executed immediately. You have to schedule a job (eg in LBWE definitions) to process these. This is again to optimize performance.

    V2 and V3 are separated from V1 as these are not as realtime critical (updating statistical data). If all these updates were put together in one LUW, system performance (concurrency, locking etc) would be impacted.

    Serialized V3 update is called after V2 has happened (this is how the code running these updates is written) so if you have both V2 and V3 updates from a txn, if V2 fails or is waiting, V3 will not happen yet.

    BTW, 'serialized' V3 is discontinued now, in later releases of PI you will have only unserialized V3. (This weblog is very good).


    Advantages of Queued delta over Direct Delta

    Queued Delta: Document posting -->Appl table --> Stat table ---> 10,000 LUW ---> LBWQ ---> RSA7 ---> BW delta run delta into BW .

    Here 10,000 Transaction is collected as 1 LUW and records moved to RSA7

    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:

    Document postings -> Appl table -> Stat tables --> RSA7 (Delta Queue ) ---> Using delta run delta come into BW .

    Here each transaction is 1 LUW and each LUW is moved to RSA7 .

    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.

    Pls refer to this ..








    *pls assign points,if links are useful*


    CSM Reddy

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.