ENQUEUE PROCESS
It is used to enque/deque (lock/unlock) the objects during an update. By default one enue process is installed along with Message Server. It is possible to configure more than one enque process in a massive update system. Enque processes are configured by using parameter.
rdisp/wp_no_enq=2
Ensure the enque process is configure on the CENTRAL INSTANCE to store the Enque Table. Enque locks are stored in enque table which is configured by parameter
enque/table_size
This table resides in the main memory of the instance where enque processes are configured. Generally enque processes are configured on the Central Instance (to communicate with message server)
Enque replication servers are installed in an high availability system to replicate the locks between the instances (nodes).
ERS is installed on all the nodes and lock replication table gets replicated from Central Services lock tables.
ENQUEUE PROCESS FLOW
1. User submits the request for an update.
2. The request is received by dispatcher and keeps it in wait queue.
3. Based on freely available Dialog process, the dispatcher allocates a process to user request.
4. When dialog identifies update then it communicates with enque process to obtain lock on the record, so that no other user modifies it and has only a display access. These locks are displayed in SM12.
5. If the update request is made through an application server. The Dialog Process communicates with message server and message server in turn communicates with enque process to obtain lock on behalf of the dialog process.
Message server obtains the lock from enque process and provides to dialog process.
Generally the enque time on the Central Instance is 1ms to 5ms. If more than one dialog instances are configured then the enque time can go up to 100ms(if it goes beyond then turn on the enque trace for RCA(ROOT CAUSE ANALYSIS))
Enque Trace --> ST01 and ST05 for RCA
ENQUEUE MONITORING
1. The Locks are monitored in SM12.
2. The locks which are held for more than 12 hours are documented into checklist and escalated to next level.
3. As a part of monitoring locks held by dialog process should not be more than one hour. But the locks held by a BTC process during batch processing can consume more than one hour or even days.
4. It is possible to delete the locks from T-Code SM12 but it is not recommended instead the users can be logged off from SM04 which automatically releases the lock.
5. Lock deletion/ users log off are treated in SM21 so take the necessary approvals while deleting a lock/user.
LOCK ISSUES
1. Enque time is too high-: i.e. beyond threshold value 1-5ms (CI) to 100ms (dialog instance) considering the enque time we can increase one or more enque processes which shares the same lock table.
2. Lock table over flow (increase the lock table size up to maximum of 100mb)
3. Deadlock-: (It is due to the program error).
Identifies the error and inform SAP to release a note/support
pack/packages or follow the SAP recommendations.
Lock table overflow is logged in SM21/ST22 and the users could not get lock and there by process congestion occurs/users encounter hourglass situation. Check whether update mechanism is active SM14
Check in SM12 --> extras-->top capacity used-->if it reached maximum then consider increasing the enque table size to 100mb.
As of kernel release 701 and higher, the default table size is increased to 32mb. In32-Bit version, the default value is increased to 16mb.
EG-: SAP ECC6.0 EHP3,4,5
Even though the settings for the profile parameter ENQUE/TABLE_SIZE are correct the task execution terminates with an overflow of the lock table.
The lock logic creates several detailed lock entries (due to program error) and these may be too much for the lock management to handle and subsequently lock table overflow occurs.
Escalate the issue to SAP and apply a patch/support package/note etc.
Regards
Samar
