1

2
Guides
Note 1609155 - Guided Self Services
Note 1634757 - Guided Self Service 'Performance Optimization'

Known issues
Note 1560500 - ST-A/PI: CAT_GET_SQL_TRACE_INFO not taking care of
instance
Note 1600748 - ST-SER 2010_1: Replacing parameters for issues in GSS
Note 1626734 - ST-SER 2010_1: Replacing parameters for issues in GSS
Note 1637052 - ST-SER 2010_1: Tasks in issue are randomly sorted
Note 1641962 - ST-SER 2010_1: Duplicate tasks are generated in GSS
scenario
Note 1643208 - ST-SER: Session dumps after content update

4
5
6
The above shows the four modes for recording traces:
• Tasks & HTTP
• Work Process Trace
• Current Mode – trace yourself executing a function
• Scheduled trace – for example, trace a background job when you
are not logged on to the system.

The scheduled trace can also be launched via the menu bar as show in the
screenshot.

7
Automated collections
ABAP trace
SQL summary

8
Gross: Sorted by gross time ( expensive mod. units). Gross times are used to get a top-down
overview. Modularization unit names often give a good indication what happens
below them, so that their gross time can be attributed to a certain functionality.
Net: Sorted by net time ( expensive execution). Sorting by net times shows single expensive
statements or mod. units that themselves consume much execution time.
Per Mod. Units: ‘Per modularization unit' is a kind of mixture of gross and net time display. On
an upper level it shows only one line for every modularization unit. When such a line
is expanded, the statements and calls inside this mod. unit are shown in aggregation
'per calling position'. Statements and calls outside of mod. units are grouped below
dummy lines '<program> [outside of mod. units]'. The net times of simple statements
are added to the net time of their upper level mod. unit. This aggregation is suitable to
detect localized issues in single mod. units.
Top down time-split: Shows the ~30 most important below an entry in a swimming lane
diagram. Importance is measured in terms of how much aggregated time flow they
receive from the original entry. The subordinate modularization units are grouped into
distinct branches, it is shown how they are linked to the original entry and where the
time flow splits up (several empty diamonds in the line). This is very helpful for time
distribution and for time-loss analysis.
Bottom-Up: ‘Bottom-up call hierarchy' works like a multi-level where-used search. The hierarchy
above an entry is displayed in the form of a swimming lane diagram. The empty
diamond symbols show where a call is issued, the filled up/down triangles where it
arrives. The small arrows between them are pure cosmetics, illustrating the call
direction. The exact meaning is: “Out of modularization unit <empty diamond> a call
to modularization unit <filled up/down triangle> is issued”.

9
Maintain the technical trace settings
• Set flag ‘internal tables’
• Under further options set the maximum trace file size and recording time
• If needed, set the trace resolution to low (see typical trace problems)

• Note: Never use the fully aggregated trace since it is not useful for trace
analysis (no statement call positions)

10
11
12
In the "Current Mode" scenario you are going to trace the execution of a program
or transaction.

You can enter a comment to give a meaningful description for the trace. Enter
your program or transaction in the corresponding field and set the appropriate
radio button, see nr. 3. In the lower part of the screen you define the
measurement scope. The left part is for the ABAP trace and the right part for the
Performance Trace.

Note: Since ST12 uses the functionality of both transactions (SAT and ST05) the
options are similar or the same. ST12 hides some details to make the traces
more easy.

Before you trace, it is recommended to execute your program or transaction

several times to fill the buffer and caches, as filling the buffers and caches is
something that cannot be optimized with ABAP or SQL tuning.
Always before starting the trace you have to define the measurement scope. In
ST12 this is done "on the fly", no measurement variants are saved.

For the ABAP trace the most important decision is if you want to trace "with
internal tables".
It is recommended to switch this setting on.
Other options like Particular units, Filters or "Further opt." are only needed in
exceptional cases and will be explained later.

13
The ABAP and SQL Traces are recorded for all of the execution time
(between T1 and T2). This means that all activities are recorded, including,
for instance, the report screen generation.

14
15
The status column shows you whether your trace is ready for evaluation.
There might be a red and white circle, which means the ABAP trace is still
being imported into the database.
The yellow flash indicates a measurement error (e.g. time limit exceeded,
file size too small, ...).

16
The green tick shows that the ABAP trace has been successfully imported
to the database.

17
It is possible to activate the trace for only a specific part of the execution of
a transaction.

18
19
The particular unit mode is useful to trace between two steps you can
choose.
After filling in the Report name and a comment for the trace, we select the
"Particular units" option.
Note: this option is only available in the "Current Mode" Scenario.
All other options are set as described in this presentation.

20
We don't want to trace the whole execution (dashed black arrow) between
T1 and T2 but only the data process (solid red arrow) between T1a and
T1b.

Note: As you can see in figure 2 the ST05 trace (dashed grey arrow)
records the whole execution of the transaction and not only particular units
of it.

21
After you start the trace, the report Z_ITAB_DYNPRO (or the transaction /
program you entered in the corresponding transaction / program field in
ST12 in the main screen) will show up.

Since we switched on the "Particular Units" nothing is traced so far.

The SQL trace has started recording, but the ABAP trace hasn’t.

Now we can execute the initialization, nothing will be recorded in the ABAP
trace yet.

22
After the initialization, the button “Process data” appears, we can type "/ron"
in the ok-code field (this is the field where you type in the transactions e.g.
ST12 as well) and press ENTER (nr. 1).

This signals that the ABAP trace should be recorded from now on. This is
confirmed with the message "Runtime analysis enabled" at the bottom of
the screen (nr. 2).

23
After we execute the “Process Data” step, the screen shows the execution
runtime. We have to set the second marker now that indicates we want to
stop trace recording so that nothing else is traced from this point on.

We enter "/roff" in the transaction code field (nr. 1). We get the message
"Runtime analysis disabled" at the bottom of the screen (nr. 2).

After this, nothing else (e.g. clicking on save) will be recorded in the ABAP
trace any more. But the SQL trace is continuing to record.

If you return to ST12 and open the ABAP trace, it will only contain those
parts of the execution that were running between the markers "/ron" and
"/roff".

24
Now, you are able to analyze the trace results (nr. 2).

25
Alternatives for the "/ron" and "/roff"
In dialog transactions you can either work with the ok codes "/ron" and
"/roff" like we have seen above. Alternatively you can use the menu path:
System - Utilities(H) - Runtime Analysis - Switch on
System - Utilities(H) - Runtime Analysis - Switch off

In your own developments (e.g. for programs running in background) you

can even do it in the ABAP code with these 2 commands:
SET RUN TIME ANALYZER ON.
SET RUN TIME ANALYZER OFF.

See how the above mentioned ok codes can be used in modal popup
windows:
http://wiki.sdn.sap.com/wiki/display/ABAP/SAPGUI+shortcuts

26
27
28
The work process tracing is dedicated to trace an already running program.

Imagine you started a program which runs longer then you expected.
The program is still running and you wonder what the program is doing.
This time we use ST12 to perform an ABAP and SQL Trace on a program
that is currently running.

Since both the ABAP and the SQL trace are application server specific, you
have to choose on which application server you want to start the trace.

To do so click on the "Choose application server" button (Nr. 3) and choose

one application server from the popup that appears (Nr. 3) by marking it and
confirming with the green tick.

If you don't choose an application server the local application server is used
as the default.

29
The work process selection screen is similar to the SM50 transaction.

Mark the process you want to trace by simply clicking on it.

Then activate the trace by clicking the "Start traces for workprocess" button (Nr. 2) or press SHIFT
+ F7.
You will see yellow triangles or green squares in the columns for each trace.
-A yellow triangle means that the trace has been activated but nothing has been recorded so far.
-A green square means that the trace is active and has recorded actions.
In the slide, the ABAP trace has already recorded some actions while the SQL trace is only active,
and has not recorded anything yet.
After some time when you want to finish the trace click the "End all traces and collect" button (Nr.
4) or press SHIFT + F1.
You can see the appropriate status messages for both actions.

Note:
In case you don't deactivate the trace before the transaction is finished, the ABAP trace ends with
the traced transaction, whereas the SQL trace continues with work process filter.
So if another program starts on the same work process it will get SQL traced (but not ABAP
traced).

Tracing processes on remote application servers :

ST12 triggers the traces (SE30 and ST05) remotely, that means the trace files are written on the
remote server. After the trace is finished, ST12 imports the SE30 trace file from the remote server
into the database.
It can then be evaluated on any application server in the system.
For the ST05 trace, if you click on the Performance trace button, you will be logged in automatically
on the server where the trace has been taken on.
This of course only works if the trace has not been overwritten in the mean time on the file system,
since the ST05 trace is not imported into the database by ST12.

30
31
32
Since both the ABAP and the SQL trace are application server specific, you have to choose on which
application server you want to start the trace. To do so click on the "Choose application server" button
(Nr. 3), and choose one application server from the appearing popup (Nr. 3) by marking it and
confirming with the green tick. If you don't choose an application server the local application server (the
one on which you presently are) is used by default. In cases where load distribution is used you don't
know which application server will handle the request, for this ST12 offers the opportunity to choose
<All Servers > in order to activate the trace on all application servers in your system. This option is very
useful when you have several application servers and incoming RFCs or HTTP requests.

The next input is the user and the task type field (Nr. 4). You can specify a filter for a specific task type.
Choosing “HTTP" for example will only start a trace if a HTTP request of the specified username is
executed. For other task types like e.g. "R RFC" or "D DIA" it works in the same way.

The final input you have to make is the number of trace activations / requests (Nr. 5). Here you can
specify how many requests should be traced:
This allows to specify the maximum number of ABAP trace activations (=ABAP trace files) per instance.
This option is suitable to trace a certain number when dealing with many similar incoming requests e.g.
from ABAP Web Dynpro or BSP applications where screen elements can make their own calls (HTTP
requests) to the SAP system. For incoming RFC calls this option is very useful as well since each RFC
call results in its own trace.

Note that synchronous RFCs to the same destination without a "Connection close“, are considered as
one transaction (one trace) in the remote system.

Please note the warning if you set up a trace for your own user. Depending on the task type (e.g. in
case of "D DIA" or "*any" a trace request will be used for ST12 itself when you close the popup).
Other actions you are performing in the system while tracing might use trace requests as well.
Additionally ST12 tracing activities (namespaces /SSF/ and /SSA/) will appear in the performance trace
(SQL RFC).

33
Starting a trace

After starting the traces the text of this button (Nr. 5) changes to "End traces &
Collect". Press this button if you want to stop the measurement. In case no traces
have been recorded there will just be a message at the bottom of the GUI saying
"No traces found for collection". Possible reasons for this could be that there was
no request that matches the user you specified or the trace has been set up on
the local application server only and the requests arrived at a different server.

After having started the trace, you will see the following information in the small
table that is just above the “start trace” button.

- ABAP waiting trace requests = number of requests that still could be traced
- ABAP running traces = number of traces currently running
- ABAP finished trace files = number of traces finished so far
- SQL trace = if X, indicates that the SQL trace is running
- Enqueue trace = if X, indicates that the Enqueue trace is running
- RFC trace = if X, indicates that the RFC trace is running
- Server = the name of the server for which the information given in this line
belongs to

You can use the refresh icon (see nr. 4) to update the figures in this table while
your trace is running.

34
If traces have been recorded, they are presented in a pop-up screen. All
servers that have been specified for the trace recording will be checked for
trace files.
What you see here are the ABAP trace files taken with SE30 which was
"remote controlled" by ST12 (ST12 calls SE30 and ST05 “under the
covers”).

On this pop-up, mark all traces, or hold down the SHIFT key to mark
several ones, and import them (Nr. 2).
The traces will then be imported to the database. You will see the traces in
the table at the right bottom of the main screen of ST12

35
Some background information on trace recording
The content of the ABAP trace part might not be the same as the content of the performance trace part.
The reason for that is described here :
For the given user name and task types on the given server(s) a new ABAP trace will be started for
each transaction / LUW (logical unit of work) . That is from the first roll in of a transaction while the trace
is active. The ABAP trace will be stopped when this transaction is finished.
The performance trace (e.g. SQL trace), on the other hand, will be started immediately for all requests
for the given user, task type and server(s). It will be stopped when the trace in ST12 is switched off.
The solid arrow (top of the graphic) shows the time frame for which a trace was started in ST12 on 2
application servers (AS1 and AS2).
The green dashed arrows (ABAP trace 1, 2, and 3 respectively) show the time frames which will be
recorded in the ABAP trace if each request (R1, R2, R3) is a transaction.
The blue dashed arrows (SQL trace 1 and 2 respectively) show the time frames which will be recorded
in the performance trace.
As you can see the time frames can be quite different.
-On application server 1 (AS1):
If for the given user / task type combination no other processes are running between start time T1 and
stop time T2, the content for the ABAP and the performance trace will cover the same request (R3) and
you will find in both traces only actions for this request. Note if other processes for the given user / task
type are running during the trace their actions will be included in the performance trace and generate
ABAP traces as well.
-On application server 2 (AS2):
If for the given user / task type combination no other processes are running between start time T1 and
stop time T2 the content for the ABAP and the performance trace will be different. We will have 2 ABAP
traces: one each for request 1 (R1) and request 2 (R2), showing their respective actions. But there will
be only one performance trace containing all actions from request 1 (R1) AND request 2 (R2). Note if
other processes for the given user / task type are running during the trace their actions will be included
in the performance trace and generate ABAP traces as well.

36
37
38
For the background jobs tracing, in the ST12 transaction, you have to
maintain the technical trace settings (nr.1, nr.2 and nr.3).
Leave blank the others fields like “comment” or “username”.

It is important that you enter technical settings in this first screen, these
settings will be necessary and valid for the next job setting step.

As the trace can be executed over a long period of time, it is important to

increase the max size of file to at least 20MB so as to not overflow the file
size.

39
Use the Utilities menu to schedule the trace for batch job or work process.

40
In our specific example, the focus will be on the background job tracing.

You have to enter the followings parameters :

- the name of the job, and/or the name of the report,

- the time frame, the maximal trace duration,
- the trace start delay time, meaning when the job running has been
found, and the “delay time” has been finished, the real trace
recording can start.
- check interval( the trace daemon will check if the job is active every
n seconds, n=check interval ),
- minimum value = 10s,
- default value = 60s,
- recommended value = 10s
- the name of the trace (comment)

and press the button “Schedule trace”.

41
In the table of scheduled trace requests(nr. 1), you see the trace recording
status.
Use the “Refresh” button (nr. 2) to update their status.
Once the status is green, the ABAP trace recording has started.

Trace status :
- Glasses - is waiting for matching jobs
- Yellow triangle - is trace activated but not recording yet
- Green - is trace recording

When the trace is finished, the entry will disappear and application will
continue.

42
Important information :
According to the combination of time frame, trace start delay, and check
interval, you may start the trace during the execution of a SELECT
statement that delivers thousands of records and consequently taking a
long time.

In the performance trace file, you will see many FETCH lines but not the
OPEN cursor statement since the trace has been activated after the
cursor was opened.

Without the OPEN cursor action you can't get the source of the SQL
statement in the ABAP program. The information in the trace will not show
you the source of the long running SQL statement.

If several jobs match the criteria for the trace starting, only the first one
will be traced, the others will be ignored (only 1 work process can be
traced in parallel)

43
44
45
Automated collections
ABAP trace
SQL summary

46
The “Collect ext. traces” functionality is useful e.g. to analyze the
performance on the RFC processing side during RFC calls.

For this, we have to select the external trace on the external system (in our
specific example, same system), and import it to our source system, if SAP
BASIS components are identical).

It is important to specify the time frame before searching. The usage of the
TransactionID is useful when analyzing an end-to-end scenario.

Best practices:
It is preferable to collect the trace on the target RFC system due to the fact
that we will have the possibility to jump into the source code from the trace
details.
If the SAP BASIS components of source systems and target systems are
different, inconsistencies are possible while attempting to evaluate the
ABAP source code.

47
A pop-up is showing the found external traces.

48
Automated collections
ABAP trace
SQL summary

49
The statistical records functionality is useful to analyze the STAD
information related to your ABAP/performance trace.

With this detailed procedure, you can associate the STAD records, and
store it with your ABAP/performance trace.

50
You can also analyze record per record without importing it.

51
The statistical records have been imported to your selected
ABAP/perfomance trace.

52
53
Automated collections
ABAP trace
SQL summary

54
55
56
57
59