SAP ST05 Transaction: How to Run and Read an SQL Trace

The SAP ST05 transaction is the SAP GUI performance trace for investigating database access and other technical activity in an ABAP system. It helps you connect a slow business action to the SQL statements, tables, executions, and processing time recorded during that action.

Use ST05 for a focused investigation rather than as a permanent monitoring tool. Start the trace immediately before reproducing the issue, stop it as soon as the test finishes, and analyze the resulting records while the test conditions are still clear.

01What ST05 does

ST05 can capture several trace categories, including SQL trace, RFC trace, enqueue trace, and buffer-related traces. The SQL trace is the usual starting point for a slow report, transaction, interface, or custom ABAP program that appears to spend time waiting for database access.

A trace records technical activity for a selected user or scope. It can show the statement executed, execution count, records processed, duration, database object, and the ABAP location associated with the operation. The exact usefulness of the result depends on a controlled reproduction and an appropriately narrow trace scope.

For a broader reference to related SAP GUI transactions, see the SAP transaction code list. ST05 belongs to the technical performance and troubleshooting group, while business transactions such as VA01 or ME21N perform application processing that can be traced.

02How to start an ST05 SQL trace

Before activating the trace, identify the user who will reproduce the problem, the exact business action, and a short test window. Remove unrelated browser sessions, background activity, or repeated clicks from the test where possible.

1. Open SAP GUI and enter transaction ST05.
2. Select the SQL Trace option.
3. Choose the trace scope, such as your own user or a specified user, according to your authorization and the test plan.
4. Activate the trace.
5. Reproduce the slow action once, using the smallest realistic test case.
6. Return to ST05 and deactivate the trace immediately.
7. Display the trace records for analysis.

A trace started for the wrong user can produce an empty or irrelevant result. Confirm the logon user and the session used for reproduction before you activate tracing. When another user must be traced, coordinate the start and stop times closely so unrelated activity does not enter the result.

03How to analyze ST05 trace records

Begin with the statements that have the highest total duration or the largest number of executions. A statement with modest individual runtime can still create a serious delay when an application executes it thousands of times.

Review these dimensions together:

• Total duration: the combined time spent on the recorded operation.
• Execution count: how often the statement ran.
• Records processed: the amount of data handled by the database operation.
• Statement text: the filters, joins, sorting, and selected fields.
• ABAP call position: the program and source location connected with the database access.
• Database object: the table or view involved in the operation.

Use the trace display to sort and summarize the records before drawing a conclusion. Select a representative statement and inspect its details. The Explain function can help show how the database plans to access the relevant objects, subject to the database platform and available privileges.

Compare the trace with the user’s action and business data volume. A full or broad selection, repeated single-record reads, excessive conversions, or an unsuitable access path can explain a high runtime. The trace is evidence for the investigation; it does not by itself establish that adding an index or changing code is safe.

04How to troubleshoot an ST05 trace

An empty trace usually points to a scope, timing, or activation problem. Check that the trace was active during reproduction, the correct trace type was selected, and the reproduced request used the traced user. Repeat the test with one deliberate action and then deactivate the trace.

A very large trace usually means the scope or test window was too broad. Stop the trace, clear or isolate the result, and repeat the test with a shorter scenario. Tracing a busy shared user can mix several requests and make the result difficult to interpret.

If ST05 cannot be opened or trace controls are unavailable, review the user’s authorizations with the system security team. Transaction access and trace permissions are separate concerns. When an authorization check fails during the business action, use SU53 authorization analysis immediately after the failure so the relevant check remains available.

Use SE16N data browser only for controlled validation of table contents and record counts. Do not use unrestricted table browsing as a substitute for analyzing the application’s access pattern, and protect sensitive business data while investigating.

05How to use ST05 results for remediation

Document the test conditions with the trace: user, transaction or report, selection values, start time, stop time, and the statement or call position that requires attention. This makes a later retest comparable and prevents a performance change from being judged against a different workload.

For custom ABAP, review the source location associated with the expensive statement. Common remediation areas include reducing repeated database access inside loops, restricting selections earlier, selecting only required fields, and replacing avoidable row-by-row processing with a set-based approach. Test the change with representative data and verify functional results.

For standard SAP processing, provide the trace evidence to the application or technical support team responsible for the process. Keep the original trace, the summarized findings, and the retest result together. Database changes, code changes, and configuration changes should follow the system’s change-control process.

06ST05 operating checklist

Use this short checklist for a repeatable investigation:

• Define one slow action and one reproducible test case.
• Identify the exact SAP GUI user and session.
• Activate only the trace type needed for the investigation.
• Reproduce the issue once where practical.
• Deactivate the trace immediately after the test.
• Sort by total duration and execution count.
• Inspect the statement, database object, and ABAP call position.
• Record the proposed change and retest under comparable conditions.

ST05 is most effective when the trace is narrow, the reproduction is repeatable, and the result is interpreted alongside application behavior. It provides a technical path from a user-visible delay to the database access that deserves further analysis.