ABAP Troubleshooting

ABAP Troubleshooting
Boris Gebhardt Erik Sodtke

SAP AG
Warm Up
How can I analyze this runtime error? Why is the performance of my program so poor? Where does this message come from?
SAP AG 2003, TechED_Basel / ABAP257, Boris Gebhardt / 2
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
Tools for ABAP Programs - Agenda

static checks Syntax Check Extended Program Check (SLIN) Code Inspector (SCI)
Coverage Analyzer
runtime checks post mortem analysis System log (SM21) ABAP dump analysis (ST22) runtime analysis traces ABAP runtime analysis (SE30) SQL Trace (ST05) Dynpro Trace (ST20) detailed runtime analysis
ABAP Debugger
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.
Tools for ABAP Programs - Overview

Static checks of ABAP programs Quality management Syntax More sophisticated checks like parameter match etc. Code Inspector / Extended program check Coverage Runtime checks Dumps check environment of the error System log (SM21) ABAP dump analysis (ST22)
Syntax Check
Analyzer program flow find statements Screen processing
Performance analysis
ABAP runtime analysis (SE30) SQL Trace (ST05) Dynpro Trace (ST20) Debugger
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.
Static Checks Quality Management

Static checks Coverage Analyzer 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.
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.
Static Checks: Extended Program Check

From the ABAP editor you can access the extended program check
F1-help tests of each category
/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.
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.
Static Checks: Code Inspection from the ABAP Editor

ABAP Editor Code inspection from SE38: The code inspector executes a default test set for the selected program.
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
Static Checks/Code Inspector: Defining Check Runs

/nsci
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.
Static Checks/Code Inspector: Analyzing Results
Search run (find sy-subrc) finished The result contains all source lines found and all errors which occurred during searching.
Navigate to the source line

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)
10
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
11
Static Checks: Code Inspector Exercise

Exercise 1: Use the code inspector to run the extended program check or syntax check for all our test programs. They all start with ZTSTECHED02* .
The code inspector can be used to run the extended program check for all your programs to get an overview of the current quality level.
12
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.
13
Coverage Analyzer
SAP Easy Access
/nscov
Make sure that the coverage analyzer is running properly on your server before testing!
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
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
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
Tools for ABAP Programs (I)

static checks Syntax Check Extended Program Check(SLIN) Code Inspector runtime checks post mortem analysis System log (SM21) ABAP dump analysis (ST22) runtime analysis traces ABAP runtime analysis (SE30) SQL Trace (ST05) Dynpro Trace (ST20) detailed runtime analysis
ABAP Debugger
17
Post Mortem Error Analysis: System Log
/h SM37
My batch job crashed after 7 hours. Which tool is a good starting point?
ST22
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)
18
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
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
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
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
Dump Analysis ST22
Which information is available in the dump display?
Dump overview: Press F6 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
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 FRANKM FRANKM FRANKM Clt X Error ID
12.07.1999 11:47:01 pawdf025 12.07.1999 11:48:11 pawdf025 12.07.1999 11:51:17 pawdf025
000 C CALL_FUNCTI 000 C CALL_FUNCTI 000 C CALL_FUNCTI
Please check if all dumps occur on one machine or only one user is involved
24
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
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
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
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 Function group SAPLS_IMG_TOOL_5
current include LSVIMF59
External perform External perform perform abc in program xyz.
current event form VIM_BC_LANGU_ADD. 330 --> faulty source line endform.
28
Dump Analysis
(4) Contents of system fields / Chosen variables
Read the hexcode 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
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
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.
31
Dump Analysis Exercise (DUMP TABLE_INVALID_INDEX)
Exercise 2: If you run report ZTSTECHED02_ST22 you get the DUMP TABLE_INVALID_INDEX. (Remember the introducing story.) Please do not debug the program. Only analyzing the Dump text is allowed. Find out why this DUMP occurred and how the program should be corrected.
32
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!)
33
Runtime Analysis Traces

ABAP Debugger
34
ABAP Runtime Analysis: Motivation
Where does this message come from? I want to know the exact source line of the message statement.
35
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
36
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: Modul. units: Internal tables: File handling: Others: Select, Exec SQL, Module, CALL Function, CALL Screen, CALL Transaction, CALL Dialog Append, Collect, Sort, Read Table, Read Dataset Transfer, Open Dataset 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.
37
ABAP Runtime Analysis: Start the ABAP Trace

Start the Runtime Analysis via: Menu: System -> Utilities -> Runtime Analysis -> Execute Transaction: /nSE30
Insert the transaction, program or function you want to trace. Or start the trace for a parallel session
Maintain the trace restrictions in a variant
38
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.
39
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.
40
ABAP Runtime Analysis: 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.
41
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.
42
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)
43
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)
44
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.
45
ABAP Runtime Analysis: Trace a Parallel Process (II)

Ensure that you run SE30 on the same server as the running batch job! Switch on/ off the trace for the marked process
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)
46
ABAP Runtime Analysis: Trace a Parallel Process (III)
Analyze the trace file
Looks like an endless loop!
47
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.
48
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: aggregation By call: None: full aggregation for the selected statements if the source position differs -> no aggregation no aggregation at all.
Profile parameter abap/atrasizequota and your variant settings limit the maximum trace file size
49
ABAP Runtime Analysis: Demo
Demo
50
ABAP Runtime Analysis: 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.
51
ABAP Runtime Analysis: Performance Problems Hit List I

Filter variant: all parts of the program only modules aggregation by call
Filter variant: Only form MSG_NR default statements aggregation by call
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!
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.
52
ABAP Runtime Analysis: 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.)
53
ABAP Runtime Analysis: Exercises

Exercise 4a Run the SE30 trace for the 2nd performance killing form MAX_MSGNR (program: ZTSTECHED02_SE30_PERF) as well. Try to understand why the performance of this form is so poor. Compare this with the trace of the same form MAX_MSGNR in program ZTSTECHED02_SE30_PERF_OPT.
Exercise 4b (optional) Run the SE30 trace for the form NUMBER_OF_MESS (program: ZTSTECHED02_SE30_PERF) as well. (Switch on the internal-table statements in your restriction variant.) Compare this with the trace of the same form NUMBER_OF_MESS in program ZTSTECHED02_SE30_PERF_OPT. Why is the performance of the LOOP in the optimized program so much better?
54
ABAP Runtime Analysis: 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.
55
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,
56
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).
57
Dynpro Trace Available Info

Trace level 1 severe errors only Trace level 2 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 Trace level 3 field contents conversion exits field exits global fields set/get parameter modify screen batch input processing screen resize screen compression subscreen tree
58
Runtime Analysis Debugger

ABAP Debugger
59
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.
60

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)
61
Debugger: SE37 Demo

Function module
Z_DEBUG_SE37 SE37 Button Single Test.
1 2 3 4 5 6 7 8 9 10 11 12 13 function z_debug_se37. *"----------------------------*"*"Lokale Schnittstelle: *" IMPORTING *" VALUE(MY_IMPORT) *" EXPORTING *" VALUE(MY_EXPORT) *"----------------------------my_export = 123. write: / my_import. endfunction.
Where is the output ?? My_export should be 123 ??
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.
62
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
63
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
64
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 !
65
Debugger: Start Debugging with a Shortcut

Create the shortcut with a SAPGUI higher than 4.5A
Generate Shortcut on the desktop
Select SystemCommand from the pull-down menu Insert the debug command (/h or /hs)
Confirm with OK and the shortcut will be placed on the desktop

66
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!
67
Debugger: Navigation in the Source Code
Increase program section size Step to current statement Scroll source code
Control buttons
F8 F7 F6 F5
Continue (Beginning with 4.5: Continue until cursor)
Return
Execute
Single Step
Navigate through the coding:

Single step: Execute: Return: Continue: watchpoint, one single statement will be processed (functions, forms, etc. will be entered) one single statement will be processed (functions, forms, etc. are treated as one command) all remaining statements of the current routine will be processed until its end is reached all remaining statements will be processed until the next breakpoint or 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.
68
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)
69
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)
70
Debugger: Display Data in the Debugger

(2) Doubleclick (1) Hex- Display Press the magnifier icon.
VIEW: SINGLE FIELD
(3) Doubleclick
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 Structured field Internal table (Ctrl + F2) (Ctrl + F3) (Ctrl + F4)
71
Debugger: Display Data in the Debugger
(1) Doubleclick
(2) Doubleclick
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.
72
Debugger: Manipulation of Variables

Each value displayed can be changed as well
edit the value (1) click the pencil icon afterwards (2)
(2) change
(1) edit
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.
73
Debugger: Manipulation of Internal Tables

Scroll Buttons for switching between the columns Search Buttons for searching in the internal table Delete the title if you want to hide the column (This does not delete the column.)
Header line (WA)
Columns
Choose the table operation you want to perform

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
74
Debugger: Exercise (Change Variables)

Exercise Get comfortable with the display and change features of internal tables. Use itab[] in ZTSTECHED02_DEBUG_DISPLAY, form FILL_ITAB (after the SELECT) as an example. Display the list output after each WRITE statement. (You may set a breakpoint at the statement WRITE to access the first WRITE Menu: Breakpoint -> Breakpoint AT -> Statement)
Optional task: Start ZTSTECHED02_SE30_JOB via transaction SA38 as a background job. (Start time: immediately). You remember this was the program which never ends and which we traced with SE30. Now we would like to debug it. Step to transaction SM50 find the batch process where the program is running. Mark this line and jump into the debugger. (Menu: Program/Mode ->Program -> debugging). Change the variable I in the debugger so that the program can finish. Verify in sm50 that the program finished and our program no longer occupies the batch process.
75
Debugger: Display ABAP Objects

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.
Doubleclick
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!
76
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.
77
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 conversionexits. The runtime will not stop there. You have to test your exits in an isolated test environment. (SE37)
78
Debugger: Dynamic Breakpoints
You can activate and deactivate breakpoints temporarily
You may want to save the breakpoints for the next debugging session
Choose the criteria you want to set a breakpoint at
Set breakpoint at:

Statement, e.g. select. You will find breakpoints at all select and (open/fetch) cursorstatements 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.
79
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.
80
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.
81
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.
Watchpoint: Matnr = 1234
Program flow Matnr = 0000

Matnr = 0120
Matnr = 1234
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.
82
Debugger: Creation of Watchpoints

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
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.
83
Debugger: Exercise
Run transaction SE09: Where does the pre-set USER = GEBHARDT come from?
1. 2. 3. Get the ABAP field name
(TRDYSE01CM-USERNAME)
Start SE09 in debug mode (SE93) and set a watchpoint on the field. 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
84
Demo
Demo
Demo: watchpoint on a table header. (report ZTSTECHED02_DEBUG_ITAB) Each internal table has a header which contains administration data like number of lines. If, e.g., someone deletes lines or appends lines, then this header is updated. It is possible to set a watchpoint on the table header. This is very helpful if you want, e.g., find the source line where an internal-table line is deleted. But keep in mind that modifications of the contents in a line have normally no effect on the table header. There is some more info stored in the table header (like the loop counter); therefore don't be too astonished if the program stops, e.g., at a LOOP statement. Watchpoints on table headers in different releases: < 40B 40B 45 since 46 itab-*sys* itab[] itab[]+0(128) *itab[] (header is only filled when table is not initial!)
Since release 46 the table header is no longer stored directly in the addressable memory. Only a table reference (8bytes) remains in the memory addressable by the user. This table reference is a pointer which points to the header information. The table reference can be displayed by &itab[]. 85 (The same syntax */& is used for object, string and data references.)
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
86
Debugger: Settings System Debugging

System Debugging on/off (/hs)
System programs are outlined by blue color in the call stack. System programs are skipped during debugging if you dont use system debugging.
SE38/Attributes /Display
System debugging can be switched on via menu Settings or by /hs in the OKcode 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.
87
Debugger Settings Update Debugging
Asynchronous update - Whats that ?

CALL FUNCTION ABC IN UPDATE TASK EXPORTING ... COMMIT WORK. Dialog WP
FUNCTION ABC . ... UPDATE ZDEBARFC. ... ENDFUNCTION.

Update 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.
88
Debugger Settings Update Debugging
Why do I need Update debugging ?

Debugger Update is launched
COMMIT WORK
The debugger is attached to one process and cannot jump to the update process
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.
89
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.
90
Debugger: Monitor Memory Consumption
How can I find the major memory consumer of the greedy program?
Your process alone allocated ztta/roll_area + EM + HEAP~ 270 MB.

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 sytabix 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 "
91
Debugger: Monitor Memory Consumption Release > 45B
If you are able to debug the memory consuming program, you can use the ITABTOP25 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.
92
Debugger: Monitor Memory Consumption 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)
93
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
94
Questions?
Q&A
95
Feedback
Please complete your session evaluation and drop it in the box on your way out.
Thank You !
The SAP TechEd 03 Basel Team
96
Copyright 2003 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix and Informix Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries. ORACLE is a registered trademark of ORACLE Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.
97

ABAP Troubleshooting

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ABAP Troubleshooting

Enviado por

Direitos autorais:

Formatos disponíveis

ABAP Troubleshooting

Boris Gebhardt Erik Sodtke

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

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

Tools for ABAP Programs - Agenda

Organisation of the tools:

Run time checks

Tools for ABAP Programs - Overview

Analyzer program flow find statements Screen processing

Static Checks Quality Management

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

Static Checks: Extended Program Check

F1-help tests of each category

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

Static Checks: Extended Program Check

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

Static Checks: Code Inspection from the ABAP Editor

Code inspector is available with WEB AS 6.10

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

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

You can define your own:

Static Checks/Code Inspector: Defining Check Runs

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

The code inspector provides an open architecture for ABAP tests.

Some remarks to the object selection:

Static Checks/Code Inspector: Analyzing Results

Navigate to the source line

Code Inspector Tips & Tricks

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

Static Checks: Code Inspector Exercise

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

Coverage Analyzer is available with WEB AS 6.10

Coverage Analyzer Global View (QM)

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

Coverage Analyzer Detail View

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

Tools for ABAP Programs (I)

Post Mortem Error Analysis: System Log

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

The syslog is helpful if you encounter:

Post Mortem Error Analysis: System Log Remark

Additional useful selections

Post Mortem Error Analysis: System Log

Double-click for details

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

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

Post Mortem Analysis: Dump Analysis

Lock a dump to ensure that it will not be deleted automatically

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

Dump Analysis ST22

Which information is available in the dump display?

Dump overview: Press F6 in the dump display

SAP BASIS >= 46D

SAP BASIS < 46D

Dump Analysis Systematic Steps

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

12.07.1999 11:47:01 pawdf025 12.07.1999 11:48:11 pawdf025 12.07.1999 11:51:17 pawdf025

000 C CALL_FUNCTI 000 C CALL_FUNCTI 000 C CALL_FUNCTI

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

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

Collect the information regarding the System environment

Collect the information regarding the user and transaction

(2) Error analysis / How to correct the error