ERPClimb logoERPClimb
Login
Performance Tuning
ABAP Developmentbeginner

Performance Part 1: Measuring with ST05, SAT and STAD

Key takeaway

Measure before tuning: STAD to see where the time goes (DB, CPU, wait, RFC), ST05 SQL trace (statements, executions, records, identical selects, execution plan), SAT runtime analysis (hit list, call hierarchy), and ST12 as a combined tool — with a repeatable measuring routine.

What this complete series covers

Learn evidence-based ABAP performance tuning with ST05, SAT, SQL optimization, internal tables, HANA pushdown and large-volume processing.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of Performance Tuning.
Prerequisites
Basic SAP navigation and ABAP syntax help. For hands-on practice, use an ABAP system with ADT or the relevant ABAP development tools.
Final outcome
By the end, you should be able to measure a bottleneck, choose the right optimization and prove the improvement with the same workload.
  1. Part 1: Performance Part 1: Measuring with ST05, SAT and STAD

    Make performance tuning evidence-driven: establish a reproducible baseline, use ST05 and SAT to locate the dominant cost, optimize that bottleneck and rerun the same workload to prove improvement.

  2. Part 2: Performance Part 2: The Database-First Rule

    Tune ABAP from the database outward: first reduce data volume and expensive SQL, then choose efficient internal-table keys and only then optimize CPU-level ABAP logic.

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

    Practical performance tuning patterns used on real ABAP projects — from SELECT-in-LOOP fixes to ST05/SAT analysis.

  4. Part 4: Performance Part 4: SELECT Inside LOOP — The Classic Performance Killer

    Eliminate database round trips inside ABAP loops by reshaping logic into joins, set-based reads or preloaded keyed tables, then verify improvement with SQL trace and realistic data volume.

  5. Part 5: Performance Part 5: FOR ALL ENTRIES — Correct Use and Hidden Risks

    Use FOR ALL ENTRIES only with a nonempty deduplicated driver set, selecting the minimal columns needed and comparing the pattern with JOIN or CDS alternatives for correctness and performance.

  6. Part 6: Performance Part 6: Internal Tables — Standard, Sorted and Hashed

    Choose STANDARD, SORTED and HASHED internal tables from the real lookup pattern, using exact-key hashed access, ordered or range sorted access and sequential standard-table processing deliberately.

  7. Part 7: Performance Part 7: JOIN vs FOR ALL ENTRIES vs Nested SELECT

    Choose JOIN or CDS for relationships the database can resolve directly, FOR ALL ENTRIES when keys already exist in ABAP, and avoid nested database selects unless each iteration gen

  8. Part 8: Performance Part 8: HANA Pushdown with Open SQL, CDS and AMDP

    Push set-oriented filtering, joins and aggregation to HANA using modern Open SQL or CDS first, and use AMDP only when database-native logic is justified and cannot be expressed cle

  9. Part 9: Performance Part 9: Package Processing for Large Data Volumes

    Process very large SAP datasets in restartable, memory-bounded packages using stable keyset pagination, controlled transaction units and progress logging instead of loading everything at once.

  10. Part 10: Performance Part 10: Indexes, Selectivity and WHERE Conditions

    Improve SQL performance by reducing rows early with selective predicates and correct keys before proposing indexes, because poor WHERE design usually costs more than the absence of a custom index.

System and release assumptions: Examples follow modern ABAP practices. Exact syntax, available APIs, and tools can vary by SAP release, so release-dependent points are called out where needed.

Explanation

📌 KEY POINTS
✅ Measure first: STAD shows whether time is in database, CPU (ABAP), RFC, or waiting — that decides which tool to use next.
✅ ST05 SQL trace shows each statement with executions, records, duration, identical selects and the execution plan — the main tool for database problems.
✅ SAT (runtime analysis) shows where ABAP time is spent — hit list by duration, call hierarchy, internal table operations.
⚠️ Tune with measurements from realistic data volumes — a program fast on 100 test records can be slow on 10 million production records.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

  • Part 1 — measuring with ST05, SAT and STAD (this lesson)
  • Part 2 — the database-first rule
  • Part 3 — tuning in real projects: measure, fix, verify
  • Part 4 — SELECT inside LOOP
  • Part 5 — FOR ALL ENTRIES: correct use and risks
  • Part 6 — internal table performance: standard, sorted, hashed
  • Part 7 — JOIN vs FOR ALL ENTRIES vs nested SELECT
  • Part 8 — HANA pushdown with Open SQL, CDS and AMDP
  • Part 9 — package processing for large volumes
  • Part 10 — indexes, selectivity and WHERE conditions

━━━━━━━━━━━━━━━━━━━━
▶ 1. STAD (STATISTICAL RECORDS)

  • Per dialog step/job: response time, DB time, CPU time, RFC time, wait time, records read.
  • High DB time → ST05; high CPU (ABAP) time → SAT; high RFC time → the called system; high wait → work process shortage/locks.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ST05 SQL TRACE

  • Activate trace for your user → run program (short) → deactivate → display.
  • Summarised views: "Structure-identical statements" (same statement executed many times), "Value-identical" (same statement with same values = redundant reads).
  • Columns: executions, records, duration per execution; "Explain" shows the execution plan (index use).
  • Trace only as long as needed — traces are large.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SAT (RUNTIME ANALYSIS)

  • Create measurement for a program/transaction with a variant (e.g. aggregation none for call hierarchy).
  • Hit list: statements/methods by gross/net time; "Processing blocks"; internal table operations.
  • Find expensive loops, nested reads on standard tables, repeated calls.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 4. ST12\nCombines ABAP (SAT) and SQL (ST05) traces in one tool; common in performance projects.

━━━━━━━━━━━━━━━━━━━━
▶ 5. MEASURING ROUTINE
Same data, same user, warm buffers (run twice), note runtime before and after each change.

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

  1. Run a slow report; check STAD for DB vs CPU time.
  2. Trace it with ST05 and sort by duration; look at identical statements.
  3. Measure it with SAT and read the hit list.

✅ CHECKPOINT: you can measure where time goes and choose the right trace tool.

Code example

ABAP Code
* ===== Measurement routine (tools) =====* STAD   : response time split -> DB / CPU / RFC / wait* ST05   : activate SQL trace (own user) -> run -> deactivate -> display*          -> "Structure-identical statements": executions per statement*          -> "Value-identical statements"    : redundant reads*          -> Explain                          : execution plan / index use* SAT    : measure program with variant -> hit list (net/gross), call hierarchy* ST12   : combined ABAP + SQL trace * ===== Simple runtime measurement inside code (for comparisons in test programs) =====REPORT zperf_measure. DATA: lv_t1   TYPE i,      lv_t2   TYPE i,      lv_diff TYPE i,      lt_vbak TYPE STANDARD TABLE OF vbak. START-OF-SELECTION.  GET RUN TIME FIELD lv_t1.   SELECT * FROM vbak INTO TABLE lt_vbak UP TO 1000 ROWS.   GET RUN TIME FIELD lv_t2.  lv_diff = lv_t2 - lv_t1.                  " microseconds  WRITE: / 'Runtime (microseconds):', lv_diff,         / 'Rows:', sy-dbcnt.* Run twice: the second run shows buffered/warm times.

Real project scenario

A team spent a week optimising internal table loops in a slow sales report because "the code looked inefficient". STAD then showed 92% of the runtime was database time. ST05 revealed one SELECT on VBFA executed 40,000 times without a proper key.
Fixing that single access cut runtime from 25 minutes to 90 seconds. The team made "STAD first, then ST05 or SAT" their standard performance routine.

Common mistakes

  • Tuning without measuring.
  • Tracing with tiny test data only.
  • Leaving ST05 traces running.
  • Ignoring identical/redundant selects.
  • Comparing cold and warm runs.

Best practices

  • STAD first to classify DB/CPU/RFC/wait.
  • ST05 for SQL, SAT for ABAP.
  • Realistic data volumes.
  • Measure before and after every change.
  • Document findings with numbers.

Interview angle

Questions: "How do you analyse a slow program?", "What does ST05 show?", "ST05 vs SAT?"
Strong answer: STAD for response time split; ST05 SQL trace (executions, records, duration, identical selects, explain plan) for DB time; SAT hit list/call hierarchy for ABAP time; ST12 combined; realistic data, before/after measurements.

Practice this lesson

Quick check

1. STAD shows 90% database time for a slow report. Which tool do you use next?

2. SQL trace is available in transaction:

3. SAT (Runtime Analysis) primarily helps you find:

Interview questions

1. A slow finance report is blamed on the ALV display. How do you prove where the time really goes?

Answer it in your own words first, then compare.

2. A report takes 30 minutes. How would you start performance analysis?

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.

More lessons in this topic

Interview questions on this topic

Related SAP topics