1. Overview
The SAP Enqueue Server manages database object locks centrally to ensure data consistency in a multi-user environment.
Locks are stored in an in-memory lock table and normally cleared upon a clean system restart.
However, when a lock is handed over to an update work process via COMMIT WORK, it is marked with a backup flag and persisted in a backup file (enque/backup_file parameter).
This design ensures that:
-
If the system restarts before the update is completed, the lock is still in place to prevent duplicate or partial updates.
-
Update work processes can resume processing pending transactions after restart.
Key point: Locks that are not marked with the backup flag (dialog-only locks) are not persisted and are cleared immediately when the system restarts.
2. Key Components
| Enqueue Server Lock Table | Shared memory structure holding active locks; size defined by enque/table_size. |
| Backup File | Disk file storing locks handed to update work processes with backup flag set. Reloaded after restart. |
| VBHDR | DB table containing update request header information (user, transaction code, status, timestamp). |
| VBDATA | DB table containing payload data for the update. |
| VBMOD | DB table containing metadata for update function modules. |
3. Lock Lifecycle
-
No backup flag → Lock is cleared upon restart.
-
Backup flag set → Lock is written to the backup file and restored after restart.
4. How VBHDR and Backup File Are Updated
Process Flow:
-
User executes a transaction and issues
COMMIT WORK. -
SAP writes update request header to VBHDR, payload to VBDATA, and function module list to VBMOD.
-
Lock is stored in the in-memory lock table.
-
If the lock is passed to update (backup flag set), it is also saved to the backup file.
-
On restart, the enqueue server reloads these locks from the backup file.
5. Post-Restart Behavior in SM13
-
Enqueue server reloads persisted locks.
-
SM13 shows corresponding update requests:
-
INIT → Normally auto-processed if update WPs are active; becomes
AUTO(sys)when processing starts. -
AUTO(sys) → In-progress updates.
-
ERR → Failed updates; locks released immediately.
-
6. Reasons Updates May Not Auto-Process
-
Status is ERR before restart (requires manual intervention).
-
Missing or inconsistent business data.
-
Update work processes disabled or stopped.
-
Locks restored but with no matching process context to resume.
7. Reprocessing Locks That Reappear After Restart
-
SM12 → Identify lock details (transaction, user, object).
-
SM13 → Find corresponding update request.
-
If status is
INIT→ Attempt Repeat Update. -
If status is
ERR→ Fix the cause (ST22/SLG1) then reprocess. -
As last resort, delete the update request (after business approval) and remove the lock manually.
8. Extended Memory Impact
-
Extended memory shortages can indirectly cause work processes to fail, leaving pending update requests and thus persistent locks.
