SAP Enqueue Server
Introduction to the Enqueue Service
Enqueue Performance
🔐 Enqueue Work Process – Basics
Handles ENQUEUE/DEQUEUE (lock/unlock) operations during updates.
Default: 1 Enqueue WP installed with Message Server.
More can be configured for large-scale update systems.
⚙️Key Configuration Parameters
rdisp/wp_no_enq = 1 (or more if needed)
enque/table_size = 4–100 MB → Lock table in main memory
Configured on Central Instance (CI)
🔄 Enqueue Replication (HA Setup)
ERS replicates locks from ASCS to other nodes.
Replication helps in failover scenarios.
ERS is installed on other cluster nodes.
🧠 Lock Types Managed
Shared Lock
Exclusive Lock
Cumulative Lock
Optimistic Lock
Stored in TLOCK table (shared memory)
📂 Log Location
/usr/sap/<SID>/<Instance>/log
🔧 Useful Transactions
T-Code Purpose
SM12 View/delete lock entries
SM01 Lock/unlock transaction codes
🔁 Enqueue Replication Server (ERS) – Overview
🔐 Enqueue Server Basics
The enqueue server (lock server) manages the lock table in main memory.
In a distributed SAP system, there is only one active enqueue server.
🧭 ERS Purpose
Provides High Availability (HA) by replicating the lock table.
Allows automatic failover without loss of lock data.
🏗️Architecture Evolution
SAP Release Architecture
Pre-7.00 Enqueue server part of Central Instance (CI)
7.00+ Enqueue server separated into ASCS (standalone)
7.50+ ASCS is mandatory if more than one app server exists
AS Java Always installed with SCS (Central Services)
⚙️Installation Options
1. Standalone Enqueue Server (ASCS/SCS)
o Enqueue server + Message Server in one instance (ASCS/SCS)
o Single Point of Failure, but can be protected with ERS
2. Enqueue as Work Process (CI)
o Old design where enqueue is part of CI
o Used only in single-instance or older systems
🧠 ERS Key Points
Installed on a separate host from ASCS
Receives real-time lock replication
Used with cluster software (e.g., Pacemaker, MSCS) for automatic failover
Ensures no lock data is lost if ASCS crashes
✅ ERS Installation & Monitoring Checklist
🛠️I. Pre-Installation Checklist
Checkpoint Description
🔲 System Type Ensure system uses ASCS/SCS architecture (ABAP ≥7.00 or JAVA)
🔲 HA Requirement Confirm HA requirement with ERS + cluster software (e.g., Pacemaker, MSCS)
🔲 ERS Host Select a separate host from ASCS for ERS
🔲 Hostname Resolution Maintain correct /etc/hosts entries or DNS records for ASCS and ERS
🔲 Ports Availability Reserve replication port (default: 32)
🔲 Profile Preparation Identify and prepare DEFAULT.PFL, ASCS<nn>_<SID>.profile, and ERS<nn>_<SID>.profile
🔲 Filesystem Preparation Ensure /usr/sap/<SID>/ERS<nn> directory exists with proper permissions
📦 II. ERS Installation (SWPM or SAPinst)
Step Task
🔲 Use SWPM Launch Software Provisioning Manager (SWPM) on ERS host
🔲 Choose ERS Option Select: Install Enqueue Replication Server for existing ASCS
🔲 Provide ASCS Details Enter ASCS hostname and instance number
🔲 SAP System Credentials Provide SAPSID, SAPADM, and password details
🔲 Ports Confirm/adjust replication port
🔲 Profile Creation SWPM will generate ERS<nn>_<SID>.profile
🔲 Complete Installation Finish and validate installation logs (SAPinst & sapinst_dev.log)
⚙️III. Post-Installation Configuration
Task Command/File
🔲 Check DEFAULT.PFL Ensure entry: enque/server/replication = true
🔲 Check ASCS Profile Confirm enque/server/replication_port = <port> is set
🔲 Check ERS Profile ERS profile includes rdisp/enqname = ASCS<nn> and replication settings
🔲 Start ERS Use sapcontrol or startsap
🔲 Validate Connection ASCS dev trace dev_enqwork should show ERS connection confirmation
🔲 Cluster Integration Integrate ERS into your HA solution if applicable (optional)
🔍 IV. Monitoring & Validation
Checkpoint Tool/Command
🔲 Enqueue Replication Status SM51 → System LogsSM12 → Lock entries visible
🔲 SAPControl Status sapcontrol -nr <nn> -function GetProcessList
🔲 Replication Logs dev_enqwork, dev_enrepsrv in /usr/sap/<SID>/ERS<nn>/work
🔲 Replication Test Simulate ASCS shutdown → Check if ERS takes over locks
🔲 Failover Test Perform manual or cluster-based failover to validate HA functionality
🔲 Enqueue Log Files /usr/sap/<SID>/ASCS<nn>/work/ENQLOG*, ENQSTAT
🧰 V. Maintenance Tips
🔄 Restart after patching: Always restart ASCS and ERS after profile changes or kernel upgrade
🧪 Regular failover tests: Perform semi-annual ERS failover testing
📂 Monitor replication latency: Check for delayed lock sync in logs
🚦 Cluster alerting: Set up alerts if ERS or ASCS is down (via OS cluster or monitoring tool)
⚠️Classical Setup Without ASCS – SPOF (Single Point of Failure)
Message Server
o Can restart quickly.
o While it's down, no app server communication occurs.
o No data loss, just temporary unavailability.
Primary Application Server (PAS/CI)
o Contains Enqueue Work Process holding critical lock data in memory.
o If it fails:
All lock data is lost.
Transactions with locks must be reset.
o → Enqueue is a major SPOF in classical setup.
✅ HA (High Availability) vs Non-HA (Classical) SAP System Setup
Aspect Non-HA System (Classical) HA System (with ASCS & ERS)
Central Instance (CI) Hosts both Message Server and Enqueue WP Separated into ASCS (Msg+Enqueue) + App Servers
Enqueue Server Runs inside CI as Enqueue WP Runs as Standalone Enqueue Server (multi-threaded)
SPOF (Single Point of Failure) Yes – CI crash means lock loss, user disruption No – ERS (Enqueue Replication Server) provides redundancy
Message Server Failure Minor impact – comms stop but no data loss Same – restarts quickly without critical impact
Enqueue Failure Critical – lock data in memory is lost Handled – ERS keeps replicated lock data
ERS Present? ❌ Not applicable ✅ Yes – maintains backup lock table
System Restart After Crash Locks lost, manual cleanup needed ERS syncs lock table back to restored ASCS
Recommended for Prod? ❌ No ✅ Yes
Supported in latest versions? ❌ Deprecated setup ✅ Mandatory for systems with >1 app server (ABAP 7.50+)
🧠 Summary
Non-HA setups (with CI) are vulnerable to Enqueue failure.
HA setups use ASCS and ERS, enabling automatic failover and no loss of lock data.
Modern SAP installs require ASCS/ERS-based architecture for true high availability.
🔐 Key Advantages of Standalone Enqueue Server (ENSA) in ASCS
1. Direct Communication
o Work processes connect directly to the Enqueue Server via TCP, bypassing the dispatcher → faster
lock handling.
2. High Availability with ERS
o ASCS enables Enqueue Replication Server (ERS) → lock table changes are replicated in real time
for failover safety.
3. Multithreaded Performance
o ENSA supports parallel lock processing, improving performance under high load.
4. Dedicated WP Connections
o Each work process has its own connection, reducing contention and delays.
5. Port-Based Communication
o Uses sapdp<instance> port; ASCS must have its own instance number to avoid conflicts.
🔵 Step 1: Installation of ERS
Tool Used: SWPM / SAPinst
ERS is installed using the Software Provisioning Manager (SWPM) or classic SAPinst.
The installation sets up a dedicated instance that replicates the Enqueue table from the primary Enqueue
Server (usually on ASCS).
It should be installed on a different host than the ASCS to ensure failover in case of ASCS failure.
📌 Outcome: Directory structure (ERS SID), kernel executables, profile files are created.
🔵 Step 2: Check File System Structure and Executables
Level: File System
Tools/Commands:
Use OS commands like:
Verify presence of:
o ensmon: Monitoring tool for ERS.
o enqt: Replication tool that handles lock table copies.
o Kernel files such as disp+work, sapstart, etc.
📌 Objective: Ensure ERS has all required binaries and folders like exe, work, and log.
🔵 Step 3: Check Profile Parameters
Level: File System / SAP Profile
Go to:
Open the ERS instance profile and confirm parameters like:
o rdisp/enqname → must point to the ASCS instance hostname.
o rdisp/replicatename → this should reflect the ERS hostname.
o Network-related parameters like enque/serverhost.
📌 Objective: Ensure ERS knows how to connect and replicate from the Enqueue Server (ASCS).
🔵 Step 4: Start ERS (if necessary)
Tools: SAP MMC (Windows) or SAP MC / sapcontrol (Linux)
On Linux:
On Windows, start the ERS from SAP Management Console (SAP MMC).
📌 Objective: Bring the ERS up so it starts replicating the Enqueue Table in real-time.
🔵 Step 5: Monitor ERS
Tool: ensmon
Run at OS level:
This tool displays:
o Replication status
o Time of last update
o Lock table content replication consistency
You can also check via:
o SM12 (lock table on ASCS)
o SM51 or AL08 for instance monitoring
📌 Objective: Ensure ERS is actively syncing with the ASCS and ready to take over in failover.
✅ Summary: Flow of ERS Setup and Monitoring
Step Action Tools
1 Install ERS SWPM, SAPinst
2 Validate file structure ls, ensmon, enqt
3 Check profile Manual (OS-level or RZ10)
4 Start ERS SAP MMC, SAP MC, sapcontrol
5 Monitor ERS ensmon, SM12
1. Installation of ERS
Prerequisite: ASCS (ABAP Central Services) must already be installed in the system.
If ASCS was not installed initially, use SWPM (SAPinst) to split ASCS from the existing instance.
ERS is installed using SWPM on a separate host from the ASCS instance to ensure high availability.
2. File System Structure
After installation, ERS resides in:
**/usr/sap/<SID>/ERS<Instance_Number>**
Inside this directory:
o **exe/** subdirectory contains executables:
**ensmon**: Tool to monitor ERS & replication status.
**enqt**: Used to view the lock table of ERS, similar to SM12 but at OS level.
3. Profile Parameters
a) On the Enqueue Client (Application Server) Instance Profile
Parameter Description
TRUE (waits for server response synchronously), FALSE (asynchronous) — Case-
enqueue/dequeue_wait_answer
sensitive.
Communication type with Enqueue Server. Should be REMOTESA (default), do not
enqueue/process_location
change.
enqueue/serverhost & Specify the hostname and instance number of the standalone enqueue server
enqueue/serverinst (ASCS).
b) On the Enqueue Server (ASCS) Instance Profile
Parameter Description
enqueue/server/replication Must be set to TRUE to enable communication with ERS.
enqueue/encri/repl_port Use this only if you do not want to use default port 5<system number>16.
enqueue/server/max_clients Max parallel client connections to Enqueue Server. Default: 1000.
enqueue/enrep/* Specific parameters used by the Enqueue Replication Server (ERS).
4. Start and Stop ERS
Use SAP MMC or SAP MC to manage ERS and ASCS.
Start order:
o Start ERS first, then ASCS.
Stop order:
o Stop ASCS first, then ERS.
This order is important to prevent inconsistencies in lock replication.
5. Monitoring ERS
Use **ensmon** to monitor replication status and connectivity between ASCS and ERS.
o Command examples:
ERS lock table monitoring:
o Use the program **enqt** on the ERS host to view the replicated lock table.
High Availability Monitoring:
o ERS and ASCS are monitored using SAPStart service or external HA software in clustered
environments (like Pacemaker, Veritas, etc.).
📘 SAP Enqueue Server & Enqueue Replication Server (ERS) – Detailed
Overview
🔧 1. Installation & Setup
Before installing ERS, ensure your SAP system is configured with ASCS (ABAP Central Services).
If your SAP system isn’t separated, use SWPM (SAPinst) to split ASCS from the existing instance.
ERS should be installed on a separate host from ASCS.
🗂️2. File System Structure
Path Description
/usr/sap/SID/ERS Installation path for ERS
exe/ensmon Monitor lock replication correctness
exe/engf View lock table manually
work/ Contains logs like dev_enrepsrv
⚙️3. Profile Parameters
A. Common Parameter
enqueue/table_size: Defines lock table size (default: 16MB)
B. Enqueue Client (App Server) Profile
Parameter Description
enqueue/dequeue_wait_answer TRUE = synchronous dequeueFALSE = async dequeue (case-sensitive)
enqueue/process_location Type of communication (default: REMOTESA)
enqueue/serverhost Hostname of standalone enqueue server
enqueue/serverinst Instance number of enqueue server
C. Enqueue Server (ASCS) Profile
Parameter Description
enqueue/server/replication Must be set to TRUE to enable replication
enqueue/encri/repl_port Optional: Port used for replication (default: 5**16)
enqueue/server/max_clients Default 1000; Max enqueue clients
enqueue/enrep/* ERS-specific replication parameters
▶️4. Start & Stop Sequence
Action Tool
Start ERS before ASCS SAP MMC / SAP MC / sapcontrol
Stop ASCS before ERS SAP MMC / SAP MC
Restarting Enqueue Server sapcontrol -nr <Inst> -function RestartService
🔄 5. ERS Integration with HA Cluster
Refer full HA guide earlier, but in short:
ERS and ASCS installed on different nodes.
Managed using HA software (Pacemaker, Veritas, or Windows Failover).
Virtual IPs assigned to ASCS and ERS.
Use SAPInstance OCF resource agents.
Define colocation, order, and failover policies.
Ensure ERS is up before ASCS, and never on same node simultaneously.
📜 6. Log Files (Located in work/ directory)
File Description
dev_enqserv Logs for enqueue server startup
dev_enqwork Logs issues in enqueue lock processing
dev_enqio_* Tracks communication with enqueue clients
dev_enrepsrv ERS-specific log file (replication issues)
💡 7. Enqueue Server – Key Features
Receives lock requests and checks the lock table for conflicts.
If no conflict, sets the lock and records it in the lock table.
Centralized lock handling ensures consistency across app servers.
Used mainly in dialog, background, and update processing.
🔁 8. Enqueue Process Flow
1. User submits a request (e.g., transaction or update).
2. Dispatcher queues it and assigns an available dialog work process.
3. The dialog work process attempts to lock relevant records.
4. It contacts the enqueue server:
o Directly (if local)
o Via message server (if remote)
5. Lock is granted if no conflict and stored in lock table.
6. If multiple DIs exist, enqueue time may increase:
o CI: 1–5 ms
o DI: 50–100+ ms
7. Performance tuning tools: Use ST01, ST05 for tracing lock time delays.
🧭 9. Monitoring
Tool Usage
SM12 View/Delete current locks
ensmon Monitor ERS and replication
enqt Display lock table manually (for ERS)
SM21 Logs user logoff/lock deletion
SAP MMC / sapcontrol Instance-level monitoring
HA software Cluster-level service health
📌 Monitoring Guidelines
SM12 shows locks (user, object, time).
Locks older than 12 hours should be reviewed.
Locks held by dialog processes > 1 hour are suspicious.
Locks by batch/background may be valid even for hours or days.
Instead of deleting locks from SM12, prefer logging off the user from SM04, which also releases the lock.
All lock deletions/user logoffs are audited in SM21 — take proper approval.
✅ Summary
Component Role
Enqueue Server (ASCS) Central lock manager for SAP system
ERS Backup lock table (standby), auto-takeover during ASCS failure
SM12 Lock monitoring
ensmon, enqt Replication and lock table checks
SM21, ST01, ST05 Audit and trace tools
Cluster Ensures HA via node failover of ASCS with lock consistency
🔒 SAP Lock Issues – Troubleshooting & Analysis
🔹 Common Symptoms & Root Causes
1. High Enqueue Time
In Central Instance (CI): Enqueue time exceeds 1–5 ms
In Dialog Instance (DI): Enqueue time exceeds 100 ms
⚠️Indicates performance bottleneck or enqueue contention.
2. Lock Table Overflow
Detected via: SM21 (system log), ST22 (dumps)
Cause: Lock table reaching its maximum capacity.
Resolution:
o Increase profile parameter:
o enque/table_size = 200 MB (for newer kernel versions)
o Monitoring:
SM12 → Menu: Extras → Statistics
Top Capacity / Current Capacity helps determine threshold status.
3. Update Process Deactivation
Scenario: Update process hangs due to enqueue delays and sudden file system surge.
Monitoring:
o Transaction: SM14 (Update administration)
o Lock statistics: SM12 → Extras → Statistics
Resolution:
o Check filesystem availability.
o Monitor work process logs for update terminations.
o Re-activate update process via SM14.
4. Deadlock Situation
Cause: Programmatic conflict between two transactions working on the same LUW (Logical Unit of Work).
Error Type: Detected in ST22 with DEADLOCK or related runtime errors.
Resolution:
o Apply latest Support Packages or SAP Notes.
o Raise an SAP Incident if issue persists.
5. Network Problems
Symptoms: Delayed enqueue response or work process hanging.
Actions:
o Perform connectivity tests using ping or traceroute.
o Ensure low-latency between application and CI/ERS hosts.
6. Message Server Issue
SAP Level Check: Transaction SMMS
OS Level Check: Utility msmon
o Used to verify message server process status and connections.
7. Improper Configuration of Application Server
Parameters to validate:
o rdisp/enqname – must point to the correct Enqueue Server
o rdisp/mshost – must reference the correct Message Server host
🛠️Required especially when setting up additional application servers.
🔍 Lock Table Monitoring & Ownership
📌 How to Check Locks in Enqueue Table
SAP Level:
o Transaction: SM12 or system log via SM21
OS Level:
o Command:
o enqt pf=<INSTANCE_PROFILE> 20
o Displays enqueue table content and performance metrics.
🧑💼 How to Identify Owner of Lock Object
1. Go to SE11
2. Input the Lock Object name → Display
3. Navigate to the Attributes and Package tabs
o These fields indicate the technical owner (developer/object) and relevant application component.
🔐 SAP Enqueue Server: Advanced Monitoring & Performance Analysis
🔹 What Happens to Locks if Enqueue Server Crashes or Restarts?
Lock data is not lost immediately:
o During update commit phase, locks are backed up to disk if parameter enque/backup_file is
enabled.
o Upon restart, SAP reloads lock entries from the backup file to the lock table.
Path for lock backup:
Critical Parameter:
🔹 Enqueue Operation Trace with ENQT Tool
🛠 Used when ENSA/Standalone Enqueue Server is running
Location:
Usage:
o To enable trace:
o To disable trace:
Precaution: Do not run trace > 30 seconds, as it may impact performance.
Log File Output:
🔹 Identifying Programs Using Enqueue Objects
Go to: SE11 → Enter Lock Object → Utilities → Where-Used List
You’ll find all programs that call ENQUEUE/DEQUEUE functions tied to that lock object.
🔹 Enqueue Logging
Activation/Deactivation (set in instance profile or via transaction RZ10)
o Enable:
o Disable:
Analysis:
o UNIX/Linux:
o Windows:
Use Notepad++ or SAP GUI text viewer to check ENQLOG99.
🔹 Monitoring Enqueue Threads and Handles
Use ensmon tool (as <SID>adm) → Option 7 for thread analysis:
o ADM Thread – Main control thread
o Listen Thread – Manages incoming connections
o Replication Thread – Handles ERS communication
o Worker Thread(s) – Perform lock operations
🔹 Enqueue Session Quota (To Prevent Lock Table Overflows)
🔸 Problem:
If enqueue table overflows, programs fail with dump and may bring entire system down.
🔸 Solution:
Use session quotas to restrict lock consumption per user/session.
1. Enable session quota:
2. Enable dump when quota exceeded:
☑️If a session exceeds the quota, it receives ENQUEUE_QUOTA_EXCEEDED dump.
⚠️Limitation: This protects only per-session lock count, not total system overflow due to mass parallel usage.
🔹 Finding Enqueue Replication Server (ERS) Connectivity
Check Replication Port:
o Usually defined in DEFAULT.PFL or instance profile:
Verify Connection:
o Use:
o Or OS-level logs:
🔹 Performance Analysis with ENQT
🔸 SAP Level
In SM50, check for WPs:
o Program: SAPLSENA or SAPLSENT
o Status: Long running or On Hold due to ENQ
🔸 OS Level (Using enqt with Interval Statistics)
Output Field Meaning
Count Absolute enqueue count
Actual Ops/min since last refresh
10s, 1m, 5m, 15m Ops/min in each interval window
🔹 How to Identify Enqueue Performance Bottlenecks
1. Transaction STAT (or STAD):
o Check:
Enqueue time (response time breakdown)
Enqueue count
2. Transaction SM12 → Extras → Statistics:
o View from:
o Must reside locally on the Enqueue Server host (not via NFS/remote) to avoid performance hits.
🔹 Summary of Tools
Tool / File Purpose
SM12, SP12 Lock monitoring, stats
ENQT, ensmon OS-level enqueue trace
ENQLOG99, ENQSTAT Logs and statistics
dev_enq* Developer trace files
Tool / File Purpose
RZ10 / DEFAULT.PFL Profile parameter tuning
SE11 > Lock Object Program usage mapping
🎯 Creating an Enqueue Operation Trace (Java / ENSA)
🔧 1. Context
If you are running a Java-only system (e.g., AS Java or SAP NetWeaver with Java stack), the Enqueue
Server is handled by ENSA (standalone enqueue server).
For tracing enqueue operations, use the ENQT tool provided by SAP.
📌 2. Tool Location
Example:
🟢 3. Enable Enqueue Trace
or explicitly:
This starts the tracing of enqueue operations.
Start tracing just before reproducing the issue.
🔴 4. Disable Enqueue Trace
or:
Disable tracing immediately after the issue occurs to avoid performance degradation.
⚠️Best Practice: Run trace for < 30 seconds only, as it consumes CPU and memory and may affect system
performance.
📂 5. Trace File Location
Enqueue logs are stored in the instance work directory:
If log rotates, you might also see:
o ENQLOG00, ENQLOG01, ..., ENQLOG99
📘 6. Trace Analysis
To read the trace file:
You can apply filters like:
🧩 7. Typical Use Case
Use the trace to identify:
Lock conflicts
Deadlocks
Long-holding locks
Missing DEQUEUE calls
High-frequency lock requests
✅ Summary
Step Action
1 Navigate to /usr/sap/<SID>/<Instance>/exe
2 Start trace: enqt -on
3 Reproduce issue within 30 seconds
4 Stop trace: enqt -off
5 Analyze /usr/sap/<SID>/<Instance>/work/ENQLOG99 with enqt -read
🔐 Enqueue Log Activation & Deactivation
✅ To Activate Enqueue Logging
1. Set the following profile parameter (in instance profile or via RZ10):
2. Restart the instance for the parameter to take effect.
3. Log File Location:
o xx can be 00 to 99 depending on the number of logs generated.
❌ To Deactivate Enqueue Logging
1. Set the following profile parameter:
2. Restart the instance to apply the change.
🔎 Important Notes
Enqueue logging is resource-intensive and should only be enabled for short-term analysis or during SAP
support troubleshooting.
Do not keep it enabled permanently in production environments.
✅ Make Use of the Enqueue Replication Server (ERS)
🔹 SAP System Without ERS
If Enqueue Server fails, all lock entries in memory are lost.
Transactions holding locks must be reset manually.
This is a single point of failure (SPOF) in the system.
🔹 SAP System With ERS
Locks are replicated in real-time from Enqueue Server to ERS.
If the Enqueue Server fails:
o ERS takes over
o Locks are retained
o No manual reset is needed
Provides High Availability (HA) for critical operations.
🔍 Check ERS Configuration
1. Go to SAP MMC or SAP Management Console
o Look for ASCS and ERS instances.
2. At OS level:
3. Or check instance profile:
o File: /usr/sap/<SID>/SYS/profile/START_<SID>_ERS<nn>_<hostname>
o Parameters like:
SAP Lock Management (SM12)
🔹 Basics
SAP uses a special lock mechanism to synchronize access to database records.
Purpose: Prevent simultaneous changes to the same data by different transactions.
Locks are set and removed automatically by user programs when accessing and releasing data.
Lock mechanism is tightly integrated with the update mechanism.
🔹 Key Profile Parameters for Locking
Parameter Description
enque/table_size Size of the lock table in memory (managed by enqueue server). Holds lock info.
rdisp/wp_no_enq Number of enqueue work processes configured in the system.
rdisp/enqname Name of the application server providing enqueue service.
🔹 Types of SAP Locks
Lock Type Code Description
- Exclusive lock: Only one user can modify the locked data.- Any other read/write request is rejected.- Cumulative
Write Lock E
lock: Same user can lock again.
Read Lock S - Shared lock: Multiple users can read the same data.- Write lock is not allowed while read locks are held.
Enhanced Write
X - Exclusive non-cumulative lock.- Can be set only once even by the same transaction.- More restrictive than E.
Lock
Optimistic Lock O - Used when users open data in change mode.- Starts as Read Lock (S).- Converted to Write Lock (E)
Lock Type Code Description
upon save.- All other optimistic locks on the same object are removed.
➕ Difference: Write Lock (E) vs Enhanced Write Lock (X)
Feature Write Lock (E) Enhanced Write Lock (X)
Repeatability Can be reapplied by same transaction Can be set only once
Lock Type Cumulative Non-cumulative
Use Case Normal editing Critical sections needing strict exclusivity
🔹 Monitoring SAP Locks
✅ SAP Transaction Monitoring
Tool Purpose
SM12 View current lock entries in the system.
SP12 Monitor Enqueue statistics, lock table usage and capacity.
RZ20 Use CCMS Monitoring Infrastructure for enqueue resource alerts and statistics.
✅ Operating System Level Monitoring
Tool/Utility Purpose
ensmon (run as Advanced analysis of Enqueue Server and lock table usage. Helpful during high lock contention or lock table
<SID>adm) overflow.
✅ SM12-Based Performance Tuning Recommendations
🔹 1. Monitor Lock Table Usage Regularly
🛠 Tool: SP12 → Menu: Extras > Statistics
Check:
oTop Capacity (%): Indicates how full the lock table is.
oCurrent Usage: Number of lock entries currently in use.
Threshold Warning: If top capacity exceeds 80–90%, tuning is required.
📌 Tip: Schedule regular monitoring or CCMS alerts for lock table usage.
🔹 2. Increase Lock Table Size
🛠 Profile Parameter: enque/table_size
Default: ~4 MB (older systems); modern systems may need up to 100–200 MB.
Increase if:
o Frequent Lock Table Overflow dumps (in ST22).
o High lock usage reported in SP12.
Set in instance profile and restart system:
enque/table_size = 200000000 " (for 200 MB)
📌 Use SAP Note 198467 for lock table sizing guidance.
🔹 3. Analyze Long-Held Locks
🛠 Tool: SM12
Sort by Lock Time.
Investigate:
o Long-held locks from batch jobs, custom programs, or stuck user sessions.
o Ensure update logic is optimized to release locks quickly.
Kill inactive sessions cautiously only if business impact is high.
📌 Use transaction SM04 or AL08 to analyze the user holding the lock.
🔹 4. Avoid Lock Contention in Custom Code
In ABAP, ensure:
o Lock objects (ENQUEUE_...) are used correctly.
o Lock scope is minimal—lock before update and release immediately.
o Avoid nested or unnecessary locks.
📌 Custom code should not hold locks during user interaction (e.g., dialog popup).
🔹 5. Avoid Deadlocks & Improve Update Performance
Optimize update work process settings to prevent backlogs.
Use:
o SM13: Analyze update errors.
o SM21: Look for enqueue-related errors.
Consider:
o Increasing update work processes (rdisp/wp_no_vb*).
o Reducing the complexity of update logic.
🔹 6. Use Enqueue Replication Server (ERS) for High Availability
In high-availability setups, use ERS to prevent lock loss during failovers.
Ensure ERS is:
o Synchronized properly.
o Regularly monitored using ensmon and SAPStart.
🔹 7. Set Up Alerts via RZ20 (CCMS)
Monitor:
o Lock table overflow.
o High enqueue wait times.
o Number of locks.
Set thresholds for early alerts before the system hits critical levels.
🔹 8. Technical Monitoring Automation (SAP Solution Manager)
Use SolMan or Focused Run to:
o Monitor lock behavior in real-time.
o Trigger auto-notifications based on lock thresholds or trends.
🔹 Useful Transactions Summary
Transaction Purpose
SM12 View/delete lock entries
SP12 Lock table statistics
RZ20 Enqueue resource monitoring
SM21 System log (for lock errors)
ST22 ABAP dumps (e.g., lock overflow)
ensmon OS-level enqueue monitoring
SM04/AL08 User sessions (lock owners)
⚠️How to Check Enqueue Overflow
✅ 1. SAP GUI Level
T-Code: SM12
o Navigate to: Extras → Statistics
o Look for:
"Maximum Fill Level"
"Maximum Number of Locks"
🔍 If Maximum Fill Level > Maximum No. of Locks, it indicates enqueue table overflow.
✅ 2. OS Level
Run the enqt tool with the profile:
enqt pf=<instance_profile> 20
⚠️Note:
o This only works if you are using the ENSA (Standalone Enqueue Server) setup.
o Does not work with classical CI, where enqueue is inside a dialog instance.
🔍 How to Check if a Lock Entry Should Be Deleted
✅ Step 1: Use SM12
Go to T-Code: SM12
Select the lock entry ➤ Click “Details”
o Review:
User
Transaction
Timestamp
Table/Object locked
🚫 If the lock is old and the user/session is inactive, it may be safe to delete — but always double-check first.
✅ Step 2: Trace the Lock Owner
To investigate further:
1. Go to SM51
2. Select the host ➤ Goto → Server Name → Information → Trace Search
3. Use Lock Owner ID as the search keyword
4. You can also check the relevant work process trace files (dev_w*) on OS level:
5. /usr/sap/SID/DVEBMGS<nn>/work/dev_w*
🔍 How to Identify the Cause of Lock Table Overflow
✅ 1. OS Level
File: ENQHISOVR
Path:
/usr/sap/<SID>/<Instance>/work/
This file shows:
o Usernames
o Programs
o T-codes responsible for the lock overflow event.
📌 Use less or cat to view the file.
✅ 2. SAP Level
T-Code: SM12
o Go to: Extras → Top Capacity Used → History
o Review:
Time of peak usage
Top locking users/programs
This view helps analyze historical trends that led to overflow.
🔐 How to Check Locks in the Enqueue Table
✅ Method 1: SAP GUI Level
T-Code: SM12
Shows all current lock entries in the system.
You can filter by user, table, or client.
✅ Method 2: OS Level
Command:
Displays current lock entries — similar output to SM12.
Useful when SAP system is unresponsive or for scripting/automation.
🔍 Check Enqueue Deployment Mode (Classical CI vs Standalone Enqueue Server)
📍 T-Code: SM12 → Menu ➜ Extras → Diagnosis
1️⃣ Classical CI
Lock management operation mode:
→ Internal lock management in the same work process
Enqueue runs as part of the Central Instance (CI)
No standalone enqueue or replication
2️⃣ Standalone Enqueue Server (ASCS)
Lock management operation mode:
→ Lock management in a standalone server
Indicates use of ASCS instance
Typical path in UNIX:
p/SID/DV*/j2ee (for Java stacks)
or p/SID/ASCS<xx> (for ABAP)