[1] Question: How large can and should the lock table be configured?

[2] Question: What does the expired queue time in the syslog mean for locks? [3] Question: How does communication take place in lock management? [4] Question: What are "black" and "blue" locks? [1] Question: How large can and should the lock table be configured? s of Release 4.0 the default size for the lock table is 4 MB. For medium-sized sy stems this value is absolutely sufficient. As of 4.6, it appears that a size of 10-20 MB is required for some background jobs, and a size of 32-200 MB may be re quired for large systems, although this is the exception. As a lock table that i s too small causes transaction terminations, but resources for the lock table ar e relatively low, a size of 20 MB should be specified initially. no further chan ges are generally required to the layout of the shared memories with this size ( except for AIX 32 bit). You can enter this setting using the profile parameter: enque/table_size = 20000 You can monitor the lock table in transaction SM12 via the menu option "Extras > Statistics". The lock table is a shared memory, not a database table. [2] Question: What does the expired queue time in the syslog mean for locks? Locks can usually only be set in the R/3 system if they are available. If an obj ect is already locked, requests to lock it are refused and the error message " . .. locked by user ..." is issued. This prevents the dead lock situations familia r from databases. However, a job should not terminate in background processing i f a lock happens to be unavailable. In such cases, the locks are requested with the addition "and wait". The queue time incurred is then logged in the syslog. T he maximum queue time is set using the profile parameter enque/delay_max. [3] Question: How does communication take place in lock management? This question is especially important for troubleshooting since it indicates the characters at which errors can occur. In the Central Instance, all work process es can access the lock table directly. Therefore, the ENQ work process is not ne eded, and so no communication occurs. An application server sets and deletes locks via the Message Server. There is th erefore communication from work process-> dispatcher->server -> dispatcher -> EN Q work process. The lock table is read by RFC, that is, work process-> dialog pr ocess -> gateway-> gateway-> dialog process -> dialog process. Here again, the E NQ process is not required, although two dialog processes are needed for RFC com munication. Central instances with few dialog processes can be overloaded quickl y in this way. The same also applies to pure background or update server process ing. The number of dialog work processes must therefore be at least as high as t he number of remaining processes. [4] Question: What are "black" and "blue" locks? Black locks are normal transaction locks. Blue locks are inherited by the update system and deleted with the corresponding update request. Blue locks are also s aved in the file system and restored when the system is restarted.