ABAP SQL Trace PDF

HOW TO VERIFY
PERFORMANCE
REQUIREMENTS FOR
YOUR DEVELOPMENT
PROJECTS MANUALLY
IN NETWEAVER ABAP
Document Version 1.1

March 2013
2013 SAP AG. All rights reserved
Typographic Conventions
Type Style
Description
Example Text
Words or characters quoted

from the screen. These
include field names, screen
titles, pushbuttons labels,
menu names, menu paths,
and menu options.
Icon
Description
Caution
Note or Important
Example
Recommendation or Tip
Cross-references to other
documentation
Example text
Emphasized words or
phrases in body text, graphic
titles, and table titles
Example text
File and directory names and

their paths, messages,
names of variables and
parameters, source text, and
names of installation,
upgrade and database tools.
Example text
User entry texts. These are

words or characters that you
enter in the system exactly as
they appear in the
documentation.
<Example text>
Variable user entry. Angle

brackets indicate that you
replace these words and
characters with appropriate
entries to make entries in the
system.
EXAMPLE TEXT
Keys on the keyboard, for

example, F2 or ENTER.
Document History
Document Version
Description
1.00
First official release of this guide
Table of Contents
1
1.1
1.2
1.3
1.4
2
2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.5
2.5.1
2.5.2
3
3.1
3.2
3.2.1
3.3
3.3.1
3.4
3.4.1
3.5
3.5.1
3.6
3.6.1
3.6.2
3.6.3
3.7
3.7.1
4
Introduction...............................................................................................................................3
Planning tests .............................................................................................................................3
Determine the bread-and-butter processes ................................................................................3
Running Single user tests ...........................................................................................................3
KPIs and Best Practices for performance optimized programming ............................................4
Verifying recommended architecture characteristics ...........................................................5
How to check the number of unnecessary accesses to the persistence layer ............................5
How to check Indexes...............................................................................................................10
How to check parallel processing .............................................................................................12
How to check programs for nonlinear scaling behavior ............................................................14
Processing time / CPU ..........................................................................................................14
Memory.................................................................................................................................15
Server-to-server roundtrips .......................................................................................................16
JCO and RFC specific information........................................................................................16
HTTP specific information .....................................................................................................17
Measuring recommended Performance KPIs ......................................................................18
Number of accesses to the persistence layer ...........................................................................18
Measurement with the Statistical Records Monitor ...................................................................19
Mobile application .................................................................................................................21
Data volume (net value in KB) transferred to and from persistence layer .................................23
Example: Mobile Application NW Gateway........................................................................23
Peak memory consumption (MB) .............................................................................................24
CPU consumption (msec) .........................................................................................................25
SAP GUI-based front ends: End-to-end Response time, Roundtrips, front end network traffic 26
End-to-end response time ....................................................................................................26
Number of round trips between frontend and application layer .............................................27
Data volume transferred between frontend and application layer .........................................28
Browser front ends: Response time, roundtrips, network load ..................................................28
Further Information ................................................................................................................32
1 INTRODUCTION
This document describes how you can manually check performance KPIs in NetWeaver ABAP of your
development. The document focuses on obtaining the proper values only, not on performance analysis or
optimization. The document is targeted at people with little experience in using SAP performance tools.
1.1 Planning tests

The pure planning phase probably is also the most time-consuming one. The more experience the project
teams have in setting up and running tests, the less time they need, obviously.
1.2 Determine the bread-and-butter processes

There are basically two sets of performance requirements: user-driven and throughput-driven. In the first
example you analyze the system from an end user perspective, considering perceived performance
requirements as well as system performance requirements. In the second case response time is negligible.
Here, you test the nightly background jobs where hundreds of thousands of data items need to be
processed in a few hours, or where several processes are interdependent on each other.
Tip: Try to reduce the number of processes as much as you can. Five to ten should be sufficient as it is
better to define a few scenarios well than have many ill-defined scenarios. There are mainly two reasons for
this: keep the complexity at a minimum. Also, the test cases need to be scripted and analyzed from different
perspectives.
Examples for bread-and-butter processes:
Client A planned to include a single-sign on authorization check in their corporate portal. For them
the end user response time for this process was very important.
Client B ran several different systems and applications within one process chain. Their critical path
analysis determined that the full order processing had to be completed within 15 minutes or else
they would run into severe business problems.
Determining the bread-and-butter processes sometimes is a trade-off as well. In addition to asking the
application owners, you can also make use of the legacy system to understand the core business processes
and critical applications.
1.3 Running Single user tests

One basic principle for achieving meaningful performance results is to let the system warm up with pre-runs.
This fills buffers and caches and in general minimizes the influence of artifacts. The rule applies to singleuser tests and load tests alike. The advantage is that the results will be reproducible, a very important factor
for performance analysis and regression testing.
Pre-runs also bear the advantage that you can still check if there are any functional issues with the test
cases. However, you could also decide to measure the performance of a cold system, because a cold start
shows non-optimal programming on first access of the applications (optimization potential). This could
become critical in situations where you cannot increase buffers and caches due to hardware limitations and
eviction of cached data is necessary or cached content simply expires. By having the system restarted
automatically by the load testing environment just before the load generation is triggered, you can get a
reproducible initial state of all buffers and caches. On the other hand, these results are not reproducible and
should not be used as a basis for regression testing. It is important that you understand the implication of
each method for your test results.
3
2013 SAP AG. All rights reserved.
A single user test refers to one user clicking through a series of screens entering data as required while
these activities are being performance-monitored. Of course the test can also be automated. However, the
important aspect here is a manageable well-defined test scenario. A unit test describes roughly the same,
where a huge background application is split into smaller jobs for an initial analysis.
These tests can also run in a smaller test system, you do not necessarily need the complete load test
infrastructure for these kinds of tests. Whichever system you will use, for optimal results make sure you
have the system all to yourself so only your activities are captured.
If you really cannot be alone, then at least make sure there are no background processes, and that the
CPU utilization is below 10%.
If there are serious time restraints, you can capture only the performance KPIs (such as the number of
database accesses, amount of data retrieved, CPU time per step, peak memory consumption, number
of roundtrips to front end and between two servers and transferred kilo bytes to front end).
In a second step you can analyze the quality of the database accesses (index design, identical selects,
memory allocation, quality and quantity of cached data, and so on) and remove bugs. These findings can
then be returned to the application team which is responsible to modify the application software, as
appropriate.
1.4 KPIs and Best Practices for performance optimized programming

Derived from the performance design patterns you could for example use the following KPIs in performance
tests carried out by developers themselves, and for quality check points and regression tests run by quality
teams.
Check the number of unnecessary accesses to the persistence layer

Check Indexes
Check parallel processing
Check programs for nonlinear scaling behavior
o Memory
o CPU
Minimize Front end to server or Server-to-server roundtrips
Many performance issues cannot be solved by fixing a simple bug in the software code alone. They are
caused by inappropriate design decisions made in the software architecture. Performance design patterns
specify target behaviors and design rules for software components and interfaces while at the same time
allowing a high degree of freedom for the implementation. A SAP business application generally consists of
3 layers: the persistence layer, the application layer, and the front end layer. Relational database systems
are typically used in the persistence layer, and the data accesses are executed by so-called SQL
statements. While the persistence layer has to ensure the data consistency under highly concurrent data
accesses, the application layer carries out CPU intensive processing of business logic. The application layer
of a large software system is typically built up by a load-balanced cluster of application servers, which scale
in CPU and memory and provide high availability at the same time. The front end layer represents the user
interface (UI), typically running on PCs, connected by a LAN or WAN to the application servers, providing
high usability and productivity to the end users.
2013 SAP AG. All rights reserved 2013 SAP AG. All rights reserved
2 VERIFYING RECOMMENDED ARCHITECTURE

CHARACTERISTICS
2.1 How to check the number of unnecessary accesses to the
persistence layer
There are basically four different types of statements that unnecessarily access the persistence layer, tables
that are not needed at all for the business process at hand, statements that bypass the different types of
buffers on the application server (mainly the table buffer and nametab buffers), incomplete where clauses
and identical accesses within the same business transaction retrieving the same information multiple times.
There is an additional type of error when it was forgotten to set the right buffering flag for tables or views
which contain rarely changed data such as meta data or customizing data. This fifth type of error cannot be
detected by looking at the SQL statement, but by looking at the technical setting of the table or view.
Because accessing the database is always very closely linked to the business process, fully automated
verification will never be possible and is also not intended. However, you can make use of some tools that
help you to cast light on possible areas for improvement. These tools can help you in the decision making
process, they cannot make the decision for you.
To check you would look for two separate indicators:
the number of executions and
the runtime of the accesses.
Procedure:
1. For an overview of the SQL statements use the Performance Analysis (SQL Trace, transaction ST05).
For further information please check:
The SQL Trace (ST05) Quick and Easy
Help Portal: Global Performance Analysis
2. Summarize the trace according to SQL statements (as of NetWeaver 7.02/7.20 in the menu Trace List
Summarize Trace by SQL Statement).
For the purpose of this documentation we use a somewhat artificial example, please do not over
interpret the figures and thus the findings. In this exercise, the total number of executions is
assumed at 106 and the total runtime at 59,008 micro seconds:
Figure 1: Summarized SQL Statements in ST05

3. Check the 5 different types of performance bugs/improvements for in the category unnecessary DB
accesses and determine the fraction of the DB request time which can be saved by optimizing your
code.
For the purpose of this documentation we use a somewhat artificial example, please do not over
interpret the figures and thus the findings. In this exercise, 32% of the total DB request time or 19,021
mircosec can be saved.
a. Check that no buffered or customizing data is read from persistency. Filter column Buffer type
(BfTp) according to filter criterion non-initial to see which statements access buffered data or
customizing data:
Figure 2: Filter criteria, select unequal empty

The system then displays statements which retrieve data from the DB,
although it is buffered in the table buffers (BfTp=SNG, GEN, FUL)

Rewrite the statements to use table buffers
although it is buffered in the so called nametab buffer(BfTp=DDIC) and can be retrieved via the
official DDIC interfaces to buffered runtime data and
User DDIF_FIELDINFO_GET, DDIF_NAMETAG_GET, look at the documentation of the
function module used by your coding to see alternatives recommended there
although it is data which very likely should be buffered (BfTp=DESNG, DEGEN, DEFUL, CUST).
Consider changing the buffer settings in the technical settings of a table
To see how many executions are unnecessary, look at column Executions. In this example 24
unnecessary executions with a total runtime of 8,591 micro seconds are caused by non-buffered
accesses that should not go to the database layer at all.
Figure 3: Filtered SQL statements

b. Check if only those tables are read that are really needed for the business application. First change
the filter on column Buffer type (BfTp) according to filter criterion is initial to exclude those
statements that were already covered in the previous check.
In column Object name check the tables that are being read. Ensure that only those tables are
being read that are needed for the business process. Examples for tables that are unnecessary are:
The address data of a business partner when you only need the name.
Items of a document when only header information is needed
Figure 4: Checking for business relevance of access

This analysis cannot be automated and you need application knowledge to understand which tables
can be removed. Depending on the number of accesses, removing these tables can save
considerable CPU cycles. To identify the runtime of the tables, take the according runtime. In the
sample test assume that all tables have to be read because the data is needed with one exception:
The data of table FIAD_GL_ACCT is not needed. There are 2 executions with a runtime of 822
microseconds.
c.
To identify the runtime of unnecessary accesses caused by identical selects first exclude the tables
identified in the previous check by using the filter on the object name. Additionally, you should set a
filter on column Redundancy, so the system displays the lines with redundant accesses. In column
Redundancy you can see the number of unnecessary executions, 23 in total in this example.
Figure 5: Checking for identical selects

To obtain the runtime caused by these unnecessary identical executions, take the relevant
percentage of the identical accesses. Finally sum it up:
90% of 3,748 micro seconds = 3,373 micro seconds

89% of 3,318 micro seconds = 2,953 micro seconds
Do that for all statements. In sum, 9,180 micro seconds are superfluous in our example due to
identical accesses
This method delivers only a part of the identical accesses. It marks entries as identical only if the
complete WHERE clause is identical, when you look at it is as string. If the WHERE clause of one
statement looks like WHERE fieldA = valA and fieldB = valB and the WHERE clause of another
statement just turns it round WHERE fieldB = valB and fieldA = valA then these two statements are
not detected as being identical by the SQL Trace, although they are looking at the same result set.
Therefore it is a good idea to sort the unfiltered SQL trace summary by column Object name. If the
same object name appears multiple times you can manually compare the statement whether it is in
fact an identical access which is not automatically recognized by the tool. If you find such
statements they have to be counted, too, and have to be added to the sum above.
Possible actions:
In case of repeated accesses from your own coding implement a Data Provider that buffers
data internally and provides the data buffered to the consumer
Try to use standard data providers from SAP if you read standard tables (for example
function module Material_Read etc.)
d. To identify how much runtime was caused by incomplete Where-clauses, use the summarized SQL
statements. First remove again the filter on the Redundancy column set in the previous check. Then
sort the list descending according to the number of records read. Try to find those tables where the
number of records does not fit to the expected number, when looking at the test case from the
business point of view (e.g. how many different products are used for the creation of a sales order
and how many records should therefore be read from the corresponding database table(s).
Figure 6: Checking for incomplete Where-clauses

In our example assume that in only one statement the where-clause could be improved.
If only 12 of the actual 23 records of table FDT_DEPL_0000 make sense for this application, you
determine the unnecessary access runtime by subtracting the percentage from the total runtime to
get the run time for the unnecessary accesses: 894 (12/23)*894 = 428 micro seconds.
You have to be careful if you identify a non complete Where-clause for a statement that has also
identical selects. In that case avoid double counting.
Finally, build the sum of all individual findings of 3a to 3d: (8,591 + 822 + 9,180 + 428 = 19,021
micro seconds) and compare the figure to total runtime 19,021/59,008 = 32%
By code optimization 32% of the total DB request time or 19,021 mircosec can be saved. If you want
to optimize your coding, you can either start with those performance issues which contribute most or
you take the easy wins first, i.e. usually correct the buffer related statements first.
2.2 How to check Indexes

There are several ways of checking indexes:
Use the Code Inspector (transaction SCI) to check whether there is a WHERE clause at all, and to
check for WHERE clauses that contain no index field and no first index field of a database table index.
Choose the following single checks within the Code Inspector: Analysis of WHERE clauses for SELECT
and Analysis of WHERE clause in UPDATE and DELETE (activate all attributes, if required).
Run the Performance Analysis (transaction ST05) and view Trace List -> Summarize Trace by SQL
Statements (_before SAP Web AS 6.20: _Go To -> Statement Summary). Sort column Min.time/r. A
10
high value is an indication for a database access which is highly probably not supported by a proper
index. Use Explain on this statement to check the access path. Try to find a solution by rewriting the
select statement, changing an existing index, or defining a new index.
When testing with small amounts of data in the corresponding database tables, the above procedure
may not be completely reliable, because accesses times even without an appropriate index may be fast,
or the explain function may not use an existing (appropriate) index.
Alternatively you can check the selects in the SQL trace with code inspector: From the trace list, choose
Goto -> Trace Analysis Using Code Inspector (Ctrl F3). If the code inspector results show errors for
SQL Trace Check: Analysis of WHERE Condition for SELECT or SQL Trace Check: Analysis of
WHERE Condition for UPDATE and DELETE, then the check is not ok.
Figure 7: SQL Trace Check in the Code Inspector
If your test cases can be automated, we recommend that you use the Global Performance Analysis
(transaction ST30). The Global Performance Analysis enables you to automate the required checks to a
high degree and delivers most of the required results for a test case in one go.
If the checks identify problems, correct them and repeat the checks.
11
2.3 How to check parallel processing

To check for parallel processing, proceed as follows:
1. Check the program for exclusive SAP locks.
To check for exclusive locks, use the Performance Trace (ST05) and here at least SQL Trace and
Enqueue Trace.
The Enqueue Trace shows the request and release of enqueues as in the example below.
Figure 8: Overview of enqueues in the Enqueue Trace

In column Operation you see the enqueues and dequeues. Dequeues may take place for a single lock
or for all locks set in a LUW (DEQ ALL).
Column Statement shows the lock argument, starting with S means a shared, E an exclusive lock.
Check for exclusive locks.
-
There must not be exclusive locks in pure retrieval functions
If there are exclusive locks on objects that were just created, you can discount them.
If there are exclusive locks on central objects, that may be accessed and locked by many LUWs in
parallel (for example master data), compute the duration between enqueue and dequeue (using the time
stamps) and the resulting maximal achievable throughput.
In our example (Change delivery (VL02N) and post goods issue), there is an exclusive lock on object
ELIKP (which locks a delivery document, see definition in the Data Dictionary using transaction SE11).
The duration of this lock is 18 msec (14:21:02.067 msec 14:21:02.085 msec). As this is a lock on a
(just created) document and not on a central object, this is ok.
For exclusive locks on central objects, e.g. master data, compute the locking time and the maximal
throughput.
In our example a material is locked for 533 msec (14:21:09.046 msec 14:21:09.579 msec).. This
means that at maximum 1,87 processing units (transactions using the same material) can be processed
per second, thus 1,87*3600 = 6732 per hour.
2. Check the database operations for updates
Display the SQL Trace List in transaction ST05
12
Figure 9: Trace List in transaction ST05.

In the trace list look for locks set implicitly by INSERT, UPDATE, DELETE statements and for the next
COMMIT WORK which releases the locks .
(This does not apply for all accesses to tables VBHDR, VBDAT, VBMOD, which are needed for
communication with asynchronous update task).
-
Determine the critical object/ table for your application
Check if the order of first INSERT, then UPDATE is kept.
If there are updates, compute the lock duration using time stamps of UPDATE and next COMMIT
WORK and calculate the maximum achievable throughput.
In the above example (showing only the last part of a SQL trace (Change delivery (VL02N) and post
goods issue), we see UPDATEs of table VBBS as last operation before COMMIT WORK, so this is
ok. The duration of the implicit lock of the VBBS is 3 msec.
This means that 333 processing units (transactions) can be processed per second. So this lock
would restrict the maximal achievable throughput for this function to 333*3600 = 1.200.000 per hour.
During load tests you have the additional possibility to use

-
SM12 to monitor the system wide enqueue situation
ST04 (Lock Waits) to monitor system wide database locking situation
SM66 to identify work processes waiting for database locks
Note that ST04 and SM66 usually are not helpful in single user tests, as there will be no wait situations
usually.
13
3. Which parallelization technique is used for batch jobs

If your program is designed for handling high volume throughput, it must make use of any of the
manifold parallelization techniques.
2.4 How to check programs for nonlinear scaling behavior

2.4.1
Processing time / CPU
There are several ways of identifying nonlinear processing times / CPU:
If you run into a performance problem due to nonlinear dependency, the problematic program code can
often be found by identifying the most time consuming parts with the help of Monte-Carlo debugging, i.e.
the process of repeatedly and randomly invoking the debugger for a program from transaction SM50,
the odds being that this will most likely get you to the most time consuming process.
However, with much smaller amounts of data the problematic program parts are easily missed using this
technique. It is possible to identify the program parts that show a nonlinear increase by making a
detailed comparison of the program parts of two test cases with different amounts of data. You can use
the following method for making such a comparison, using the results of the ABAP Runtime Analysis
(transaction SE30), which measures the runtimes for all operations in the program.
As of SAP NetWeaver AS 7.02 you can use the hit list compare implemented in the new ABAP Trace
(transaction SAT, the successor of SE30). This transaction is not available in older releases,
however, traces from SAP Web AS 6.40 systems can be sent by RFC to a SAP NetWeaver AS 7.02
system and be compared there.
Trace two test runs with SE30. These two test cases should differ in the amount of processed data by a
factor of x (if possible use x=10). For example, compare two runs, one with 10 and one with 100
business objects.
The scalability of a large application can only be achieved when the resource consumption depends
maximally linearly (to be very precise logarithmically) on the number and size of processed business
objects. Otherwise, the resource requirements will exceed any possible limits quickly, and result in
unpredictably increasing response times.
The program parts with nonlinear increases of net runtime should be re-implemented using the
recommendations from above.
14
Figure 10: Linearity
Simple performance bugs, e.g. caused by using inappropriate statements within one modularization
unit, can be found be using the Code Inspector tool. Use the Code Inspector (transaction SCI) to search
for sequential accesses to internal tables, i.e. accesses that cannot be optimized by the ABP runtime
using an index or key. This check is called Low Performance Operations in Internal Tables. On the
Information part of the check possible solutions are explained.
Use the Code Inspector (transaction SCI) to search for nested loops (if they are not hidden in different
modularization units) and for database accesses (SELECT, INSERT, UPDATE, MODIFY, DELETE)
inside of loops. Choose the following single checks within the Code Inspector: SELECTs in loops,
Changing database access in loops, and Nested loops.
2.4.2
Memory
An application is scalable only if it has no memory leaks. Performance measurements for an application that
has memory leaks show misleading results. The application will run slower over time.
Repeat the test case / function several times (for example 10 times), but stay within the same transaction. In
other words, do not clear the user context by starting the transaction with /n again. Using eCATT or the
scripting capability of the SAPGUI makes it very easy to execute such iterations automatically. Check
memory consumption for the repeated executions in the Statistical Records (transaction STAD). There must
not be any increase in memory consumption.
If you have found a memory leak in the step above, use the ABAP Memory Inspector (transaction
S_MEMORY_INSPECTOR) to compare the memory use of two memory snapshots. Take these snapshots
e.g. after the first and after the second execution of the test case. Depending on the size of the memory
leak, the differences will be better visible if you use a higher execution number (after the first and after the
11th execution, for example). The ABAP Memory Inspector creates a hit list of the memory increase and
makes it easy for you to find the responsible objects, such as internal tables, classes and instances of
ABAP objects, strings and anonymous data objects.
15
2.5 Server-to-server roundtrips

2.5.1
JCO and RFC specific information
Use the Performance Analysis (transaction ST05), and select the RFC checkbox to trace the amount of
RFCs between servers and the data volume transferred. In current releases you have to count the number
of RFCs using the search or filter functionality, e.g. by searching for unique search strings such as the
server name, and divide by the number of dialog steps to get the average number of server-to-server
roundtrips per dialog step.
For RFC trace records the column object name contains the information on the communication partner.
Only entries with a non-empty object name are relevant, empty cells are representing local calls to the
SAP automation queue (which are cached are flushed later-on).
Entries that show your frontend PC these are roundtrips to the frontend, not between servers are even
more important. This type of round trips should be counted also following the same pattern and are subject
to the same restrictions. Please see chapter 3.6.2 Number of round trips between frontend and application
layer
Figure 11: Trace List

Recommendation: 2 round trips per user interaction step"
16
2.5.2
HTTP specific information
Use the Performance Analysis (transaction ST05), and select the HTTP button to trace the amount of HTTP
connections between servers and the data volume transferred.
Figure 12: Performance Analysis - HTTP Trace.

17
3 MEASURING RECOMMENDED PERFORMANCE KPIS

3.1 Number of accesses to the persistence layer
Proceed as follows to obtain this performance figure:
1. Execute your scenario once to fill the buffers of the application server (session 1). Otherwise the
performance figures will be distorted.
2. Only if you are using asynchronous updates: If there is more than one application server, check that
update dispatching is switched off (use transaction SM14 to ensure that parameter rdisp/vb_dispatching
is set to 0). Then you need to have a local update task-WP configured. Alternative switch on SQL trace
for all remote update servers. But this makes the analysis more complex since we cannot summarize
traces
3. Start a parallel session (session 2) and invoke the SQL Trace of the Performance Analysis (transaction
ST05, menu path System Performance Trace) there.
a. Select SQL Trace on the ST05 initial screen and make sure of the following:
The trace logs all activities in all sessions performed by the user that is specified in the filter.
Therefore, do not work with a user name that can also be used by other people, for example, a
generic display or test user. If you do this, all their activities will also be traced and counted.
The trace can only be activated for one filter combination per application server. This means
that it is not possible for two users to trace at the same time. Therefore, check the Trace Status
field on this screen to ensure that the trace has not already been switched on for someone else.
b. Start the SQL trace by selecting Activate Trace.

Note: When measuring asynchronous process, e.g. workflows, these could be executed under a
different user name. If this is the case in your scenario, select Activate Trace with Filter and enter
the user name with which the asynchronous process will be started (e.g. an RFC user). This does
not apply to the SAP update task; this is executed with the user name used for dialog steps.
If you want to trace both the synchronous and the asynchronous processes, there are two options:
Execute the test case twice and run two traces with the two user names
Switch the trace on for all users. List the trace twice, each time filtering for one of the users
involved.
4. Execute your scenario in session 1. After the scenario has completed, wait about 10 seconds (or up to
30 seconds during high system load) for any remaining update tasks to finish.
5. Stop the trace in session 2 by selecting Deactivate Trace.
6. Display the trace by selecting Display Trace. Use the default filter settings proposed on the screen
displayed next, unless you have traced asynchronous processes. If this is the case, enter the name with
which the asynchronous process was started.
7. Check the trace for completeness:
8. As the trace is overwritten from time to time, the beginning of long traces might have been overwritten
and entries could be missing.
9. If you use the SAP update task, check whether it is contained within the trace. You can identify the start
of the SAP update task when table VBHDR is read. You can identify the end of the SAP update task by
a delete entry on the same table.
10. Select Trace List > Summary
18
The Executions column shows the number of accesses to the persistence layer per aggregated
SQL statement. The total number of accesses to the persistence layer is shown at the bottom of
this column.
In later SAP Web AS releases, COMMIT WORK statements are treated as database accesses. If
you are comparing the traces of two releases, make sure that you always count COMMIT WORK
statements as database accesses.
3.2 Measurement with the Statistical Records Monitor

Do the following to avoid distorted measurements:
Before starting the measurement with the Statistical Records Monitor (transaction STAD), execute your
scenario at least once to fill the buffers and to compile involved programs.
Do not execute the measurements for the abovementioned KPIs at the same time as the measurement
for KPI 1 (number of accesses to the persistence layer). The fact that the SQL trace is activated for the
measurement of KPI 1 will influence the measurements for the other KPIs, especially for the CPU
consumption.
To obtain meaningful measurement results for memory consumption:

Applications using classical dynpros stop the Easy Access menu running in the session in which you
want to perform the measurements. Enter "/n" once or several times in the relevant session. The Easy
Access menu has been stopped successfully if the screen with the Start SAP Easy Access button is
displayed.
As statistical data are always being collected you can use transaction STAD to display all transaction steps
of a user. However, you are only interested in those steps that are part of your scenario. For this reason, we
recommend that you set markers to help you identify the beginning and the end of the interaction steps
relevant for your scenario. Proceed as follows to obtain the statistical data of your scenario and mark the
relevant data:
1. Invoke any transaction (in the example below STAD, but do not perform any further steps in this
transaction. This single STAD call will mark the beginning of the relevant statistical data when you
display the results in transaction STAD later on.
2. Execute your scenario. When it has completed, wait a while until the SAP update task has finished, if
necessary.
3. To display the statistical data collected for your scenario, start transaction STAD again from the same
session. Narrow down the data to the relevant bits, as follows:
In the Filter Parameter settings, specify your user name or the user name used for asynchronous
processes, such as workflow or middleware processes.
If there are several application servers in the system, select the application server you have been
working on via Server Selection.
Specify the time interval during which you executed the scenario by providing the start time and
duration. (Note that depending on the system release, the default values for the starting point and
interval may be inappropriate.)
Select OK or press Return to list the statistical records of all transaction steps involved. The
relevant statistical data are displayed between two single calls of transaction STAD.
19
4. The default list display does not contain all fields required for our purposes. Use the Selection Output
Fields option to display the columns containing the data required. These are:
Response time (ms)

Transferred kBytes, DB requests (total),
CPU time (ms)
Max. mem. in roll (kB), Total allocated page mem (kB), Max. ext. mem. in Step (kB), and Priv.
mem. in use (kB).
In older releases you may have to use Max. ext. Mem. in TA instead of Max. ext. mem. in
Step (kB) (for details see the section on memory below)
No. of roundtrips
Terminal in-message, Teminal out-message
The display should look something like figure 12:
Figure 13: Workload Statistical Records - Start and Stop of Transaction
20
In this example, you see the first call of the transaction STAD as a marker for the start of the measurement,
followed by the traced transaction VA01 with dialog and update tasks. In this example
The end of the relevant measurement is identified by the second call of the transaction STAD.
5. Make sure that all expected user interaction steps are displayed in the list. If some are missing, you
may have specified an incorrect time interval.
Based on the data displayed you can now calculate the required performance figures as described in the
appropriate sections below.
3.2.1
Mobile application
The following architecture for mobile applications is characterized by a synchronous request and response
pattern initiated by the device. By exposing SAP Business Suite functionality as REST-based OData (Open
Data Protocol) services, SAP NetWeaver Gateway enables SAP applications to share data with a wide
range of devices, technologies, and platforms in a way that is easy to understand and consume.
Figure14: Architecture for mobile applications

As described above statistical data are always being collected and you can use transaction STAD (SAP
Netweaver Gateway and SAP backend) to display the request initiated by the device.
21
Note:
Please be aware that depending on your application an user interaction step initiated on the device can
result in several ODATA requests. This will lead to several statistical data records in STAD (Gateway).
Furthermore on Gateway one HTTP request can trigger multiple RFC calls which again will lead several
statistical data records in STAD (Backend).
To correctly interpret CPU and response times you would need to check the HTTP details and the RFC
details if you want to analyze why the difference between CPU - time and response time might be high.
For the statistical data records in STAD focus on the user(s) that are configured for your application.
Figure 15: STAD (Gateway) for request initiated by the device
Figure 16: STAD (Gateway) for request initiated by the device detailed view
As described in the previous chapter, we recommend that you set markers to help you identify the beginning
and the end of the interaction steps relevant for your scenario.
22
3.3 Data volume (net value in KB) transferred to and from persistence
layer
For the net data volume transferred to and from the persistence layer, add up the appropriate entries in the
column kBytes transferred. For the example shown in figure 2 below, the value is (2.8 + 49.4 + .. +127.9) =
1157.8 kB
Figure 17: Workload Statistical Records - kBytes transferred

3.3.1
Example: Mobile Application NW Gateway
Figure 18: Workload Statistical Records - kBytes transferred
23
3.4 Peak memory consumption (MB)

The instructions below only apply to dialog processes, or to those batch processes that can be run in dialog
mode using transaction SE38. Currently there is no simple way of measuring memory for any type of batch
process. Proceed as follows to obtain the required performance figure:
1. Complete the steps described in section on preparing the measurements.
2. To obtain the peak memory consumption per user interaction step, add the values in the columns Max.
mem. in roll (kB), New allocated page mem (kB) and Max ext. mem in step (kB) for each line. Since we
are interested in the peak memory consumption, note down the biggest value of the sum.
Figure 19: Workload Statistical Records Memory

3.4.1
Figure 20: Workload Statistical Records Memory

24
3.5 CPU consumption (msec)

For the CPU consumption per user interaction step in milliseconds, refer to the column CPU time (ms) and
add all values of your scenario. For the example shown in figure 4 below, the value is 2460 ms
(=110ms+30ms+...+250ms+50ms)
Figure 21: Workload Statistical Records - CPU Time

3.5.1
Figure 22: Workload Statistical Records - CPU Time

25
3.6
SAP GUI-based front ends: End-to-end Response time, Roundtrips, front end network traffic
Nowadays network time can be a dominating part of the end-to-end response time while using WAN (Wide
Area Networks), as network latency time and the time needed to transfer the data to the frontend adds
significantly to the end-to-end response time. For example, a synchronous round trip over a satellite could
add 0.5 seconds to the total response time easily. The round trip time is even higher for mobile devices
which are connected via any type of wireless network. The conclusion is obvious: The more round trips the
worse the applications response time.
In order to achieve good end-to-end response times, it is important to understand and optimize the
underlying network infrastructure. During development make sure that your application is optimized for low
bandwidth (small amount of data being transferred to/from the front end) and high latency (only 1-2 round
trips per user interaction step). This ensures best possible response times.
The recommendation is to have not more than 2 sequential round trips per user interaction step between
front end and application layer as well as not more than 2 sequential round trips between two
servers/instances.
3.6.1
End-to-end response time
There are several ways of checking the average end-to-end response time response time:
Display the detailed information of the status line of your SAP GUI for Windows, and select Response
time to display the response time permanently. Then, run your scenario and write down the response
time for each user interaction step. Add all response times and divide them by the number of all the user
interaction steps of your scenario to obtain the average dialog response time. This measurement
includes the network time and should not be used in case you access the system remotely.
Alternatively, you can use the Statistical Records (transaction STAD) to get the average dialog response
time. Ideally, both times should be very close. The SAP GUI dialog response time includes network
time, so in Wide Area Network connections this value will be much higher than the server response
time.
26
3.6.2
Number of round trips between frontend and application layer
For the average number of round trips between frontend and application layer per user interaction step refer
to the column No. of roundtrips. Add all values of your scenario (only include steps of the type D (dialog) in
this calculation), and divide the sum by the number of dialog steps. For the example shown below, the value
is 1.8 (25 roundtrips / 14 interaction steps).
Figure 23: Number of round trips and transferred KB
27
3.6.3
Data volume transferred between frontend and application layer
For the data volume, refer to the columns Terminal in-message, Teminal out-message and add up the
values for both columns for all user interaction steps. Only include transactions of the type D (dialog) in this
calculation. In the example shown in figure 5 above, the value is 99.8 kBytes (416 bytes + 116 bytes + +
490 bytes + 12,854 bytes + 4,508 bytes + + 4435 bytes). Divide the value calculated for the whole
scenario by the number of user interaction steps (in the example above there are 14 user interaction steps)
to obtain the required average value (6.5 KB in this case).
3.7
Browser front ends: Response time, roundtrips, network load
In case of browser front ends, currently the statistical records lack of information, because
they do not reflect end-to-end response time (front-end rendering time is missing)
the number of roundtrips is 0

o
STAD can only provide information for a single roundtrip and has no knowledge about all
roundtrips associated to a user interaction step
the data transferred may be incomplete, for example, in case of additional communication
with other servers
Communication did happen only to the Internet Communication Manager (due to incorrect
cache setting of static MIMEs), which produces no STAD entry, as the ABAP layer was not
called.
You could use various browser plug-ins or network sniffer tools to analyze network communication (number
of roundtrips and amount of transferred data to/from the front end) like HTTP Watch, Live HTTP Headers
(Add-on for Firefox), Fiddler2,
These are only examples and do not mean a recommendation from SAP.
Remark: For further analysis you could also check the http log from the Internet Communication
Manager. The Internet Communication Manager ensures that communication between the SAP
System (SAP NetWeaver Application Server) and the outside world via HTTP, HTTPS and SMTP
protocols works properly. In its role as a server, the ICM can process requests from the Internet that
arrive as URLs with the server/port combination that the ICM can listen to. The ICM then calls the
relevant local handler for the URL in question.
This enables you to retrieve the KPI number of roundtrips per dialog step and amount of transferred data
per dialog step also for http based UIs.
28
3.7.1
This behavior also reflected when a request is initiated by a device.
Figure 24: Number of round trips

Therefore you would have to use the mentioned tools above.
Further information to analyze the mobile application:
29
In the detailed screen of the STAD record (double click on the record) you see in this example that 1 HTTP
request was sent to SAP Netweaver Gateway.
Figure 25: HTTP Request
30
that triggered 2 RFC calls to the SAP Backend.
Figure 26: RFC calls
31
4 FURTHER INFORMATION
Related Websites:
http://service.sap.com/performance
http://service.sap.com/sizing
http://service.sap.com/benchmark
www.sap.com/benchmark
Related SDN site:

http://scn.sap.com/community/performance-scalability
32
2013 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information
contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System ads, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries,
pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture,
POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN,
DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Inform ix are trademarks or
registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorp orated in the United
States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein
as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other
product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes
only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("S AP Group") for
informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the
materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as constituting an additional warranty.
33

ABAP SQL Trace PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP SQL Trace PDF

Uploaded by

Copyright:

Available Formats

HOW TO VERIFY

Document Version 1.1

2013 SAP AG. All rights reserved

Words or characters quoted

File and directory names and

User entry texts. These are

Variable user entry. Angle

Keys on the keyboard, for

2013 SAP AG. All rights reserved

First official release of this guide

2013 SAP AG. All rights reserved

2013 SAP AG. All rights reserved

1.1 Planning tests

1.2 Determine the bread-and-butter processes

1.3 Running Single user tests

1.4 KPIs and Best Practices for performance optimized programming

Check the number of unnecessary accesses to the persistence layer

2 VERIFYING RECOMMENDED ARCHITECTURE

Figure 1: Summarized SQL Statements in ST05

Figure 2: Filter criteria, select unequal empty

although it is buffered in the table buffers (BfTp=SNG, GEN, FUL)

Figure 3: Filtered SQL statements

Figure 4: Checking for business relevance of access

Figure 5: Checking for identical selects

90% of 3,748 micro seconds = 3,373 micro seconds

Figure 6: Checking for incomplete Where-clauses

2.2 How to check Indexes

Figure 7: SQL Trace Check in the Code Inspector

2.3 How to check parallel processing

Figure 8: Overview of enqueues in the Enqueue Trace

There must not be exclusive locks in pure retrieval functions

Figure 9: Trace List in transaction ST05.

Determine the critical object/ table for your application

Check if the order of first INSERT, then UPDATE is kept.

During load tests you have the additional possibility to use

SM12 to monitor the system wide enqueue situation

ST04 (Lock Waits) to monitor system wide database locking situation

SM66 to identify work processes waiting for database locks

3. Which parallelization technique is used for batch jobs

2.4 How to check programs for nonlinear scaling behavior

Processing time / CPU

There are several ways of identifying nonlinear processing times / CPU:

Figure 10: Linearity

2.5 Server-to-server roundtrips

JCO and RFC specific information

Figure 11: Trace List

HTTP specific information

Figure 12: Performance Analysis - HTTP Trace.

3 MEASURING RECOMMENDED PERFORMANCE KPIS

b. Start the SQL trace by selecting Activate Trace.

3.2 Measurement with the Statistical Records Monitor

To obtain meaningful measurement results for memory consumption:

Response time (ms)

The display should look something like figure 12:

Figure 13: Workload Statistical Records - Start and Stop of Transaction

Figure14: Architecture for mobile applications

Figure 15: STAD (Gateway) for request initiated by the device

Figure 17: Workload Statistical Records - kBytes transferred

Example: Mobile Application NW Gateway

Figure 18: Workload Statistical Records - kBytes transferred

3.4 Peak memory consumption (MB)

Figure 19: Workload Statistical Records Memory

Example: Mobile Application NW Gateway