Explain ABAP Performance Tuning & Debugging in SAP

12 / 65

ABAPadvanced

ABAP Performance Tuning & Debugging

Using SAT, SE30, ST05, and the ABAP debugger to diagnose and resolve runtime performance bottlenecks.

A report that used to finish in two minutes now times out. The discipline is to measure before changing anything, because the obvious suspect is usually not the cause.

Debugging without tracing is like trying to fix a slow commute by guessing which street has traffic; ST05/SAT is putting a GPS tracker in the car so you can see precisely which block cost you twenty minutes.

Key Concepts

Start with the SQL trace (ST05). It records every database statement a program issues — the text, how many times it ran, and how long each took.

ST05

    statement                       executions   total time
    SELECT FROM kna1 WHERE kunnr     40,132       38.2 s
    SELECT FROM vbak WHERE vbeln          1        0.4 s

That first line is a select inside a loop, and it is 90% of the runtime. You did not have to read the code to find it.

ST05 is the first tool because database access is where most ABAP time goes, and because the execution count makes the pattern obvious.

ST05

Then the runtime analysis (SAT, formerly SE30). This profiles the ABAP side: time per method, per form, per statement, with call counts.

SATSE30

Use it when ST05 shows the database is not the problem. Then you are looking at string handling in a loop, an internal table with the wrong type, or a nested loop over two large tables — all invisible to a SQL trace.

ST05

Together they answer one question: is the time in the database or in ABAP? Almost every tuning decision follows from that, and guessing it wrong wastes the afternoon.

The debugger, past the basics. Breakpoints and stepping are the obvious part. Three features are worth knowing:

Watchpoints stop execution when a variable's value changes, which is how you find what is corrupting a field without stepping through thousands of lines.

Conditional breakpoints stop only when a condition holds — the 4,000th loop pass with the bad document number, rather than the first.

The script debugger automates repetitive debugging, such as collecting a value on every pass without stopping.

For something running right now. SM50 shows this server's work processes and what each is doing; SM66 shows the whole system. A process sitting on a database read for ten minutes is a different problem from one spinning on CPU.

SM50SM66

SM37 shows background jobs with their logs, which distinguishes a job that is stuck from one that is slow — and those have different fixes.

SM37

On HANA. ST04 and the plan visualiser show whether a query is being answered efficiently from the column store or falling back to expensive row-by-row operations. Code pushdown — CDS views and AMDP — is the usual fix when the answer is that millions of rows are being moved to the application server to be aggregated there.

ST04

The method, stated plainly.

  1. Reproduce it, and time it, so you have a number to beat
  2. Trace it — `ST05` first, then `SAT`
  3. Quantify: "38 of 42 seconds are 40,000 single-row selects"
  4. Fix the largest item only
  5. Re-measure, and confirm

ST05SAT

Step 5 is the one that gets skipped. A change that was supposed to help sometimes does not, and without a second measurement you have added complexity and kept the problem.

What the interviewer is probing.1. "What is your first step on a slow program?" Probing: the method. Stalls: "Read the code." Moves up: the SQL trace in ST05 and the runtime analysis in SAT — the bottleneck is usually one statement, not the whole program.

2. "What do you look for in an SQL trace?" Probing: interpretation. Stalls: "Slow statements." Moves up: identical statements executed many times, full table scans, and the explain plan showing which index was used.

3. "How do you debug a background job or an update task?" Probing: practical skill. Stalls: "You cannot." Moves up: a breakpoint in the job's user with debugging in the update task enabled, or JDBG from SM37 on the finished job.

4. "What is the difference between a session and an external breakpoint?" Probing: the detail. Stalls: "None." Moves up: a session breakpoint applies to your dialog session; an external one is tied to a user and catches background and RFC calls.