SAP Performance issues
Performance problems, slow transactions, reports or jobs, frustrate users and delay the business. This page covers a disciplined approach to diagnosing SAP performance.
When SAP is slow, measure before tuning: ST03 shows where time goes by transaction, database, CPU or wait; ST05 and SAT find the expensive statements; SM50 and SM66 show work-process contention. The usual causes in order are SELECT in loops and SELECT *, inefficient custom code, missing indexes or stale statistics, and under-sizing. Fix one thing, then re-measure.
- Watch out: rank by total time, not duration; a fast statement running constantly costs more than a slow one.
Symptom
Transactions or reports are slow, jobs run long, or the system feels sluggish.
Start here: read the evidence
Measure before tuning: ST03 (workload analysis) shows where time goes (database, CPU, wait) by transaction; ST05 (SQL trace) and SAT (runtime analysis) find the expensive statements; SM50/SM66 show work-process contention.
Likely causes, in order
- Expensive SQL, SELECT in loops, SELECT *, missing indexes.
- Custom code inefficiency (nested loops, huge internal tables).
- Database, missing indexes, outdated statistics.
- Work-process/memory contention or under-sizing.
How to fix it
- Baseline with ST03 to find the worst offenders.
- Trace with ST05/SAT to find the cause.
- Fix the code/SQL (or add an index); size buffers/processes.
- Re-measure to confirm the improvement.
Preventing recurrence
Enforce ABAP performance rules (no SELECT-in-loop, filter/aggregate in the database), keep indexes and statistics current, and size the system for the workload. Most performance problems are preventable custom-code or database issues.
Common pitfalls
- Guessing instead of reading the log/dump.
- Fixing the symptom, not the root cause.
- Changing several things at once.