Would you pl tell me the how can we differenciate the unsearilised V3 and queued delta and which one is more effective?
Anyway, you have to choose between direct, queued or unserialized delta...about which mechanism (V1, V2 or V3) these methods use, refer to
Here are few points about V1,V2 & V3 updates:
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.
don't forget to assign points if useful..
In this Method, extraction data is transfered directly from the doc postings is collected in an extraction Queue, from which a periodic collective is used to transfer the data into the BW delta queue.
Queued Delta: 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.
Unserialized V3 Updated
This method is almost exactly identical to the serialized update method. the only diff is that the order of doc data in the BW delta queue does not hav tobe same as the order in which it was posted.
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.
Hi Ketun ,
It depends on ur application which method u want to use.unserialized method is used Only if its irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence (serialization) in which the data was generated in R/3 . but normally in my applications queued delta method is used. u can find more information about these methods in weblog.
"queued delta" update method:
"unserialized V3 update" update method:
With this update mode, that we can consider as the serializers brother, the extraction data continues to be written to the update tables using a V3 update module and then is read and processed by a collective update run (through LBWE).
But, as the name of this method suggests, the V3 unserialized delta disowns the main characteristic of his brother: data is read in the update collective run without taking the sequence into account and then transferred to the BW delta queues.
Its pleonastic to say that all (performance) problems related to the serialized V3 update cant apply to the unserialized one !
However, already known V2 dependency keep on subsist.
When this method can be used ?
Only if its irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence (serialization) in which the data was generated in R/3 (thanks to a specific design of data targets in BW and/or because functional data flow doesnt require a correct temporal sequence).
plz assign points if u r satisfied by the reply.