Lesson 3 of 5
Analysis tools
9 min
Listen to this lesson
Code review catches obvious patterns. Real performance work starts with measurement: which statement, called how often, from where, costing how much. SAP gives you static checks, traces for a single run, and monitors that collect runtime data across the system. Each answers a different question.
Static checks in ATC
The ABAP Test Cockpit includes performance checks that flag patterns such as SELECT statements in loops, nested loops or missing WHERE conditions. They are cheap and run on every transport release if you configure them. SAP's conversion guidance adds a caution: optimizing all custom code from ATC findings alone is unlikely to be practical. Static checks do not know which code runs ten million times a day and which runs once a year.
Traces for a single run
The SQL trace (transaction ST05, the Performance Trace) records every database statement a user or process executes while the trace is on: the statement, its duration, the number of records and the calling ABAP code. Its summarized views show identical statements repeated many times, the fingerprint of SELECT in LOOP. The ABAP runtime analysis (transaction SAT) and the ABAP Profiler in ADT measure where time goes in ABAP itself: which methods, how many calls, how much time in ABAP versus database.
- ReproduceRun the slow job in CMQ with production-like data and parameters
- TraceSwitch on the SQL trace for the job's user; profile ABAP time in the same run
- SummarizeGroup identical statements; sort by total time and executions
- Navigate to sourceJump from the top statements to the calling code
- Fix and re-measureChange one thing, trace again, compare against the baseline
Runtime data across the system
Traces show one run. To know what matters across the whole system, use the SQL Monitor (transaction SQLM). Once activated, it collects aggregated runtime data for SQL statements over days or weeks in a production or production-like system, with low overhead: executions, total and average time, records read, and the ABAP source position and entry point (transaction, report, job, RFC) that triggered them. SAP's guidance for converted systems is to combine it with static results in the SQL performance tuning worklist (transaction SWLT), which joins ATC findings with SQL Monitor data so you can find and prioritize real hot spots.
| Tool | Question it answers | When Contoso uses it |
|---|---|---|
| ATC performance checks | Does this code contain risky patterns? | On every transport release from CMD |
| SQL trace (ST05) | What did the database do during this run? | Analyzing the fleet rebate run in CMQ |
| Runtime analysis (SAT) / ABAP Profiler (ADT) | Where does time go inside ABAP? | When ABAP time, not database time, dominates |
| SQL Monitor (SQLM) | Which statements cost the most across the system? | Collected in production after go-live, and in CMQ during regression cycles |
| SQL performance tuning worklist (SWLT) | Which risky code actually runs a lot? | Building the post-go-live tuning backlog |
Choosing the tool by the question. Check transaction availability and authorizations for your release and role.
What would you do?
Two weeks after go-live, Maria reports that the fleet order overview "feels slow some mornings". Nobody can reproduce it in CMQ. What should Kenji do first?
- ATC finds risky patterns statically; it cannot tell you what runs often.
- SQL trace (ST05) and SAT or the ADT ABAP Profiler analyze one run in depth.
- SQL Monitor (SQLM) collects system-wide SQL runtime data with source positions.
- The SQL performance tuning worklist (SWLT) joins ATC findings with runtime data to rank hot spots.
Check your understanding · not graded
Lesson check
1. Which tool records every database statement of one run, with duration and calling code?
2. What does the SQL performance tuning worklist combine?
3. Why are performance measurements in CMD of limited value?
4. What does SQL Monitor record about each statement besides its cost?