ST05: Activate Trace Recording with Filter
This is the second blog post in my series of posts about SAP GUI transaction
ST05. Here, I explain that you can control and customize the trace recording with filter conditions, and how this is useful for analyzing your applications’ performance. With a small case study I show this feature in action.
In the introduction to the sequence of blog posts (Use ST05 to Analyze the Communication of the ABAP Work Process with External Resources) I have referred to my transactions
STATS_FE as measurement tools, which help you to find performance hot spots in your applications. To identify root causes of poor performance (long response time or high resource consumption), you need dedicated analysis tools. With respect to communications and data transfers between the ABAP work process and external components,
ST05 is the analysis tool of choice. I have described the straightforward way of working with it in my previous post ST05: Basic Use. Be sure to read it for a quick review.
To trace events originating from or handled by a non-local application server instance within the current system, expand the dropdown list box for the Instance field to see all active instances. The local instance is explicitly indicated. If you know the relevant instance, select it. Otherwise, to activate tracing on all instances, choose <
ALL>. This tries to switch on tracing, but if it is already active for another user on an instance, the attempt fails for this instance. A popup will inform about this failure. The brute force option <
ENFORCE> unconditionally terminates any tracing in progress on all instances and then activates trace recording per your conditions. Use this option sparingly and carefully. It is convenient and safe for you, but may be disturbing and annoying for your colleagues.
With the group of fields Transaction Name, Program Name, RFC Function Name, or URL, you can limit the captured events to those that are triggered while executing a particular application. Note that this application must be at the very top of the call hierarchy. Therefore, a value can be given for at most one of the fields. Patterns with the asterisk
* as a terminating wildcard are allowed.
Occasionally, an application (most often a batch job) may occupy a work process for a very long time. With transaction
SM50 you can determine the work process’ number and then enter it into the Process Number field of the filter conditions popup. Thereby, you confine the trace recording to events related to the given ABAP work process. The resulting trace may identify the reason for the long duration. There is one caveat: A long running database operation that started before the trace was switched on will not trigger the creation of an associated trace record.
(To the best of my knowledge, the value of this filter criterion is rather limited, and it is not used very often. Please add a comment to this blog post if you know of an important use case.)
For an SQL trace, you can restrict the recording of SQL statements to those that work on certain database tables (or database views, including CDS views). You may define up to 5 tables to be included. Similarly, you can exclude up to 5 database tables. Statements accessing these excluded tables will then not be recorded. For both options, you may filter on groups of tables by terminating entries in columns Include or Exclude with an asterisk
*. For implemented Open SQL
JOINs, the table name filter applies to the first of the
JOINed database tables. If a database table matches entries in both columns, Include and Exclude, SQL statements against this table will not be recorded.
If you specify a table in the Include column, but also want to trace all statements that do not directly affect an individual table (e.g.,
SET SESSION VARIABLE,
SET CLIENT INFO), you must mark the check box Include Statements with Empty Table Names.
You may identify tables to be included with transaction
STATS(cf. my blog post Measure your Application’s Performance and Resource Consumption: Evaluate Statistics Records with Transaction STATS): The Top N Table Accesses sub record in the DB area shows the top N most expensive tables. You may also decide to focus on a table with central importance for your line of business, so that you get an overview and deeper understanding of where or how this table is used. Based on this knowledge, you can derive approaches for optimizing the accesses to this table.
Excluding certain tables from trace recording may be helpful if your application triggers many statements against these tables and you have already verified and confirmed that they are all necessary and processed in the best possible way. Then the corresponding trace records would only clutter up your trace, without adding any useful information. Even worse, they increase the risk that the available trace files get filled up to their capacity and then are successively overwritten, thereby evicting potentially important records. (Refer to my blog post ST05: Technical Background of Trace Recording and Analysis for a detailed description and explanation of the underlying mechanism.)
Make sure that you do not by mistake exclude a table that your application accesses via potentially expensive statements.
Imagine that you need to investigate the communications triggered by a batch job. You know its scheduled start time and have an idea about its expected duration. If the job starts or ends well outside of your work time, you can use
ST05’s Scheduling capability. Mark the check box Schedule Trace Recording, specify the relevant Start Date and Start Time as well as End Date and End Time. This schedules and releases jobs named
ST05_Trace_Off, which respectively activate and deactivate tracing on the appropriate dates and times. Start Date and Start Time should be slightly earlier than the beginning of the batch job you want to analyze, and End Date and End Time should be a little later than its projected end. Only then will the trace recording be active for the job’s entire duration so that the resulting trace can cover all relevant events.
If you cannot analyze the trace shortly after it was recorded, other subsequent tracing activities may overwrite it from its beginning. To protect against this, mark the check box Save Trace in DB and provide a Description. This will add a second step to job
ST05_Trace_Off, which processes all available trace records in the prescribed time frame and persists them with your description into the trace directory. There they will expire only after 120 days, giving you plenty of time for your evaluation. Please note that an active trace recording may overwrite its own beginning. The danger for this increases with the time during which tracing is switched on. Option Save Trace in DB cannot prevent this. It will nevertheless store the remaining trace records into the trace directory so that you can work at least with those that are still available, and do not lose even more records to other tracing activities. Of course, the previously explained approach to limit traced SQL statements to those that do or do not access specified database tables is very efficient in reducing the risk that a scheduled trace overwrites its own leading records.
The option to Activate Trace with Filter significantly enhances the basic trace recording capability of
ST05 to capture the communications and data transfers between the ABAP work process and external components. Without it many performance analysis projects would be much more complicated, and others would even be impossible.
The particular choice of filter conditions shall be guided by previous measurements of the application under analysis, e.g., with transactions
STATS_FE based on the statistics records. They identify the critical areas, and with corresponding filter criteria you limit the trace recording to these parts. This facilitates your subsequent investigation.
Trace Scheduling is really convenient for the analysis of applications that run at known after-hours times.