SAP LOAD_PROGRAM_TABLE_MISMATCH 处理记录

问题记录：

对VBAK做增强，传输请求到QAS后，导致LOAD_PROGRAM_TABLE_MISMATCH异常；

问题原因：

增强结构发生变化，但是存在系统缓存，因结构差异出现DUMP；

解决方案：

使用AL12重置语句缓冲区即可临时解决此次报错问题

AL12重置后即可。

彻底解决方案需要打系统补丁，详情参考NOTE：2559989 - [Best Practice] How to solve dump LOAD_PROGRAM_TABLE_MISMATCH - SAP ONE Support Launchpad

NOTE内容如下：

Symptom

Dump error LOAD_PROGRAM_TABLE_MISMATCH with Short Text "The runtime object of a database table has been changed".

Normally in the ST22 dump log, we can find similar descriptions like:

Database table "XXXX" was changed at program runtime. This can cause inconsistencies.

Database table "XXXX" has ABAP time stamp 20171028220859. Program "XXXX" uses the table

with ABAP time stamp 20170503172929. Internal mode was started at 20171107090746.

Environment

ABAP System

Reproducing the Issue

[Enter your Reproducing the Issue here...]

Cause

1)

In most cases, the root cause can be explained by SAP Note 1840131 and SAP Note 1871058.

2)

If the dump happens at UPDATE statement towards a projection view, the problem is caused by a kernel error documented in note 2815286

The issue could happen at program include "LV50UP01" program "SAPLV50U":

IF it_vbap_status IS NOT INITIAL.

>>>>> UPDATEv_vbap_status FROM TABLE it_vbap_status.

ENDIF.

3)

If the time stamp of the table differs from the time stamp that you find in transaction SE11 in the runtime object of the table, then the statement cache is out-of-date.

Resolution

Depending on the above causes, there are three possible solutions:

1.

Execute the program TOUCHTAB from SAP Note 162991 to regenerate the programs dependent on the structures in dumps.

Then reactivate the inconsistent tables.

[How to avoid it in the future?]

The corresponding logic has been improved by following SAP Notes:

1838560 - Program runs permanently with obsolete ABAP Dictionary type

2503187 - Improvements for touching of dependent programs

2549669 - Improvements for touch and synchronization

The kernel patches delivered by the SAP Notes above can avoid MISMATCH dumps as much as possible. But the problem could still happen and you still need to perform transports or activation when there is lowest usage of the system, or bring your system to be non-productive status before transport/sp upgrade. To bring the system to a non-productive status in an orderly way, reschedule all scheduled background jobs using the report BTCTRNS1 and let any background jobs that are running complete, or terminate them manually. Prompt all users to close any transactions they are working in and to log off from the SAP system. In case the dump happens you still need to perform the steps in this KBA to solve it.

2.

Update kernel to the latest patch level according to Note 2815286.

Temporary workaround:

Resetting the statement cache in AL12:

Press 'Monitor' -> 'Statement Cache' -> 'Reset'

3.

Implement SAP Note 3112437. If the Note can't be implemented on short notice, reset the statement cache, as described in point 2.

See Also

2182690 - LOAD_PROGRAM_MISMATCH after insertion or deletion of index for non-buffered tables

2264680 - Dump LOAD_PROGRAM_TABLE_MISMATCH in ABQL access for table ACCESS_CONTROL_LIST2_ROOT

3112437 - Ignoring of obsolete statements in statement cache

Keywords

LOAD_PROGRAM_TABLE_MISMATCH, mismatch, ABAP, time stamp, runtime, change