Analyse Problem - Debugging Tool

Performance Trace

Active Global Support

March 2009

1
Course Content (current Highlighted)

Introduction Dump Analysis

R/3 Basis Technological Overview ABAP Trace (Runtime Analysis)

Debugger I Performance Trace

Screens Memory Management

ABAP Messages Batch Processing

Debugger II Updates

Dynpro Trace User Exits

Syslog

2
Unit Objectives

This unit will prepare you to perform the following tasks:

Use the performance trace for error and performance analysis
Use SQL, RFC, ENQ and Buffer trace

3
Performance Trace - SQL - Overview

The SQL traces enables you to check how the db is accessed when using
your program.

You can: You can find and eliminate problems

Display the SQL statements executed by your with the following causes:
program.
Display the values that the system uses for • missing indexes
particular database access and changes.
• missing commits
Display how the system converts ABAP Open
SQL statements (such as SELECT) into • inefficient and unnecessary database accesses
Standard SQL statements.
Check where your application executes What is this
COMMITs. program
Check where your application repeats the same doing?
database access. Tip: Use the ST05 to learn
Display the database accesses and changes that quickly what a program
occur in the update part of your application. is doing!

• What SQL statements

• What Buffer accesses
• What RFS‘s
• What ENQUEUES

4
 SQL - Trace - Understand the trace

Technical Introduction
R/3 Basis System translates ABAP Open SQL statements into Embedded SQL. In
Embedded SQL, the system defines a cursor that is used to regulate the data transfer
between ABAP programs and a database. During every FETCH operation, the database
passes one or more data records to the R/3 database interface.

Each SQL statement is broken down into database operations by the R/3 System. The SQL
Trace allows you to measure the runtime of each of these operations:
DECLARE FETCH
Passes one or more records selected to the R/3 DB-
Defines a new cursor InterfaceI
PREPARE REOPEN
Converts the SQL statement Reopens a cursor prepared by the system for a
Determines the execution plan previous SELECT
OPEN EXEC
Converts the SQL statement
Determines the execution plan Passes the parameters for the database statement
Executes the statements that changes data in the database
(such as UPDATE, DELETE, or INSERT).
REEXEC
Reopens a cursor prepared by the system for a
previous EXEC statement.

If you want to understand the trace you need to know what you will read there.

As of 4.6 ABAP allows the definition of cursors in the abap language and you will not only
see this statement as a generated statement from the database interface (As wll as joins,
...).

The DECLARE CURSOR statement defines a named result table with the name
result table name .

An OPEN CURSOR statement with the name of the result table is required to actually
generate the result table defined with a DECLARE CURSOR statement.
more information next page

5
 SQL - Trace - Understand the trace

Declare My_Result_Table Cursor for select * from sbook where mandt = ‚000‘.
My result table

This will be the box where my result will be

stored when it is deliverd (you may think of
your mail box at home)

!
Open My_Result_Table
•Opening the same result table
My result table overwrites....
Actually generates the result defined before
000, LH, ... (all or some depending on the search
•Using the name of the
000, LH, ... database table
strategy of the deatabase)
000, LH, ...
...... locks the db table...

Fetch first | last | next | previous My_Result_Table into parameter.....

My result table

Reads the requested row from the result

000, LH, ...
000, LH, ... table, but may as well have to read the next
000, LH, ... row from the database table, depending on
...... the search strategy

The DECLARE CURSOR statement defines a named result table with the name
result table name

An OPEN CURSOR statement with the name of the result table is required to actually
generate the result table defined with a DECLARE CURSOR statement.

Existing result tables are implicitly deleted when a result table is generated with the same
name.

All result tables generated within the current transaction are implicitly closed at the end of
the transaction using the ROLLBACK statement.

All result tables are implicitly deleted at the end of the session using the RELEASE
statement. A CLOSE statement can be used to delete them explicitly beforehand.

If the name of a result table is identical with that of a base table, view table (see Table), or
a synonym, these tables cannot be accessed as long as the result table exists.

At any given time when a result table is processed, there is a position which may be before
the first row, on a row, after the last row or between two rows. After generating the result
table, this position is before the first row of the result table.
Depending on the search strategy, either all the rows in the result table are searched when
the OPEN CURSOR statement is executed and the result table is physically generated, or
each next result table row is searched when a FETCH statement is executed, without being
physically stored. This must be considered for the time behavior of open cursor statements
and fetch statements.
If the result table is empty, the return code 100 – row not found - is set.
6
 SQL - Trace - Understand the trace

Logical sequence of database operations: select * from sflight where carrid = 'LH' .
DECLARE OPEN
Defines a new cursor and Converts the SQL statement by adding the relevant
assigns a number to it values to it. OPEN would assign the value LH to
PREPARE the field carrid
Converts the SQL statement Determines the execution plan
Determines the execution plan FETCH
only structure matters at this time Passes all records selected to the R/3 DB-InterfaceI
no values contained REOPEN
Reopens a cursor prepared by the system for a
previous SELECT

Note that the values are filled in after at the open statement.

7
 SQL - Trace - How To Start it

1) Choose the trace

2) Start it

3) Specify the user to be traced

To start the Performance trace use transaction ST05

Note that ST05 will trace all actions in the system (more precisely: on the current Instance)
unless you specify some filter criteria. Usually it is a good idea to restrict the the recording
to one user but restriction to other criteria (Tcode, program, table name ..) is also possible.

Note: Don’t perform any other action with that user as soon as the trace has been started.
If available better use 2 users. One for performing the action to be traced, another for
monitoring!

ST05 allows to trace DB access (SQL), locking and unlocking through Enqueues
(ENQUEUE), Remote functon calls (RFC, e.g.communication with SAPGUI or other
systems) and Access to table buffer (Buffer).

With the buffer trace we can really see if the buffer

is existing and accessed or
if it is loaded or
if it is not accessed because of change operations or wrong select statement

We can do systemwide traces for one table.

But be careful: If you start a second trace this will overwrite the old one. To open a new
trace file you can use transaction ST01 and then choose: Edit – File – New file

8
SQL – Trace - How To Stop And List it

Note:
If you want to list
the trace you need
to be on the same
server where the
trace has been
1) Stop it started!

Note the time, the

server and the file
2) List it for SQLR and later
listing.

3) Specify your list options

9
 SQL – Trace - How To Read It

Number of records returned

Table or view accessed Program name, Complete Statement
Seconds.Milliseconds.Microseconds Real time and Where-clause

Good practice:
Use the more info option to see the program where the statement is issued, but be aware
of the fact that the program might have been changed by the customer or a user exit
might have be activated.
Attention:
If the duration is only about a few micro or milli seconds and the next statement is protocolled with a
start time really later than that (several seconds or minutes), than you know that intensive time
consumption of the ABAP coding is causing the time delay.
If you started to trace a batch program that was already running you will not be able to catch the
statement that is already in process of execution, but you will catch all the one‘s that are issued from
now on.
If you hit the explain button, you do not get any stored data that is retrieved from a file or the database,
but you get the information on how the statement would be executed right now. FOR EXAMPLE: if the
missing statistics for a table were the reason for the problem of choosing a not suitable index at the
execution time, you would not see that anymore if the problem is fixed right now.

10
Exercise: Perform and Analyze an SQL-Trace

Task:
Which table is storing the Tcode
of your favorites in the
Easy Access Menu!

Create an SQL trace and find out!

11
Solution: Perform and Analyze an SQL-Trace

1. Switch on the SQL-Trace for your user and create a new Favorite

2. Search for INSERT

3. Find the statement

4. Double-click to verify
the details of the
statement

12
 SQL – Trace - How To Read It

Use the sorted by

output sequence
option!

You don‘t understand this order

(17:13:50 < 17:13:54)?

It might be quit irritating if you want to understand what database operations the program is
performing if you don‘t use the sorted by output sequence feature. BY default the result is
sorted by process ID.

If you want to see the accesses to one table only you can use the Selection for objects
feature.

13
 SQL – Trace - How To Read It

You can filter the output and

display only the objects you are
interested in

If the trace is very long you may want to limit the output to some tables, after you know
what you are interested in.

Also you can search for a particular statement, e.g. UPDATE or INSERT to find information
what table is storing your input data.

14
 SQL – Trace - How To Read It

Compare the ABAP and the SQL Statement

•Summary (what accesses took most of the time)

•Identical Selects (what accesses can be eliminated)

Check for commits and the program that issues the command
In case of short dump check for object SNAP
this is the table that holds the short dump information
shortly before the insert starts the error occurred

To get an overview on the trace results ST05 offers various options:

A Statement summary listing all the accessed tables sorted by time
A Summary of identical selects (listing if the same select is performed e.g. 3000 times in
a transaction)
A Summary of the actions that have been performed

These lists are usually a good starting point for analysis

If you have found the long running statements you can navigate directly to the
Table definition in DDIC
ABAP Statement in the program

Also you can get an explain on the execution path that will be chosen by the database

15
 SQL – Trace - Check one statement

ST05: Explain one SQL statment

You can explain any statement you want

•Pay attention to the notation
(use host variables (‚:A0‘) or literals)
•Save it (4.0) Explain button (4.6)

You can use the Exlain also independent from a trace recording.

16
 SQL – Trace - Check one statement

ST05: Explain one SQL statment

You can explain any statemnet you want

•Check if the execution plan meets
your expectations
•Check the information available
•Adjust the statement or Shows the
•Adjust the index or statistic
•Adjust the statistics information for
the index as
well

If you click on the orange table name to get the comprehensive information on that table
What indexes are there
Do we have statistics created (at what date, with what accuracy, ...)
Who many rows are in that table...

17
SQL – Trace - Check one statement

ST05: Explain one SQL statment

This is only what the optimizer estimates

If it gets worse after the index is choosen
(that you know is good)
It only proofs that the optimizer would not have taken it
(What we already know)

Hints:
Are ignored with wrong syntax

•FIRST_ROWS
•USE_CONCAT
•NO_MERGE
•RULE
•INDEX („tabelle“ „index“)

Generic note: 129385

Oracle: 130480
If you can solve the problem creating statistics with a different method or refreshing them
you should prefer this.

18
SQL – Trace - Check one statement

ST05: as of 4.6: Check or recreate the statistics

Create statistics for an index

Rebuild the index

•During runtime
•Check the table size
•Small table smight only
need
minutes
•For big tables you may block
users for several hours

Report name of that button is rsanaora (for oracle only)

Even if the statement is not in ST04 or ST05 anymore, you can always get the execution
plan using the function explain one statement

19
SQL – Trace - Check one statement

DB02: Get the detailed table or index data

20
SQL – Trace - Check one statement

DB02: Get the detailed table or index data

Check the distinct values

for all columns

21
SQL – Trace - Check one statement

DB02: Get the detailed table or index

data

•Select the Index and run the detailed analysis

•Storage quality below 50-70 %...
•May be this is the problem
•You should consider recreating the index
•Dont ‚forget‘ to talk to the dba, he needs to do
that in the future

You can use the report rsanaora, but

Check if something is running or scheduled to run that needs that index
Schedule the action together with the DBA

22
Exercise: Trace Ztrace_For_AllNo_Entries

Start the trace in ST05

Start: ZTRACE_FOR_ALLNO_ENTRIES TASK

Use the Statement Summary to find the statement that is consuming most of
the execution time.

Compare the ABAP and SQL statement for the select on SFLIGHT

Use the Keyword Docu in the ABAP editor to get a precise understanding of
the SELECT Statement

Use the Debugger to verify what is going wrong!

What is the problem and how can it be solved

23
Solution: Trace Ztrace_For_AllNo_Entries

Solution
The programmer
intended to do a select
specifying the
conditions in the where
clause using an for all
entries.
The DB interface
transformed the
statement. Every field
not filled is removed
from the where clause.
In this case this would
result in a full index
scan for most of our
customers (Worse than
only a full tablescan)

Make sure that this never happens for big

tables! Check that the fields are filled before the
select.

24
Exercise: Trace One statement

Start the trace in ST05

TASK
Use explain for one statement

‚select * from rfblg where belnr = : A0‘

Use the explain button (or save on 4.0)

Why is the index not used?

Check the statistics!
Check the distinct values for the fields of the table!
Would other indexes help?
Would you find a note on that one?
What is the (one and only) suggestion to solve the problem?

25
 Solution: Trace One statement

ST05: Explain one statement Solution

SE12

The unselective field BUKRS is missing in the where

clause (and should always be known for a select like
that). Clustered tables do not get statistics.
Add BUKRS to the where clause (and MANDT of
course)

Note 122718

26
 Performance Trace – Buffer Trace

New on 4.6!

1) Note the color

Yellow: reading from the database
Blue: reading from the buffer

Performance Trace – What is new with 4.6*?

2)
Doubleclick to see the info
from the dictionary

You may see the blue line for a buffer access but only for the open and afterwards the table
access on the database. This is telling you that the data is in the buffer but the buffer is
invalidated due to change operations and you are redirected toread from the database.

27
 Buffer Trace

ST02: Additional
Information

Space information

Here you would see how much space is still left,

if the objects are swaped out and

objects in the buffer

Onjects invalidated

28
 Buffer Trace

ST02: Additional
Information
F1 Help for more info

•Check buffer state

•Sort by invalidations
•Doubleclick (and scroll
down) to see the
buffered objects

A high number of invalidations is either caused by a program error (wong selectivity for
change operations) or the object should not be buffered by that method

Example:
You may see millions of invalidations on usrbf2 on 4.6 (this was caused by a kernel
problem that is fixed in patch level 480, wron delete strategy)

29
Expensive SQL - Statements

How to find expensive statements?

Why should I
find them?
Shared
Process Statistical
Cursor
Overview Records
Cache

Table name Transaction Code Table name

Report name Wait Time WHERE clause
DB Time

SQL
Trace
Table name
WHERE clause

Explain SQL Explain SQL

Statement Statement

Index used Index used

I might be the one driving with 30km

Expensive
per hour in front of everybody else on
statement
the street, and they hate me!

30
 Expensive SQL - Statements

How to find expensive statements?

Shared
Cursor ST04
Cache

Table name
WHERE clause

Explain SQL
Statement

Index used

Expensive
statement

Transaction ST04 allows the analysis of statements that are stored in the Cursor Cache. It
offers equivalent options as ST05.

The advantage of ST04 is:

You can analyse statments that are still in process (or even statements that have been
executed in the past)

31
Expensive SQL - Statements

My statement!
The most
expensive one
in the system?
No WAY....

Sort

Disk Reads -> Buffer Gets -> Double-click on the statement

expensive expensive
I/O Load CPU Load

1) Wrong access path?

2) No statistics?
2) Number of executions?
3) Program / ABAP statement

32
Expensive SQL - Statements

How to find expensive statements?

Statistical ST03
Records

Transaction Code
Wait Time
DB Time

SQL
Trace
Table name
WHERE clause

Explain SQL
Statement

Index used

Expensive
statement

33
Expensive SQL - Statements

Found it!

34
Expensive SQL - Statements

How to tune an expensive SELECT statement?

Expensive Inefficient Yes

statement coding?

No SQL Where
DDIC Explain used list
Info
good
a suitable Yes Yes Check application
optimizer
index exists? re-code
decision?

No

No
No "Missing Yes
Index"?
If you cannot do it on your
create own get at least the he
secondary index re-code traces, the access plan,
create index
in DDIC or the statistic information,
on DB
further rules! change index .... and get help

35
 Expensive SQL - Statements

Roadmap to find unnecessary statements

Process Report name

Overview
Table name

SQL
Trace

GOTO GOTO Check for technical Short access time

Identical Selects Summary tables used by application Extremely often accessed

eliminate identical Sort by access time Txxx tables Check for table buffer
selects In the R/3 program
and unnecessary coding

If you cannot do it on your

own get at least the traces,
Expensive the access plan, the statistic
statement information, .... and get help

GOTO: Identical Selects

should be avoided
the result could have been saved last time

GOTO: Summary
especially in long traces it is better to identify the most expensive statements here

Technical tables in application programs: Txxx tables

should not be selected by an application program
function modules are provided by the basis development

Selects on buffered tables

if a table should be bufferd and is found in the trace not only in the first run the table is
either swithed to not buffered or the table buffer is to small (use se14 to check the
buffering and st02 for table buffer swaps)

36
SQL – Trace - How To Use the SQLR

Insert the start time and end time in transaction SQLR

Goto the summary and determine the part of the application that consumes
the highest amount of time

Classification? / ATP? / ….

37
Performance Trace - Enqueue Trace

Enqueue trace - Overview

The Enqueue trace enables you to check the granularity of the locks
that are set by a transaction or program

You can display: You can find and eleminate problems with
the lock mode the following causes:
the table name
the granularity argument wrong granularity (blocking other programs)
too many locks
the owner
the request time
the operation type (enq, deq, deq all)

Client Material Distribution

Center

Not precise enough

Higher granularity ensures better operation

38
Performance Trace - RFC Trace

RFC trace - Overview

The RFC trace enables you to check the duration and frequency of
RFC calls.

You can display: You can find and eleminate problems with
the rfc calls the following causes:
the request time long rfc times

39
Performance Trace - RFC Trace

40
Summary

Now you are able to:

Apply the Performance trace and related Performance
monitors in the analysis of
Functional problems
Performance problems
Identify long running SELECT statements
Identify database commits and rollback
Analyse Enqueues with respect to their granularity
Make sure that you only trace what you are interested in!

41
Copyright 2009 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 i, 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 Informix 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 Incorporated 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, 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 other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and
services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries.
Business Objects is an SAP company.
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 ("SAP 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 warrant.

42