ABAP Troubleshooting PDF

1
ABAP
Troubleshooting
Boris Gebhardt
Erik Sodtke
SAP AG
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
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
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
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
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
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
Static Checks: Code Inspection from the ABAP Editor
Code inspection from SE38:
The code inspector executes a
default test set for the selected
program.
ABAP Editor
Code inspector is
available with
WEB 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
Static Checks/Code Inspector: Defining Check Runs
2 1
/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
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
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
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 and
may be obsolete.
find program parts that are executed very often and may benefit from
code 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.
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.
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.
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).
17
Tools for ABAP Programs (I)
static checks
Syntax Check
Extended Program Check(SLIN)
Code Inspector
runtime checks
System log (SM21)
SQL Trace (ST05)
Dynpro Trace (ST20)
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<n> files, accessible via transaction ST11)
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
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.
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)
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.
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
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 line
number 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
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
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.
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.
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
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.
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.
31
Dump Analysis Accessing the Debugger
If a runtime error occurs, you
can jump directly into the ABAP
Debugger 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.
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!)
34
Runtime Analysis Traces
static checks
Syntax Check
Code Inspector
runtime checks
System log (SM21)
SQL Trace (ST05)
Dynpro Trace (ST20)
35
ABAP Runtime Analysis: Motivation
Where does this
message come from?
I want to know the exact
source line of the
message statement.
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 statement
level.
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
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<number> 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.
38
ABAP Runtime Analysis: Start the ABAP Trace
Start the Runtime Analysis via:
Menu: System -> Utilities -> Runtime Analysis -> Execute
Transaction: /nSE30
Maintain the trace
restrictions in a variant
Insert the transaction, program
or function you want to trace.
Or start the trace for a parallel session
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.
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.
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.
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.
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)
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)
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.
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)
47
ABAP Runtime Analysis: Trace a Parallel Process (III)
Analyze the trace file
Looks like an endless loop!
48
ABAP Runtime Analysis: Performance Problems
Why is the performance
of my program so poor?
ABAP Runtime Analysis is the
best starting point for an
ABAP performance analysis
After the hierarchy we want to use ABAP Runtime analysis to analyse
performance problems.
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
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.
52
Performance Problems Hit List I
Gross time
Time consumed in, e.g., a function. This includes the execution time of all modules
or 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.
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.)
55
Performance Problems Special Hit Lists
no aggregation
-> all hit lists and the hierarchy are available
Group hit list
DB table hit list
Class hit list
Instance hit list
Method hit list
Event hit list
Internal table hit list
(only if internal-table statements
are 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.
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 the
major 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,
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).
58
Dynpro Trace Available Info
Trace level 2 Trace level 3 Trace level 1
severe errors only
focus
OK-Code
data received flag
Load/generate dynpro
PBO,PAI,DCI,DCO steps
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
59
Runtime Analysis Debugger
static checks
Syntax Check
Code Inspector
runtime checks
System log (SM21)
SQL Trace (ST05)
Dynpro Trace (ST20)
detailed runtime analysis
ABAP Debugger
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.
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)
62
Debugger: SE37 Demo
Function module
Z_DEBUG_SE37
SE37
Button 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 same
type:
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.
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
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 to
leave the endless loop
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 !
66
Debugger: Start Debugging with a Shortcut
Create the shortcut with a SAPGUI higher than 4.5A
Select SystemCommand from the pull-down
menu
Insert the debug command (/h or /hs)
Generate Shortcut
on the desktop
Confirm with OK and the shortcut will be placed
on the desktop
67
Debugger: Start Debugging with a Shortcut
Drag the shortcut directly on the screen where you want to start
debugging
Message Debugging switched on
will 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!
68
Debugger: Navigation in the Source Code
Increase program
section size
Step to current
statement
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.
69
Debugger: Navigation from the Debugger to the
Output
Show next
list line
You can always have a
look 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)
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)
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)
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.
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) change
0
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.
74
Debugger: Manipulation of Internal Tables
Columns
Delete the title if you
want to hide the
column
(This does not delete
the column.)
Scroll Buttons for
switching between
the columns
Choose the table
operation you want
to perform
Header line (WA)
Search Buttons for
searching in the
internal 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
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. the
private 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<class_name> (e.g. 69<CL_GUI_ALV_GRID>).
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!
77
Debugger: Display ABAP Object Events
Display the events of
grid1.
(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.
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), these
breakpoints 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)
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.
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 in
SE38. 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.
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 the
INSERT 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.
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.
83
In the view Watchpoints you can
check the list of active watchpoints
create watchpoints
specify the logical operator between the watchpoints to stop
either when all specified conditions are true or at least one of
them
Debugger: Creation of Watchpoints
Create
change or delete
watchpoints
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.
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
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
87
Debugger: Settings System Debugging
System programs are
outlined by blue color in
the 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.
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.
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.
90
Debugger: Settings Update Debugging / ARFC
Update debugging on
If you enable the update debugging option, all update function
modules 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 on
You can lock the sending of an asynchronous function call.
(CALL FUNCTION IN BACKGROUND TASK.)
This locked function is then available in transaction
SM58 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.
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 delete
some 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 "
92
Release > 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.
93
Release > 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)
94
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

ABAP Troubleshooting PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ABAP Troubleshooting PDF

Загружено:

Авторское право:

Доступные форматы

1

330 --> faulty source line

Вам также может понравиться