V1(synchronous) denotes time-critical updates used for updating the actual transaction tables.
V2(asyncronious) denotes non-time-critical updates used for updating statistics tables related to the transaction tables.
For Example, after a sales order entry transaction is completed, the corresponding sales order tables would be updated in V1 mode, and the corresponding statistics tables would be updated in V2 mode.
V3(asyncronious with background schduling) update mode(Uses delta queue technology) is similar to the V2 update mode. The main differenceis that V2 updates are always triggered by applications, while V3 updates may be scheduled independently. Many extraction programs available for mySAP.com applications today use the delta queue technology to identify deltas.
Direct Delta (update mode A): 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.
• Each document posting is directly transferred into the BW delta queue
• Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
• Extraction is independent of V2 update
• Less monitoring overhead of update data or extraction queue
Cons:
• Not suitable for environments with high number of document changes
• Setup and delta initialization have to be executed successfully before document postings are resumed
• V1 is more heavily burdened
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.
• Extraction data is collected for the affected application in an extraction queue
• Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
• Extraction is independent of V2 update
• Suitable for environments with high number of document changes
• Writing to extraction queue is within V1-update: this ensures correct serialization
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.