1/28/2016 7:36:36 PM
 Question: How large can and should the lock table be configured?
As of Release 4.0, the default size for the lock table is 4 MB. This value is sufficient for medium-sized systems. As of Release 4.6, it becomes apparent that a size of 10 to 20 MB is required for some background jobs, and a size of 32 to 200 MB may be required for large systems, but this is the exception. Since a lock table that is too small causes transaction terminations, but the resources for the lock table are relatively low, you should initially specify a size of 20 MB. In general, no further changes to the layout of the shared memories are required when you use this size (except for AIX 32-bit). You can make this setting by using the profile parameter: enque/table_size = 20000
You can monitor the lock table in transaction SM12 by choosing the menu option "Extras -> Statistics".
The lock table is a shared memory, not a database table.
 Question: What does the started wait time in the syslog mean for locks?
Usually, locks can be set in the R/3 system only if they are available. If an object is already locked, the system rejects lock requests and issues the error message " ... locked by user ...". This prevents deadlock situations, which you may be familiar with in databases. However, a job should not terminate in background processing if a lock is unavailable at that moment. In this case, the system requests the locks with the addition "and wait". The wait time incurred is then logged in the syslog. You can use the profile parameter enque/delay_max to set the maximum wait time.
 Question: How does communication take place in lock management?
This question is especially important for troubleshooting because it indicates where errors may occur. In the central instance, all work processes can access the lock table directly. Therefore, the ENQ work process is not required, and no communication takes place.
An application server sets and deletes locks via the message server. Therefore, communication takes place as follows: work process -> dispatcher -> message server -> dispatcher -> ENQ work process. The lock table is read using RFC, that is: work process -> gateway -> gateway -> dialog process. In this case, the ENQ process is not used either. However, central instances with few dialog processes may be overloaded quickly because dialog work processes are required for RFC communication accordingly. The same also applies to pure background servers or update servers. Therefore, the number of dialog work processes must always be at least as high as the number of remaining processes.
 Question: What are "black" and "blue" locks?
Black locks are normal transaction locks. Blue locks are inherited by the update system and are deleted with the corresponding update request. Blue locks are also saved in the file system and are restored when the system is restarted.
If you like this blog, please share (Facebook/LinkedIn/Google+) to click below links so it will reach to others.