Basis Errors and Solutions

Symptom

The update tables VBMOD and VBDATA contain entries for which there is no entry with the same VBKEY in the update table VBHDR. Below, such records are called orphans.
Data is missing in the application tables, but no update terminations have yet occurred.
Other terms

VBMOD, VBDATA, update
Reason and Prerequisites

VBMOD, VBDATA, update
1. Due to a kernel error, the VBKEY changes in a SAP-LUW. This may result in inconsistent entries in the application table because subsequently, the system only performs a part of the update request.2. An error occurs in the Oracle database (see Note 1107700).3. Due to an application that was programmed incorrectly, the system leaves the current callstack without ‘COMMIT WORK’ or ‘ROLLBACK WORK’. An update request that is in the process of being created is not completed but not deleted either.Solution

Reasons 1. and 2. are critical because they may cause inconsistencies. Therefore, you must use a kernel with at least patch level
4.6D: 2335
6.40: 194
7.00: 145
7.10: 91
These kernel patch levels provide a correction for the first reason.
For an Oracle database (second reason), you must also implement Note 1107700.
The third reason does not cause any inconsistencies. This reason is eliminated as of the kernel patch levels
4.6D: 2384
6.40: 224
7.00: 154
7.10: 98
We recommend that you use at least these kernel patch levels, as the system cannot differentiate between orphans that cause inconsistencies and orphans that do not cause inconsistencies.
Using the report Z_HANDLE_ORPHANS that is attached to Note 1280546, you can check whether there are entries in the tables VBMOD and VBDATA for which no entry with the same VBKEY exists in the table VBHDR.
Import the report into the affected system. The report should be scheduled in the background. In Unix systems, you can determine the point of time at which the orphan was created from the VBKEY value. This requires a runtime of only a few minutes. In a Windows system, you cannot determine the point of time at which the orphan was created from the VBKEY value. Here, the report has a runtime of approximately one day because it must be ensured that update requests that are in the process of being created are not evaluated as orphans. The output of the report informs you whether orphans exist in the system and which function modules are affected.

Display in transaction SM13:

In SM13, you can find the orphaned update records created in this way under the date 22.01.2222. (alternatively, you can select according to user OR* [2 letters only] in SM13). There, you find records that either begin with ORP* or with ORU*.
ORP_*: records that contain the function module that was found most often.
ORU_*: all other records.
For both users, the asterisk contains the date (YYMMDD) at which the function module was created originally. Example ORU_080524: Year 2008 (two digits only), month: May, day: 24.
If the report finds a high number of orphans, the third reason is likely to be the reason.

Function modules and procedures that usually occur:

ADRESSE_WRITE_DOCUMENT
NRINTERVAL_WRITE_DOCUMENT
generally