Update Processing

What does rdisp/vbdelete control, what's the default, and how do you disable it?

Which four database tables hold the data behind the update mechanism?

Which report reorganizes update requests by deleting incomplete ones?

What's the difference between V1 and V2 updates in priority and rollback behavior?

How do you split V1 and V2 processing into separate work processes, and what's the system minimum?

What defines a logical unit of work (LUW), and how does it end?

Why are multi-step updates saved up and executed asynchronously instead of being written immediately?

What update methods exist, and who decides which one is used?

What is an immediate (local) update, and at what point can it no longer be reversed?

Why can synchronous updates slow processing, especially on remote application servers?

How are V1 update modules processed relative to the transaction's locks?

How does V2 update processing differ from V1 in locking and LUW structure?

Why won't V3 (collective run) updates process on their own, and where do they appear in SM13?

What's the rough starting guideline for the number of update processes relative to dialog processes?

What does rdisp/vb_delete_after_execution control, and what do values 1 and 2 do?

What does rdisp/vb_dispatching do, and what goes wrong if you set it to 0?

A user reports their posting failed — which transaction analyzes canceled update requests, and what can you do there?

When an update is canceled, which other log should you analyze, and why?

Where do you monitor update processing and activate or deactivate it, and what's the caveat?