Performance Problems in ABAP Programs: How to Find Them
Performance Problems
in ABAP Programs:
How to Find Them
Werner Schwarz
Werner Schwarz joined SAP
Retail Solutions in October
1998. Today, he is the
development team contact
for all performance-related
issues concerning SAP’s
Retail Industry Business
Unit. Werner’s major
tasks include information
rollout and support of his
colleagues regarding
performance during both
development and
maintenance.
(complete bio appears on page 62)
For site licenses and volume subscriptions, call 1-781-751-8699.
Editor’s Note:
SAP Professional Journal has published ABAP performance articles on a
number of occasions. It is with particular pride that we present this special
two-part series. This first installment demonstrates how to use SAP’s tools for
performance analysis and describes how to identify the areas that dominate the
runtime of a poorly performing program. Although some of you may already be
familiar with using Performance Trace to analyze database accesses (an article
in the May/June 2002 issue covered this topic in detail), we think you will find
additional insights here, along with new material about using ABAP Runtime
Analysis, which is an invaluable tool for identifying critical sequences in your
ABAP code.
The second installment will profile the most frequently encountered causes of
runtime maladies and offer suggestions for addressing those problems, with
a focus on both database accesses and ABAP statements.
Together these articles deliver a comprehensive approach to performance
optimization.
Lots of factors can give rise to sluggish execution of a transaction or a
report. Sometimes there are general system problems. Sometimes users
use the program in a way it was not designed for. Sometimes the nature
of the application and workload calls for parallel processing. And
sometimes the source of the performance malady can be traced back to
performance issues in your ABAP code.
If you’ve ruled out deficiencies in the system setup, mishandling by
users, or the need for parallel processing, then you need to revisit your
code and see if the source of your runtime problems is lurking there.
But how do you approach such an exercise? I have found that most
39
SAP Professional Journal May/June 2003

Is There a Bug Among Us?

Before you rush off on a search-and-destroy mission for bugs within your ABAP code, ask yourself the
following questions:
Does the performance problem occur only sporadically, even with small data volumes? And do
other transactions running at the same time also exhibit poor performance?
If the answers to these questions are yes, chances are good that the system setup is at fault. Ask your
system administrator to check for insufficient hardware, improper system configuration, database locks,
and system bottlenecks.
Are users misusing the program? Are they, for example, entering insufficient or unreasonable
restrictions in the data selection screen such that far more data is processed than necessary?
In this case, you should check if it is possible to optimize the user interface (using mandatory input
fields) or if you can perform some plausibility checks in your program to detect unreasonable input.
Finally, it can also make sense to retrain users.
Is the prolonged runtime simply caused by the amount of data that must be processed?
If this is the case, parallel processing and/or reducing the functionality of your program may be the
answer. In general, you should always ask yourself if the extent of the used functionality is really
needed and if the business benefits balance the required runtime.
If in reviewing your performance troubles you answered yes to any of the above questions, do not
proceed with the methodology I’m suggesting in this article. Address these issues first!

developers are more familiar and adept with the tools
and procedures for identifying functional bugs than
those associated with performance analysis. This
article aims to reduce, or even eliminate, that imbal-
ance. Here, I offer an introduction to the use of
SAP’s performance monitoring and tracing tools, and
recommendations for wielding them.
In the first part of this article, I will show you
how to determine whether your performance prob-
lems are caused by inefficient database accesses or by
awkward ABAP coding. I will also show you how to
deal with both types of performance problems. Of
course the procedure described in this article cannot
help you in all situations, as there are so many differ-
ent scenarios that can lead to performance problems.
But the strategies I will describe, which are based on
personal experiences and preferences, turned out to be
successful ones in many cases.
In the second part of this article, I will discuss
the possible reasons for runtime problems. I have
found that there are a few issues that tend to be
responsible for a majority of performance problems.
I will describe these issues in detail and also present
possible solutions.
Performance Problems
Come in a Variety of Flavors
I know that most of you are familiar with the multi-
tier SAP architecture shown in Figure 1. There, you

40 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.

Figure 1 The Standard SAP System Architecture
User ... User User User ...
Instance 1 Instance 2
Database
see one database, some instances where your ABAP
programs are executed in several work processes, and
a presentation layer (the client frontends) for display-
ing screens to the user and accepting user input. This
is standard fare. Typically, the database is installed
on a database server along with an instance for
administrative purposes and the enqueue processes.
The other instances are installed on one or more
application servers.1 Each user uses a presentation
server (e.g., a PC with an SAP GUI), which is con-
nected to an instance when logging in to the system.
Network connections between the database and
application servers are typically fast. However, that’s
not always the case with connections between the
presentation layer and the application server, where
you often find slow WAN connections with high
latency times or small bandwidth. Let’s start our
performance diagnosis dialog here.
1
One typically finds a single instance per application server, and that
is why the expressions “instance” and “application server” are often
used interchangeably, even though they denote different things.
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
User User User ... User User
... Instance n
Slow speeds and reduced bandwidth are obvi-
ously not ideal conditions for short response times.
Performance problems are bound to ensue. Perfor-
mance problems are compounded when developers
allow the amount of data sent between the application
server and presentation layer to be greater than it
ought to be. Assume, for example, that a user wants
to see a document that contains 3,000 line items. If
the complete information on all 3,000 line items is
sent, the load on the frontend and the time required to
transfer the information can be considerable. Note,
however, that only about 20 lines can be displayed at
the same time and that the user has to scroll down to
see more information. In this scenario, the argument
that scrolling would be faster with all the information
downloaded to the frontend is not a sound one,
because users would have to wait up to several min-
utes (an insufferably long time as far as they are
concerned) before the first screen could be displayed.
Here, it appears to be better to send only the informa-
tion to the frontend for those 20 lines that can be
displayed, despite the fact that data would have to be
41
SAP Professional Journal May/June 2003
exchanged between the frontend and application
server with each scrolling.
ü Tip
While this article focuses on finding performance
problems in existing programs, let me offer you
this piece of advice for programs that you have
yet to develop: When it comes to performance,
your best defense is a good offense. You can
minimize the amount of data exchanged
between the application server and presentation
layer through proper use of controls (e.g., trees,
tabstrips, and tables) and by not sending
superfluous data to the frontend or performing
superfluous roundtrips.
Working our way down the layers of the multi-
tier architecture, the largest part of the load in a trans-
action is generally supposed to be performed in the
work processes on the application servers. Here, a
possible performance issue can be reading (and pro-
cessing) too much data from the database or not
eliminating irrelevant data at the earliest opportunity.
Another critical point can be the unnecessary, identi-
cal repetition of actions. For example, lots of time
can be needlessly expended executing a function over
and over again for all the line items of a document,
when, in fact, the function only needed to be per-
formed once per document. This mistake probably
stems from a lack of understanding that the function
does not depend on the line information — or simply
from carelessness. I see developers make this mis-
take quite a bit with the implementation of certain
user exits. Bugs like that can cause a considerable
increase in runtime. Fortunately, they can be easily
identified with the appropriate monitoring tool. Later
in this article, I will show you how.
Among the most treacherous pitfalls are those
caused by sub-optimal handling of large internal
42 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
tables. This can cause a non-linear runtime (i.e.,
processing twice the number of work items in your
program leads to far more than doubling the runtime),
which can result in severe runtime problems with
growing data volumes. This problem can frequently
be solved — without changing the program design or
the functionality — by simply applying the suitable
technical solution for the handling of the table
and some smaller modifications. (This will be
covered in the second installment of this two-part
article series.)
Finally, all programs perform numerous accesses
to the database. This is another possible source for
runtime problems, which should be considered thor-
oughly. For example, selections that are not sup-
ported by a suitable index can entail long (very long!)
runtimes. This not only potentially hampers the
running programs themselves, but is also an encum-
brance to all users, as they have only limited access
to the database if it is blocked by some long-running
selections.
So, now that you know that performance prob-
lems can be lodged in a variety of places, where do
you start your analysis when confronted with a
poorly performing program? That’s what we will
examine next.
Pinpointing Performance
Problems: Where to Begin
The first thing you need to do when trying to pinpoint
a performance problem in your code is determine
whether the program’s runtime is dominated by time
spent on database requests or within the ABAP pro-
gram. If the answer is database accesses, your perfor-
mance analysis will take you down one path; if the
answer is ABAP execution, you’ll head down
another, as shown in Figure 2. As you can also see
in Figure 2, the determined path will prescribe which
tool you will use (Performance Trace or ABAP
Runtime Analysis) in the next steps of your analysis.
 Performance Problems in ABAP Programs: How to Find Them

Figure 2 Is Runtime Dominated by Database Accesses or ABAP Execution?

@ Use transaction Statistics (STAD/STAT) or Process Overview (SM50).

? Is the database request time equal to or considerably larger than the CPU time?
@ Use Performance Trace (ST05) and ascertain which tables cause the highest load.

? Is the load caused by the use of an unsuitable execution plan?

Æ Check the execution plan of expensive statements using Explain SQL.

? Is the load caused by a large number of records/accesses?

Æ Check for identical selections or missing restrictions in the WHERE clause.

Æ Check for correct use of R/3 buffers.

? Is the CPU time equal to or considerably larger than the database request time?
@ Use ABAP Runtime Analysis (SE30) for further analysis and sort hitlist by net time.

? Are there modules with a high percentage of net time due to numerous calls?
Æ Reduce the number of calls if they are not justified.

? Are there modules with a high percentage of net time for only a few calls?
Æ Repeat analysis for this module including only accesses to internal tables.

? Long runtime cannot be linked to a few modules?

Æ Check program for possibilities to avoid unnecessary functionality.

There are usually two ways to make this determi-

ü Tip
Before you attempt to isolate your performance
problem, verify that the suspected program has
been recently executed. Otherwise, when
running the program, the runtime will be hard-
hit by the time it takes for database accesses to
fill table and program buffers on the application
server, and hence distort the result. If possible,
you should run the program once before
executing the run for the analysis. It is not
necessary to perform this “pre-run” with the
full data volume — it is sufficient to process
only one small document, or a small part of
the workload, for example, to fill the program
buffer or table buffers.
nation. One is to use statistical data from the system.
The other is to observe the program at runtime. In a
moment, I will show you how to take advantage of
both options. Just one caveat before I do: If the
program you want to analyze for performance prob-
lems takes hours to finish, it will not be feasible to
conduct a performance analysis of the full execution
of the program. In cases such as this, see if it is
possible to run the program with smaller data vol-
umes and conduct your performance analysis over the
abbreviated runtime. Often, this will give you the
insights you need. In the descriptions that follow,
I will assume that you can use a test case with a
runtime that is short enough to perform a complete
analysis. If this is not the case, you will have to try
to analyze certain parts of the program, performing

For site licenses and volume subscriptions, call 1-781-751-8699. 43

SAP Professional Journal May/June 2003
Figure 3 Statistical Records Display (Transaction STAD)
your analysis in several smaller steps, or you will
have to rely on observation and your wits. I will
offer a bit of help on this when I review the Process
Overview (transaction SM50) analysis in an upcom-
ing section.
Performance Analysis Option #1: Review the
Statistical Data
The R/3 system records statistical data for every
executed dialog step. This data contains (among
other things) information about the response time,
the time required for database requests, and the
required CPU time (which can essentially be consid-
ered as the time that is spent in the ABAP code).
You can access the statistical information using
transaction STAT (in Release 4.5 or lower) or STAD
(starting with Release 4.6).
44 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
A performance analysis based on STAD/STAT
would proceed as follows:
1. Run your program.
2. Call transaction STAD/STAT and select the
relevant information.
3. Examine the values in columns DB req. time
and CPU time.
In Figure 3, you see a screenshot with the output
from transaction STAD. Each dialog step that was
executed on the system, and fulfills the restrictions
you selected on the initial STAD screen, is displayed
in a line of its own. You see the time of execution,
the server where the dialog step was executed, the
transaction and/or program it belongs to, the type of

work process (dialog, batch, update, etc.), the screen
number of the dialog step, and the logical number of
the work process that executed this step. With this
information you can precisely identify the dialog
steps of interest.
The important performance information appears
in the columns described below. You can select the
information to be displayed using the Sel. fields
button in the application toolbar. For a performance
analysis, we are interested in the Response time, CPU
time, and DB req. time columns (which are displayed
by default):
• The Response time of a dialog step comprises
the time for the dialog request in the dispatcher
and in the work process, the processing time
itself, and the completion time of the dialog in the
dispatcher. Note that the time required for trans-
ferring the data from the presentation server to the
dispatcher (and back) is not considered here. In
long-distance or low-performance networks, this
can lead to considerably longer “subjective”
response times, where the user’s impression of
the response time is longer than the time shown
in this column.
For example, assume there is a very slow modem
connection between the user’s PC and the applica-
tion server, and that the transfer of the request to
the application server takes 2 seconds, the process-
ing of the request takes 1 second, and the transfer
of data back to the user’s PC takes 1 minute due to
the large amount of data. While STAD will show a
response time of 1 second for the dialog step, the
user’s impression will be that he had to wait over a
minute to continue his work.
• During execution of a dialog step, the application
server CPU is used for processing. In general,
the CPU time can be roughly identified as
the time required for the execution of ABAP
statements.
• A certain amount of the time is required for a
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
dialog step involving database operations (e.g., to
read or change records). Database calls are calls
to the SAP database interface, which are either
already fulfilled by the R/3 table buffer or trans-
ferred to the database. The value of DB req.
time to a large extent depends on network run-
times and the database server load.
In general, Response time is roughly the sum of
CPU time and DB req. time. So:
• If DB req. time is considerably larger than
CPU time, you should take this as a cue to focus
your attention on the database accesses. Proceed
with a detailed analysis of the database accesses
using the Performance Trace tool, as indicated in
Figure 2.
• If CPU time is considerably larger than DB req.
time, you should investigate the ABAP code.
Proceed with an analysis of the ABAP program
code using the ABAP Runtime Analysis tool.
• If DB req. time and CPU time are almost equal,
you must analyze both.
ü Exercise Common Sense!
• Always remember that statistical or derived
data can be unreliable. For example, with
long-running dialog programs, a value
overflow of variables can occur, making the
derived time meaningless.
• Rely on the data only if it appears plausible
(e.g., if the sum of CPU time and DB req.
time is not considerably larger than the
Response time).
• If you are not sure whether the data is
plausible, check to see if the data
corresponds to the results of other
monitoring tools or to any observations
you’ve made using the Process Overview
tool (transaction SM50).
45
SAP Professional Journal May/June 2003
Figure 4 Process Overview Screen (Transaction SM50)
Performance Analysis Option #2: Observe
the Program with Process Overview (SM50)
The Process Overview tool (transaction SM50) pro-
vides a real-time view of what’s happening with your
program. You can see which process is currently
handling your program and which database operation
is being performed on which table (if any).
With the Process Overview (see Figure 4), you
can see the current state of all work processes on the
instance. Work processes are sorted by their logical
numbers, which are shown in column No. You can
also see the work process type in column Ty. (e.g.,
dialog, batch, update, etc.), the work process identi-
fier used by the operating system in column PID, and
the work process status in column Status. The status
of most work processes is usually waiting. For a
performance analysis, we are interested in the work
process that is currently executing the program under
examination (with a status of Running). For all run-
ning work processes, you see the execution time
(which is reset by certain operations, such as
COMMIT WORK), the name of the report that is
executed, the client used, and the user who started the
program. If a statement accessing a database table is
46 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
processed, you see which action is currently being
performed on which table.
To use transaction SM50, proceed as follows:
1. Run the program that you want to analyze.
2. Start a second session and open transaction SM50
to observe the execution of the program while
refreshing the display constantly.
You can identify the work process handling the
test program with the help of the User and Report
columns. As you observe the test run, focus your
attention on the Report, Action, and Table columns.
If you see that most of the processing time is
consumed by database operations (e.g., only one or a
few long-running operations), then the long runtime
your program is exhibiting is likely caused by data-
base accesses. Alternatively, if the program is not
executing database operations for long periods of
time (e.g., it remains in the same report without any
database operations), the long runtime is likely
caused by sub-optimal ABAP coding. Either way,
your path is clear — you need to perform an analysis
 Performance Problems in ABAP Programs: How to Find Them

Figure 5 Performance Trace Process Overview

Session 1 Session 2 Session 1 Session 1

Start Run Stop List

Trace Program Trace Trace

1 2 3 4

of the database access activities, which I’ll review
next, or you must perform an analysis of your
program’s ABAP routines, which I will cover after
the database access discussion.
• Performance Trace records only the information
coming from the work processes on the same
instance. Consequently, if you are using Remote
Function Calls (RFCs) or asynchronous updates
in your program, the database accesses from these
modules will not be recorded if they are executed
on other instances.

Analyzing Database Access • Performance Trace can be used by only one

Activities with Performance Trace user at a time on each instance. Before using
the trace, please make sure that it is currently
If you found (or have assumed) that the long runtime switched off and not already in use (see the State
is caused by database accesses, use the Performance of trace section at the bottom of Figure 6).
Trace tool (transaction ST052) for further analysis.
With Performance Trace you can record all accesses
to the database coming from the instance. Figure 6 Performance Trace Start Screen
(Transaction ST05)
As you can see in Figure 5, you typically start
the trace in one session (1), start the program you
want to test in another session (2), switch off the trace
after the end of the program (3), and then analyze the
recorded data (4). Note that you can start the trace for
a program that is already running and switch it off
before the program’s end.

Figure 6 shows the start screen of the Perfor-

mance Trace tool. Before we examine the details of
using this tool, it is important to note the following
considerations:

2
The ST05 screenshots that appear in this article are based on Release
4.6C running on an Oracle database. If you are using a different
release or database, the screens you see may be different.

For site licenses and volume subscriptions, call 1-781-751-8699. 47

SAP Professional Journal May/June 2003
Figure 7 Narrow the Data to Be Traced
• The trace information is written to a file of a
fixed size. If the size limit of the file is reached,
the oldest data is overwritten. Consequently, it
is possible that the trace information of a long-
running program will be incomplete and you will
only see the most recent data. If this happens, a
dialog box will inform you that parts of the trace
file were overwritten. Data from older traces
remain in the trace file only until the space is
required for new trace information.
As you can see in Figure 6, there are four differ-
ent trace modes for the performance trace:
• SQL Trace covers all database accesses.
• Enqueue trace covers all enqueue operations.
• RFC Trace covers all RFC communications from
and to the instance.
48 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
• Buffer trace covers all accesses to the table
buffers on the instance.
For the analysis of database accesses, it is suffi-
cient to activate just the SQL trace. The enqueue,
RFC, and buffer traces are useful for a performance
analysis if you know (or suspect) that enqueue
requests, RFCs, or accesses to the table buffers are
taking more time than they should.
When you start the trace, you can select whether
or not you want to record data from all programs
running under your user name on the instance (the
Trace on button) or if you want to define some filters
(the Trace on with filter button).
Figure 7 shows your options for narrowing the
data to be traced. You can select data from programs
running under another user’s name, select or exclude

Figure 8 Filter the Data to Be Displayed
certain tables, restrict the data to a specific work
process (e.g., if you start the trace when the program
is already running), and so on.
By pressing the Trace off button in the start
screen of ST05 (Figure 6) the trace is stopped. With
Trace list, the recorded data is displayed for analysis.
Figure 8 shows your options for filtering the data
to be displayed. You can select the type of informa-
tion to be displayed (SQL, enqueue, RFC, buffer);
you can specify that you want to see only the basic
list or extended information; you can select the time
period in which the data was recorded (by default it is
the period of the last recorded trace); you can select
the name of the user whose data should be displayed;
and you can select the tables you want to see (or
not see). If a lot of data was recorded, a dialog box
might appear telling you that 5,000 trace records, for
example, have been evaluated and asking if you want
to evaluate more records. Generally, you do want to
evaluate all the data, but be aware that the analysis of
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
a very large trace file can be quite slow for certain
functions, like determining identical selections, which
might be a consideration for you.
Now let’s take a look at how to interpret all of
this performance data.
Interpreting the Results
of Your Performance Trace
Please be aware that the interpretation of the trace
information will be more effective if you are at least
somewhat familiar with the application and the busi-
ness context, so that you can judge the usefulness of
database accesses. The SQL trace can even help
you discover superfluous functionality that you might
not be aware of. Eliminating such unnecessary func-
tions is always the best way to improve a program’s
performance.
49
SAP Professional Journal May/June 2003
Figure 9 Extended List Display of an SQL Trace
Take a look at Figure 9, which shows the
extended result of an SQL performance trace.
The columns shown in Figure 9 (from left to
right) have the following meanings:
• HH:MM:SS.MS — The time at which the
operation was executed
• Duration — The duration of the operation (in µs)
• Program — The name of the ABAP program
• ObjectName — The name of the affected table
• Op. — The database operation
• Curs — The used cursor
• Array — The number of records that can be
transferred in one step from the database
• Rec — The number of records that were read or
sent to the database (e.g., when inserting data)
50 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
• RC — The return code from the database
• Conn — The name of the database connection
• Statement — The statement as it arrives at the
database
The shaded items are the ones that are important
for our performance discussion, and are the ones I
would like to offer you a bit more detail on.
Sometimes the line that indicates the duration of
the operation is shaded in red, which means that the
duration time exceeds 100 ms. Note that this does
not necessarily mean there is a performance problem
with this access, as you always have to take the num-
ber of processed records into consideration. For
example, reading 1,000 records in 200 ms is a very
good result, while reading only 5 records in 80 ms is
quite bad (as a rule of thumb, a processing time of
up to 2-5 ms per record is okay, and thus need not
be a major concern to you at this time, even if it can

Figure 10 Details on the Number of Operations Performed in Each Step
potentially be faster). In the former case, where the
duration time is high although the response time per
record is not, you should still check whether this high
number of records is really required — perhaps you
do not really need them all.
In the column Program, you see the name of the
ABAP program where the access was coming from.
In order to navigate to the code sequence belonging to
it, place the cursor on the line with the statement in
question and select the ABAP display button ( ),
Goto → ABAP display, or F5. Please make sure that
the cursor is not located on a FETCH operation, as
navigation to the source code — like some other
functions — is not possible for this operation.
The column ObjectName contains the name of
the database table affected. If you want to see some
information from the DDIC (the data dictionary) for a
particular table, place the cursor on a line containing
that table and select the DDIC info button, Goto →
DDIC info, or F6.
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
Each database access from the program can
be split up into several database operations (e.g.,
PREPARE, OPEN, FETCH, etc.). For each of these
operations there is a separate line, which is identified
by the Op. column. With the SQL performance trace,
operations look different for different databases. For
our purposes, it is not necessary to consider these
operations in detail; you can simply sum up the times
for the single operations concerning an access or
consider only the largest value.
The column Rec tells you how many database
records were read and transferred to the application
server in one step (operation FETCH). Sometimes
the result of the query consists of more records than
can be transferred in one step. In this case, you
would see several lines with repeated FETCH opera-
tions, as you can see in the example shown in
Figure 10.
In this example, each FETCH transferred 1,625
51
SAP Professional Journal May/June 2003
Figure 11 Summary of the Trace
records in one step, but this had to be repeated until
all records (50,000 in this case) were transferred. For
INSERT, UPDATE, or DELETE operations, this
column tells you how many records were inserted,
updated, or deleted.
In the final column (Statement) you see the
statement as it was handed over to the database.
This usually looks a little different from the original
ABAP statement because it was transformed by
the Open SQL layer on the instance. The complete
statement is displayed when you place the cursor
on the line with the statement in question and select
the details button ( ), Edit → Details, or F2.
Ascertaining Which Database Accesses
Cause the Highest Load
Central to any database access performance analysis
52 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
is an understanding of which accesses cause the high-
est load. It’s only logical that this is where you con-
centrate your efforts.
In order to identify which tables are excessively
accessed, Performance Trace enables you to aggregate
all accesses by the names of the tables. By summing
up all the request times, you can see which accesses
to which database tables are causing the highest
database loads.
The menu item Goto → Summary provides
you with a shortened version of the SQL perfor-
mance trace. After activating the Summarize
button, you will see a list with the information
aggregated for each table (after confirming the
checks in the resulting dialog box). Figure 11
displays a list that is already sorted by time to
identify the database tables with the highest loads.
These loads might be caused by the number of
accesses, the amount of read data, or by expensive
 Performance Problems in ABAP Programs: How to Find Them

Indexes — A Quick Overview

A good way to think of an index is to envision a phone book. If you are looking for a specific phone
number, you need not check the complete phone book from end-to-end because entries are sorted by
city, last name, first name, and street. You can find a phone number (i.e., a searched record) very
quickly if you know the address and the name of the person you want to call. Even if you don’t know
the street address, there remain only a few entries. The time you need to find the number is only
marginally dependent on the total number of entries (i.e., the size of the database table).

However, if you want to use the index, you must know the values of the index fields of the searched
record, or at least the values of the first few fields. If you don’t know the location, and only know the
last name, first name, and birthday of the person you want to call, then a standard phone book won’t
help. You would need an additional phone book (i.e., another index) where the entries are sorted by
last name, first name, and birthday. Thus it is useful for large tables to have indexes for all types of
frequently used accesses. Keep in mind that while additional indexes will accelerate accesses, actions
that modify the database table (e.g., INSERT, DELETE, UPDATE) will suffer performance degradation,
since these actions require an update of all indexes.

statements. You should first focus your analysis on WHERE clause. Obviously, the higher the num-
the accesses to these tables. ber of entries in the table, the longer this proce-
dure takes.3

• Use an index that points directly to those records

ü Tip
You can also use the “Statement summary”
function (menu item Goto → Statement summary)
to get an indication of which database accesses
should be analyzed in detail.
Examine the “Execution Plan”
Used by the Database
For each access, the database determines the best way
to handle the request. There are basically two options
for this database “execution plan”:
• Perform a full table scan where the database
simply reads all records from the table and then
picks the ones that meet the conditions from the
with specific value combinations for the index
fields. This can substantially reduce the number
of records to be read. (See also the above sidebar
“Indexes — A Quick Overview.”)
For each selection in the SQL trace, you can
check the execution plan that is being used by the
database. Simply place the cursor on the line
containing the statement in question4 and then select
the button, Trace → Explain SQL, or F9.
The look of the next screen is heavily dependent on
the specific database you use, so there are several
different possibilities for the display you might see.
In general, you will see the statement as it was
3
Due to a block-wise reading, several records can be fetched in one
step, so this execution plan is ideal for smaller tables or if the result set
consists of a large part of all records in the table (about 10% or more).
4
This must not be a FETCH operation!

For site licenses and volume subscriptions, call 1-781-751-8699. 53

SAP Professional Journal May/June 2003

handed over to the database and the execution plan Figure 12 Example Execution Plans
(note that for some databases, you might have to
activate another button to see the execution plan).
Then you can decide whether or not the selected
execution plan is acceptable.

Figure 12 shows a few example execution plans

as they are displayed for an Oracle database. In the
first of these execution plans, you see a Full Table
Scan. In the second, you see an Index Unique Scan, Full Table Scan
which means that all index fields were specified with
“=” in the WHERE clause. The third execution plan
is an Index Range Scan, which tells you that not all
index fields were specified with “=” in the WHERE
clause, requiring the database to read several index
entries to determine the result set.

The execution plan also tells you how the data-

base handles a selection using a JOIN command. A
JOIN is used to access combined information from
multiple tables. When using a JOIN, you must con-
sider the way the database reads and uses the infor-
mation from these tables. Usually you expect the
database to perform a “nested” JOIN, which means Index Unique Scan
that the database first reads the information from
one table according to the restrictions in the WHERE
clause, starting with the table with the “best” restric-
tion. Using the result set, and considering the JOIN
condition, the next table is accessed to read further
data, and so on. In this way, the number of records
to be read from the different tables should progres-
sively decrease.

But the database might decide to use a “merge”

JOIN, where the records from the affected tables
are read independently and only restrictions in the
WHERE clause are considered. In a second step, the
result sets are merged according to the JOIN condi-
tion. Obviously, this can cause very long runtimes,
especially if large tables are affected that have no Index Range Scan
suitable index available. In such a case, it may be
beneficial to replace the JOIN statement by two or
more selections on each table, using the FOR ALL
ENTRIES clause to emulate the nested JOIN. You
can also use this trick if the database uses a nested
JOIN but starts with the wrong table.

54 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.

Figure 13 Example Identical Selects
Finding Identical Selects
When analyzing an SQL performance trace, you will
quite often find the same database accesses being
performed repeatedly within a program or transaction.
There are only very rare cases where this is really
necessary. Usually it is sufficient to perform a data-
base query once and keep the results in the program
context for future use.
With the Performance Trace tool, it is easy to find
these identical selections (i.e., “Identical Selects”),
which are superfluous in most cases. Activating the
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
menu item Goto → Identical Selects gives you a
list of all identical selections in the trace. Selections
are considered identical if they perform the same
query on the same table(s) with the same values
for the fields in the WHERE clause. Figure 13
shows an example.
Be aware that two statements are considered iden-
tical selections only if both the database statements —
compared as strings — and all the values for the fields
in the WHERE clause are the same. There might be
several other statements that read the same record and
55
SAP Professional Journal May/June 2003

Listing 1: Example Selections on Table MARC

1 SELECT * FROM MARC WHERE "MANDT" = '800' AND "MATNR" = 'ABCD'

AND "WERKS" = '3000'
2 SELECT * FROM MARC WHERE "MANDT" = '800' AND "MATNR" = 'ABCD'
AND "WERKS" = '3001'
3 SELECT * FROM MARC WHERE "MANDT" = '800' AND "WERKS" = '3000'
AND "MATNR" = 'ABCD'
4 SELECT * FROM MARC WHERE "MANDT" = '800' AND "MATNR" = 'ABCD'

are not considered identical. For example, take a look
at the selections shown in Listing 1.
If these statements were in the trace, they would
not be rated as identical for the following reasons:
• Statement 2 is nearly the same as statement 1, but
the value of the searched record’s WERKS field is
3001 (rather than 3000).
• Statement 3 reads exactly the same data as
statement 1, but the sequence of the fields in
the WHERE clause is different, so the string
comparison considers these statements different.
Analysis of ABAP Routines
Now that you are aware of the problems that can be
caused by the database, it’s time to turn our attention
to the ABAP program runtime. As indicated back in
Figure 2, you should use the ABAP Runtime Analy-
sis tool for further investigation if the major part of
the runtime is spent within the ABAP program itself.
Although this is the preferred method, as it provides
you with the most accurate results, you can also try a
more heuristic approach (the “Monte Carlo” method
described in the sidebar on the next page) to identify
the critical code sequences.

• The result set of statement 4 already contains the
data that is read in statements 1-3, as there is no
additional restriction with respect to the WERKS
field. So, it would be sufficient to retrieve the
records from statement 4’s result set and omit
statements 1-3. Of course, this cannot be
detected by the search for identical selections
in the performance trace.
The identical selection results provide you with a
list of statements that you should check during your
analysis. However, as you have just seen, there
might be more superfluous selections that are not
detected automatically by Performance Trace. In the
second, and concluding, article of this series, I will
show you how to deal with identical selections and
how to avoid the associated performance penalties.
Using the ABAP Runtime Analysis Tool
(Transaction SE30)
The ABAP Runtime Analysis tool was considerably
improved with Release 4.6, at which time it became a
far more usable tool than it had been previously. The
most striking improvement is in the way the tool can
be used to configure the traced information, espe-
cially with regard to aggregating the data. This sig-
nificantly reduces the size of the trace information,
which in turn avoids the occurrence of short dumps
due to trace file overflow and reduces the time needed
to evaluate the trace. There are still some restrictions
— no tracing of update processes, RFCs, or batch
jobs, except in a parallel session, sporadic problems
on certain operating systems — but they will be
mostly eliminated with the R/3 Enterprise release.

56 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
 Performance Problems in ABAP Programs: How to Find Them

The “Monte Carlo” Method

With this heuristic approach, you do not perform a detailed trace for the whole program. Instead, you
monitor the program with the Process Overview tool (transaction SM50), and when you find the process
remaining in the same program for a long time, you simply stop the program with the debugger (menu
item Program/mode → Program → Debugging). Analyze the current call stack, and in particular search
for a loop over large internal tables. If you do this repeatedly, and you see that the process frequently
stops in the same loop on the same internal table, it is very likely that the reason for the extended
runtime lies in the processing of this loop.

You may uncover the reason for the problem just by investigating the code in this area (the description in
the second installment of this series will help you a lot with this) or by using the ABAP Runtime Analysis
(transaction SE30) for a detailed analysis of this code area.

Figure 14 ABAP Runtime Analysis Initial Screen

Although I assume that you are familiar with this After starting the ABAP Runtime Analysis (see
tool, allow me to offer a short description of how to Figure 14) via transaction SE30, you should first
use it for our purposes here (on a 4.6 system). configure the restriction variant you want to use.

For site licenses and volume subscriptions, call 1-781-751-8699. 57

SAP Professional Journal May/June 2003

Figure 15 The “Program (parts)” Tab Figure 16 The “Statements” Tab

For the first analysis, it is usually sufficient to

use the DEFAULT variant. The DEFAULT variant
traces the complete transaction, considers almost all
statements and modularization units,5 and aggregates
the data. Aggregation means that the times for local
module calls are summed up and you will get one
entry for each module showing the total time and
• Handling of internal tables is the key to the prob-
number of calls.
lem in many cases. So on the Statements tab,
activate the checkboxes Read operations and
For a more detailed analysis of a single module or
Change operations for internal tables, as shown
a certain code sequence — which is usually the sec-
in Figure 16.
ond step of a performance analysis — you should
define a new variant:
• Usually, aggregated data gives you sufficient
information for your analysis. If, however, you
• To trace only a specific function module/form
still need more detailed information, switch off
routine/method, enter its name on the Program
the aggregation by using the appropriate radio
(parts) tab — in Figure 15, form PARALLEL
button on the Duratn/type tab (see Figure 17).
in program ZDS400_APDX_LZA. To trace
only a certain code sequence (e.g., only
After configuring and then selecting the new
some statements inside of a module), activate
variant, start the test run. You can add a short
the checkbox Particular units and mark the
description of your test case in the Comment field on
start and the end of this sequence with
the main screen to distinguish between the trace files
breakpoints. Later, when hitting the break-
from different test runs. Depending on whether you
points at execution, switch the tracing on and
want to trace a program or a transaction, select the
off accordingly using the menu item System →
appropriate radio button in the In current session
Utilities → Runtime Analysis → Switch on/off
area. Enter the name of the transaction or program to
inside of the debugger.
be tested in the corresponding input field and click
the Execute button. The program/transaction starts
5
Except accesses to internal tables, which would be too detailed for the and the data records are collected according to your
first analysis. selected variant. When the program/transaction is

58 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.

Figure 17 The “Duratn/type” Tab
complete, return to the ABAP Runtime Analysis by
pressing F3 or using the back icon ( ).
The ABAP Runtime Analysis display will show
you information about the recorded trace file in the
area Performance file (see Figure 18).
Figure 18 The ABAP Runtime Analysis
Display After the Program Executes
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
Now that the information records are collected,
click the Analyze button to start the analysis.
ü Tip
Sometimes you will see an error message in the
status line saying that there is no data displayed
in the “Performance file” area or that the file
size is zero. Nevertheless, you should check if
there is a trace file (using the button “Other
file…”) that can be used. Look at the trace
information and assess whether the information
is plausible. If it is, use it for your analysis.
Interpreting the Trace Information
The first screen of the analysis — which you can see
in Figure 19 — shows how the elapsed time is dis-
tributed among three categories:
• ABAP — The time spent in the ABAP program
• Database — The time spent in the database
• R/3 System — The time spent solely on system
issues
Figure 19 Overview of the Runtime
Analysis Results
59
SAP Professional Journal May/June 2003

Figure 20 The Hitlist Sorted by Net Time

The time spent in ABAP should have the highest
percentage. If the highest percentage is spent on
database accesses, it may be more useful to use the
SQL performance trace for analysis (see the earlier
discussion in the section “Analyzing Database Access
Activities with Performance Trace”). If you find a
major part of the runtime was spent in the R/3 sys-
tem, this may indicate problems when recording the
trace information, and often the data cannot be used
for a helpful analysis.
will find one or more icons for displaying further
information on the call hierarchy, accessed database
tables, and internal tables, for example. In the
discussion here, I will focus on the hitlist button
( ),6 which is always available, regardless of the
variant’s settings.
In the hitlist (Figure 20) you will find informa-
tion on each function module, form routine, and

Depending on your variant’s settings (i.e., 6

Instead of this button you can also press F5 or use the menu item
whether the information is aggregated or not), you Goto → Hitlist → Standard.

60 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.

method that was called during the run. As you can
see, the following information is displayed:
• No. — The number of times the module was
called
• Gross — The gross time spent in this module,
including the time spent in modules called from
within this module
• Net — The net time spent solely in this module,
not including the time spent in modules called
from within this module7
In order to find the most critical modules, you
should sort the list by net time. If you find some at
the top of the list that are consuming a high percent-
age of the total net time (as is the case with the first
module listed in Figure 20), these are good candidates
for optimization.
If one module consumes a large percentage of the
runtime, focus on this module in the next step of your
investigation. I recommend defining a new restric-
tion variant for a thorough analysis of this module,
including the use of internal tables. Then repeat the
analysis using this new variant. In many cases the
hitlist (sorted by net time) shows operations on inter-
nal tables at the top of the list.
ü Note!
If no such modules exist, tuning the transaction is
not that easy and likely cannot be achieved by
local technical optimizations. Instead, check
the complete order of events in the program —
analyzing the hitlist sorted by gross time can give
you a clue as to which modules/functions require
the most time and where an optimization can pay
off. But this is heavily dependent on the specific
program or transaction, so unfortunately in this
case I cannot give you “one-size-fits-all” advice
on how to proceed.
7
If the module does not call any other modules, the net time is equal to
the gross time.
For site licenses and volume subscriptions, call 1-781-751-8699.
Performance Problems in ABAP Programs: How to Find Them
In the second installment of this two-part article
series, I will discuss in detail performance problems
that are caused by the sub-optimal use of internal
tables and outline possible solutions.
Conclusion
In our work with SAP R/3 installations, my col-
leagues and I have found a number of common
performance pitfalls. Sometimes there is a weak
design, which makes a correction quite expensive —
a widespread modification of the program would be
necessary instead of only a local optimization. But
sometimes the extended runtime is simply caused by
the way functionality was implemented — i.e., not
all relevant performance aspects were considered.
Whatever the cause of your program’s perfor-
mance troubles, optimizing the runtime of the appli-
cation requires that you first find out where the major
part of the runtime is spent. It just doesn’t make
sense to focus your tuning efforts on the parts of the
program that require relatively little runtime. There
is probably one exception to this: to achieve a satisfy-
ing result if no single hotspot is found, you may be
forced to optimize the program by tuning several
parts, even if separately they are responsible for only
small fractions of the runtime.
With the help of SAP’s performance tools,
you can easily identify the critical actions or code
sequences. As a first step, you have to decide where
to optimize: the database accesses or the ABAP cod-
ing of the program. Your decision will be driven by
examining the statistical data of the program (using
transactions STAT/STAD) or by observing the pro-
gram in the Process Overview (transaction SM50).
To analyze database accesses, use Performance
Trace (transaction ST05), and for the analysis of
an ABAP program, use ABAP Runtime Analysis
(transaction SE30).
Depending on the results of your analysis, you
can then implement the necessary corrections. In the
61
SAP Professional Journal May/June 2003
next installment of this two-part series — “Perfor-
mance Problems in ABAP Programs: How to Fix
Them” — I present common performance bugs and
recommended solutions. After applying a correction,
you should run and analyze the program again in
order to verify that the revision produces the desired
result. You may also observe newly visible runtime
effects that you could not see before — if you are not
satisfied with your program speed, continue tuning it
by focusing on these new effects.
62 www.SAPpro.com ©2003 SAP Professional Journal. Reproduction prohibited. All rights reserved.
Werner Schwarz joined SAP Retail Solutions
in October 1998 after working as a developer
at two other IT companies. Today, he is the
development team contact for all performance-
related issues concerning IBU Retail (Industry
Business Unit Retail). Werner’s major tasks
include information rollout and support of his
colleagues regarding performance during both
development and maintenance. He can be reached
at werner.schwarz@sap.com.