MM42 change material, split valuation at batch level, M301, locking table

Question

Dear All,
I'm working on ECC 6.0 retail and I have activated split valuation at batch level.  Now in MBEW for this specific material I have almost 14.400 entries.
If I try to change some material data (MM42) I receive an error message M3021 A system error has occurred while locking and then Lock table overflow.
I used SM12 to see the table (while MM42 is still running) and it seems that MBEW is the problem.
What should I do?  For any material modification the system has to modify every entry in MBEW? Is there any possibility to skip this?
Thank you.

Answer 1

Hi,
Symptom
Key word: Enqueue
FM: A system error has occurred in the block handler
Message in the syslog: lock table overflowed
Other terms
M3021 MM02 F5 288 F5288 FBRA
Reason and Prerequisites
The lock table has overflowed.
Cause 1: Dimensions of the lock table are too small
Cause 2: The update lags far behind or has shut down completely, so that the lock entries of the update requests that are not yet updated cause the lock table to overflow.
Cause 3: Poor design of the application programs. A lock is issued for each object in an application program, for example a collective run with many objects.
Solution
Determine the cause:
SM12 -> Goto -> Diagnosis (old)
SM12 -> Extras -> Diagnosis (new)
checks the effectiveness of the lock management
SM12 -> Goto -> Diagnosis in update (old)
SM12 -> Extras -> Diagnosis in update (new)
checks the effectiveness of the lock management in conjunction with updates
SM12 -> OkCode TEST -> Error handling -> Statistics (old, only in the enqueue server)
SM12 -> Extras -> Statistics (new)
shows the statistics of the lock management, including the previous maximum fill levels (peak usage) of the partial tables in the lock table
If the owner table overflows, cause 2 generally applies.
In the alert monitor (RZ20), an overrunning of the (customizable) high-water marks is detected and displayed as an alert reason.
The size of the lock table can be set with the profile parameter u201Cenque/table_size =u201C. specifies the size of the lock table in kilobytes. The setting must be made in the profile of the enqueue server ( u2026_DVEBM.. ). The change only takes effect after the restart of the enqueue server.
The default size is 500 KB in the Rel 3.1x implementation of the enqueue table. The resulting sizes for the individual tables are:
Owner table: approx 560.
Name table: approx 560.
Entry table: approx 2240.
As of Rel 4.xx the new implementation of the lock table takes effect.
It can also be activated as described in note 75144 for the 3.1I kernel. The default size is 2000 KB. The resulting sizes for the individual tables are:
Owner table: approx 5400
Name table: approx 5400
Entry table: approx 5400
Example: with the
u201Cenque/table_size =32000u2033 profile parameter, the size of the enqueue table is set to 32000 KB. The tables can then have approx 40,000 entries.
Note that the above sizes and numbers depend on various factors such as the kernel release, patch number, platform, address length (32/64-bit), and character width (Ascii/Unicode). Use the statistics display in SM12 to check the actual capacity of the lock table.
If cause 2 applies, an enlargement of the lock table only delays the overflow of the lock table, but it cannot generally be avoided.
In this case you need to eliminate the update shutdown or accelerate the throughput of the update program using more update processes. Using CCMS (operation modes, see training BC120) the category of work processes can be switched at runtime, for example an interactive work process can be converted temporarily into an update process, to temporarily increase the throughput of the update.
For cause 3, you should consider a tuning of the task function. Instead of issuing a large number of individual locks, it may be better to use generic locks (wildcard) to block a complete subarea. This will also allow you to considerably improve the performance.