ABAP Troubleshooting.pdf

8/10/2019 ABAP Troubleshooting.pdf

1/88

1

ABAPTroubleshooting

Boris Gebhardt

Erik SodtkeSAP AG


2/88

2

SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 2

Warm Up

How can I analyze

this runtime error?

Why is the performance

of my program so poor?

Where does this

message come from?

There are many different possibilities to be in trouble with ABAP programs:

Hard errors (Runtime errors, abortion messages )

Wrong program flow or behaviour

Poor performance.

But the programming language ABAP and the surrounding tools will not let you

alone with the error.

But a major problem is to choose the appropriate tool at the right time


3/88

3

SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt/ 3

Tools for ABAP Programs - Agenda

static checks Syntax Check

Extended Program Check (SLIN)

Code Inspector (SCI)

runtime checks

System log (SM21)

ABAP dump analysis (ST22)

post mortem analysis

ABAP runtime analysis (SE30)

SQL Trace (ST05)

runtime analysis traces

Dynpro Trace (ST20)

detailed runtime analysis ABAP Debugger

Coverage

Analyzer

Organisation of the tools:

Static checks during development and quality phase

Different tools analyse the ABAP code concerning possible runtime errors, screen

consistency, possible performance killer

Run time checks

Post mortem analysis:

If hard errors occur during the run of a program abortion messages, runtime errors, ,then the first approach is always to analyse the error and its surrounding, especially if you cannot reproduce

the error.

For instance, the runtime dump contains 20 pages of very precious information, which are often good enough

to solve the error without any further debugging.

The system log provides the surrounding of the error. What was the initial error of an error chain?

Runtime analysis trace

The error can be reproduced and now you want to get more details about the program without using the

debugger.

(The debugger often provides too detailed info, particularly if you are not familiar with the program)

A normal ABAP program contains SQL statements, screens and of course - the ABAP statements.

For each part we provide very elaborated trace tools: SQL trace, dynpro trace and ABAP trace.

Detailed runtime analysis

The most detailed approach to find an error is the debugger. Here you can check each bit, but dont use it as a

default tool because the mass of info can hide the really important traces.


4/88

4


Tools for ABAP Programs - Overview

System log (SM21)

ABAP dump

analysis (ST22)


SQL Trace (ST05) Dynpro Trace (ST20)

Static checks of ABAP programs Quality management

Syntax More sophisticated checks like parameter match etc.

Runtime checks

Performance

analysis

program flow

find statements

Dumps

check environment

of the error

Syntax Check Code Inspector / Extended program check

Screen

processing

Debugger

Coverage

Analyzer

Organisation of the tools(II): error category approach

Which tools is suitable in which error situation?

Most of the runtime tools cover several problem areas.

The ABAP Trace is e.g. a very good tool to search performance lacks, but also

for analysing the program flow.


5/88

5


Static Checks Quality Management

Static checks Syntax Check

Extended Program Check (SLIN)

Code Inspector

Avoid trouble shooting of difficult ABAP problems by intensive

static checks in the development phase!

1. Syntax Check correct the syntax errors

2. Extended program check make your program error / warning free

3. Code Inspector analyze the performance, security and further hints

4. Check the runtime behavior of your program

With the Coverage Analyzer you can ensure,

that you run through all parts of your program.

Coverage Analyzer

Sophisticated static program checks should be part of each development

process.

Ensure a very high quality of your ABAP programs:

First the program should have no syntax errors.

The next step is to run an extended program check for this program.

This includes more time consuming checks, which are not part of the syntax check like correct

function calls w.r.t. the interface or finding unused variables, etc.Even more tests are provided by the code inspector. Here you get, e.g., hints where you may

have a not totally perfect select statements (performance!) or where you may encounter

security problems.

Afterwards you must assure the correct runtime behaviour of the program.

You may use the coverage analyser to check if all parts of your programs were covered by the

test.


6/88

6


Static Checks: Extended Program Check

F1-help

tests of each category

From the ABAP editor you

can access the extended program check

/nslin

Extended program check (transaction SLIN)

You can decide which checks shall be done. Press F1 for each test family to get

detailed information on the tests to be executed.


7/88

7


Static Checks: Extended Program Check

Get detailed info about the error and access directly

the responsible source line.

The result of an extended program check is a table which displays the messages

/ warnings / errors for each test family.

Errors and warning should be corrected by the developer. An error would be e.g.

to call a function which does not exist.

This will lead to a runtime error during program execution anyway.

From the overview table you get, via double click, to a detailed error description

and from here you can directly access the source code to do your correction.


8/88

8


Static Checks: Code Inspection from the ABAP Editor

Code inspection from SE38:

The code inspector executes adefault test set for the selected

program.

ABAP Editor

Code inspector is

available withWEB AS 6.10

for R/3 >=46C a transport

is available

-> note 543359

The code inspector (transaction SCI) is a mass test framework which is delivered

with WEB AS 6.10.

( for R/3 >=46C a transport is available -> note 543359)

You can define your own:

program set (Which programs shall be checked?),

Test set (Which test shall be executed you can even define your own checks)

From the ABAP editor you can access the code inspector with a default program

set (the program which is currently in use of the ABAP editor) and a default test

set. This global default test set has the name default and can be adapted to

your requirements like any other test set.

The default test set contains the following tests:

Performance checks (e.g. tuning of select statements)

Security checks (e.g. client depending INSERT/UPDATE.)

Extended program check


9/88

9


Static Checks/Code Inspector: Defining Check Runs

21

/nsci

3

The code inspector provides an open architecture for ABAP tests.

1. Create a check variant: Specify which tests shall be executed.

2. Object set: Which ABAPs (programs, classes, ) shall be checked?

3. Inspection: Define an inspection which contains the relevant check variant (1) and the object

set (2).

The inspection can now be executed online or in background. You can even make settings for a

parallel run. (on several servers)

Some remarks to the object selection:

You cannot collect SAP repository objects in your object set. Only customer objects are

allowed.

There is one exception. If you have changed a SAP program (e.g. because of a note), then

you can use single code inspection from SE38 (-> slide 8) during the first week after the

change.

Only in a development system code inspections are possible

If you check the flag Save Selections only in the program set definition, then the programs

will be extracted as soon as the inspection starts. Only the selection, not the programs are

stored beforehand. This is a suitable technique if your program set will change before the

inspection runs.


10/88

10


Static Checks/Code Inspector: Analyzing Results

Navigate to the source line

Search run (find sy-subrc) finished

The result contains all source lines found and

all errors which occurred during searching.

Example: searching for a special string (e.g. the use of a special SY field)

The result list contains all found occurrences, and all errors which occurred

during searching.

You can navigate from an occurrence to the relevant source line.

If a run didnt finish successfully, then you can restart the inspection from the

point where the error occurred.

(no rerun from scratch necessary)


11/88

11


Code Inspector Tips Tricks

Anonymous inspections

If persistent inspections results are not needed, you can create

an anonymous inspection:

create an inspection with blank name

you can either use predefined object sets and check variants

or define everything online

inspection results are not stored on the database


12/88

13


Coverage Analyzer

The Coverage Analyzer is a tool for monitoring the system-wide

execution of ABAP programs.

You can

monitor which programs and even which modules of a program were

covered by a test

find program parts or complete programs which are never used andmay be obsolete.

find program parts that are executed very often and may benefit fromcode optimisation

Coverage Analyzer is available

with WEB AS 6.10

The Coverage Analyzer stores which programs and even modules of programs

where executed in a system and if any errors (dumps) occurred.

This allows you to ensure that all programs and even modules were covered by a

test.


13/88

14


Coverage Analyzer

Make sure that the coverage analyzer is running properly

on your server before testing!

/nscov

SAP Easy Access

The coverage analyser is divided in the administration and the display part.

The administration covers:

Switching on /off the data collection

You can specify the conditions, when a program shall get the flag tested.

e.g. at least 1 time executed without any error.

Reset the results for special programs to start a new test phase

Define test groups and attach users to these groups.

You can now display the results for these test groups.

Monitor the data collection to detect errors or problems (RFC connection )

Check the consistency and repair inconsistencies in the coverage analyser data. E.g between

shared memory and the database.


14/88

15


Coverage Analyzer Global View (QM)

Global view:

Get the test coverage and number of errors for a development class or an author.

This is a good tool for a quality manager who has to ensure professional testing

and a good quality of a development project.

You see the statistics since the last reset and the accumulated values.


15/88

16


Coverage Analyzer Detail View

Check which modularization units

of your programs were executed

(covered) during a test.

For a developer is is more important to see not only the test coverage of e.g. a

development class, but to go more into details and display the coverage of a

special program or even of one module.

In this example function group WBABAP was covered 76.1% by your test. If you

loot at the details, you see that e.g. the form BRANCH_TO_TYPE_ATTR hasnt

been executed and therefore is not tested (red traffic light).


16/88

17


Tools for ABAP Programs (I)


Extended Program Check(SLIN)

Code Inspector

runtime checks

System log (SM21)




SQL Trace (ST05)


Dynpro Trace (ST20)



17/88

18


Post Mortem Error Analysis: System Log

SM37

ST22

/h

My batch job crashed after 7 hours.

Which tool is a

good starting point?

The syslog is helpful if you encounter:

update terminations (SM13)

job terminations (SM37)

any kind of unknown errors

If you encounter the dump SNAP_NO_NEW_ENTRY (no more dump can be written in the

dump database table SNAP), then you can find the real error in the syslog

The syslog is very helpful if you want to check the general situation of the system:

Which errors occur in the neighborhood of the real error? Which was the first

error of an error chain?

Additionally the syslog is a good starting point for a deeper analysis.

With the information about error kind/user/transaction/work process/ you can

tackle more detailed trace files like the developer traces.

(dev_w files, accessible via transaction ST11)


18/88

19


Post Mortem Error Analysis: System Log Remark

Keep in mind:

The normal (local) system log only

shows log entries of the current

server !!

Update or batch errors may occur only on special

servers with update and batch work processes!

System messages are logged in a single circular file on a server. When this log

file reaches the maximum allowable size, the system starts overwriting the file

from the beginning.

Types:

If the R/3 system runs on UNIX hosts, there are two types of logs:

Local: Each R/3 application server has a local log that contains messages generated by that server.

Central: Each application server also copies its local log entries to a central log.

You can always use ALL remote logs to get the system log of all servers.

Accuracy:Local log file: Always up to date

Central log file: There can be brief delays between when the system records a message in a

local log and when the same message is written to the central log

Additional useful selections

User: Due to the number of logged information this will reduce the displayed list.

SAP process (Workprocess x, update process, etc. See F1-help for the field)

Problem classes


19/88

20


Post Mortem Error Analysis: System Log

Example 1: Batch job for user GEBHARDT failed

1st step: System Log (or Job Log: SM37)

Double-click for details

Time: When was the error recorded

TA: W1 and W5 means that the problem occurred in work process 1 and 5 (see

transaction SM50).

If the customer has more than 9 Dialog work processes, then we use characters

to count them.

(R/3 release < 4.6) -> WF = work process 15

Cl.: The client

Tcod: The transaction in which the problem occurred

MNo: Message number

Problem class (after double-clicking a line)

K = Kernel messages

S = Status messages

T = Transaction messages

W = Warnings

X = Other types of messages

A > sign in a text line means that this is a continuation line.


20/88

21


Post Mortem Analysis: Dump Analysis

2nd Step: Runtime Error analysis ST22 select the relevant dump

Lock a dump to ensure that it

will not be deleted automatically

Get the date/time and user data from the system log and select the appropriate

dumps in transaction st22.

The following list contains the selected dumps.

Usually a periodic job deletes all dumps which are e.g. older than one week. To

ensure that a dump will not be deleted you can explicitly lock it. (-> compare note

11838)


21/88

22


Dump Analysis

I got this dump during a batch run.

It aborted after 7h.

It is very hard to debug this error.

The dump file must be sufficient

for the analysis.

At the end of this chapter you will be able to extract all the valuable info from a

short dump.


22/88

23


Dump Analysis ST22

Dump overview: Press F6 in

the dump display

Which information is available in the dump display?

SAP BASIS < 46D

SAP BASIS >= 46D

The most valuable information are included in:

(3) Error analysis

(4) How to correct the error

(5) System environment

(6) User, transaction

(7) Information on where termination occurred

(8) Source code extract

(9) Contents of system fields

(10) Chosen variables

(11) Active calls / events

(12) Internal notes

(13) Active calls in SAP kernel


23/88

24

SAP AG2003, TechED_Basel / ABAP257, Boris Gebhardt / 24

Dump Analysis Systematic Steps

1) Check the dump identification (e.g.

CALL_FUNCTION_CONFLICT_TYPE)

2) Get the system environment (release, OS)

and user information (user, transaction)

3) Read the error analysis and how to correct the error

4) Check the frequency of the dump and search for common

info (server, transaction)

5) Determine the affected programs/includes and the linenumber in the source code

6) Decide about further analysis

(code analysis, field checks, call stack, )

Some remarks on point 4). The other points are described in detail on the

following slides.

If you start transaction ST22 and select, e.g., all

CALL_FUNCTION_CONFLICT_LEN dumps of the last days, then you get a list

like this

Date Time Machine User Clt X Error ID

12.07.1999 11:47:01 pawdf025 FRANKM 000 C CALL_FUNCTI



Please check if all dumps occur on one machine or only one user is involved


24/88

25


Dump Analysis

(1) dump header, system environment, user & transaction

Dump header:

Date and time of dump

Dump identification

Exception type (if runtime error is cacheable)

Collect the information regarding the System environment

SAP release, kernel release, patch level

Operating system, database type

Application server

Is the error server-dependent, or do you find the same dump on other application servers,

too?

Collect the information regarding the user and transaction

Client, user, transaction

This will help to reproduce the problem

Get the screen number and the main program if the problem occurs depending on a screen


25/88

26


Dump Analysis

(2) Error analysis / How to correct the error

For many dumps, the information in

sections Error analysis and How

to correct the error is already

sufficient to diagnose the reason

for the dump.

The Error analysis is one of the most valuable information sources:

In this example you get the information that the function module BGTEST has a

formal parameter MY_CARR. The imported field (SFLIGHT-CARRID) has a type

non-compatible to MY_CARR.

With the normal ABAP tools (SE38 / SE37 / extended program check [SLIN]) you

can extract the cause of the error.


26/88

27


Dump Analysis

(3a) Information on where the error occurred /

Source code extract

current program

current event (form,

function, )

main program.

Head of the program

group

current include

and source line

Use transaction SE38 with the Include name to access the source.

Knowing the number of the source line you can navigate directly to the faulty

statement.

There you can set a breakpoint for debugging or check the surrounding code.

Please be careful, sometimes the displayed source line is one statement behind

the faulty one.


27/88

28


Function group

SAPLS_IMG_TOOL_5

current include

LSVIMF59

Dump Analysis

(3b) Information on where the error occurred /

source code extract

main program.

Head of the program

group

SAPLS_IMG_TOOL_5

Other programs

current event

form VIM_BC_LANGU_ADD.

330 --> faulty source line

endform.

External perform

perform abc in program xyz.

External perform


28/88

29


Dump Analysis

(4) Contents of system fields / Chosen variables

Read the hex-

code vertically

e.g.

SPACE = 20

With WEB AS kernel 6.20, there are Chosen

variables for every level of the ABAP call stack.

For information about system fields, please use F1-help (in SE38) with ABAP System Fields

In our example we learn from the system fields that the program BGTEST5 looped 1000 times

until it failed. (sy-index = 1000).

In a LOOP AT ITAB loop sy-tabix would be essential.

If you have problems with memory consumption of large lists please have a look at sy-linno and

sy-colno (line number, column number).

The chosen variables display some variables in the neighborhood of the faulty statement.

The first line (blue) of the field contents displays the character representation of the underlying

hex-value. Please read the hex-values vertically.

In our case the interesting field P has the hex-value = 99 9C.

Since P is a packed number and not a character field, the first (blue) line of field P shows only

senseless characters. 99 9C is the hex-representation of the packed number 999.

With WEB AS 6.10 you get a variable list for each stack level!

We deal with a packed number with length 2. This means it can comprise only 3 digits.

Therefore we cannot exceed the number 999 and our program fails at the 1000th execution of the

incrementing statement.

With WEB AS kernel 6.20, there is a Chosen variables entry for every level of the ABAP call

stack.


29/88

30


Dump Analysis

(5) Active calls / events

event

program

include

The call stack shows you the flow of the program. With this information you can,

e.g., display (via transaction SE38) the include LCATREF20, line 655 in order to

check how the form CALL_DYNAMIC_FUNCTION_UNIT was called.

Please note that only the call stack, not a complete call history is available. If a

function is called and then the runtime returns from this function and goes on, you

will not find this function on the stack.

If you have, on the other hand, a CALL_FUNCTION_CONFLICT_TYPE, then the

called function is not on top of the stack because the call itself failed.


30/88

31


Dump Analysis Accessing the Debugger

If a runtime error occurs, you

can jump directly into the ABAPDebugger and use the display

features of this tool.

This is possible only as long as

the dump is fresh.

After terminating the internal session (/n) the environment of the dump is deleted

and you cannot access the debugger from ST22 any more.


31/88

33


Dump Analysis Solution: DUMP TABLE_INVALID_INDEX

Analyze the dump We learn from the dump:

Insert with Index 0 because

sy-tabix = 0.

Sy-tabix = 0 because the read

failed.

(target structure my_flight is

empty!)


32/88

34


Runtime Analysis Traces



Code Inspector

runtime checks

System log (SM21)




SQL Trace (ST05)


Dynpro Trace (ST20)



33/88

35


ABAP Runtime Analysis: Motivation

Where does thismessage come from?

I want to know the exact

source line of the

message statement.


34/88

36


ABAP Runtime Analysis: Overview (I)

ABAP Runtime Analysis Overview

Enables you to execute a performance and structure analysis of any

transaction, program, or function module created with ABAP.The measurements are saved in performance data files.

Program flow hierarchy:

Only this tools is able to trace the flow of ABAP programs on statementlevel.

Find the location of the statement you are interested in Compare the flow of the application in different clients / systems

Find USER EXITS, FIELD EXITS,CONVERSION EXITS, TA Variants. Trace the memory consumption of your application

Hit lists performance measurements:

Determine the specific bottleneck area of the program (ABAP vs. SQL) Determine the SQL or ABAP statement causing the highest load


35/88

37


ABAP Runtime Analysis: Overview (II)

What is measured?

ABAP statements that are potentially expensive in terms of CPU time.

The most significant of these are:

DB accesses: Select, Exec SQL,

Modul. units: Module, CALL Function, CALL Screen, CALL Transaction,

CALL Dialog

Internal tables: Append, Collect, Sort, Read Table, Read Dataset

File handling: Transfer, Open Dataset

Others: EXPORT TO , IMPORT FROM , Rollback,

SET PF-STATUS, SET TITLEBAR, MESSAGE, ASSIGN

How is it measured?

During runtime analysis, the system measures the statements listed above.

The system stores these measurements in a performance data file. (DIR_ATRA)

You can evaluate the file (on the current server) immediately or at a later time. The system subtracts the CPU consumption needed for doing the measurement

from the total CPU consumption.

ABAP Runtime Analysis trace file have the name AT and are stored on

the local application server in the directory

specified in the profile parameter DIR_ATRA.

If ABAP Runtime Analysis has problems to read the filed and e.g. you get a

runtime error using Se30 before the first screen

comes up, then you may transfer (or delete) the AT trace files on this server to

another directory for later analysis.


36/88

38


ABAP Runtime Analysis: Start the ABAP Trace

Start the Runtime Analysis via:

Menu: System -> Utilities -> Runtime Analysis -> Execute

Transaction: /nSE30

Maintain the tracerestrictions in a variant

Insert the transaction, program

or function you want to trace.

Or start the trace for a parallel session


37/88

39


ABAP Runtime Analysis:

Variants Trace Restrictions

Create your own restriction variant:

Press button temporary variant

Press button Change

Possible trace restrictions:

Program parts (Method nnn of Class CL_)

Statements (e.g. with OPEN SQL SELECT )

Trace file / aggregation

Hierarchy is only available with aggregation none !!

With WEB AS 6.20 you can easily create a se30 variant with a new Create Icon.

This Button will substitute the Button temporary variant

With aggregation the hierarchy is not available.

For memory usage info in the hierarchy check the With memory use flag.

Program (parts) Particular units

This option allows you to switch on/off the ABAP trace during the running

transaction. Especially, if the you are only interested in a special part of the

transaction (e.g. between screen 3 and 4), then you should use Particular units.

Instruction for tracing Particular units: (trace program part between two screens)

Start SE30

Switch on Particular units for your variant

Start the tracing for your transaction. (Execution button)

The trace will be started as soon as you prompt /ron (Trace on) in your transaction. With /roff

the trace is stopped. (Or you use the menu: System -> Utilities -> Runtime Analysis -> Switch

On / Switch Off)

You can even use this technique in combination with the debugger. Set a

breakpoint at the beginning of the interesting program part and at the end.

If you stop at the first breakpoint, switch the trace on and at the second switch it

off.


38/88

40


ABAP Runtime Analysis: Tracing a Transaction

Run your transaction

Step back to the runtime analysis

Your trace file is now accessible.

Start the program / transaction via se30 with your variant. Step back to SE30 if

the interesting part of the transaction is finished.

You now see the new trace, which can be analysed.

If the trace file is not available, then please use the button Other file to

browse for your trace file.

If you got an error message when returning to SE30, which indicates that the

measurement failed,

then you may use the File info button to get the detailed error code.

If you used a variant with active aggregation the please rerun your trace with

Activation = NONE.


39/88

41



Tracing a Transaction Hierarchy

Call hierarchy

Access the hierarchy (only available with a no aggregation variant) from the

overview screen.

You get a list which represents the complete path through your application.


40/88

42


ABAP Runtime Analysis: Hierarchy Features

Display filter

-> Which info of the trace file shall be displayed?

Default: Only application info is displayed.

For each trace line you can step

to the relevant ABAP source line.

In the trace variant you specified already which statements and which parts of

your application shall be traced.

Additionally you can now filter which data you want to display.

Please notice that some display filters are switched on per default (e.g. no

system programs).

Therefore if you miss something, switch off all display filters and check your trace

variant.

You can step from the trace directly to the relevant source line.


41/88

43


ABAP Runtime Analysis: Hierarchy

Stack level Allocated memory in Bytes

Switch on With memory use in the

trace variant to get this info!

The hierarchy list contains the following data:

Gross/net time (-> performance part of this chapter)

Level: Stack level

Call hierarchy: name of the statement / event.

Program: current program / class

Memory requirement: the current use of memory. The maximum values are marked with a red

background colour.

This feature is only available, if you switch on With memory use in the area duration/type of

your trace variant.

(default: switched off)


42/88

44


ABAP Runtime Analysis: Hierarchy Exercise

Exercise 3

Run transaction ST22 (Runtime Error Analysis)

and search for dumps for user XXX.You get the error message:

None of the selected short dumps exist

(SN/404).

Use SE30 to find the source position of this message statement.

Find out in which form the message is launched

(use the stack level in the hierarchy list)


43/88

45


ABAP Runtime Analysis: Trace a Parallel Process (I)

The batch job is running and always reading DB table SFLIGHT.

What is this program doing?

With Basis release >=46B you can use Runtime analysis to trace program which

run in a parallel session.


44/88

46


ABAP Runtime Analysis: Trace a Parallel Process (II)

Switch on/ off the trace

for the marked process

Ensure that you run SE30 on the

same server as the running

batch job!

If you used a 46D kernel with patch level >=1413 (or 6.10 kernel patch level

>=427), then you can switch on the ABAP trace for idle processes as well (note

586940)

You must create your trace variant for the parallel trace as well.

(no aggregation to get the hierarchy)

Stop the trace after a short tracing time in order to avoid reaching the trace file

quota! (profile parameter abap/atrasizequota)


45/88

47


ABAP Runtime Analysis: Trace a Parallel Process (III)

Analyze the trace file

Looks like an endless loop!


46/88

48


ABAP Runtime Analysis: Performance Problems

Why is the performance

of my program so poor?

ABAP Runtime Analysis is thebest starting point for an

ABAP performance analysis

After the hierarchy we want to use ABAP Runtime analysis to analyse

performance problems.


47/88

49


ABAP Runtime Analysis: Performance Problems

Strategy:

Restrict the trace file as much as possible (-> Variant).

Especially for long running programs.

Otherwise the file quota will be exceeded quickly.

Start with full or by call aggregation (only hit list available)

Restrict the statements e.g. only modules (functions, forms, methods)

Restrict the analysis in a second trace to the performance killing modules

Trace only a part of the transaction with the restriction Particular units

Variant area Duration / type

aggregation Full: full aggregation for the selected statements

aggregation By call: if the source position differs -> no aggregation

None: no aggregation at all.

Profile parameter abap/atrasizequota and your variant settings limit the maximum

trace file size


48/88

51



Performance Problems Overview

With full aggregation only

the hit list is available.

1. Distribution of the execution time:

ABAP (all ABAPs except OPEN SQL)

Database (Open and native SQL)

System (implicit program generation,

loading of programs, )

Reliability of the execution times on machines running with more then one

processor:

The numbers represent not an exact measurement. But you get a good

impression which parts of the programs consume most of the time.

To get reliable results you should execute the measurement several times.

The overview of the runtime evaluation shows if the performance killer must be

searched in expensive selects (Database) or perhaps not perfect internal table

handling (ABAP).

For SELECTs a switch to the SQL trace (ST05) produces more detailed info

concerning tuning (which index was used ).

In our demo example the overwhelming part of the execution part is spent on

database operations.


49/88

52



Performance Problems Hit List I

Gross time

Time consumed in, e.g., a function. This includes the execution time of all modulesor other program parts which were traced and which were called from inside.

Net time

= Gross time minus traced program parts which were called inside.

E.g. the execution time of the FETCH T100 in FORM MSG_NR is subtracted from the gross time

to get the net time.

Sort the list by net time to identify the performance killer!

Filter variant: Only form MSG_NR default statements aggregation by call

Filter variant: all parts of the program only modules aggregation by call

First run: We use the trace restriction variant:

Program parts: no restriction

Statements: only modules

Duration / type: aggregation by call.

The hit list is sorted by net time: We get the most time consuming modules (here

forms).

FORM MSG_NR consumes ~ 39% of the total run time.

So this form seems to contain some expensive statements and

it seems to be worthwhile to go into details concerning this form.

Second run: We use the trace restriction variant

Program parts: only form MSG_NR

Statements: default

Duration / type: aggregation by call.

We traced only form MSG_NR, but now we trace all statements.

The hit list is sorted by net time again and we see that a

SELECT FROM T100 (Fetch) is the major

time consumer in FORM MSG_NR.


50/88

53



Performance Problems Hit List II

Use SQL trace for detailed analysis

of SQL statements.

From the Fetch line we can directly navigate to the source line to check why this

SELECT is so time consuming.

In this case it is obvious. For counting DB entries the developer should use

aggregations like COUNT(*), but if it is not so easy, then a SQL trace (ST05) for

this

single statement would be the next step.

(missing index etc.)


51/88

55



Performance Problems Special Hit Lists

no aggregation

-> all hit lists and the hierarchy are available

Group hit list

DB table hit listClass hit list

Instance hit list

Method hit list

Event hit list

Internal table hit list

(only if internal-table statementsare included in your variant!)

DB table hit list

If you use no aggregation, you can choose within a variety of hit lists.

Most important is the DB hit list. Here you can see with one glance which DB

table are accessed how often and how much execution time is attached to them.

Additionally you get some info from the DDIC, concerning the Table type

(TRANSP, POOL, ) and the buffering.

The other hit lists provide info which internal table or class consumed most of

the time.


52/88

56


ABAP Runtime Analysis: Summary

ABAP Trace (Call hierarchy)

Trace on ABAP statement level (find MESSAGE )

Restrict the trace to the ABAPs you are interested in.(Explicitly by naming the programs or dynamically with particular

units.)

Trace the memory consumption of the transaction

(trace variant with switched on With memory use)

Performance Trace (Hit lists)

Restrict the trace in the first run to the modules and use aggregation in

your trace variant . In the second run you can specialize the trace on themajor performance killer.

Check the global hit list for the major performance killer. (Sort by net time)

If you use no aggregation then you may analyze the detailed hit lists for

DB tables, ABAP Objects,


53/88

57


Screen Trace

Start screen trace via transaction: ST20

With SAP Basis release 46B, transaction ST20 (screen trace) is available to

analyse Batch Input or all other errors which are connected with screen handling

(field transport, screen sequence, resize, F1, F4 help)

In older releases you can use the report RSTRC000 to look at the screen trace.

(notes 0508748 or 0087150).


54/88

58


Dynpro Trace Available Info

Trace level 2 Trace level 3Trace level 1

severe errors only focus

OK-Code

data received flag

Load/generate dynpro

PBO,PAI,DCI,DCOsteps

application/system modules

dark processing

main screen, subscreen

set screen, leave screen

call screen, skip screen

call dialog, call transaction

submit

step loop processing

messages

send/receive data from SAPGUI

field contents

conversion exits

field exits

global fields

set/get parameter

modify screen

batch input processing

screen resize

screen compression

subscreen tree


55/88

59


Runtime Analysis Debugger



Code Inspector

runtime checks

System log (SM21)




SQL Trace (ST05)


Dynpro Trace (ST20)



56/88

60


Debugger: Start an ABAP with the Debugger

ABAP-Report

SE38

Button Debugging

The report will be started directly in debugging mode.

If you insert /h in the OK-field, you will not debug RSPARAM but the editor

(SE38) itself.


57/88

61



Function module

SE37

Button Single Test

Fill in the parameters for the

function interface and press

Debugging

For function modules use transaction SE37 -> Button Single Test.

In the generated function interface fill in the parameters and press Debugging

Please notice that this is the only possibility to debug functions which are

connected to Conversion Exits or Field Exits. They cant be debugged during the

running transaction (-> only isolated testing is possible)

If you debug a complicated transaction and you are sure that the problem occurs

in one function module, obtain the parameters for the function interface and try to

reproduce the error in an isolated test (SE37)


58/88

62


Debugger: SE37 Demo

Function moduleZ_DEBUG_SE37

SE37Button Single Test.

Where is the output ??

My_export should be 123 ??

1 function z_debug_se37.

2 *"-----------------------------

3 *"*"Lokale Schnittstelle:

4 *" IMPORTING

5 *" VALUE(MY_IMPORT)6 *" EXPORTING

7 *" VALUE(MY_EXPORT)

8 *"-----------------------------

9

10 my_export = 123.

11 write: / my_import.

12 endfunction.

13

If the type of the export parameter is not specified in the test environment of

SE37, a default field with type char(200) will be generated.

By the way, if you call this function from another program without specifying the

import parameter:

call function 'Z_DEBUG_SE37'

exporting my_import = 'ABC'.

Then my_export in the function will have the default type char(4).

If you specify the parameter, the system will generate a field which has the sametype:

data int type i.

call function 'Z_DEBUG_SE37'

exporting

my_import = 'ABC'

importing

my_export = int .

my_export has type I in the function module.


59/88

63



You can start a transaction in debug mode from the

transaction maintenance. (SE93)

The transaction will be started directly in debugging mode.

With R/3 Release < 4.6A:

SE80, button Edit

Fill in transaction (e.g. VA01)

Test / Execute (F8)

Select radio button Debugging

Or much faster (Enjoy release 4.6A):

Transaction SE93 Fill in your transaction

Menu path: Transaction Code -> Test -> Debugging


60/88

64


Debugger: Start Debugging for a Running ABAP

For a transaction:

OK-Code field in the

transaction:

/h (switch on debugging)/hs (system debugging)

For a batch job or long running program

SM50:

Select the program to be debugged

Menu: Program/Session -> Program ->Debugging

Starting the debugger while the program is already running allows you to reach

the point of interest faster and more precisely.

Start the debugger (/h) in a transaction at the point where you have the problem

Start to debug e.g. a batch report when you think the problem comes up (e.g. high memory

consumption)

For debugging basis transactions usually the system debugging will be needed (/hs)

A batch job will not stop if a breakpoint is reached. Even for the statement

BREAK-POINT only a sys log entry (Breakpoint reached ) is generated.

But you can access the batch process via SM50 and then you can use all

features of the debugger

You can set dynamic/static breakpoints, display or change fields

To debug a batch job at a specific line of your code you may introduce an

endless loop in the code.

(I = 1. WHILE I=1. ENDWHILE)

Then you use sm50 to debug the batch process and change the condition toleave the endless loop


61/88

65


Debugger: Job Debugging Hidden Feature

In the job overview(SM37) you can debug

each job with the ok-code JDBG.

But please keep in mind:

This is like a restart of the job.

->All possible updates will be executed !

If you have to analyze an aborted job, then you can restart the job in debug

mode.

This is a background simulation which actually runs in a dialog work process to

allow debugging.

But e.g. the spooling is done and sy-batch =X. So from the ABAP perspective

the program runs in a background environment.

Instructions:

Run SM37

Mark the job you want to restart in debug mode

Prompt jdbg in the ok code

You reached the debugger

But please keep in mind, this is no simulation. All updates, deletes or

whatever else is done in this job will be executed !


62/88

66


Debugger: Start Debugging with a Shortcut

Create the shortcut with a SAPGUI higher than 4.5A

Select SystemCommand from the pull-downmenu

Insert the debug command (/h or /hs)

Generate Shortcuton the desktop

Confirm with OK and the shortcut will be placedon the desktop


63/88

67


Debugger: Start Debugging with a Shortcut

Drag the shortcut directly on the screen where you want to start

debugging

Message Debugging switched onwill appear in the status field

This technique is really helpful if you are on a popup and want to start debugging.

You cant access the OK-field, therefore the shortcut technique is the only

possible solution to debug the ABAP of a popup directly.

Please assure (especially if you use a CITRIX client) that you have the

(Windows) permission to save files on the desktop!


64/88

68


Debugger: Navigation in the Source Code

Increase programsection size

Step to currentstatement

Scroll source code

Control buttons

F6 Execute

F8 Continue

F7 Return

F5 Single Step

(Beginning with 4.5: Continue until cursor)

Navigate through the coding:

Single step: one single statement will be processed

(functions, forms, etc. will be entered)

Execute: one single statement will be processed

(functions, forms, etc. are treated as one command)

Return: all remaining statements of the current routine will be processed

until its end is reached

Continue: all remaining statements will be processed until the next breakpoint or

watchpoint,

or the current cursor position, or the end of the program is reached

Search buttons can be used to search within the coding

To navigate back to the next statement to be processed use the icon display

current statement

To hide the view section click the icon increase program section size

The flag Fixed pt. Arithmetic indicates whether the actual program uses fixed

point arithmetic or not (adjustable via SE38 -> Attributes).

If you use NO Fixed pt. Arithmetic, then packed figures are similar to integers and

the DECIMALS settings influences only the output.


65/88

69


Debugger: Navigation from the Debugger to theOutput

Show next

list line

You can always have alook at the current list

output.

Using this technique you

can control the output

line after line

You navigate from the debugger to:

the current state of the list-output (GOTO -> Display condition -> Display List)

the current ABAP source (Development -> ABAP Editor / Object Browser)

the screen painter (if you are in the flow logic of a dynpro)


66/88

70


Debugger: Navigation using the Active Call Stack

Double-click this line in

order to navigate to this

function on the call stack

The call stack shows the current call hierarchy (which program was called by

which program)

It is always possible to switch to the other levels of the hierarchy. Within this level

it is possible to access all variables and their values, but you have to keep in

mind that only the local variables have their current values; global variables might

have been changed during the program flow.

The switching itself is triggered by double-clicking on the desired level.

Please keep always in mind that you only see the pure call hierarchy. If the

program jumped to another routine and returned you are not able to find a trace

in the call stack.

(For this purpose use ABAP Trace [SE30].)

If system debugging mode is off, you will not be able to switch into system

modules!

(switch on system debugging: /hs)


67/88

71


Debugger: Display Data in the Debugger

(2)

Double-

click

(1)

Hex- Display

Press the

magnifier icon.

VIEW: SINGLE FIELD

(3)

Double-

click

In the fields view you can switch to hexadecimal display by using the magnifier

icon (1).

Starting from the fields view you can double-click on any field name; this will lead

into the detailed field view (3) or, if the field name specifies a structured field, you

will be switched into the structured field view (2).

A double click onto any field in the structured field view or table view will lead you

into the detailed view of the simple field.(3)

You can also access the field directly:

Enter: sflight-paymentsum.

You can access the different views also from the menu:

Goto -> Display data object ->

Single field (Ctrl + F2)

Structured field (Ctrl + F3)

Internal table (Ctrl + F4)


68/88

72


Debugger: Display Data in the Debugger

(1)

Double-

click

(2)

Double-

click

Starting from the fields view you can double-click onto the field name to branch

into the table view (1).

A double click onto any field in the table view will lead you into the detailed view

of the field. (Like shown in the slide above, into an internal table (3))

You can also access the field directly:

Enter: my_struc-itab2[].

([] means table contents / itab2 might be only the header line of the table)

Example:

my_struc-itab2[2]-mandt will display the field mandt of the second line of the

internal table my_struc-itab2.

If you have an internal table with a header line:Data: itab like sflight occurs 0 with header line.

Then itab represents the header line and itab[] the body of the table.


69/88

73


Debugger: Manipulation of Variables

Each value displayed can be changed as well

edit the value (1)

click the pencil icon afterwards (2)

(1) edit

(2) change0

If you enter a variable name in the variable area of the debugger, you will be able

to see the contents of the variable (and scroll if needed). When using structures

or tables instead of normal variables the system will display the work area of the

variable. Entering a variable can also be done by double-clicking on a variable in

the coding.

It is also possible to change the contents of a variable by overtyping the contents

and pressing the pencil. This change will be documented in the SYSLOG and you

need a special authority. (S_DEVELOP/DEBUG/01)

Its not possible to change the hex-values of fields.

If you allow a user to change variables via the debugger, then this user can

overcome almost all authority checks.


70/88

74


Debugger: Manipulation of Internal Tables

Columns

Delete the title if youwant to hide thecolumn(This does not deletethe column.)

Scroll Buttons for

switching between

the columns

Choose the tableoperation you wantto perform

Header line (WA)

Search Buttons for

searching in theinternal table

In order to manipulate internal tables you can either use the button Table or

double-click on the internal table. The system will switch to the table view screen.

Within this view you can:

scroll horizontally and vertically through the table

hide columns by deleting the column title in the column line

shift column by entering a specific column name instead of a displayed column name

(e.g. replace VONTG by PERDLY and you will see PERDLY as first column)

This is merely a display functionality. Your changes have no effect on the internal table.

search (R/3 Release > 4.0B) through the lines by using the search button in the application

toolbar. Positioning the cursor on a certain line uses the line contents as search pattern.The normal search button (in the standard toolbar) searches in the source code.

insert, modify, delete an entry

Please keep in mind that the entry is only changed column by column (except with the delete button)

If you want to insert a line, you need to click on insert first and to change every column of the row afterwards.

If you want to change a whole row, you need to do that column by column as well


71/88

76


Debugger: Display ABAP Objects

Double-

click

The object reference grid1 contains an

instance of class CL_GUI_ALV_GRID.

Double click on this instance to get the

contents of this object.

You may use the filter

to display e.g. theprivate attributes as

well

You can display all attributes of your ABAP objects. To see the private/protected

attributes use the filter icon.

If you display a reference, you get the referenced instance name

nr (e.g. 69).

Double-click on the instance displays the content of this instance.

With Goto -> System -> Find references you can display all references that point

to a special instance of a class!


72/88

77


Debugger: Display ABAP Object Events

Display the events ofgrid1.

(CL_GUI_ALV_GRID)

Get the handling object of the grid1 events

(Set by SET HANDLER)

The button event for an instance displays all events of this class and the attached

event handler.


73/88

78


Debugger: Static Breakpoints

Set breakpoints directly in the editor (SE38)

position the cursor in a valid line

press the stop icon

the line will be marked (Rel. < 46A: stop icon in the source code)

Set breakpoints directly in the debugger

position cursor in a valid line and double-click

the stop icon will appear in front of the line

1. hard coded breakpoints:BREAK-POINT.

BREAK JACK. (Hans is the user name).

The first leads to a stop for all user which are in a dialog session (on all servers).

The second is a macro, which is defined in Table TRMAC.

This macro is the short form of:IF sy-uname = JACK'.

BREAK-POINT.

ENDIF.

2. If you use the normal breakpoint mechanism in the editor (stop icon), thesebreakpoints are only effective for your user and your current logon session!

(You will not realize this breakpoint on a different server!)

3. If you set a breakpoint in the debugger, this breakpoint is only effective for the

current debug session. If you save the breakpoints, they behave like editor

breakpoints (->2)

Unfortunately its not possible to set a breakpoint in field-exits and conversion-

exits. The runtime will not stop there. You have to test your exits in an isolated

test environment. (SE37)


74/88

79


Debugger: Dynamic Breakpoints

Choose the criteria

you want to set a

breakpoint at

You may want to save

the breakpoints for the

next debugging session

You can activate

and deactivate

breakpoints

temporarily

Set breakpoint at:

Statement, e.g. select. You will find breakpoints at all select and (open/fetch) cursor-

statements

Event/Subroutine: at, e.g., start-of-selection (event) or at a form of the current program.

If you use a release > 4.0B, you can specify the main program of the form explicitly

Function module: Insert the name of the function module. The Debugger will stop at the first

statement of the function module.

System exception: If your program uses the CATCH/ENDCATCH functionality, you may

miss an occurring dump. If you set breakpoints at system exception, the debugger will stop at

the statement where the skipped dump occurred.

Deactivate / Activate breakpoints

Thats not the same as deleting and setting breakpoints.

If you deactivate a breakpoint, the breakpoint is still there, but the program will

not stop. This is a very convenient technique if you pass the breakpoint several

times.

So, e.g., you can deactivate the breakpoints, then fill some screens, and then

activate the breakpoints again. This technique allows you to reach the interesting

part of the program as quick as possible without loosing time, because you

always stop at the breakpoint before the interesting situation comes up.


75/88

80


Debugger: Possible Problems with Breakpoints

Please save the breakpoints in the debugger if you want to use

them in a later debugging session

If you use dynamic breakpoints (breakpoint at statement) please

save these breakpoints to ensure that they are available in all

internal sessions.

Please restart the program after setting a static breakpoint inSE38. A running program will not see the new breakpoints.

The saved breakpoints are only available in your

current logon session. Other users or you in another session

will not realize the breakpoints.


76/88

81


Debugger: Manipulation of Breakpoints

Counter

In the view Breakpoints you can

check and change the list of active breakpoints

assign a counter to a specific breakpoint, which will cause the

program to not stop before the specified occurrence of the

breakpoint

The breakpoint overview allows you to delete, e.g., only the dynamic breakpoints

at WRITE.

So you dont have to delete all breakpoints. You can decide very specifically

which breakpoints should be deleted.

Example (Counter):

You are in a form which fills an internal table. This form is called very often.

During runtime a dump occurs at an INSERT statement, which complains about a

too big an internal table and a lack of memory.

Now you have the problem to debug the program.

You place a breakpoint at the proper INSERT statement, but unfortunately theINSERT statement is executed thousands of times.

Now you can use the Count-technique.

Set the count-field to, e.g., 1000 and execute. If you get the dump, decrease the

value to 500, then 250, With this technique you can quickly detect the exact

moment when the error occurs and start debugging there.


77/88

82


Debugger: Watchpoints

If you set a watchpoint on the field matnr (matnr = '1234'),

the debugger stops as soon as matnr contains the value

'1234'.

If you do not specify a condition, the debugger stops as soon as

the field matnr changes.

Matnr = 0000

Watchpoint: Matnr = 1234

Matnr = 0120 Matnr = 1234

Program flow

Watchpoints are very dynamic breakpoints.

You can specify a field that should be monitored and you can specify a stop

condition.

The system will inspect the memory address that is connected to the field name

and will compare the value in this memory address according to the condition

given by you.

As soon as the condition and the current value match, the debugger stops.


78/88

83


In the view Watchpoints you can

check the list of active watchpoints

create watchpoints

specify the logical operator between the watchpoints to stopeither when all specified conditions are true or at least one of

them

Debugger: Creation of Watchpoints

Create

change or deletewatchpoints

If you wish to stop the program depending on the contents of a variable, you have

to use a watchpoint.

Within the watchpoint you can specify the relational condition under which the

system should stop (, , =). Even the comparison with another variable

(rather than a given value) is possible

If you create more than one watchpoint, you can link them together with AND or

OR.

Local and global watchpoints:

The debugger always looks at the memory address of the watchpoint-field.Some special variables and fields are shared between programs.

(e.g TABLES, COMMON PART, SY-fields)

This means two program look at the same memory address.

If you use local watchpoints, the debugger checks not only if the contents of the

memory address has changed, but compares also the actual program with the

watchpoint-program.

If you use global watchpoints, the debugger will always stop if the memory

contents change, independent of the program.


79/88

84


Debugger: Exercise

Run transaction SE09:

Where does the pre-set USER = GEBHARDT come from?

1. Get the ABAP field name(TRDYSE01CM-USERNAME)

2. Start SE09 in debug mode (SE93) and set a

watchpoint on the field.

3. You stop at the following lines:

CALL FUNCTION 'TRINT_READ_USER_CUSTOMIZING'

IMPORTING

es_settings = ls_settings.

CLEAR: trdyse01cm.

MOVE-CORRESPONDING ls_settings TO trdyse01cm.

4. Set a breakpoint at the preceding function

and find out where and how es_settings is

filled


80/88

86


Debugger: Settings

Menu: Settings ->

Display and change all

Be careful: Some settings are not displayed in the menu Settings.

To get the full settings information choose Settings -> Display and change all

(< 4.5A: Settings -> Display)

Detailed information about these settings are available in the extended help of the

debugger


81/88

87


Debugger: Settings System Debugging

System programs are

outlined by blue color inthe call stack.

System programs are

skipped during debugging

if you dont use system

debugging.

System Debugging on/off (/hs)

SE38/Attributes /Display

System debugging can be switched on via menu Settings or by /hs in the OK-

code field.

If you debug a CALL FUNCTION statement, but the runtime skips the function,

check if this function is part of a function group with status S (System program).

This effect can be eliminated by System Debugging

System Debugging is necessary if you want to debug:

variants

selection screens

logical databases

the update process

batch processing

With Release < 4.5A the system modules are not visible in the call stack if you

use normal debugging.


82/88

88


Debugger Settings Update Debugging

Asynchronous update - Whats that ?

FUNCTION ABC .

...

UPDATE

ZDEBARFC.

...

ENDFUNCTION.

Update WP

CALL FUNCTION ABC IN UPDATE TASK

EXPORTING ...

COMMIT WORK.

Dialog WP

Field 1 Field 2 Field 3 Field 4

VBDATA

VBMOD

If you use the normal direct update then after each screen the DB -changes are

committed.

To ensure that you can ROLLBACK all DB changes of a multiple screen

transaction you must use the SAP LUW concept. This means usually you use

CALL FUNCTION... IN UPDATE TASK .

If you call a function in Update task then this function is not called instantly but

merely its name and the interface data is stored in database tables(VBMOD

/VBDATA)

If a COMMIT WORK is reached then the stored function modules which are

linked to this LUW will be read from the database and executed in a free update

workprozess.


83/88

89


Debugger Settings Update Debugging

Why do I need Update debugging ?

The debugger is attached to one process

and cannot jump to the update process

Update is launched

COMMIT WORK

Debugger

If you use the normal asynchrony update then after a Commit Work the update

work will be done by another workprocess (update workprocess). Therefore the

debugger cant debug

the update procedure and will stop after the COMMIT WORK.

If you switch on Update Debugging then after the COMMIT WORK the update is

executed in YOUR process and therefore the debugging can go on.

Please keep in mind that many customer bundle there update work processes on

one server.

This implies that the process switch after COMMIT WORK can include a server

switch as well.

If the program uses SET UPDATE TASK LOCAL then the update is executed in

the same process and the update data is not stored on the database but in the

memory. In this case you dont need update debugging.


84/88

90


Debugger: Settings Update Debugging / ARFC

Update debugging onIf you enable the update debugging option, all update functionmodules are processed in the Debugger after the COMMIT WORK

statement.

This is the only possibility to debug the update process.

In background task: Lock Release onYou can lock the sending of an asynchronous function call.(CALL FUNCTION IN BACKGROUND TASK.)This locked function is then available in transactionSM58 for debugging.

Transaction SM58

Position your cursor on the

function module.

Then choose Edit -> Debug LUW

If you locked a background function in the debugger, you will find this function

after the COMMIT WORK in transaction SM58.

If you use the normal asynchronous update, after a COMMIT WORK the update

work will be performed by another work process (update work process).

Therefore the debugger cant debug the update procedure and will stop after the

COMMIT WORK.

If you switch on Update debugging, after the COMMIT WORK the update is

executed in YOUR process and therefore the debugging can go on.

If you have to deal with aborted updates, then you can analyze them in

transaction SM13. There you can restart, test or even debug the

failed update modules.


85/88

91


Debugger: Monitor Memory Consumption

Your process alone allocated ztta/roll_area + EM + HEAP~ 270 MB.

How can I find the

major memory consumer

of the greedy program?

Programs often consume much memory to build up big internal tables.

If, at the next APPEND, the system resources are exhausted, the program will fail with, e.g.,

TSV_TNEW_PAGE_ALLOC_FAILED

The resulting dump will show that the APPEND (e.g.) was the last command. The system field sy-

tabix will show the number of lines appended.

In the section How to correct the error you will find the amount of memory which was allocated at

that moment. To get an overview you must sum up ROLL, EM and Heap. The Roll memory is the

sum of all Roll memories of all users. But the EM and Heap figures correspond to your process.

(Therefore, if another process also allocates much memory, then your process will abort before it

reaches the parameter limits.)

Unfortunately the information in the section internal tables is not really useful because we deletesome internal tables to get some memory for the dump output

Transation ST02 is very useful to analyze memory problems.

E.g. Press Detailed Analysis Menu and then the Button SAP Memory.

Current Parameters -> Get all memory parameters

If the Extended memory is exhausted, the Workprocess switches to PRIV mode. This means this

process is now exclusively locked for this user. No one else can use this process. This event is

stored in the dump as well. Part Error Analysis:

Error text "Warning: EM-Memory exhausted: Workprocess gets PRIV "


86/88

92


Debugger: Monitor Memory ConsumptionRelease > 45B

If you are able to debug the memory consuming program, you can use the ITAB-

TOP25 system area to find the biggest internal table.

The columns alloc. Netto and Used netto differ because we always allocate a

certain amount, then use this up for e.g. several appends, and then we allocate

fresh memory.


87/88

93


Debugger: Monitor Memory ConsumptionRelease > 46D Memory Inspector

With Release > 4.6D it is possible to display a ranked list of the most important

memory consumers.

This includes all loaded programs and all possible data types. (Internal tables,

ABAP Objects, )

This feature allows us to see with a glance which fields hold most of the memory.

With WEB AS 6.40 the memory inspector is delivered. This is a tool which is

integrated in the debugger and provides a standalone framework to compare and

analyze memory snapshots. This functionality will be available in the WEB AS

6.20 at the end of the year.

(note 606368)


88/88


Debugger: Outlook - New ABAP Debugger

Main features of the new debugger :

Standard debugger features (stack, variables, break points)

Sophisticated navigation between ABAP data structures

Layout can be customized freely

New tools can be plugged in easily

Desktops for different views (standard, tables, user defined )

History + undo functionality

Tools can be instantiated 4 times -> e.g. compare 4 internal tables

Documents

ABAP Troubleshooting.pdf