Skip to Content

ST12 – new features

The Single Transaction Analysis was extended recently and has some great new features. This blog shows you what you can expect from the latest version.

Before you start:

ST12 is delivered as a part of the Service tools for Applications (ST-A/PI). SAP note 69455 describes how to get the latest version of the ST-A/PI. Watch out for the 01N_* version which is RTC (released to customer) since 21st of March.

Please note that the ST12 transaction is not officially documented / supported and only available in English language. Although it is mainly intended for use by SAP or certified Service consultants during SAP Service Sessions, you can use it for you own performance analysis. A brief description of ST12 is given in SAP note 755977 (ST12 “ABAP Trace for SAP EarlyWatch/GoingLive”). A few blogs on ST12 can be found in the ST12 WIKI in SDN:

New Features:

If you are on SAP NW EhP2 (7.02) ST12 calls the new ST05 which is faster and offers more features than the old ST05.

Let’s have a look at the new elements on the main screen of ST12 in figure 1.


Figure 1: Main screen

The button “SQL summary” (nr. 3 in figure 1) will forward you to the SQL trace summary which has been collected and imported automatically by ST12. The SQL summary (figure 3) is as well stored together with the trace in the database. This data is independent from ST05 after import. That is you can do an explain plan (nr. 9 in figure 3) for a statement within ST12 without leaving to ST05 and without having the data of ST05 available. Furthermore some additional data (nr. 8 in figure 3) like”% of the time of ABAP trace time” for the SQL statement or additional statistics (e.g. min, avg, max execution time) per calling position is available in the SQL summary.

With the button “Statistical Records” (nr. 1 in figure 1) in the top of the screen you can manually collect data from an existing STAD record and store it together with the trace analysis to the DB. This button brings you to a pre filtered list of possibly matching STAD records where you can choose the right one. All important KPIs of the STAD record chosen will be imported and stored together with the trace in the database. Up to now the import has to be triggered manually; future versions may offer an automated import. The statistical data can be accessed with the button “Stat. records” (nr. 3 in figure 1) after they have been imported.

Now let’s have a look at the new options on the Trace list (after clicking on the list button).

 figure 2

Figure 2: New options

In the new version it is possible to compare (nr. 4 in figure 2) and merge (nr. 5 in figure 2) ABAP trace files. The comparison of trace files will be further extended in the near future. With the buttons below (nr. 6 in figure 2) you can directly evaluate the data starting from the trace overview list. Furthermore it is now possible to mark multiple traces e.g. to delete a bunch of traces. Please note that for the comparison you have to mark two traces and for the merge at least two.

In the ABAP trace analysis we can see some UI changes an ALV is used now which makes the analysis more convenient.

Another great option is the link between ABAP trace and SQL SUMMARY (figure 3). For SQL statements you can see a DB-> (nr. 7 in figure 2) sign at the end (which appears only if you have clicked on SQL summary before, see (nr. 3 in figure 1). This button opens the matching SQL records for this source code position from the SQL summary (figure 3) for the ABAP trace entry you just clicked on. This is like a join between ABAP trace data and SQL trace data which makes analysis even more powerful.

 figure 3

Figure 3: SQL Summary


In the last months ST12 made a great leap forward. The options introduced above will make performance analysis more easy, convenient and powerful. As soon as I have some time I’ll blog about the new features in more detail, so stay tuned. You will find these blogs in the ST12 wiki mentioned below.

More information on ST12 can be found here:



You must be Logged on to comment or reply to a post.
  • the improvements like STAD records and SQL trace will not be overwritten any more are really nice.
    It reminds me some of other “dreamed” functionalities I wish we have:
    0. A better view of the trace files. If we can simply adjust the location of the trace file to the bottom of the screen thus we can see user + time + trace name+ trace length etc at the same time.
    1. When doing trace by request, we may get multiple trace results to collect. It will be nice to have more information shown before the collect. At least a run time?
    2. Possibilities to navigate the trace with time line. For example, the trace is for a background job from 15 seconds to 120 seconds. It will be really nice to limit the time frame to see what’s happening between 40~60 seconds. This will be really helpful for program logic analysis.
    3. Possibilities to get some memory consumption / internal table size information. E.g. the memory consumption during the trace; size of the all (certain) internal tables.  If we have “trace level” it will be nice to choose from different level of details we need.
    • Hi Kai,

      thanks for the comment.

      1.) is not possible without reading (importing) the trace…
      2.) and 3.) would require an unaggregated trace (with the aggregation we loose important information) but regarding 0.) we could at least check what is possible….

      Kind regards,


      • actually if we can get 0) improved then the problem with 1) will be much simple.It is now really painful to get 50 requests first and then delete 49 of them. if we can do a multiple select on the trace files it will be much better

        I know 2) and 3) might be too much to ask for now. But technically this should not be difficult I assume (I wrote profiling tools with simple functionality couple of years back)? Non-aggregated trace is already possible with SE30 so I guess most of the logic required is already there. Then an additional time stamp will solve most of the issue.

        • Hi Kai,

          but the “mark multiple traces” is there now… (in the new version).

          And ST12 only traces aggregated by call… .

          Kind regards,


          • Hi Hermann,

            thanks a lot. I just tried a system with newer versions, it is possible now do a delete with mutiple traces with in the “list”. quite handy, thanks again.

            Best regards,

      • Hello Hermann,

        to 1): we are working on it. Bernd had made a request to ABAP development to store additional information in the trace header and we’ll not have to import the trace for it.
        Here is the list of requested info. I don’t know the current status of the request unfortunately:
        – Task Type (+add. info in case of RFC)
        – Passport and relationship info (to better assign abap and sql trace to each other)
        – RFC connection ID
        – Session ID and dialog step
        – Work Process ID

        So, we are working on the enhancements 🙂

  • Hello Hermann,

    there are more exciting features to come:

    1) A log for scheduled traces shall be written (currently they are deleted and if not successfull there is no information).

    2) For a long running job automatically a next trace shall be scheduled.

    3) Workprocesstrace: All servers (SM66) shall be shown by default

    I’ll keep you updated.