ABAP Developmentintermediate

Performance Part 3: Tuning in Real Projects — Measure, Fix, Verify

Key takeaway

Run performance work like a project: define targets, reproduce with production-like volumes, find the top offenders with STAD/ST05/SAT, fix the biggest item first, verify with numbers, protect with ATC/SCI performance checks and SQL Monitor, and communicate results.

Explanation

📌 KEY POINTS
✅ Start with a target ("month-end job under 30 minutes"), not with "make it faster".
✅ Find the top offenders with measurements; typically one or two statements cause most of the runtime — fix those first.
✅ Verify every change with the same data and compare before/after numbers; keep functional results identical.
⚠️ Production-like volume matters: many problems (nested loops on standard tables, FAE with duplicates) only appear with large data.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–2 gave tools and principles. This lesson shows how to use them in a real tuning assignment.

━━━━━━━━━━━━━━━━━━━━
▶ 1. DEFINE THE PROBLEM

Which program/transaction/job, which variant, which runtime now vs target.
When: always, month-end only, for certain users/organisational units?

━━━━━━━━━━━━━━━━━━━━
▶ 2. REPRODUCE

QA with production-like volumes (system copy) or a controlled measurement in production (ST05 for a short period, SAT with sampling, STAD history).

━━━━━━━━━━━━━━━━━━━━
▶ 3. FIND TOP OFFENDERS

STAD: DB vs ABAP time.
ST05 sorted by total duration; structure-identical statements.
SAT hit list: top net time.
SQL Monitor (SQLM) in production: which statements are executed most and cost most over days; SWLT (SQL Performance Tuning Worklist) combines SQLM data with static checks.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FIX IN ORDER OF IMPACT
Typical fixes: set-based reads instead of SELECT in LOOP, sorted/hashed tables for lookups, selective WHERE/index, aggregation/pushdown, package processing.

━━━━━━━━━━━━━━━━━━━━
▶ 5. VERIFY

Same data, same variant; compare runtime and result (row counts, totals, output comparison).
Record numbers in the change documentation.

━━━━━━━━━━━━━━━━━━━━
▶ 6. PREVENT

SCI/ATC performance checks (SELECT in loop, nested loops, missing WHERE).
Code reviews with performance checklist; volume tests before go-live.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Choose a slow program and write target, data volume and current runtime.
Identify its top 3 offenders with ST05/SAT.
Fix the top one and record before/after numbers.

✅ CHECKPOINT: you can plan and run a measurable performance tuning task.

Code example

ABAP Code

* ===== Tuning worksheet (template) =====* Object      : ZSD_MONTH_END_REPORT, variant MONTHEND* Problem     : runtime 3h 10min, target < 30 min* Data volume : 2.1 million billing items / month* STAD        : DB 78%, ABAP 20%, other 2%* Top offenders (ST05/SAT):*   1 SELECT VBFA inside LOOP      : 180,000 executions, 1h 50min*   2 READ TABLE lt_kna1 (standard, no binary search) in LOOP: 35 min*   3 SELECT * FROM VBRP            : 40 GB transferred* Fixes:*   1 one FOR ALL ENTRIES / JOIN read before the loop*   2 lt_kna1 as HASHED TABLE WITH UNIQUE KEY kunnr*   3 field list with 9 fields* Verification: runtime 22 min, row counts and totals identical (compare output files)* Prevention  : ATC performance checks in transport release * ===== Tools =====* STAD, ST05, SAT, ST12   : analyse single runs* SQLM (SQL Monitor)      : production statement statistics over time* SWLT                    : worklist combining SQLM + static checks* SCI / ATC               : static performance checks

Real project scenario

A billing month-end job ran 3 hours and blocked downstream reporting. The team followed the worksheet approach: STAD showed database dominance, ST05 found one SELECT inside a loop executed 180,000 times, and SAT found a standard-table lookup in a loop.
Two targeted changes brought the job to 22 minutes with identical results. SQL Monitor later confirmed no new hotspots after go-live.

Common mistakes

No target or baseline.
Testing with small data.
Fixing low-impact items first.
Not verifying functional equality.
No prevention (ATC, reviews).

Best practices

Target, baseline, volume first.
Fix top offenders by impact.
Verify runtime and results.
Use SQLM/SWLT for production hotspots.
ATC performance checks and volume tests.

Interview angle

Questions: "Describe a performance tuning you did.", "How do you find hotspots in production?", "How do you ensure results don't change?"
Strong answer: target and baseline, production-like data, STAD → ST05/SAT, SQL Monitor/SWLT for production, fix by impact (set-based reads, hashed/sorted tables, WHERE/index, pushdown, packages), verify runtime and identical results, prevent with ATC/SCI and volume tests.

Practice this lesson

Quick check

1. Which tool collects SQL statement statistics in production over days to find hotspots?

2. What should come first in a performance tuning assignment?

3. Which tool is commonly used to trace SQL performance in ABAP?

Interview questions

1. A month-end job takes three hours and must finish in 30 minutes. How do you run this tuning task?

Answer it in your own words first, then compare.

2. A job is fast in DEV/QA but slow in production only during month-end. Where do you start?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.