ST05 — SQL and Performance Trace

ST05 switches on a kernel-level trace that captures every database call a work process makes for a chosen user: SELECT, INSERT, UPDATE, DELETE, COMMIT, and optionally OPEN CURSOR/FETCH. It can also trace RFC calls, enqueue/dequeue requests, table buffer activity, and HTTP calls. The trace is not a continuous monitor; it must be explicitly activated, the problem step reproduced, and the trace deactivated before the results are readable. The structural fact that explains most confusion: the trace list only contains what happened during the recording window for the filtered user. If the filter is left open to all users, or the window is too wide, the list fills with unrelated background activity and the real signal gets buried in noise.

ST05 is reached for once a transaction, report, or interface step is confirmed slow and the question becomes where the time is going. It sits after basic timing checks (a stopwatch on the transaction, or a runtime analysis in SAT) once those point at the database rather than at ABAP-side loops or formatting. Typical triggers: a report that used to run in seconds now takes minutes, a batch job whose runtime scales badly with data volume, or an interface call that times out intermittently. ST05 is not used to monitor live system load in general; ST02, SM50, or workload monitoring cover that. It is a targeted, one-shot diagnostic run against a single reproducible step, not a background health check.

ST05 does not write its results into standard transparent application tables the way a business transaction writes master or transaction data. The trace is recorded by the kernel into temporary trace data tied to the work process and the trace request, and is read back into the transaction's own list display. There is no SE16-style table to browse for the raw trace content; the trace list inside ST05 is the record.

There is no separate table to query for proof; the proof is the trace list itself. After recording, group the list by statement text and count occurrences: a single SELECT text executed hundreds of times with only the key values changing is the signature of a select-inside-loop or a missing FOR ALL ENTRIES/JOIN. To confirm the underlying table behavior, cross-check the key values seen in the trace against the actual table in SE16N: if the same key is fetched repeatedly and the data barely changes, that table is a candidate for buffering or for a bulk read instead of repeated single selects.

ST05 exists on S/4HANA and works the same way operationally: activate, reproduce, deactivate, review the list. On a HANA database the Explain output reflects HANA-specific plan operators rather than the classic database's access paths, so the details of what a good or bad plan looks like differ, but the trace workflow itself is unchanged. No Fiori app replaces ST05 as the primary SQL trace tool; broader end-to-end tracing capabilities exist in separate monitoring tools, but the SAP GUI transaction remains the standard entry point for this specific diagnostic.

Primarily an ABAP/development or performance-consulting task; Basis gets involved when the root cause is database configuration, missing indexes, or buffer sizing rather than the ABAP code path. A good handover includes the trace excerpt with the repeated-statement counts and durations highlighted, the exact transaction or report and variant used to reproduce it, and the time window the trace covered.

SE38 is used to locate and re-run the report being traced so the same step can be reproduced cleanly. SE11 is used to check the table definition and its buffering setting once a suspect table is identified in the trace. SE16N is used to sanity-check the actual data volumes and key values that ST05 shows being fetched repeatedly. ST22 is worth checking alongside ST05 when the traced step also produced a timeout or runtime error dump, since the dump often names the exact statement or table that the trace should focus on.