WORKPROCESS

Basics
  Types of workprocesses

 PID

📘 SAP Dialog Work Process (DIA) – In-Depth Analysis

🔹 1. Purpose of Dialog Work Process

 Handles interactive user requests such as data entry, report execution, and transaction processing in real-
time.
 Provides immediate response to user input via the SAP GUI or web interface.
🔹 2. Key Characteristics
Feature Description

User Interaction Handles data read/write from the database and application logic execution in real-time

Short Tasks Only Designed for short-lived processes; long tasks must be run as background jobs

Multiplexing One dialog WP can serve multiple users (5–10 users depending on load and config)

Session Release Once a task is done, the process becomes free for others

Memory Use Each request uses approx. 75–300 MB

Minimum Count Minimum 2 dialog WPs (1 for dispatching, 1 for task execution)

More Dialog WPs Should outnumber non-dialog processes

Max per instance

 Up to 100 in NetWeaver ≤ 7.3

 Up to 600 in NW ≥ 7.4 |

🔹 3. Important Parameters (Profile)

Parameter Description

rdisp/wp_no_dia Number of dialog work processes

rdisp/max_wprun_time Timeout for dialog requests (default: 600–1800 sec)

rdisp/wppriv_max_no Max number of dialog WPs allowed in PRIV mode

rdisp/max_priv_time Maximum time a WP can stay in PRIV mode (default: 600 sec)
🔹 4. Monitoring Tools
T-Code Use

SM50 Local work process monitoring

SM66 Global work process monitoring

SM51 Application server overview

ST03N Dialog WP performance (response time, wait time)

ST02 Buffer/memory statistics

ST04 DB performance stats

SM04 / AL08 Logged-in user details

dpmon OS-level WP monitoring (via <SID>adm)

🔹 5. Dialog Work Process Status Types (in SM50)

Status Meaning

Waiting Idle, available for new request

Running Currently processing a user task

PRIV Using heap memory (private mode)

Stopped Terminated manually or due to error

On Hold Blocked by another process

🔹 6. Common Issues & Solutions

🟡 A. User Can’t Log In

 Reason: Dialog WP queue is full

 Solution: Increase rdisp/wp_no_dia or add additional app instance

🟡 B. Long-Running Task in SM50

 Action:
1. Check if user is still active
 2. Ask them to logout
3. Cancel the process if it's blocking others

🟡 C. Dialog WP Time Out

 Message: “Program time limit exceeded”

 Action:
o Increase rdisp/max_wprun_time
o Schedule the process as a background job via SM36

🔴 7. PRIV Mode – What It Means

PRIV Mode: When a dialog WP exceeds shared memory limits and uses heap memory, it becomes private and
cannot serve other requests.

Cause Example

Memory-heavy report Large ALV or full-table SELECTs

Inefficient code Nested loops, huge internal tables

Bad memory settings Misconfigured ztta/roll_area, abap/heap_area_dia

Large datasets Reports pulling GBs of data in one go

🔍 Identification

 Check SM50 / SM66 for status = PRIV

 Use ST02 and ST04 to analyze memory and DB load

🔧 Resolution
Step Action

1. Analyze Code Use SE30 / SAT to identify the memory-heavy logic

2. Optimize Break data into chunks; use pagination

3. Adjust Parameters Tune:

 abap/heap_area_dia
 ztta/roll_area
 em/initial_size_MB |
| 4. Convert to BTC Job | Schedule heavy task via SM36 |
| 5. Auto-terminate | Use rdisp/max_priv_time = 600 to kill WPs stuck in PRIV mode |

🔔 8. Messaging and Communication

Tool Purpose

SM02 System messages (One to Many)

SE37 Function modules (One to One messages)

SBWP Business Workplace notifications

🔐 9. Summary Best Practices

 Ensure enough dialog WPs for user load

 Monitor response time (<2 sec ideal), wait time, and memory
 Avoid running heavy reports in dialog mode
 Use load balancing via SMLG
 Tune buffer and memory parameters regularly

📘 SAP Background Work Process (Type: B) – Detailed Analysis

✅ 1. BASIC OVERVIEW

 Background Work Processes are used for executing long-running jobs in the background without user
interaction.
 These jobs are typically:
o Data-intensive
o Scheduled to avoid peak hours
o Used for system housekeeping, report generation, exports/imports, etc.

🔁 2. FUNCTIONAL BEHAVIOR
Feature Explanation

Long Execution Can run for minutes to hours or even days without timing out

No Timeout Unlike dialog WPs, background processes are not subject to GUI timeout

Full Transaction Handling Executes entire transaction (unlike dialog WPs that handle one dialog step at a time)

Dedicated Work Process Once assigned, it stays with the job until it finishes or is cancelled
⚙️3. TECHNICAL PARAMETERS
Parameter Description

rdisp/wp_no_btc Number of background WPs (min 2)

rdisp/btctime Job scheduler run interval (default: 60 seconds)

DEFAULT.PFL These parameters are stored in this profile

usr/sap/SID/SYS/global Location of background job logs

🔁 4. MINIMUM REQUIRED BTC WPs

At least 2 Background Work Processes are recommended:

 One for defining jobs (by the scheduler)

 One for executing the jobs

📌 5. JOB SCHEDULING
Via Transaction SM36
Field Details

Job Name Should start with Z or Y (custom convention)

Max Length 32 characters

Start Condition

 Immediate
 Date/Time
 After Job
 After Event
 At Operation Mode
 At Factory Calendar |

🧱 6. JOB STEPS

A background job can have 1 or more of the following step types:

🔹 6.1 ABAP Program

 Standard or Custom ABAP report

 Variants provide input during runtime
 Variant table: TVARV
 Created via: SE38 → Goto → Variants

🔹 6.2 External Command

 Pre-defined OS command created via:

o SM69 (define)
o SM49 (test)
  Executed using SAPXPG
 Used in DB13 for:
o brconnect -f check
o brconnect -f next

🔹 6.3 External Program

 Triggers OS-level programs directly using SAPEVT or events

 Used in:
o Transports (tp, R3trans)
o Backup, monitoring, file transfers

🔄 7. JOB MANAGEMENT COMMANDS

Transaction Purpose

SM37 Monitor and analyze jobs

BTCTRNS1 Suspend all background jobs

BTCTRNS2 Resume suspended jobs

🧾 8. JOB STATUS LIFECYCLE

Status Description

Scheduled Job created, but not yet started

Released Ready to be picked up by the scheduler

Ready Scheduler picked it up, waiting for free WP

Active Currently executing

Finished Successfully completed

Cancelled Terminated manually or failed due to error

🗂️9. BACKGROUND JOB TABLES (TBTC*)
Table Description

TBTCO Job overview/status

TBTCP Job steps and program links

TBTCS Job start time table

TBTCT Job template / definitions

⚙️10. JOB EXECUTION MECHANISM

1. User schedules a background job using SM36, SE38, SA38, DB13, SPAM, SAINT, etc.
2. The dispatcher receives the job request and assigns a dialog WP to save it in TBTC* tables.
3. The scheduler program SAPMSSY8 (running in dialog mode) checks every rdisp/btctime (default 60s) for
jobs with status READY.
4. A free background WP picks up the job and changes its status to ACTIVE.
5. Once completed, status is updated to FINISHED or CANCELLED.

🧹 11. HOUSEKEEPING & STANDARD JOBS

 SAP recommends scheduling standard housekeeping jobs post-installation via SM36:

o Clean spool requests
o Delete expired job logs
o Reorganize update requests
 DB13 schedules DB-specific jobs (backup, reorg, stats)
 These use ABAP programs and external commands combined
🧰 TIP: MONITORING
Tool Purpose

SM37 Job monitoring

SM50 Check background WP usage

ST06 CPU/Memory bottleneck analysis

SM21 Background job errors

ST22 Check ABAP runtime errors/dumps

📘 SAP Update Work Process (V1, V2, V3) – Complete Analysis

🔹 1. Purpose of Update Work Process

 Responsible for committing changes to the database after user transactions complete.
 It works asynchronously with no direct user interaction.
 Ensures data consistency and integrity by writing from temporary update tables (VB)* to permanent
database tables.

🔹 2. Types of Update Work Processes

Type Purpose Parameter Notes

V1 Critical, time-sensitive updates rdisp/wp_no_vb Must have at least one V1 WP

V2 Non-critical, statistical updates rdisp/wp_no_vb2 If not configured, handled by V1

V3 Reserved by SAP – Used for BW/logistics updates

🔹 3. Update Process Flow

1. User initiates a transaction via a dialog WP.

2. Dialog WP collects update data and writes to VB temporary tables*:
o VBHDR: Header info
o VBDATA: Actual update data
o VBMOD: Update modules
o VBERROR: Errors
3. Transaction is committed, and update requests appear in SM13 with status INIT.
4. The update WP picks up the request and performs DB operations (INSERT/UPDATE/DELETE).
5. The record status changes:
o RUN: In progress
o ERROR: Failed
o AUTO: Restarted automatically
o INIT: Waiting to be processed

🔹 4. Transaction Codes
T-Code Description

SM13 Monitor update requests

SM14 Update administration (do not deactivate manually in PROD)

🔹 5. VB* Temporary Tables

Table Description

VBHDR Update header

VBDATA Update data

VBMOD Update function modules

VBERROR Error logs

VBWRK Worklist for mass processing

🔹 6. Update Modes
Mode Description

Local Update Dialog WP updates DB directly (rare)

Synchronous Update Temp table used; update occurs once all dialog steps are committed

Asynchronous Update Temp table entries written during dialog steps; DB updated later by Update WP

🔹 7. Key Parameters
Parameter Purpose

rdisp/vb_stop_active Controls automatic update deactivation (0 = off, 1 = on)

rdisp/vbreorg 1 = Delete incomplete updates on WP startup

rdisp/vbdelete Auto-delete old update records

rdisp/vbmail Sends mail on update errors

rdisp/vbname Specifies update server

 Parameter Purpose

rdisp/vb_delete_after_execution 1 = Delete update records after processing

🔹 8. Update Status Meanings

Status Description

INIT Initial state – waiting for update WP

RUN Update currently being processed

ERROR Update failed

AUTO Update restarted automatically after deactivation

🔹 9. Common Issues & Troubleshooting

🛑 Update Deactivated
Possible Cause Resolution

Tablespace full (ORA-1653/1654) Add/resize tablespace

ORAARCH full Trigger archive log backup

Max extents reached (ORA-1631/1632) Increase max extents

Deadlock / Kernel issue Apply SAP Notes, verify kernel version

💡 To Check:

 SM21, ST22, SM13, work directory traces

 Restart updates using SM14 after issue is resolved
 Trigger report RSM13002 to clean VB* tables

🔹 10. Update Reorganization & Cleanup

 Run report RSM13002 regularly for housekeeping.

 Enable:
o rdisp/vbreorg = 1
o rdisp/vbmail = 1

🔹 11. Performance Notes

 At least 1 V1 WP per 5 Dialog WPs.

 Insufficient update WPs cause INIT backlog.
 SAPMV45A is a sample program that uses update mechanism.
 One failed update in a busy system can block all others — causes full system stall.

🔹 12. Advanced Notes

 Updates stuck for long? Check if:

o Deadlocks exist
o V1/V2 queue is blocked
o Update process is hung
 Reprocess failed updates:
 o Use SM13 → select failed record → repeat update
o If you get INSERT_DUPLICATE RECORD FAILED:
 Means data already exists in DB (check logic before retrying)

🔍 Summary
Topic Tool

Monitoring SM13, SM14, SM66, SM21

Trace Work directory logs, OS logs

Analysis ST22 (Dumps), DB logs (ORA*)

Cleanup Report RSM13002

Config RZ10 profile parameters

📘 SAP Enqueue Server (E) – In-Depth Technical Analysis

🔹 1. Overview

The Enqueue Work Process is responsible for:

 Locking and unlocking business objects to ensure data consistency across SAP transactions.
 Managing concurrent access by multiple users to the same data objects using a central lock table in
memory.
🔹 2. Basic Characteristics
Feature Description

Lock Management Prevents data inconsistencies by serializing user access to database objects

Lock Table Stored in main memory; not in the database

Configured In Typically on the Central Instance (CI) or ASCS (for ABAP stack)

Parameter rdisp/wp_no_enq – Defines number of enqueue WPs (typically 1)

Lock Table Size Controlled by enque/table_size (in MB, default: 4–100 MB)

Directory Lock trace/logs → /usr/sap/SID/<instance>/log

Lock Table Structure Internally maintained as TLOCK in memory

🔹 3. Types of Locks
Lock Type Description

Shared Lock Allows multiple read-only accesses, no updates

Exclusive Lock Allows only one user to read/write

Cumulative Lock Multiple locks on the same object by the same transaction

Optimistic Lock Used when it's expected that no conflict will occur (less common in ABAP stack)

🔹 4. Lock Table

 The lock table exists only in memory of the enqueue server instance.
 It contains lock entries set by update or dialog work processes.
 No locks are stored in the database → improves performance, but requires caution during system restarts or
crashes.

🔹 5. Monitoring & Administration

T-Code Purpose

SM12 View/Delete current lock entries

SM01 Lock/Unlock specific T-codes (for control, not related to object locking)

AL08 / SM04 See which users are using locks (indirect)

SM21 System logs for enqueue failure or lock timeouts

🔹 6. Enqueue Replication Server (ERS)

Feature Description

Purpose Ensures high availability by replicating the lock table

Used In SAP High Availability (HA) setups with ASCS instance

Mechanism Replicates memory-based lock table to other node

Failure Handling If primary enqueue server crashes, lock replication ensures failover consistency

Location Installed on every failover node

🔹 7. Troubleshooting
🛠️Common Enqueue Issues
Symptom Cause Solution

Lock not released User didn't log off cleanly Use SM12 to manually delete the lock

Lock table full Too many concurrent locks Increase enque/table_size

Enqueue server crash Memory or kernel issue Check logs in /usr/sap/SID/<inst>/log

Lock not granted Already held by another user Investigate conflict in SM12 or via application logic

🔹 8. Best Practices

 Never manually delete locks unless you are sure no process is using it.
 Use ERS in production for HA setups to avoid data corruption during failovers.
 Monitor SM12 regularly for old or orphaned locks.
 Use SM21 and work process traces to diagnose enqueue problems.
 Define lock granularity carefully during ABAP development to avoid over-locking.

🔹 9. Memory Sizing Guidelines

Parameter Description

enque/table_size Total memory allocated to lock table

rdisp/wp_no_enq Number of enqueue WPs (default = 1)

em/initial_size_MB Total extended memory; should be sufficient for enqueue operations too

📘 SAP Gateway Work Process (G) – Detailed Technical Analysis

🔹 1. Overview

The Gateway Server in SAP enables communication between:

 SAP ↔ Non-SAP systems (e.g., Java, .NET, legacy apps)

 External clients ↔ SAP (via TCP/IP)
 Remote Function Call (RFC) connections
🔹 2. Key Characteristics
Feature Description

Communication Role Acts as a middleware bridge between SAP and external (or other SAP) systems

Processes per Instance Exactly 1 Gateway per application server instance

Visibility Not shown in SM50

Ports Used

 Default: sapgw00 = TCP port 3300 + instance number

 Secure Gateway: TCP port 4800 + instance number |
| Tool for Deployment | Additional gateways can be installed using SAPINST if needed |

🔹 3. Common Use Cases

 External systems using RFC (Remote Function Calls)

 Middleware integration (PI/PO, SAP Cloud Connector)
 BI tools (Power BI, Tableau) communicating with SAP
 Third-party monitoring or printing tools
 Communicating across different SAP components (SRM, CRM, SCM, SOLMAN)

🔹 4. Monitoring & Tracing

Layer Tool

SAP GUI Level SMGW – Gateway monitor

OS Level GWMON – OS-level process status

Trace File dev_rd in /usr/sap/SID/Instance/work

 Layer Tool

Other SM21 (for logs), ST22 (if dump occurs during RFC)

🔹 5. Gateway Parameters
Parameter Description

gw/max_conn Max concurrent connections allowed (Default = 500)

gw/keepalive Frequency to check idle connections (Default = 300 sec)

gw/timeout Time limit for establishing a connection (Default = 10000 ms or 10 sec)

💡 No SAP parameter exists to increase the number of gateway processes; only one gateway process per instance
is allowed.

🔹 6. Related SAP Transactions

T-Code Description

SMGW Gateway monitor – active connections, registered programs, etc.

SM59 RFC Destination configuration (relies on Gateway)

SMICM ICM Monitor – works alongside Gateway for HTTP/SAP GUI for HTML

SMLG Load balancing for logon groups

SE38/SA38 Run gateway diagnostics programs (e.g., RSSTAT60)

🔹 7. Typical Gateway Issues

Symptom Cause Resolution

RFC connection failure Program not registered Check SMGW > Registered programs

Timeout errors Firewall, proxy, or connection blocked Check port 3300+ and confirm routing

Connection drops Idle timeout too short Increase gw/keepalive or check external system behavior

Gateway memory full Too many open sessions Increase gw/max_conn or clear unused RFC sessions

🔹 8. Security Best Practices

 Use secure gateway (port 48xx) for encrypted communication.

 Define allowed/blocked RFC destinations using reginfo/secinfo files.
 Use SAP Gateway Security Log for auditing RFC calls.
 Monitor unregistered external program access attempts in SMGW logs.

🔹 9. Troubleshooting Steps

1. Check SMGW:
o Look for “Registered Programs”
o Analyze current connections
2. Check dev_rd trace for:
o Program errors
o Invalid connections
 3. Validate connection using SM59:
o Use connection test
o Use "Remote logon" to validate trust
4. Use SMICM:
o For HTTP/SOAP-based Gateway calls
5. If using PI/PO or CPI:
o Ensure port 3300+<instance> is open in firewall
o Registered program name must match

🖨️SAP Spool Work Process – Detailed Technical Documentation

🔹 1. Overview

The Spool Work Process (S) in SAP is responsible for:

 Managing print requests

 Creating spool and output requests
 Interfacing with OS-level print services

🔹 2. Core Characteristics
Feature Description

Purpose Manages document printing in SAP

No. of Processes Minimum 1 per SAP system; configurable up to 512

Parameter rdisp/wp_no_spo (configured via RZ10 or RZ11)

Logs Location /usr/sap/SID/SYS/global

 Feature Description

Spool Storage Controlled by rdisp/store_location

Spool Mechanism Works on WORM (Write Once, Read Many) principle

🔹 3. Spool Storage Location

Setting Description

G Global Directory (/usr/sap/SID/SYS/global)

DB SAP Database Tables (TST01 – TEMSE directory, TST03 – output requests)

🔹 4. Access Methods for Printing

Method Use Case

Local Printing via local spooler of the SAP application server

Remote Uses an RFC destination to print on a remote host

Front-End Directly from user's SAP GUI to local printer

🔹 5. Key SAP Transactions

T-Code Purpose

SP01 Display Output Requests

SP02 Display Spool Requests

SPAD Configuration of Output Devices

SP11 Display TEMSE Directory

SP12 TEMSE Administration (memory usage, cleanup, statistics)

🔹 6. Database Monitoring
Table Description

TSP01 Spool request table

TSP03 Output request table

TST01 TEMSE directory

TST03 Output request info

Check these using SE16/SE16N.

🔹 7. Spool Request Lifecycle

 Created by: Dialog or Background work process

 Stored in: TEMSE
 Print anytime using SP01 until deleted
 Can be printed multiple times unless sensitive or confidential (set for auto-delete)
🔹 8. TEMSE Administration

Use SP12 to:

 Monitor spool memory consumption

 View spool usage by client, user, time
 Detect and fix spool inconsistencies

🔹 9. Spool Reorganization
Report Purpose

RSPO1041 / RSPO0041 Delete old spool requests

RSPO0043 / RSPO1043 Check and fix spool consistency

🟢 Best Practice:

 Schedule reorg jobs daily

 Archive important requests
 Prevent spool overflow to avoid backup tape errors or TEMSE database bloat

🔹 10. Troubleshooting Tips

Issue Resolution

Spool not printing Check SP01 and SP02 for status

Print job stuck in queue Check spool server connection and printer status

TEMSE growing too large Schedule spool deletion reports, use SP12 for monitoring

Output not matching print layout Check device type in SPAD, ensure correct driver
  Administration Tasks for AS ABAP

SM50 (Work Process Overview)

 It is used to monitor and manage workprocess.
 In the work process overview, you can
📘 SM50 – Work Process Overview Fields (Menu Tabs)

Field Description Remarks / Use Case

Internal number (index) of the work process within the Helps identify messages related to this process in system logs
NO
instance. (SM21).

TYPES Type of work process. Main types include:

- DIA – Dialog Used for interactive user sessions.

- UPD – Update V1 Writes critical data changes to the database.

- UP2 – Update V2 Writes less critical data changes.

- ENQ – Enqueue Manages locks in the lock table.

 Field Description Remarks / Use Case

- BTC – Background Executes jobs scheduled in background.

- SPO – Spool Handles printing and output requests.

Use this with OS tools (top, ps, nmon) to trace CPU/memory

PID Operating System process ID.
consumption.

STATUS Current state of the work process:

- RUNNING – Actively executing a request. Normal behavior.

- WAITING – Idle, ready for new request. Normal if enough free processes.

Check "Reason" for HOLD. Too many in HOLD = performance

- HOLD – Exclusively held for a user.
bottleneck.

Needs investigation. Can be restarted via: Process >

- STOPPED – Terminated and not restarting.
Restart after error > Yes.

REASON Reason for current status (usually HOLD). Indicates what the process is waiting for.

Common values:

- DEBUG – Debug session active Developer debugging a program.

- RFC – Waiting for remote function call Indicates possible RFC delays.

Each corresponds to specific component delays (locking,

- ENQ, UPD, SPO, ADM, NUM, GUI, PRIV, LOCK, etc.
updating, printing, admin tasks, etc).

- SLEEP – Process idle due to resource bottleneck Usually memory or CPU bottleneck.

- MS, MSOP – Message server synchronization Related to logon load balancing.

- JAVA, VM – Waiting for Java VM Found in dual-stack or Java stack.

Whether the process will be restarted automatically if it Should be Yes. Can be changed via menu: Process >
START
crashes (Yes or No). Restart after error.

Monitor if this number increases; indicates faulty program or

ERROR Number of times this work process has crashed.
memory issue.

SEM Semaphore used for resource control.

- Green – Process holds the semaphore Normal when it’s actively working.

- Red – Process is waiting for the semaphore Could indicate lock contention or bottleneck.

Cumulative CPU time (in seconds) used by the work process

CPU Helpful for identifying heavy processes.
since instance start.

Time in seconds the process has been busy with the current If high and stuck in one status → might be long-running process
TIME
task. or infinite loop.

PRIV This indicates that the work process is working in private

Mode mode. Happens when:

- The user’s session exceeds ztta/roll_extension

memory.

- The work process has switched to using its own private

Performance may degrade.
memory, not shared pool.

- Suggestion: Increase em/initial_size_MB to reduce

frequent switch to PRIV.
🔍 Key Troubleshooting Tips in SM50
Scenario What to Check

Several processes in HOLD Look at "REASON". Identify bottlenecks like RFC, ENQ, SPO, etc.

Many processes in PRIV mode Indicates memory shortage. Check memory parameters like em/initial_size_MB.

Process in STOPPED state Likely due to repeated error. Check work process trace (dev_w*)

Constant high CPU usage Check if a long-running job or loop is consuming it. Use ST03/STAD for analysis.

ERROR count rising for a PID Indicates unstable process. Deep dive into traces and job logs.

✅ 1. PRIV Mode (Private Memory Exhaustion)

Occurs when a dialog work process switches from shared to private memory due to memory limits being exceeded.

🔧 Parameters to Tune:
Parameter Description Recommended Action

em/initial_size_MB Size of extended memory Increase to allow larger shared memory pool

ztta/roll_extension Max roll extension memory per user Increase to postpone switch to PRIV

abap/heap_area_dia Max heap (private) memory for dialog WP Ensure not too high; prevent OS-level paging

abap/heap_area_total Total heap memory available to all WPs Adjust accordingly to avoid overcommitment

🧪 Tips:

 Monitor with SM50/SM66 (PRIV in status).

 Use ST02 for memory buffer tuning.
 Use se30/SAT for heavy transactions.

✅ 2. HOLD Status (Work Process Waiting)

Work process is idle, usually due to external resource locks or waits.

🔧 Common HOLD Reasons & Fixes:

REASON Cause Suggested Action

ENQ Waiting for a lock Check SM12, increase enque/table_size if overflow

RFC Waiting for RFC return Analyze RFC destination with SM59, check network

UPD Waiting for update process Use SM13 to check backlog, tune update WPs

CPIC Waiting for CPIC communication Check for hanging third-party apps or gateway

DEBUG Being debugged Normal for dev use, but check if unnecessary

PRIV Switched to private memory See above (PRIV tuning)

🧪 Monitoring Tools:

 SM66 → Global Work Process Overview

 SM12 → Lock entries
 ST05 (Enqueue trace) → For lock contention
 SM13 → Update status
 ST22 → Dumps related to memory or lock overflows
✅ 3. STOPPED / Frequent Crashes

Indicates instability in a work process due to resource limits, dumps, or bugs.

🔧 Parameters to Check:
Parameter Description

rdisp/wp_auto_restart Auto-restarts work processes

rdisp/wp_no_dia / *_btc / *_enq Ensure correct number of work processes

rdisp/autoabaptimeout Kill long-running processes automatically

🧪 Logs to Analyze:

 dev_wXfiles in /usr/sap/<SID>/<inst>/work
 Use SM21 / ST22 for application-level errors

✅ 4. Enqueue Lock Table Overflow

Locks exceed table size → causing HOLD or failure.

🔧 Parameters:
Parameter Description Action

enque/table_size Size of the lock table in memory (KB or MB) Increase (e.g., from 8MB to 32MB)

🧪 Also check SM12 > Extras > Top Capacity Used

🔒 How to Prevent Dialog Work Process from Entering PRIV Mode

What is PRIV Mode?

A dialog work process enters PRIV mode (private mode) when a user session requires more memory than allowed in
the shared memory pool. The process becomes dedicated to that user and is no longer available for others—leading to
performance issues or work process shortages.

✅ Key Profile Parameters to Control PRIV Mode

1. rdisp/max_priv_time
o Purpose: Limits the maximum time a dialog work process can stay in PRIV mode.
o Action: Set a lower value (e.g., 600 seconds) to prevent long-lasting PRIV sessions.
o Default: 1800 seconds (30 mins).
2. rdisp/wppriv_max_no
o Purpose: Sets the maximum number of dialog work processes allowed in PRIV mode.
o Action: Tune this value based on your system load and available memory.
o Default: 1 (usually very restrictive).
3. rdisp/max_wprun_time
o Purpose: Maximum runtime (in seconds) of a dialog work process before it is terminated.
o Action: Prevents long-running user sessions from consuming work processes indefinitely (which may
lead to PRIV).
o Example: 600 seconds (10 minutes).
🧠 Related Memory Parameters to Tune

4. abap/heap_area_dia
o Purpose: Limits heap memory usage per dialog work process.
o Action: Lower values will force earlier memory exhaustion, reducing time spent in PRIV.
o Note: If exceeded, process goes into PRIV or terminates based on behavior and other limits.

⚠️Important Notes

 A dialog WP in PRIV mode will only be released when:

o The task completes.
o Memory is exhausted.
o It is terminated due to timeout (rdisp/max_wprun_time).
 This condition is also known as “hourglass mode”, causing UI freezes or congestion.
 Monitoring Tools:
o Use SM50 or DPMON to identify PRIV WPs.
o Use SM04 to identify user sessions.
 Termination:
o Try terminating the user session via SM04 or DPMON.
o As a last resort, kill the process at the OS level using the PID (shown in SM50).

🔧 Best Practices
Action Benefit

Set rdisp/max_priv_time to a lower value Prevent long PRIV sessions

Keep rdisp/wppriv_max_no minimal Avoid too many blocked WPs

Regularly monitor heavy transactions Prevent memory spikes

Use background jobs for large reports Offload memory-intensive tasks

⚙️SM50: Cancel with Core vs Cancel without Core

In transaction SM50 (Process Overview), you can cancel running or hanging work processes. SAP provides two
options for this:

✅ 1. Cancel with Core

  Function: Forcefully cancels the selected work process and generates a core dump.
 Core Dump File: A memory image of the process at termination is written for debugging.
 File Location: The core dump can be analyzed using transaction ST11 or checked in the
/usr/sap/<SID>/<instance>/work directory.
 Behavior:
o Process is terminated, but still appears in SM50 until it is cleaned up.
o Useful for SAP Support or developers when analyzing system crashes or severe errors.
 Check Logs:
o Review SM21 for system log entries related to termination.
o Also useful for finding dump causes like segmentation faults, memory access errors, etc.

✅ 2. Cancel without Core

 Function: Gracefully cancels or ends the selected work process without writing a core dump.
 Use Case:
o Ideal for safely terminating stuck or long-running processes that are not needed.
o Select only processes in “running” or “stopped” state.
 Behavior:
 o Process gets cleanly terminated and disappears from SM50 after completion.
 Check Logs:
o Termination info can also be found in SM21.

📝 Important Notes

 If SM50 Termination Fails:

o Identify the PID (Process ID) of the work process from SM50.
o Kill it at the OS level using:
o

On
Windows, terminate via Task Manager by identifying the corresponding process (disp+work.exe).

🔍 Summary Table
Feature Cancel with Core Cancel without Core

Core file generated? ✅ Yes ❌ No

Use Case For debugging & SAP support For normal termination

Still visible in SM50? ✅ Temporarily ❌ Removed after termination

Log Location ST11, SM21 SM21

OS-level intervention Sometimes needed if stuck Less likely

🛠️SM50 — Cancel with/without core does not work

Sometimes, when a work process hangs or enters a non-responsive state, attempting to cancel it from SM50 fails.
In such cases, manual termination from the operating system (OS) level is necessary.

🪟 1. On Windows
🔹 Steps:

1. Open PowerShell as Administrator.

2. Find the process using its PID (shown in SM50).

3. Forcefully terminate the process:

🔸 Example:

🐧 2. On Linux/Unix
🔹 Steps:

1. Login as root or a user with proper privileges.

2. Check if the process exists and confirm it:

3. Kill the process forcefully:

🔸 Example:

⚠️Important Notes

 Be very careful when killing processes at OS level — always double-check the PID.
 After killing, verify in SM50 that the process slot is now free or restarted.
 For persistent issues, check related logs in:
o Windows: dev_w* files under \usr\sap\<SID>\<instance>\work
o Linux: Same location /usr/sap/<SID>/<instance>/work/
 Consider restarting the instance if multiple processes hang repeatedly.

✅ Set SAP Trace Level of Information

🧩 1. Parameter: rdisp/TRACE

This controls the amount of information logged in developer trace files (e.g., dev_w0, dev_disp).

Value Meaning

0 Log errors only

1 Log errors + warnings (default)

2 Log errors + warnings + brief trace

3 Log everything: errors, warnings, and detailed trace (for deep troubleshooting)

🛠️Set in Instance Profile:

📌 Apply using: RZ10 → Save → Activate → Restart instance.

🧩 2. Set Trace Dynamically in SM50

No restart needed. Applies to specific work processes.

Steps:

 Go to SM50
 Select the work process
 Menu: Process → Trace → Active Components

 Set trace level 0 to 3 for specific components

📎 Notes:

 Higher trace levels consume more disk I/O.

 Use level 3 temporarily (for debugging issues).
 Trace files are located at:

🔄 Reset Trace Files via SM50

You can clear or reset trace files directly from SM50 to free space or remove old debug data.

✅ Steps:

1. Go to transaction code SM50

2. Select a specific work process or leave unselected for all
3. From the top menu, choose:
Process → Trace → Reset →
 o All files → Resets all trace files (dev_w*, dev_disp, etc.)
o Workprocess files → Resets only the selected work process trace (dev_wX)

⚠️Note:

 Does not affect running processes—only clears content of trace files.

 Useful when you want to analyze fresh traces without old clutter.

📂 Location of SAP Trace Files

Trace files are usually located in the work directory of the SAP instance:

/usr/sap/<SID>/<Instance>/work

Example:

🧹 Command-Line Steps to Reset Trace Files

You can manually clear trace file contents using the truncate or :> shell command:

✅ Option 1: Truncate All dev_ Files

✅ Option 2: Truncate Specific Trace File (e.g., dev_w0)

✅ Option 3: Use find (if there are many traces)

⚠️Important Notes

 Do not delete trace files (rm)—just clear their contents.

 Ensure no active troubleshooting is ongoing when clearing traces.
 Perform this as the <SID>adm user.

✅ 1. Using ps Command

Run this as the <SID>adm user:

Example:

This shows the running SAP work processes like disp+work, gwrd, etc.

✅ 2. Using SAP Kernel Utility: dpmon

SAP provides the dpmon tool to monitor dispatcher and work process states directly:

Then press:

 d → to display dispatcher and WP overview

 q → to quit

It shows info like:

 Process type (DIA, BTC, UPD, etc.)

 Status (Running, Waiting, Stopped)
 Memory used
 WP number

✅ 3. Using top or htop

You can identify WPs by their CPU or memory usage. Work processes appear with command names like:
✅ 4. Check dev_w Logs*

Go to:

Use tail or less:

This shows runtime logs and errors for individual work processes.

The dpmon tool (Dispatcher Monitor) in SAP is a command-line utility that allows you to monitor the status of SAP
work processes directly from the OS level — especially useful when the SAP GUI is not accessible.

✅ Location of dpmon

You can usually find it here:

✅ How to Run dpmon

🔸 Replace <SID> with your SAP System ID

🔸 Replace <Instance_Profile> with the full name of your instance profile
(e.g., DVEBMGS00_<hostname>)

✅ Key Navigation Inside dpmon

Once the tool starts:

Key Function

d Display dispatcher and work process table

m Memory info per work process

s Show shared memory info

v Version of the kernel

t Show trace info

q Quit the tool

✅ Example Output After Pressing d

✅ Why Use dpmon

 You can monitor WPs without GUI

 Very useful in emergency troubleshooting
 Can verify memory usage, PID, status, and locks
 Lightweight and doesn't require a running SAP GUI

✅ 1. Using dpmon Tool

Path:

Purpose:

 It displays the internal WP status table directly from the OS.

 Similar to SM50, but usable even when SAP GUI is not available.

Usage:

You will see:

 WP type (DIA, BTC, SPO, UPD, etc.)

 PID
 Status (Wait, Hold, Stopped, etc.)
 User, Client, and Program (if running)
✅ 2. Using sapcontrol Utility

Command:

Example:

Output:

 Lists all current WPs, their PID, type, status, and reason.
 Similar to SM50 but can be scripted or used remotely (e.g., via shell script or monitoring tools).
✅ When to Use These Tools
Tool Use Case

dpmon Deep dive analysis from SAP kernel level

sapcontrol Quick scripting, automation, remote diagnostics

Both are useful during:

 SAP startup troubleshooting

 WP stuck/PRIV mode analysis
 No SAP GUI availability (headless analysis)

✅ List CPU Time Usage in SM50

Navigation:

SM50 → List → CPU

Purpose:

 Displays cumulative CPU time used by each work process.

 Helps identify long-running or CPU-intensive processes.

Use Case:

 Detect performance bottlenecks

 Analyze which WPs consume most CPU time

✅ SM50 Logon Trace (Security Trace for Logon Issues)

1. Enable the Trace

 Go to SM50
 Menu: Administration → Trace → Reset → Workprocess Files
 o Confirm the reset
 Then: Administration → Trace → Active Components

o Set:
  Trace Level: 2
 WP Type: DIA
 Component: Select only Security
o Save → DIA rows turn yellow (trace is active)

🔁 Repeat on all app servers via SM51

2. Disable the Trace

 In SM50, go to Administration → Trace → Active Components

 Remove/clear previous settings → Save
→ Rows return to normal color
✅ Identify Delayed Jobs

1. SM50
 o Look for BTC (background) work processes
o If all are in "Wait" → normal
o If many are "Running" too long or none are free → possible delay
2. SM37
o Check for jobs with "Released" or "Ready" status not starting on time
o Sort by Scheduled Start Time and Actual Start Time

🛠️Prevent Background Job Delays

1. Check Dispatcher Timer:

o Go to RZ11
o Look for: rdisp/btctime
 Default: 60 seconds (dispatcher checks job queue every 60s)
 You can reduce (e.g., to 30) to improve responsiveness
2. Check BTC Work Process Count:
o In RZ10 or instance profile:
Parameter: rdisp/wp_no_btc
 Increase if job volume is high and BTCs are fully occupied
3. Check Job Logs:
o Use SM37 → Job Log to find errors or locks
4. Database Locks or Enqueue Wait?
 o Use SM12 and DB tools to check lock contention

Semaphores Status Information in SM50:

🔍 1. Symptoms

 In SM50, under the "Sem" (Semaphore) column, you see values like yes, no, or wait times.
 If a work process is stuck, it may be waiting for a semaphore, which indicates contention.

🧰 2. How to Analyze Semaphore Status

📍 From SM50:

 Go to SM50 → Select a work process → Click on the “Sem.” column → Press F1

→ A popup opens with information on semaphore status.
✅ Color Meanings:
Color Meaning

Green Work process is holding the semaphore

Red Work process is waiting for the semaphore

Gray/blank No semaphore involvement

🧪 When to Investigate Further

 If many WPs show red in Semaphores, or jobs are delayed/stuck, suspect enqueue or program locks.
 Use SM12 (lock entries) or SM21/ST22 for system-level clues.

🛠️Helpful Tips

 Use SM50 → Process → Details to view full task info.

 If contention is frequent:
o Check program logic (infinite loop, SELECT…FOR UPDATE without COMMIT).
o Review Enqueue Server health or increase enqueue/table_size.
o In cluster environments, check network latency between CI and DI instances.

✅ 1. OS-Level Semaphore Status (for SAP Work Processes)

SAP work processes use System V semaphores. You can monitor these using standard Linux/UNIX tools:

🔍 A. Use ipcs -s

 Shows all active semaphores.

 Look for semaphores created by user sidadm.

Example output:

🔎 B. View Semaphore Usage by SAP Instance

Use sapcontrol to list work processes and match them to semaphore owners:

Then correlate the PID shown here with OS-level semaphores using:
✅ 2. Advanced Semaphore Analysis with dpmon Tool

SAP provides dpmon (Dispatcher Monitor) in the kernel directory for low-level work process monitoring:

🔧 Run dpmon

📘 dpmon → Use Option 1 for Work Process Overview

 You can see detailed information like:

o Status (Running, Waiting, Hold)
o Semaphore ID
o Enqueue state
o Memory consumption (Roll/Heap/Extended)

Similar to SM50, but at the OS level. Also useful when GUI is inaccessible.

✅ 3. Enqueue Lock Table Analysis (Similar to SM12)

Use enqt tool:

 Lists locks similar to SM12

 Good for analyzing enqueue contentions when SM12 is slow/unavailable

🧠 Summary Cheat Sheet

Tool Purpose

ipcs -s View semaphore sets

dpmon Detailed WP/semaphore/memory status

enqt Display enqueue locks (like SM12)

sapcontrol List workprocesses, match with PIDs

🛑 Scenario: SAP Work Process is Stuck in “Hold” or “Semaphore” State in SM50

🔍 Step 1: Identify the Problem in SM50

 Go to SM50
 Status shows: Hold or Waiting for Semaphore
 The Semaphores column shows a number
  Check with F1 on semaphore field:
o 🔴 Red → Waiting
o 🟢 Green → Holding

🧪 Step 2: Confirm via OS (Linux)

1️⃣ List semaphores

Look for unusually high numbers of semaphores or ones that are not being released.

2️⃣ Identify the PID holding the semaphore

Use grep with semaphore ID or sort by memory/time to find the stuck process.

🧰 Step 3: Use dpmon to Drill Deeper

 Press 1 → Work process overview

 Press 4 → Check memory and semaphores

Look for:

 State: HOLD, RUN, PRIV

 High memory usage
 Held semaphores

✅ Step 4: Kill the Stuck Work Process

If it’s clearly stuck (not releasing semaphores, high time or loop):

✅ This will force the work process to restart automatically if instance is healthy.

Note: Don’t kill enqueue or message server WPs unless absolutely needed.

🔁 Step 5: Reset Semaphores (Only if Orphaned)

Sometimes SAP doesn't clear semaphores even after kill. Use this with extreme caution:
Clean semaphores manually:

⚠️WARNING: Only use this after shutting down SAP cleanly (to avoid data corruption).

🚫 When NOT to Kill:

 If status is briefly in HOLD but not consuming CPU, it may be normal (short lock)
 Always analyze first. Don’t kill blindly.

🧠 Tips to Prevent Recurrence

Symptom Prevention

Frequent HOLDs Tune memory parameters (ztta/*, em/*)

Semaphore overflow Kernel patch level, reduce long DB calls

PRIV mode frequent Set memory quota correctly

Hangs in lock Split large batch jobs, review DB indices

🔍 Identifying the Semaphore Locker in SAP

1. 🖥️Using SM50 (Work Process Monitor)

 Go to SM50 → Look for status = 'Sem.Wt' (Semaphore Wait).

 Click the Semaphore No. column.
 Press F1 to open help → Shows which WP is holding the semaphore.
 🔴 Red box = WP is waiting, 🟢 Green box = WP is holding the semaphore.
 Note the PID (Process ID) and username.
2. 🧰 Using DPMON (Dispatcher Monitor - OS Tool)

 From OS:
 dpmon pf=/usr/sap/<SID>/SYS/profile/<INSTANCE_PROFILE>
  Use se command inside DPMON.
 It lists workprocesses and semaphore status, and shows lock holder PID.
 Fast and lightweight tool for emergency troubleshooting.

3. 🧱 Using SAP MMC (Windows Only)

 Launch SAP Management Console (SAPMMC)

  Right-click instance → Select Processes
 Check status of Dialog or Update WP
 Look for semaphores stuck or not released.
 May need trace files (dev_wp*) for deeper info.

4. ⚙️Using SAPCONTROL (Cross-platform)

 Use:
 sapcontrol -nr <InstanceNo> -function ShowProcessTable

 Identify WPs in Sem.Wt or PRIV or long wait states.

 Advanced: GetWPTable or GetWorkProcessTable via HTTP SOAP/REST calls.

✅ Command Syntax:

🔍 Explanation:

 sapcontrol: SAP-provided command-line tool to manage and monitor SAP instances.

 -nr <InstanceNo>: SAP instance number (e.g., 00, 01, etc.).
 -function GetProcessList: Requests the list of processes managed by the SAP instance.
📋 Sample Output:

🟢 What You Learn:

 Whether core SAP processes like disp+work, msg_server, igswd, etc., are running or not.
 Status: GREEN, YELLOW, or RED
 Start Time and Uptime

📌 Use Cases:

 Quickly verify if all SAP instance services are running (helpful during restart or troubleshooting).
 Used in automation scripts for health checks.
 Useful in non-Windows (Linux/UNIX) systems where SAP MMC is not available.

If you want workprocess details like dialog/update status, use:

5. 📸 Using Dispatcher Snapshot (SM51 → Snapshot)

 Go to SM51 → Select instance → Menu:

Goto → Administration → Snapshot → Create
 It creates a memory and process state snapshot.
 Review the dev_disp and dev_wp* logs for lock ownership and semaphore contention.
 Workprocess Termination cases
 Analysis of Workprocess in “On Hold” RFC on a hanging system
 Analyzing server snapshots with Kernel snapshots analyzer
📌 How to Obtain SM50 Work Process History
✅ 1. Using Report /SDF/MON

This report is part of SAP Support Tools to monitor work process usage and performance history.

🔹 Step-by-Step:

1. Go to transaction: SE38
2. Execute report: /SDF/MON
3. On the selection screen:

o Enter date/time for the analysis

o Choose duration (if needed)
o Press Execute (F8)
4. Once the output appears, focus on:
 o Work Process Status over time
o Busy / Waiting / PRIV states
o Top memory consumers
o Program names (Z reports or standard)
o User IDs and Task types

💡 Tip: You can also schedule /SDF/MON as a background job to collect work process history periodically.

✅ 2. Using Transaction ST07

This is the Application Monitor, showing system performance and WP usage over time.

🔹 Step-by-Step:

1. Go to transaction: ST07
2. Wait for system to collect data (can take a few seconds)
3. Click on the "History" button
4. Select the Date Range
5. Choose "Period Drilldown"

6. Navigate to Used Work Processes ➝ Displays number of DIA, BTC, UPD, ENQ, etc., used per hour/day
🖼️Output:

 Graphical and tabular representation of WP usage

 Shows work process consumption trends
 Helps identify peak load time or over-utilization

🔍 Use Cases

 Identify performance bottlenecks

 Analyze peak hours
 Spot custom reports causing PRIV or long DIA usage
 Validate whether more WPs are needed

🧰 SAP Application Server Basics & Troubleshooting Checklist

🔹 1. Instance Status & Monitoring (Basics)

✅ SM51 – Application Server Overview

Use transaction SM51 to check:

 All available application servers.

 Hostnames of active instances.
 Server status – active/inactive/starting/stopped.
 No. of users logged into each instance.
 Workload/load estimate per instance.
 Queue information and SNC (Secure Network Communication) status.
🔍 If an application server is not available, it won’t be listed in SM51, and its hostname cannot be retrieved.

✅ RZ03 – Instance Status Overview

 View status of all instances in a centralized view.

 Shows whether each instance is active/inactive, and if logon load distribution is balanced.
🔹 2. Kernel Level Consistency Check

Ensure that the kernel patch level is the same across all relevant locations:

Location Description

/usr/sap/SID/DV*/exe Kernel of Central Instance (CI)

/usr/sap/SID/exe Global kernel directory (shared)

/usr/sap/SID/D*/exe Kernel of Dialog/Application Server

🔄 Kernel version mismatch can lead to unexpected crashes or connection errors.

🔹 3. Restart & Cleanup Procedure

If an application server is misbehaving or not coming up:

🛑 Stop Services

 Stop all SAP and Database (DB) services from OS level or MMC.
 Ensure no services are running:

 Kill any remaining processes:

🧹 Clean Shared Memory

 Clean up shared memory and semaphores:

▶️Start Services

 Start the database first, then SAP services.

 Validate using SM51 if the instance appears and is active.

🔹 4. Log File Collection for Troubleshooting

If issues still persist, collect the following logs from the work directory:

🗂️Important Logs:
Log File Purpose

dev_disp Dispatcher trace log

 Log File Purpose

dev_ms Message server trace log

dev_w0, dev_w* Work process logs (dialog, update, etc.)

sapstart.log Startup log

sapstart.trc Startup trace

📎 Attach these logs for further SAP support or internal escalation.

🔄 5. Switching Between Application Servers

To switch active GUI connection between SAP servers:

1. Execute transaction SM51.

2. View list of all active application servers.
3. Double-click on the desired server.
4. You’ll be connected to that specific instance.

📸 Snapshot in SAP System – Monitoring and Diagnostics

A snapshot in SAP captures the real-time state of the server when a critical event occurs, like an error or
unexpected termination of a work process. It helps SAP administrators analyze system behavior without manually
collecting logs during runtime issues.

🔹 Purpose of a Snapshot

 Provides a point-in-time dump of SAP instance status.

 Used for troubleshooting crashes, lockups, deadlocks, and resource issues.
 Collected automatically by SAP or manually triggered by an admin.

🔄 1. Snapshot Creation
✅ A. Automatic Snapshot Creation

A snapshot is automatically triggered in events such as:

Trigger Event Description

Hard shutdown Abrupt termination of instance or work process

Exhausted resources Memory, buffers, or CPU overload

Deadlock detected Two or more processes waiting indefinitely

Work process, ICM, or Gateway crash Sudden failure in components

Request hangs > 30 seconds Dispatcher detects unresponsiveness

Where is it stored?
  Snapshot info is logged in the dispatcher trace (dev_disp).
 Also retrievable via sapcontrol command line.

✅ B. Manual Snapshot Creation

Admins can manually trigger a snapshot if needed:

Via Transaction SM51:

SM51 → Goto → Administration → Snapshot → Create

📌 This is useful during performance hangs, long response times, or suspected deadlocks.

🔍 2. Viewing Snapshots

You can view existing snapshots using the following:

Method Description

SM50 Shows number of snapshots created per server (when extended info area is activated)

SM51 Navigate to snapshot admin view

RS_DOWNLOAD_SNAPSHOTS ABAP report to download snapshot files

SAP Management Console (SAP MC) External tool to open and analyze downloaded snapshots

📂 Snapshot IDs are numeric and sequential. Each instance maintains its own counter.

🔁 Snapshot Administration (List View)

In SM51:

Goto → Administration → Snapshot → Administration

You can:

 List all snapshots

 View metadata (timestamp, ID, triggered by)
 Download snapshots for offline analysis

⚙️3. Configuration Parameters for Snapshots

To control snapshot behavior, use these SAP profile parameters:

Parameter Description

service/max_snapshots Maximum number of snapshots that can be stored per instance. Default = 20

rdisp/snapshot Enables/disables snapshot creation (1 = on, 0 = off)

⚠️Set these parameters via RZ10 or DEFAULT.PFL and restart the instance for changes to apply.

📁 Location of Snapshot-Related Logs

File Purpose Location

dev_disp Dispatcher trace with snapshot info /usr/sap/SID/instance/work/

sapstart.log Startup and snapshot logs Same as above

💡 Best Practices

 Enable snapshot creation in production to catch unpredictable system behavior.

 Monitor snapshot counters in SM50 for early warnings.
 Periodically download and archive snapshots from unstable systems.
🖥️SAP SM51 – Application Server Shutdown Statuses Explained

The SM51 transaction shows the current status of each SAP application server instance. These statuses indicate
the server’s state during startup, normal operation, deactivation, or shutdown.

🔵 1. Initial

 The server has logged on to the Message Server.

 However, it is not yet fully available.
 📌 Note: At this stage, you cannot access the instance through SAP GUI.

🟡 2. Starting

 The server is starting up:

o Initializes work processes
o Loads kernel components
o Prepares services
 ❌ No requests (dialog, update, RFC, etc.) are processed during this phase.

🟢 3. Active

 ✅ Normal operating state.

 The server:
o Receives and processes user and system requests
o Can send requests to other servers
 📌 This is the desired state during normal production operation.

🟠 4. Passive

 The server is logically removed from load balancing.

 It can:
o Complete existing processes
o Initiate internal processes (like update or spool)
 But it does not accept new user logons or requests.
 🔄 Can be switched back to Active state at any time.
 ✅ Use Case: Perform safe shutdown without interrupting running jobs or updates.

🔴 5. Shutdown

 The server is in the process of shutting down.

 Similar to Passive:
o Completes ongoing tasks
o Does not accept new work
 ❌ Cannot be reverted to Active.
 Ends with server termination.
⚫ 6. Stops

 The server has:

o Terminated all work
o Disconnected from the Message Server
 It is fully offline and cannot be accessed.

🧭 Summary Table
Status Meaning Can Process Requests? Can Be Re-Activated?

Initial Just logged into message server ❌ No 🔄 Will progress to Starting

Starting Work processes/services are initializing ❌ No 🔄 Will progress to Active

Active Normal running mode ✅ Yes N/A

Passive Completes existing tasks, no new ones ⚠️Limited ✅ Yes

Shutdown In shutdown phase, similar to Passive ⚠️Limited ❌ No

Stops Completely stopped/disconnected ❌ No ❌ Must restart manually

🔄 Server Termination Options in SAP

When managing application servers in an SAP system, you have several options for terminating or controlling a
specific instance. These are crucial for system maintenance, updates, or troubleshooting scenarios.

1️⃣ Hard Terminate Server

 Effect:
Equivalent to sending a Signal 2 (SIGINT) at the operating system level.
 Impact:
o The dispatcher and all work processes are immediately terminated.
o Active and queued requests are discarded without completion.
 Use Case:
Emergency stop during a critical failure or system hang.

2️⃣ Soft Terminate Server

 Effect:
Gracefully shuts down the application server.
 Behavior:
o All services become unavailable (dialog, update, background, etc.).
o However, requests already in the queue are processed to completion.
o Once all work is done, the server shuts down.
 Use Case:
Preferred during planned shutdowns to avoid data inconsistency.
3️⃣ Close Connection

 Effect:
Disconnects the selected server from the SAP Message Server.
 Impact:
o The server stays up, but no new requests are sent to it from other servers or load balancers.
o Useful for testing message server connectivity or isolating a server.
 Use Case:
Troubleshooting inter-instance communication or load balancing.

4️⃣ Deactivate

 Effect:
Similar to a soft terminate, but the server does not shut down after completing current requests.
 Behavior:
o Enters a passive state (accepts no new load).
o Can later be re-activated without a full restart.
 Use Case:
Temporarily remove the server from load balancing without stopping it.

5️⃣ Activate

 Effect:
Re-activates a previously deactivated (passive) server.
 Behavior:
o The server re-registers with the message server and resumes normal operations.
 Use Case:
Bring a deactivated instance back into production without restarting the process.

🧠 Summary Table
Action Processes Running Accepts New Requests Queued Requests Shutdown Behavior Use Case

Hard Terminate No No Discarded Immediate Emergency shutdown

Soft Terminate Until complete No Processed Graceful Planned system maintenance

Close Connection Yes No (from others) Local only None Message server test

Deactivate Until complete No Processed Passive mode Temp removal from load balancer

Activate Yes (after) Yes Yes None Bring server back online

🔧 How to Remove Activity from a Single Application Server (Set to Passive Mode)

Sometimes, you may want to isolate or remove load/activity from a specific application server—for patching,
troubleshooting, or performance testing—without shutting it down completely.

🔹 Step-by-Step Process
✅ 1. Start the Server in Maintenance Mode (Passive)

To ensure the server does not accept dialog work (user activity):

 Add the following profile parameter:

 rdisp/start_maintenance_mode = 1

 This prevents dialog logons and background jobs from being assigned.
 Action:
o Maintain this in DEFAULT.PFL or instance profile via RZ10.
o Restart the affected instance for the change to take effect.

✅ 2. Deactivate Server Manually via SM51

If you don't want to restart or just want to deactivate temporarily:

1. Go to transaction SM51.
2. Select the target application server.
3. Navigate to:
Goto → Administration → State → Deactivate.
4. This will mark the server as passive (no new logons or activity assigned).
5. Users currently active on the server will continue until they log off.

🔁 3. Reactivate the Server

Once you're ready to resume load/activity on the server:

 In SM51, go to:
Goto → Administration → State → Activate.
 The server returns to active mode, accepting logons and dialog steps.

ℹ️Use Cases for Passive Mode

 OS-level or SAP-level patching without full shutdown.

 Temporary isolation for load testing.
 Performance troubleshooting on other nodes.
 Preventing new logins during spool or batch job tuning.

🔄 Reset the SAP Hostname Buffer

SAP maintains a hostname buffer to resolve and cache hostnames used during communication (especially in RFC,
spool, gateway, etc.). If there are hostname resolution issues (e.g., after DNS change or IP conflict), resetting this
buffer may help.
🔹 Method 1: Using SM51 (Application Server Level)

1. Go to transaction SM51.
2. Select the instance where you want to reset the buffer.
3. Choose the menu:
GoTo → Host Name Buffer → Reset.
4. Confirm the action.

✅ Use this when the issue is localized to a specific application server.

🔹 Method 2: Using SMGW (Gateway Level)

 1. Go to transaction SMGW.
2. On the top menu, navigate to:
Goto → Expert Functions → External Security → Host Name Buffer.
3. Click on the dustbin icon to invalidate the buffer.
(Or choose: Goto → List → Invalidate buffer)
4. This clears and resets the hostname buffer at the gateway level.

✅ Use this when the issue affects RFC destinations or inter-system communication.

📥 How to Check the ABAP Dispatcher Queue

The ABAP Dispatcher Queue holds user and system requests waiting to be processed by available work processes.
Monitoring this queue is essential when troubleshooting performance issues or system overloads.

✅ 1. Using Transaction Code SM50 (Per Application Server)

🔍 Steps:

1. Go to T-code: SM50 (Process Overview).

2. Observe the work processes:
o If many processes are in “waiting” or “stopped” state and few are “running,” the dispatcher may be
overloaded.
3. Look at the “Reason” column:
o If you see reasons like PRIV, WP Full, CPU Overload, etc., this could indicate dispatcher queue
congestion.
4. Check for processes stuck on long-running programs, which can block the dispatcher from serving other
requests.
✅ 2. Using Transaction Code SM66 (System-Wide View)
🔍 Steps:

1. Go to T-code: SM66 (Global Work Process Overview).

2. You can view the status of all dialog processes across instances.
3. Analyze if many processes are running for long periods — this may indicate queue backup.
4. Sort by runtime or user to identify heavy consumers.

✅ 3. Check Dispatcher Logs at OS Level

You can view dispatcher-related logs for more technical analysis:

On Linux/UNIX:

Look for messages like:

 Dispatcher queue full

 No work process available
 Timeout during allocate

✅ 4. Monitor Dispatcher Queue Length with SAP Parameters

Check profile parameters related to dispatcher limits in RZ11:

  rdisp/elem_per_wp → Number of requests per work process
 rdisp/max_queue_size → Maximum dispatcher queue size
 rdisp/wp_no_dia → Number of dialog work processes
 rdisp/queue_time → Max time a request waits in queue

These parameters help tune how many requests can wait before erroring out.

⚠️Dispatcher Queue Full – Common Symptoms

 Users experience slow response or timeout.

 SM50/SM66 show most work processes as busy.
 dev_disp shows Dispatcher queue full messages.
 CPU usage spikes.

🛠️Troubleshooting Tips

 Kill/clear long-running background or dialog sessions (carefully).

 Increase dialog work processes in RZ10 if capacity is too low.
 Schedule background jobs during non-peak hours.
 Tune database response time to avoid backend delays.

✅ How to Find SAP System Status and Kernel Information

1️⃣ From SAP Level (Application Layer)

You can use the SAP GUI to view system and kernel details:

Method A: Using System → Status

 Navigate to: SAP Easy Access Screen → System → Status

 In the System Status popup:
o Look under SAP System Data:
 System ID (SID)
 Installation Number
 Database
 Kernel release
 Patch level
 Dispatcher version
o Click on the "Other Kernel Info" or "Component Information" button for extended kernel version
details.
Method B: Using Transaction Codes

 SM51 – Displays all active application servers in the system. Double-click an instance to see kernel release
and patch level.
  SPAM → Menu → Utilities → Display/Define – Shows kernel version as well.
 SICK – Displays basic system health and version info (useful after upgrades or patches).

2️⃣ From OS Level (Operating System Layer)

You can check kernel and system info directly on the server (Linux/UNIX/Windows):

For Linux/UNIX:

Navigate to the kernel directory:

Then run:

Output Example:

Also check:

To get OS version and architecture info.

For Windows:

1. Open Command Prompt as Administrator.

2. Navigate to:

3. Run:

To get kernel and patch level details.

📝 Summary Table:
Layer Tool/Command Purpose

SAP GUI System → Status Basic system, kernel, and DB info

SAP GUI SM51 View kernel version per instance

SAP GUI SPAM → Utilities View kernel release

 Layer Tool/Command Purpose

OS (Linux/UNIX) disp+work -version Kernel release and patch level

OS (Windows) disp+work.exe -version Same on Windows

🔄 Changing the IP Address of an SAP System

Changing the IP address of a system where SAP is installed involves updates at both the operating system level and
the SAP application level to ensure smooth communication and system operation.

🖥️1️⃣ OS Level Configuration

When the IP address of a host running SAP changes, you must ensure the following files and components are updated
accordingly:

📁 /etc/hosts (Linux/UNIX)

 Update the IP address corresponding to the SAP server hostname.

 Example (before and after):

📁 /etc/services

 If custom SAP ports are used, verify that SAP-related entries (RFC, gateway, dispatcher ports) are correct
and mapped to the new IP, if needed.

🌐 DNS Entries

 If the system is using DNS instead of static /etc/hosts, ensure the DNS server reflects the new IP for the
SAP hostname.

🛣️Routing Tables

 Update routing rules if the IP change affects network segments.

 Use ip route or route commands (Linux) to check and modify routing if needed.

🔧 2️⃣ SAP Application Level Configuration

Once OS-level changes are done, make the following adjustments in the SAP system:

🔗 SM59 – RFC Destinations

 Update any RFC destinations that refer to the old IP or hostname.

 Use hostnames instead of IP addresses wherever possible to reduce dependency on physical addresses.
🧩 SM55 – Message Server Host List (for Load Balancing)

 Clear outdated or incorrect message server entries related to the old IP.
 You may need to restart the application server to repopulate this list.

⚙️SM51 – Application Server List

 Check that all application servers are listed with their correct and updated IPs/hostnames.

🌐 SMLG – Logon Groups (Load Balancing)

 Ensure that logon group definitions reference the correct updated message server host/IP.
 Regenerate logon group entries if necessary.

🔄 Additional Tips:

 Restart SAP services (startsap, stopsap, or via SAP MMC) after IP change.
 Clear SAP GUI logon entries if they contain hardcoded IPs.
 For clustered environments (e.g., ASCS/ERS), ensure virtual IPs and failover configurations are updated.
 For Java stack, check and update:
o DEFAULT.PFL
o Instance profiles
o Visual Admin/NWA settings

✅ Summary
Layer Action Tool/File

OS Level Update host-to-IP mapping /etc/hosts, DNS

OS Level Check SAP service ports /etc/services

OS Level Validate routing configuration ip route, netstat

SAP Level Update RFC destinations SM59

SAP Level Remove obsolete message server entries SM55

SAP Level Check application server status SM51

SAP Level Validate logon groups SMLG

📊 Initial Screen of SM66 – Global Work Process Overview

🔍 Purpose:

The initial screen of SM66 provides a system-wide overview of all active work processes across every application
server in the SAP system. It is a powerful tool for quickly investigating system performance issues and analyzing
runtime behavior in real time.
🧭 Key Functionalities:

 ✅ Monitor Work Process Load

View the distribution and status of work processes across all active instances in the system.
 🔒 Check for Locks / Lock Waits
Identify whether any lock contention or waiting for database locks is causing performance bottlenecks.
 🖥️Application Server Status
See the status of each application server (active, stopped, or restarted recently).
 🛠️Analyze Non-Running Processes
Understand why a work process is not in a "running" state — possible reasons could include:
o Waiting for a lock
o Long runtime
o Error or termination
 🔄 Restart Information
Determine whether any application server or work process has recently restarted, which might explain
unusual behavior.
 📈 CPU and Runtime Stats
View key performance indicators like:
o CPU time used by each work process
o Elapsed runtime of the current task/request
 👤 User and Client Information
Identify the user ID and client number associated with each active process.
 📄 Running Report/Program
See the ABAP report or transaction code currently being executed by each work process.

🧠 Use Case:

Use SM66 during performance troubleshooting to:

 Detect long-running or stuck processes

 Analyze user sessions causing high load
  Quickly spot system-wide issues across all instances

📄 Report: SAPLTHFB
🔍 Purpose:

The report SAPLTHFB is used internally by SAP to gather work process information from all active instances in
the system when transaction SM66 (Global Work Process Overview) is executed.

🧩 How It Works:

 When you run SM66, the system executes SAPLTHFB in the background.
 This report collects data via RFC from all instances to display the list of active work processes across the
system.
 As a result, one dialog work process per instance may temporarily show your user ID as active in SM66 —
this is normal behavior and indicates that SM66 is fetching data from that instance.
🔧 Additional Notes (Especially for Older Releases):

 In older SAP versions, you might see that the dialog work process used by SM66 (via SAPLTHFB) is
hidden by default.
 To view this process:
o Use the “Settings” button in SM66.
o Enable the option to display your own user’s work process, which may otherwise be hidden.
o This helps in verifying whether the system is successfully collecting RFC-based data from all
instances.

✅ Conclusion:

The SAPLTHFB report is a technical tool triggered by SM66 to aggregate system-wide work process information.
Understanding its function can help clarify why your user ID might briefly appear in multiple instances and ensure
that SM66 is retrieving accurate, up-to-date system activity data.
🚦 1. Entry Points for Work Process Monitoring

Start monitoring based on alert or user complaint.

 Alert: From CCMS, Solution Manager, or OS monitoring.

 Complaint: "System slow", "Job stuck", "Unable to login", etc.

🧭 2. Identify Monitoring Tools

Use tools across different levels.

🔹 SAP GUI (Application Level):

 SM50: Local instance WP monitoring.

 SM66: Global WP monitoring.
 SM37: For background jobs.
 SM21: System logs (e.g., work process crash).
 ST22: Dumps due to WP errors.
 STAD: Check response time peaks.
 ST03N: Workload distribution.

🔹 OS Level:

 top, nmon, vmstat, iostat, ps -ef | grep dw.sap

 Check CPU, Memory, and process-level usage.

🔹 SAP MMC / SAP MC:

 View work process status and restarts.

🔹 Web-based tools:

 sapcontrol -nr <InstanceNo> -function GetProcessList

 SolMan, EWA, etc.

🔬 3. Analyze Work Process Types

Understand which WPs are affected:

WP Type Purpose

DIA Handles user dialog tasks

BTC Background jobs

SPO Printing and spool handling

ENQ Lock management

UPD / UP2 Update processing (V1, V2 tasks)

ICM / GW Internet/Network communication

Check:

 Status (Running / Waiting / Stopped / PRIV / Hold)

  CPU time, memory used
 Repeated restarts or hangs

📌 4. Focused Analysis Based on Symptoms

📍 PRIV Mode

 Memory-intensive processes
 Check parameter: abap/heap_area_dia, ztta/roll_extension
 Tune memory or code optimization

📍 Frequent Restart / Termination

 Check dev_w* logs in /usr/sap/<SID>/DVEBMGS<nr>/work

 Analyze ST22 dump or SM21 logs
 Might be due to DB connection loss, syntax error, memory dump

📍 DIA Process Full

 Check if long-running queries or Z-reports are hanging

 Use STAD or ST03N for time analysis

📍 BTC Job Stuck

 Use SM37, check log

 Debug with JDBG
 Analyze background process usage in SM50

📍 SPO Process Idle but Print Queues stuck

 Check SP01 / SPAD for spool errors

 Ensure host spooler is up
 Spool overflow: Check rspo/store_location, rsponum, RSPO1041

⚙️5. Configuration Parameters to Review

In RZ10 or RZ11:

 rdisp/wp_no_dia, rdisp/wp_no_btc, rdisp/wp_no_enq, etc.

 rdisp/max_wprun_time
 ztta/*, abap/heap_area*, em/initial_size_MB
 rdisp/autoabaptime: To kill long-running processes
 rdisp/use_spo_server

📈 6. Performance & Load Analysis

 Use ST03N ➝ Check dialog response time, CPU, DB time

 Compare instance loads
 Check roll-in/roll-out rates

🧼 7. Cleanup and Follow-up Actions

 Kill stuck processes (if justified)

  Schedule job optimization or report tuning
 Adjust memory parameters or distribute users
 Document and notify users/admins

🛠️8. Preventive Measures

 Monitor with automated alerts (SolMan, 3rd party tools)

 Split load across app servers
 Schedule batch jobs during off-peak
 Educate developers on inefficient custom code

🔄 Work Processes with Status "Running"

These are currently active processes performing actions.

🟢 1. Current Action:
✅ Examples:

 Read directly
 Seq. Read
 Insert
 Update
 Delete
 Commit

🔍 What does it mean?

 The work process is actively performing a database operation.

 These are typical business operations (e.g., reading or updating tables).

🔧 Recommendation:

 If these actions are consistently slow or stuck, analyze:

o Long-running SQL statements
o Indexes or table locks
o DB performance (ST04, DB02, etc.)

🟢 2. Current Action: "Load Report"

🔍 What does it mean?

 SAP is loading an ABAP report or program into memory.

 This involves the program buffer.

⚠️Potential Issue:

 Program buffer (PXA) too small, leading to frequent loads and poor performance.

🔧 Recommendation:

 Check and possibly increase program buffer size using parameter:

 o rdisp/PG_MAXFS
 Use ST02 to analyze buffer hits and swaps.

🟢 3. Current Action: "Roll In" / "Roll Out"

🔍 What does it mean?

 Refers to copying user context (data) between memory areas and work processes.
 Involves:
o Roll area
o Extended memory

⚠️Potential Issue:

 Poor memory management can cause delays or failures during these actions.

🔧 Recommendation:

 Check parameters:
o em/initial_size_MB
o ztta/roll_area
 Use ST02 and SM50 to monitor memory usage.

⏸️Work Processes with Status "On Hold"

These are waiting for resources or responses (not active).

🟡 1. On Hold Reason: "PRIV"

🔍 What does it mean?

 The work process switched to private memory because extended memory is exhausted.

⚠️Impact:

 Private memory is not shared; once a process enters PRIV mode, it won’t be reused until the user logs off or
ends the session.
 Leads to less process availability.

🔧 Recommendation:

 Analyze and increase:

o em/initial_size_MB
o ztta/roll_extension
o abap/heap_area_total
 Review memory consumption via ST02 and SM04.

🟡 2. On Hold Reason: "RFC"

🔍 What does it mean?

 The process is waiting for a Remote Function Call (RFC) response.

 Often caused by a blocked or unresponsive destination system.
⚠️Error Message:

 "All work processes blocked in destination system"

🔧 Recommendation:

 Check:
oSM59: RFC connection test
oSMGW: Gateway logs
oTransactional RFC queues (SMQS, SMQ1, SMQ2)
 Ensure target systems are up and reachable.

📌 Summary Table:
Status Action/Indicator What It Means Likely Cause Recommendation

Running DB Actions DB operations in progress Normal / Possible DB slowness Check DB performance

Running Load Report Loading ABAP program to buffer Program buffer too small Tune buffer (ST02)

Moving user data between memory and Tune EM/roll memory (ST02,
Running Roll In/Roll Out Memory misconfiguration
process RZ10)

Extended memory exhausted; using private Increase EM, tune heap

On Hold PRIV Too many large user sessions
memory memory

RFC destination is Check RFC logs, test

On Hold RFC Waiting for remote system response
blocked/unreachable connections

🔧 Diagnosing and Resolving PRIV Mode, Roll In/Out Bottlenecks, and Extended Memory
Exhaustion

🧨 1. PRIV Mode Issues

❓What is PRIV Mode?

When a dialog WP can't assign more Extended Memory (EM) to a user context, it switches to PRIV mode —
locking that WP for the user session.

🔍 Symptoms:

 SM50: WP status = PRIV

 SM66: Same user hogging WP with high time
 ST02: Low free Extended Memory
 ST03N: High DIA time
 SU53 dump after long response time

📌 Root Cause:

 Insufficient Extended Memory (em/initial_size_MB)

 Poorly tuned roll memory (ztta/roll*)
 Large user sessions (e.g., reporting, bad queries)
✅ Solution:
Area Action

em/initial_size_MB Increase to match system memory (e.g., 4096 → 8192)

ztta/roll_extension Increase (e.g., 8000000 → 16000000), especially for large reports

Code review Identify custom Z transactions or reports causing large memory loads

ST05/ST12 trace Use SQL trace to pinpoint queries causing spikes

🌀 2. Roll In / Roll Out Bottlenecks

❓What are Roll In/Out?

These are internal SAP memory operations during context switches (user or task change). Bottlenecks lead to high
WP times and slow response.

🔍 Symptoms:

 High DIA response times (SM66, ST03N)

 SM50 shows long “Roll In” or “Roll Out” status
 STAD shows spike in context switch time
 Kernel logs show "roll area too small" errors

📌 Root Cause:

 Low roll buffer/area settings

 Fragmented or exhausted memory
 Misconfigured shared memory segments

✅ Solution:
Parameter Recommendation

ztta/roll_first Lower value (e.g., 128 KB)

ztta/roll_area Moderate value (e.g., 2–4 MB)

rdisp/ROLL_SHM Set high enough (e.g., 20480 KB)

Kernel update For better memory management

Analyze job behavior Long sessions = high memory switching

🚨 3. Extended Memory Exhaustion

❓What is Extended Memory?

Main working memory assigned to user contexts. It must be sized properly for smooth dialog performance.

🔍 Symptoms:

 ST02: Low “Free extended memory”

 ST06/SM50: High memory usage, WP in PRIV
 SM66: Long running sessions
 WP traces: EM_ALLOC_FAILED

📌 Root Cause:

 em/initial_size_MB too small

 Too many concurrent users
  Memory fragmentation from large sessions

✅ Solution:
Parameter Recommendation

em/initial_size_MB Set to 60–70% of physical RAM

ztta/roll_extension Increase (as fallback to EM)

em/address_space_MB For 64-bit systems (limit EM size)

Use 64-bit kernel Avoid 2 GB memory barrier

Implement memory quotas Avoid single session hogging EM

📊 Monitoring Tools
Tool Use

ST02 Memory buffer and EM stats

SM50 Work process status (PRIV, Roll, Wait)

SM66 System-wide WP monitoring

SM04 Per-user session memory usage

ST06 OS memory stats

STAD Identify DIA/RollIn bottlenecks

ST03N Transaction performance and response time analysis

⚙️Tuning Checklist Summary

Parameter Purpose Example Value

em/initial_size_MB Size of extended memory 8192 (8 GB)

ztta/roll_first Initial roll memory 128000

ztta/roll_area Total roll memory 3000000

ztta/roll_extension User context extension 16000000

rdisp/ROLL_SHM Roll shared memory 20480

em/address_space_MB Max EM in 64-bit systems 16384

abap/heap_area_total Total allowed heap for all WP 209715200

abap/heap_area_dia Per-DIA WP heap area 52428800

🔧 1. Key SAP Memory Areas & Parameters

Memory Area Purpose Important Parameters

Extended
Main shared memory for user context em/initial_size_MB
Memory

Roll Memory Used briefly during logon/logoff ztta/roll_area

Private memory used when extended memory is exhausted abap/heap_area_total,

Heap Memory
(causes PRIV) abap/heap_area_dia
 Memory Area Purpose Important Parameters

Paging Memory Used for certain buffering (rare in newer versions) rdisp/PG_MAXFS

⚙️2. Recommended Parameter Settings (Dialog Workload)

These are starting values. You must tune them based on:

 Your total physical RAM

 Concurrent users
 SAP release (NetWeaver 7.0 or higher)

🧮 Example Sizing (Assuming 64 GB RAM for SAP system):

Parameter Suggested Value Notes

em/initial_size_MB 24576 (24 GB) Main area for all dialog user context

ztta/roll_area 128000 Roll area (in bytes) – small default suffices

abap/heap_area_dia 512000000 (512 MB) Max heap memory per dialog WP

abap/heap_area_total 4096000000 (4 GB) Total heap memory available across all WPs

rdisp/ROLL_MAXFS 5120 (5 MB) Max roll memory per work process

Note: These are indicative only. Always adjust based on system logs and ST02 statistics.

🛠️3. Tuning Process Step-by-Step

Step 1: Monitor First

Use these transactions before changing anything:

 ST02 → Tune summary → Check:

o EM usage, swaps, heap usage, program buffer
 SM50 → Check for:
o WP status = "On Hold (PRIV)"
o Frequent Roll In/Out in Action column
 ST03N → Check user load (peak dialog usage)

Step 2: Adjust Extended Memory

If you see:

 Frequent roll-ins/roll-outs
 PRIV mode
 EM swaps

Then increase em/initial_size_MB gradually by 2-4 GB and monitor impact.

Step 3: Limit Heap Usage

 If heap grows uncontrollably (PRIV mode), reduce:

o abap/heap_area_dia
 o abap/heap_area_total

Step 4: Restart SAP System

Memory parameter changes (except SU3/SU01) need a system restart to take effect.

🚨 Additional Tips

 Avoid large SELECTs or reports in foreground.

 Use SU01 to restrict users from running memory-heavy transactions.
 If using 64-bit kernel and OS (most systems now are), there's no hard 2 GB limit—so you can safely increase
EM and Heap cautiously.

✅ SAP BASIS Daily Memory Monitoring Checklist

🔹 1. Work Process Monitoring (SM50)
 Check status of dialog WPs:
o Should be mostly in Running, Waiting, or Stopped.
o Investigate any stuck in On Hold with "PRIV" or "RFC" in "Reason" column.
 Review the Action column:
o Frequent "Roll In" / "Roll Out" → potential extended memory shortage.
o Long-running "Load Report" → small program buffer.

🔹 2. Global Work Process Check (SM66)

 Look for high activity from users/programs globally.
 Sort by “Action” or “Duration” → spot memory-heavy processes.
 Check for RFC-based processes stuck in "On Hold".

🔹 3. Memory Buffer Monitoring (ST02 – Tune Summary)

 Extended Memory (EM):
o Hit ratio ≥ 95%
o Swaps = 0 or minimal
 Program Buffer:
o Hit ratio ≥ 98%
o Swaps should be low (ideally < 100/day)
 Roll Buffer:
o No high roll ins/roll outs
 Heap Usage:
o Should be minimal unless in peak load

🔹 4. User Session Monitoring (SM04)

 Check if any user has large memory usage or multiple active sessions.
 Sort by memory consumption — users using extended memory excessively may need role/profile review.
🔹 5. System Logs (SM21)
 Check for any memory allocation failures or dump messages.
 Look for:
o TSV_TNEW_PAGE_ALLOC_FAILED
o TSV_TNEW_OCCURS_NO_ROLL_MEMORY

🔹 6. ST03N (Workload Analysis)

 Go to: Expert Mode → Workload → Instance → Dialog Steps
 Analyze:
o Avg. Memory Use per dialog step
o Response Time breakdown (Memory bottlenecks?)

🔹 7. Short Dumps (ST22)

 Monitor for dumps related to memory:
o SYSTEM_NO_ROLL
o TSV_TNEW...FAILED
o SYSTEM_NO_MEMORY
 Investigate offending programs/users.

🧠 Preventive Tips

 Don't allow reports or large data selection in foreground (restrict via SU01 roles).
 Schedule heavy jobs in background (BTC) mode.
 Apply OSS notes if memory management errors are kernel-specific.
 Restart application servers periodically if heap memory doesn't release (non-garbage collected).

DISPATCHER (FIFO Order)

The Dispatcher in SAP is a critical component of the SAP application server, responsible for managing and
coordinating the distribution of tasks to various work processes. It ensures that incoming requests from users are
handled efficiently and processed in First-In, First-Out (FIFO) order.

🔧 Main Roles of the Dispatcher

1. Request Management

 Receives user requests from the SAP GUI or other communication channels.
 Places these requests into the dispatcher queue.
 Assigns requests to available work processes based on type and availability.

2. Load Balancing

 Distributes workload evenly across different work processes.

 Helps prevent overload and ensures optimal performance.
3. Communication Handling

 Manages communication between the SAP application server and the database server.
 Also handles communication between different SAP systems (e.g., RFC).

⚙️Types of Work Processes Managed by the Dispatcher

 Dialog Work Processes – Handle user inputs and screen outputs.

 Background Work Processes – Run background jobs without user interaction.
 Update Work Processes – Manage database updates triggered by transactions.
 Enqueue Work Processes – Handle data locking to avoid concurrent changes.
 Spool Work Processes – Manage print/spool requests.

🖥️Monitoring and Management Tools

 SM50 – Monitors work process status on a specific application server.

 SM66 – Provides a system-wide view of all work processes across all servers.

⚠️Common Dispatcher Issues

 Dispatcher Queue Full – Happens when incoming requests pile up due to insufficient or blocked work
processes.
 Work Process Blockage – Occurs when work processes are hung, long-running, or in error, preventing task
assignment.

🛠️Troubleshooting Tips

 Use SM50 to check the status of work processes (Running, Waiting, Stopped, etc.).
 Analyze system load using:
o ST02 – Buffer statistics.
o ST03N – Workload analysis.
 Review work process configuration using RZ10 to ensure optimal numbers/types are defined.

✅ Conclusion

The SAP Dispatcher is essential for maintaining the stability and performance of the SAP system. It ensures that all
user requests are efficiently managed and assigned to the appropriate work processes in a balanced and orderly
manner.

✅ Dispatcher Monitor Overview

The Dispatcher:

 Manages request queues from SAP GUI users.

 Distributes user tasks to available work processes (WPs).
 Handles memory and load balancing within the SAP instance.
🔍 How to Monitor the Dispatcher
1. Using SAP Management Console (SAP MMC)

 Go to: SAP MMC → Instance → Process List

 Look for the disp+work.EXE process.
 Status should be "Running" and green.
 Check Queue Length and WP availability.

2. From OS Level

 Command-line tools:

Linux/UNIX:

SAPControl:

→ Look for entry: Dispatcher GREEN Running

 DPMON tool:
 → Monitor dispatcher queues, semaphore locks, WP load, etc.

3. From SAP GUI (SAP Level)

 Transaction Code: SM51

o Shows all instances and dispatcher status.
o Check each app server → double-click → WP overview.
 Transaction Code: SM50
o Monitor WP status (Running, Waiting, Hold, PRIV).
o Click on any WP → Goto → Information → Dispatcher Info.
 Dispatcher Snapshot:
o From SM51 → Goto → Administration → Snapshot → Create
o Snapshot saved in dev_disp trace for debugging.

🛠️Useful Dispatcher-Related Parameters

Parameter Purpose

rdisp/wp_no_dia Number of dialog work processes

rdisp/queue_max_length Max dispatcher queue length

rdisp/max_wp_runtime Max runtime for a WP task

rdisp/TRACE Dispatcher trace level

🛠️Dispatcher Troubleshooting Guide
🔴 1. Dispatcher Queue Overflow / No Free Work Process

Symptoms:

 SAP GUI freeze

 Long response times
 SM50 shows many work processes in status PRIV, Hold, or Running without end.

Actions:

 Go to SM50 → Check WP status

 Use DPMON or sapcontrol to view real-time dispatcher and queue stats
 Check parameter:

o If queue length exceeds this, dispatcher cannot handle new requests.

Solution: Increase rdisp/queue_max_length (e.g., from 100 to 300) after analyzing need.

🔴 2. All Work Processes in PRIV Mode (Memory Leak)

Symptoms:

 All dialog WPs stuck in PRIV

 Dispatcher unable to assign new user requests

Actions:

 Transaction SM50
o Check for long-running or memory-intensive sessions
 Transaction ST02 or ST06
o Check Extended Memory (EM) and Heap (Private) Memory usage

Solution:

 Increase:
o em/initial_size_MB
o ztta/roll_extension
 Reduce:
o abap/heap_area_dia (to avoid processes staying too long in PRIV)
 Identify and terminate bad sessions using SM04

🔴 3. Dispatcher Not Starting

Symptoms:

 SAP instance starts partially

 Dispatcher fails (status: YELLOW or STOPPED)
Actions:

 Check dev_disp log:

 Use:

to see exact status of dispatcher

Common causes:

 Port conflict (disp+work fails to bind)

 Hostname/IP not resolving
 Missing shared memory or semaphore issues

Solution:

 Restart host or clear IPC:

🔴 4. Dispatcher Hangs (High CPU / Memory)

Symptoms:

 CPU spikes
 Dispatcher not responding
 High memory usage in top

Actions:

 Check:
o SM50 (check CPU column → List → CPU)
o top / nmon / prstat (OS tools)
 Trace with:
o SM50 → Process → Trace → Active Components
o Set trace level to 2 or 3 for DIA WPs

Solution:

 Identify long-running ABAP programs and optimize

 Tune memory parameters (EM, Roll, Heap)
 Check ST03N for bad-performing custom programs
🔴 5. Deadlock / Semaphore Issues

Symptoms:

 One or more WPs wait on semaphore (RED in SM50)

Actions:

 Go to SM50
o Use "Semaphore no." column and press F1
 Use DPMON → check who is locking
 Also check in Snapshot (SM51 → Goto → Administration → Snapshot → Create)

Solution:

 Kill faulty WP if required

 Analyze trace files (dev_w*)

✅ Proactive Dispatcher Monitoring

Tool Purpose

SM50 Live WP monitoring

SM51 Instance and dispatcher overview

ST02 Memory buffer usage

DPMON OS-level dispatcher monitor

sapcontrol Process status check

dev_disp Dispatcher log file

🔍 Dispatcher Wait Queue Monitoring

✅ 1. Using SAP MMC (Microsoft Management Console)

Steps:

1. Launch SAP Management Console (SAP MMC) on the Windows server.

2. Expand your system → Navigate to the relevant instance.
3. Select “Process List”.
4. Right-click on the Dispatcher → Choose “Show Process List”.
5. It will display details such as:
o Wait queue length
o Work process status
o Dispatcher state (green/yellow/red)

🔎 Key Field: Look for "Free DIA WPs" and "Waiting Requests"
If waiting requests > 0 for a long time → Dispatcher queue buildup

✅ 2. Using SAP MC (SAP Management Console via Browser)

Steps:
 1. Open browser → Go to:
http://<hostname>:5<instance>13
(e.g., http://sapserver:50113)
2. Log in with your SAP credentials.
3. Navigate to your SAP instance → Select "Processes".
4. Go to the "Dispatcher" tab or section.
5. You’ll see:
o Number of waiting requests
o Dispatcher state
o Process details of each WP

📌 Tips:

 Use "Refresh" regularly to watch queue behavior in real-time.

 Useful for Java stack and AS Java monitoring too.

✅ 3. From OS Level

There are multiple OS tools and commands:

a) sapcontrol command

This gives:

 DIA WP queue length

 BTC queue
 Update, Spool, Enqueue, etc.

b) DPMON tool
Steps:

 Start dpmon
 Press 3 → Dispatcher Queue Info
 Shows how many requests are in the dispatcher queue, types (DIA, BTC), and wait times.

c) View logs:

 Check dispatcher trace:

Search for:

🚩 When to Worry
Symptom Likely Cause

Dispatcher queue length > 10 for long periods All DIA WPs busy, in PRIV or stuck

High wait time for DIA requests Not enough WPs or memory bottleneck

Frequent queue overflow messages in dev_disp rdisp/queue_max_length too low

✅ Parameter to Tune

 rdisp/queue_max_length – Increase this if you're hitting frequent dispatcher queue limits.

 Workprocess Status
1. Using SAP MMC

2. Using SAP MC
3. From OS Level

4. From SAP Level

SM50
SM66
5. User Context

6. Work Process Task Handlers

7. SAP R3 Buffer
8. DB Client