Enqueue and lock table issue analysis can be bit hard form time to time. They don’t regularly occur and when they do, they can have big system performance impact.
This blog will explain:
- How to detect enqueue issues?
- How to quickly analyze the enqueue issues?
Detecting enqueue issues?
Enqueue issues can be easily detected in SM50 and SM66 if work process get stuck long time with status ENQ.
First analysis on enqueue issues
The first analysis on enqueue issues can be done in transaction code SM12. From the menu now select the options Extra / Diagnosis and Extra / Diagnosis in Update. This will run the diagnostics on the enqueue handling.
Result looks like:
To get statistics on the enqueue processing, on the same SM12 start screen select the menu Extra / Statistics.
Deeper analysis on enque issues
For deeper analysis on the lock issues, you might need to switch to the detailed error handling part of SM12. This is a hidden feature. To switch it on you must have the correct authorization (S_ENQUE with ALL in the activities). Switching can be done by keying in the word TEST in the GUI command line (where you key in the tcodes and the /n etc).
Now you will see an extra menu called Error Handling.
From this menu you can directly launch program RSMONENQ_PERF via the menu option Error handling/Diagnosis environment. This programs will check the performance of the enqueue handling:
The Error Handling menu will also give you option to trace the enqueue processing.
Even more analysis is possible with the Enqueue Log Analyzer. See OSS note 3110596 – Analyze the enqueue scenario with enqueue log analyzer and kernel snapshot analyzer.
More backgrounds can be found in OSS note 2252679 – How to analyze an enqueue lock problem and OSS note 2126913 – ENQU: The enqueue log (specifically on the logging).
Troubleshooting for old locks: 2422483 – Troubleshooting old locks transaction sm12.
Large log file: 3254498 – Large number of entries in enqueue backup files.
Not all locks are shown: 2795956 – SM12 does not list all locks.
Lock table overflow
Lock table overflow can happen when more locks are set by programs then the available allocated memory for the locks. In a normal system this will hardly occur. But during a conversion that is operating on massive amount of data (sometimes even using parallel jobs) this lock table overflow can happen. If it happens this will effect ALL users. They will get lock table overflow error and cannot save their work. More then enough reason to have large conversion tested first on a test system with production like sizing and settings.
The FAQ note on lock table overflow is: 552289 – FAQ: R/3 lock management.
What can be done about lock table overflow?
Provided you have checked your system sizing, you can increase the lock table memory by increasing the parameter enque/table_size. More background read OSS note 1565578 – Lock Table Overflow and OSS note 13907 – System error in the block handler, overflow lock table.
If you are running an older ECC system, the lock table settings in the profile parameters might be set quite low. Newer upgraded ECC system can handle much higher values of the enque/table_size parameter.
Top capacity users
In SM12 you can select menu option Extra / Top Capacity Used / Current or History to find the top users of locks. Background: 2138377 – Output delivered by “Top Capacity Used” menu in SM12.
New enqueue manager 2.0
For the new enqueue manager 2.0 read this blog.