Dear Experts in BW,
I hope to be enlightened on a few aspects of LO extraction mechanism. I have read the wonderful weblogs & found it excellent for understanding the subject.
However, I still have a couple of queries. Pls help with as many of them as u can. I am preparing for exams.
1. What is technically different about Update Tables (V3 Update) vs Delta Queue (Direct Delta) vs Extraction Queue (Queued Delta)? Are they simply normal tables? Why the different names? Sounds as if they are different technically.
2. Is V3 update a variant type of update process similar to V1 & V2, the ones u see in traditional R/3? V3 is new technology right? I have used R/3 for many years and never heard of V3 update until BW. But this V3 we are talking about is in R/3. So, I don't understand V3. Is it differentiated by the 'urgency' of the record being updated?
3. Why is it that V2 update is said to be problematic? How come V1 update is not as problematic (failed updates)?
4. For V3 Update using V3 Collective run, how is it different technically than an Extraction Collective run (Queued Delta)? Does it mean that Extraction collect uses V1?
5. How is reading Update Tables to a module (V3) different from reading Extraction Queue to an Application (Queued Delta)? Application also uses a module right? So, why the different names?
regards,
bworbust
Message was edited by: bworbust
1 Answer
-
Best Answer
Former MemberPosted on Feb 18, 2005 at 02:32 PMHi bworbust,
sorry if I'm concise, but now I really don't have a minute...
1.
Update tables contain the data to be changed until it is written to the database in a database LUW:
VBHDR - update headers
VBMOD - update modules
VBDATA - update data
VBERROR - error information
Delta queue is a data store in the source system into which data records are automatically written using an update process in the source system (such as with FI documents) or using extraction using a function module after a data request from the BW (such as LIS extraction prior to BW 2.0).
With a delta request, the data records are transferred from the Scheduler into BW.
The data is stored in compressed form in the delta queue. It can be requested from several BW systems. The delta queue is also repeat enabled. In other words, the delta queue stores data from the last extraction process.
With the queued delta, the extraction data is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.
For an overview of the structure of extraction queues use transaction LBWQ or via the "Log queue overview" function in LBWE.
2.
V3 collective update must be scheduled as a job (this is the main difference from V1 and V2 and this last one asynchronous as V3 but with no scheduling possibility)...however, please refer to the first weblog episode for pro and cons...
3.
V2 is problematic only for serialized V3 (see the second weblog episode)...
V1 is problematic too (but this is a general transaction related problem since no apllication tables would be updated in this case...)
4.
As in V3, you have to use the same collective run job, but data are stored in (and extracted from) different tables!
5.
Different delta places, different names, different involved extraction module ! see a picture in the third weblog episode
Bye,
Roberto
Add a comment
Add a comment