ABAP OPTIMIZATION

ABAP OPTIMIZATION AND

PERFORMANCE TUNING

Contents

• ANALYZING INDIVIDUAL OBJECTS

• DATABASE ACCESSES

OBJECTIVE

• To understand the performance issues in ABAP programming

• To monitor ABAP performance using SAP Tools• To analyze ABAP performance problems• To solve ABAP performance problems causing

– High Database Load– High CPU Load

Examples for Scalability• 5,000 concurrent users at US customer (ca. 3,000 in SD)• More than 47,000 highly active users (SD) in a benchmark test• 161 application servers connected to 1 database in a benchmark

test • 4 terabyte disk size at an engineering & construction company• Processing requirements:

– 50,000 payroll calculations in one hour– 1.2 million SD deliveries per week– 30,000 CO invoice items per day

• Greengrocer in Hamburg with five users and a laptop

Analyzing Transaction Steps

• The transaction steps are numbered as follows.

1. Sending the user request to the application server.

2. Placing the user request in the dispatcher queue if all R/3 work processes are occupied.

3. Assigning the user request to an R/3 work process.

4. Rolling the user context in to the R/3 work process.

5. Attempting to satisfy the SQL statement from the R/3 buffer.

6. Sending the SQL statement to the database server.

7. Attempting to satisfy the SQL statement from the database buffer.

8. Importing from the database the data blocks missing in the database buffer.

9. Displacing data blocks from the database buffer.

10. Sending the results of SQL statements to the application server.

11. Changing buffered table content following database table changes.

12. Rolling the user context out of the R/3 work process.

13. Sending the results of the user request to the presentation server.

Disp Que

Dispatcher

R/3 database interface

User context

R/3 Work Process

Roll File

Roll Buffer

R/3 Table Buffer

Database Process

Database Buffer

2

6 10

5

11

4

12

3 13

Presentation Server

Application Server

7 8

9

Database Server

• Average Data access Time (per record): – R/3 buffers on application server 0.1 ms– Database buffer 1 ms– Disk 10 ms

• Memory allocation:– R/3 work process 5 MB– R/3 table buffers 120 MB – Data buffers of database 500 MB– Database on disks Several terabytes

• Data transfer (block size):– Front-end and Application server 2 KB– Application server and database server 32 KB

• The Database layer, as the central data repository, is not scalable

R/3 CLIENT/SERVER ARCHITECTURE

Steps for Performance Tuning• Single Statistics Records for a transaction step

– Transaction STAT–

Tools>>Administration>>Monitor>>Performance>>Workload>>Statistics Record

• Average database time (per record) for reference– Sequential read 10 ms– Direct read 5 ms– Accesses that change data 20 ms

• Response time, Dispatcher wait time, CPU time, DB Req. time – Helps decide whether SQL Performance Trace or ABAP

Runtime analysis is required

Various Times Recorded in STAT

CPU Time

Database Time

Database Server

Application Server

Response Time

Roll

in

LoadTime

Processing Time

Roll Wait time

Wait time

PresentationServer

Network

NETWORK

Result Analyzing of STAT Tool To analyze individual objects such as programs and transactions. First examine

the statistics records for each transaction step. Remember to perform the

analysis under production-like conditions (with representative data and, in the

production system, with representative user activity).

If in the single statistics records you find that much CPU time is used ( > 40 %),

look for optimization potential in application server processing (for example,

processing internal tables) using the ABAP runtime analysis.

If in the single statistics records you find that there is a problem during If in the single statistics records you find that there is a problem during

database server processing, (DB time > 40 %) perform an SQL Performance database server processing, (DB time > 40 %) perform an SQL Performance

TraceTrace..

SQL trace A record of SQL statements that access the database

system

Buffer trace A record of data requests that access buffered tables

Enqueue trace A record of enqueue requests received by the enqueue

server

RFC trace A record of received and sent Remote Function Calls

SQL PERFORMANCE TRACE

SQL Trace-Details

Application Server

SQL Trace File

ABAP Program

SELECT <field list> FROM vbakWHERE… R/3 table R/3 database interface buffering

Data records

Databasebuffer

Database Server

Database Process

Databasefiles

Various Operation In R/3-DB interface

Application Server ABAP Program SELECT Fieldlist FROM vbak WHERE vbeln = ‘0000000100’.

DB Cursor available, no or yes?

SAP Cursor cache

Database interfacePREPARE intrace

OPEN in trace

FETCH in trace

REOPEN intrace

FETCH intrace

Database Server

Shared memory of the database server

DB SQL cacheSELECT mandt…FROM VBAKWHERE vbeln = :A1

DB cursor cache A1

Databuffer

Data Records

Overview Database SQL cache

Data Buffer

Data Blocks (e.g. 8 KB blocks)

DB SQL Cache

SQL statements with accessstrategy

Database filesData Base

DB WorkprocessR/3 work

process

SELECT FROM MARAWHERE….

Database Server MemoryDBMS

Output of SQL Trace file

Indicators in Trace List for Expensive Statements

Indicators in trace list:

– Per database operation >= 200,000ms– Per SQL statement > = 10 FETCHES– Nested SQL Statements with the same strategy – > = 200,000 ms (for all SQL statements nested together)

Identical Selects:• Always avoid (instead, buffer in program, buffer beyond roll area limit)

• SQL statements that are similar in structure have an identical access strategy with possibly different values for the placeholders. The latter are also called identical selects.

• To display an overview of the SQL statements within a trace that are similar in value, choose Goto>>Identical Selects.

• • Identical SELECTS deliver an identical quantity of data records. Therefore it makes

sense to buffer the results in an internal table of the calling ABAP program.

• From the number of executions of SQL statements that are similar in value, you can determine the optimization potential. For example, if there are 4 value-similar executions on table VBAK, buffering the resulting data in an internal table makes 3 executions unnecessary. This represents an optimization potential of 75% for this SQL statement

Initial situation: You need to analyze a performance-critical individual object that shows poor databaseperformance

Compressed summary for the object

Trace list for the object

Are there SQL statements that take longer than 200,000 ms?

Problem classification: Unsuitable Access path

Are there SQL statements with more than 10 Fetches?


Are there nested SQL statements with the same structure that, as a group, take longer than 200,000 ms?


Identical SELECTs for individual objects

Are there SQL statements with the same values?

Problem classification: Change in Design

Cost Based Data Base Optimizer

Possible Access Paths

Full Table Scan Cost-based database optimizer

Index access

Table & Index Statistics

TABLE ACCESS FULL

SELECT STATEMENT

SELECT STATEMENT

SELECT STATEMENT

INDEX UNIQUE SCAN

INDEX RANGE SCAN

Estimated Costs

Reducing columns to be transferred

MANDT VBELN OBJNR ERNAM

Columns corresponding toSELECT clause

Reducingrows to betransferred

Data records corresponding toWHERE clause

Search range(area of table thatneeds to be searchedfor required records)

001 000013245 65487878 ERNIE001 000013246 69411151 FRED001 000013247 67415441 JOE001 000013248 21702720 VIV001 000013249 68414141 SAR

001 0000113245 98535153 NIRA001 0000113251 52525256 BERT001 0000113252 32556462 SIM002 0000113250 24152562 JIME002 0000013251 97653545 AMM002 0000013252 54262665 BAB

Overview Suitable Access path

UNSUITABLE ACCESS PATHIntroduction to DB indexes

Technical Problems

Changing the ABAP Coding

Using Database Hints

Index IntroductionTable block

ROW ID MANDT VBELN ERDAT ERZET ERNAM …

…62522 001 0000123 04005199 085123 TOM …65873 002 0000546 01829742 210429 MICK ……

The ROW ID acts as a pointer from the index to a table record

Root and branch blocks contain pointersto the next index level

Index B* tree

Root tree

Branch blocks

Leafblocks

Index block

MANDT VBELN ROW ID001 0000121 65332001 0000122 65252001 0000123 62522001 0000124 62525001 0000125 62390002 0000126 95252002 0000127 95452

Primary Index

The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database

Secondary Indexing

SAP AG

R

Secondary IndexesTable SCOUNTER

Secondaryindex viaAIRPORT

MANDT CARRIDCOUNTNUM AIRPORT001001001001001001001001001001001001001001

LHBAUALHBALHAALHBALHLHBALHLH

000000050000000400000001000000020000000300000007000000010000000300000001 0000000100000004000000020000000600000008

ACAACEBERLCYLHRBERDENFRALCYLGWLHRMUCRTMHAM

AIRPORT PACAACEBERBERDENFRAHAMLCYLCYLGWLHRLHRMUCRTM

1236781449105111213

SELECT * FROMSCOUNTER WHEREAIRPORT = ‘LCY’.

Binary search

Index Unique ScanTable blocks

ROW ID MANDT VBELN ERDAT ERZET ERNAM …

62522 001 0000123 04005199 085123 TOM …65873 002 0000546 01829742 210429 MICK ……

Unique index(Primary index orUnique secondary index)

Branch

Indexblocks MANDT VBELN ROW ID

001 0000121 65332001 0000122 65252001 0000123 62522001 0000124 62525001 0000125 62390002 0000126 95252002 0000127 95452

SELECT * FROM VBAK WHERE VBELN = ‘0000123’ENDSELECT.

Table access using ROW ID

4 blocks maximum must be read

ROW ID MANDT VBELN ERDAT ERZET ERNAM ……75892 001 0000163 04006149 055123 JIM …95883 002 0000646 03429737 310529 JOHN ……

Index Range Scan 5

ROW ID MANDT VBELN POSNR MATNR …

65872 001 0000123 04005199 085123 …65873 002 0000546 01829742 210429 …

…

1

2

3

MANDT VBELN POSNR ROW ID001 0000121 0001 65332001 0000123 0001 65252001 0000123 0002 62522001 0000123 0003 62525001 0000124 0004 62390002 0000126 0005 95252002 0000127 0006 95452

SELECT * FROM VBAP WHERE VBELN = ‘0000123’ENDSELECT.

Index search string: ‘0010000123%’

ROW ID MANDT VBELN POSNR MATNR ……75892 001 0000163 04006149 055123 …95883 002 0000646 03429737 310529 ……

Primaryindex(unique)

MANDT VBELN POSNR ROW ID001 0000121 0001 65332001 0000122 0001 65252…

4

6

5


65872 001 0000123 04005199 085123 …65873 002 0000546 01829742 210429 …

…

SELECT * FROM VBAP WHERE VBELN = ‘0000123’ENDSELECT.


to DB In


…65873 002 0000546 01829742 210429 …

…

Index

SELECT * FROM VBAP WHERE MATNR = ‘000815’ENDSELECT.


75892 001 0000163 04006149 000815’ …95883 002 0000646 03429737 310529 ……

Index not used for full table scan

Each table block is read once only

Max. no. of logical read accesses per execution = no. of table blocks


ROW ID MANDT VBELN POSNR MATNR ……75892 001 0000163 04006149 055123 …95883 002 0000646 03429737 000815’ ……

Table VBAP

Full table Scan

Concatenation


65872 001 0000123 04005199 085123 …65873 002 0000546 01829742 210429 …

53552 002 0000353 04444442 253535 ..

MANDT VBELN POSNR ROW ID001 0000121 0001 65332001 0000122 0001 65252001 0000123 0002 62522001 0000124 0003 62525001 0000125 0004 62390002 0000126 0005 95252002 0000127 0006 95452

SELECT * FROM VBAP WHERE VBELN IN ( ‘0000123’, ‘0000133’, ‘0000143’).ENDSELECT.

Index search string: ‘0010000123%’ and ‘0010000133%’ and ‘00010000143%’

ROW ID MANDT VBELN POSNR MATNR ……75892 001 0000163 04006149 055123 …

95883 002 0000646 03429737 310529 ……

Primaryindex(unique)

MANDT VBELN POSNR ROW ID001 0000121 0001 65332001 0000122 0001 65252…

Summary

Index Unique Scan: The index selected is unique (primary index or unique secondary index) and specified fully. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks need to be read.Index Range Scan: The index selected is unique or non-unique. In the case of a unique index, not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.Full Table Scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application reads each table record only once, the search results are concatenated, and duplicate entries are eliminated. The table records returned can range from none to all.

Specific index fields: MANDT, BELNR => gap in index search stringIndex search string: ’00,1 0000000100’

Ineffective use of IndexSELECT bukrs belnr gjahrFROM bkkpfINTO TABLE g_itab_bkkpfWHERE bukrs = ‘0001’AND belnr = ‘0000000100’

Specific index fields: MANDT, BUKRS, BELNR => index fields specified fullyIndex search string: ‘001 0000000100’ 0001

Effective use of Index

Missing WHERE Conditions (1)Missing WHERE Conditions (1)

SELECT bukrs belnr gjahr FROM bkkpfINTO TABLE g_itab_bkkpfWHERE belnr = ‘0000000100’

Missing Where condition(2)SELECT vbeln erdat FROM vbakCLIENT SPECIFIEDINTO TABLE g_itab_vvbakWHERE vbeln = ‘0000000100’

SELECT vbeln erdat FROM vbakINTO TABLE g_itab_vvbakWHERE vbaln = ‘0000000100’*orSELECT vbeln erdat FROM vbakCLIENT SPECIFIEDINTO TABLE g_itab_vvbakWHERE mandt = sy-mandtAND vbeln = ‘0000000100’

Specific index fields: VBELN => index fields not specifiedIndex search string: ‘0000000100’�

Ineffective use of Index

Specific index fields: MANDT, VBELN => index fields specified fullyIndex search string: ‘ 0000000100’001

Effective use of Index

• If fields in the WHERE clause are specified with operators NOT or<>, these WHERE conditions cannot be for a search over a database index. You should therefore formulate SQL statements positively wherever possible.

• If a positive formulation cannot be used, for example because the IN list would be too long, you should still specify the WHERE condition with NOT, in order to reduce the amount of data to transferred. An index search will not be performed, but the amount of data returned will be smaller.

Critical Operators NOT and <>

SELECT vbeln erdat erzet FROM v v b a k INTO TABLE g_itab_v v b a kWHERE vbeln BETWEEN ‘0000000001’ AND ‘0000000005’.

BETWEEN operatorSELECT vbeln erdat erzet FROM v v b a k INTO TABLE g_itab_v v b a kWHERE vbeln IN (‘0000000001’, ‘0000000002’, ‘0000000003’, ‘0000000004’, ‘0000000005’).

IN operator

Replace WHERE field LIKE value withWHERE field = value Omit WHERE field LIKE ‘%’

Critical Operators (BETWEEN, LIKE, > and <)

Critical Operator: Between ,LIKE , ‘<‘ and ‘ >’

SELECT vbeln erdat kunnr FROM v v b a kINTO TABLE g_itab_v v b a k WHERE vbeln IN g_vbeln ORDER BY PRIMARY KEY

Sort at DB level with Index

SELECT vbeln erdat kunnr FROM v v b a k INTO TABLE g_itab_v v b a k WHERE vbeln IN g_vbeln ORDER BY erdat DESCENDING

Sort at DB level without index

SELECT vblen erdat kunnr FROM v v b a k INTO TABLE g_itab_v v b a k WHERE vbeln IN g_vbeln SORT g_itab_v v b a k BY erdat DESCENDING

Sort in ABAP

Sort at Database Level or in Sort at Database Level or in ABAP?ABAP?

Creating/Changing Index • General rules• Disjunctive indexes only• No unintentionally used indexes• As few indexes as possible per table (as few

as possible,but as many as necessary)• Selection of index fields• As few fields as possible in index• As selective fields as possible in index• Selective fields as near to the beginning as

possible• Do not change SAP standard indexes unless

recommended by SAP

Change Index Design – Selectivity Analysis

Semantic TypingType of field Example Selectivity

Identifier KNA1-KUNNR ++

customer number

Organizational unit VBAK-VKORG

Sales organization

Status VBUK-LFSTK ++/--

Delivery Status

Classifier VBAK-AUART

Order type

Text field KNA1-NAME1 -

Name

Date and Time

Posting Date BUDAT ++

Changing Index Design : Selectivity Analysis

Database HINTUsing Database Hints

SELECT * from vvbap INTO TABLE g_itab_vvbap

WHERE ABGRU IN (’01’,’02’,’03’,’04’,’05’)

%_HINTS ORACLE “index(VVBAP “VVBAP~

Examples of database hints:

FULL (Table) : Full table scan over one table

INDEX(Table) : Index range scans with lower costs

INDEX (Table”Index”) : Index range scan over one index

FIRST_ROWS : Use the access path that returns the first records as fast as possible

ALL_ROWS : Use the access path that returns all records a fast as possible

Database hints in OPEN SQL

Pool and Cluster tables

LOGICAL VIEW

PHYSICAL VIEW

TRANSPARENT TABLES

CLUSTER TABLES POOLED TABLES

TAB_B CLUST_A

CLUST_B

POOL_A

POOL_B

DATABASE TABLES

Depending on how they are physically implemented, the ABAP dictionary has three

categories of tables: Transparent, Pooled and Clustered

Pooled and clustered tables group several logically defined tables from the ABAP dictionary

in a physical database table. In pooled tables, data is located in a table pool whereas in a

clustered pool, data is located in a table cluster.

Cluster TableCluster table TABA

A B C D

Cluster table TABB

A

A

B

B

E

H

F

I

G

J

Key fieldsA B

A B

0

1

C

G

D

H

E

I

F

J

TIMESTAMP PAGELG

Table cluster

TABAB

Cluster key VARDATA field

Structure description of

VARDATA fieldPAGNO

A

Key fields

SELECT bukrs belnr gjahr kunnr

FROM bseg

INTO TABLE g_itab_bsid

WHERE bukrs = ‘0001’

AND belnr = ‘0000000022’.

SQL statement in ABAPSELECT “ MANDT”, “BUKRS”, “BELNR”,”GJAHR”, “PAGENO”,”TIMESTMP”,”PAGELG”,”VARDATA”

FROM “RFBLG”

WHERE “MANDT” = :A0

AND “BUKRS” = : A1

AND “BE;NR” = :A2

ORDER BY “MANDT”, “BUKRS”, “BELNR”,”GJAHR”, “PAGENO”

SQL statement at DB level

Selective Access to Cluster Tables

SELECT bukrs belnr… SELECT bukrs belnr…

FROM bseg FROM “bsid”

INTO TABLE g_itab_bsid INTO TABLE g_itab_bsid

WHERE kunnr = ‘0000000100’. WHERE KUNNR = ‘0000000100’

SELECT “ MANDT”,”BUKRS”,.. SELECT “BURKS”, “MANDT”,…

FROM “RFBLG” FROM BSID

WHERE “MANDT” = :A0 WHERE “MANDT” = :A0

ORDER BY “MANDT”, “BUKRS”,… AND “KUNNR” = :A1.

UNSELECTIVE ACCESS SELECTIVE ACCESS

Unselective Access on Cluster Tables

Pooled table

A B C D

Pooled table TABA

Key

Pooled table TABB

Key

E F G H I

C D

F G H I

TABA

TABB

A B

E

Table pool TABAB

TABNAME VARKEY VARDATA

DATALN

SQL STATEMENTS IN ABAP SQL STATEMENTS AT DB LEVEL

SELECT kappl kschl vkorg vtweg matnr FROM aa005 SELECT “TABNAME’, “VARKEY”, INTO TABLE g_itab_aa005 “DATALN”, “VARDATA”

WHERE kappl = ‘CS’ and kschl = ‘SAPZ’ FROM “KAPOL”

AND vkorg = ‘0001’ AND vtweg = ‘01’ WHERE

AND kunnr = ‘0000000009’ “TABNAME” = :AO AND “VARKEY”

AND matnr = ‘000000000000000027’ LIKE :A1

ORDER BY “TABNAME”, “VARKEY”

The WHERE conditions in the SQL statement refer to key fields in table aa005. Therefore, all conditions are transferred to the database in field VARKEY. The database interface incorporates the ORDER BY clause for fields TABNAME and VARKEY which are key fields in the table pool.

Data is read from pooled table aa005. The SQL statement is transferred to the database interface and converted into an SQL statement for table pool KAPOL

Selective Access on Pooled Tables

SELECT kappl, kschl, vkorg SELECT “TABNAME’, ‘VARKEY”

FROM aa005 FROM KAPOL

INTO TABLE g_itab_aa005 WHERE “TABNAME” = :AO AND

WHERE matnr =‘000000000000000027’. “VARKY” LIKE : A1

ORDER BY “TABNAME”, . .

Unselective accessAA005 fully buffered on application server Remove AA05 from table pool KAPOL

and create index for MATNR

Repeated database read is not necessary

Efficient data read is possible

Selective access

Un Selective Access on Pooled Tables

Buffering Techniques• In a production system, the following tables rarely change

– Small tables– Tables that are mainly accessed for reading– Control tables, Customizing tables, or 'small' master data tables

• Check whether buffering allowed– No, if data must always be up-to-date (possible inconsistency within the

synchronization period)– No, if overhead due to displacement and synchronization is too high

(> 1% changes)• For effective use of the buffer

– Choose the right buffering type– Be aware that not all statements can make use of the buffer– Avoid displacement or synchronization

Buffering types

Buffering Types -Details• The buffering type determines which records of the

table are loaded into the buffer of the application server when a record of the table is accessed. There are the following buffering types:

• Full buffering: When a record of the table is accessed, all the records of the table are loaded into the buffer.

• Generic buffering: When a record of the table is accessed, all the records whose left-justified part of the key is the same are loaded into the buffer.

• Single-record buffering: Only the record that was accessed is loaded into the buffer.

Full Buffering

SAP AG

R

Full Buffering

Application serverSELECT * FROM SCOUNTER WHEREMANDT = ‘001’ AND CARRID = ‘LH’AND COUNTNUM = '00000004'.

Buffer contents0000000100000001000000020000000300000004 000000010000000200000003000000040000000500000006000000070000000800000001

AABABABABALHLHLHLHLHLHLHLHUA

001001001001001001001001001001001001001001


Database table SCOUNTERAIRPORTMANDT CARRID COUNTNUM

0000000100000001000000020000000300000004 000000010000000200000003000000040000000500000006000000070000000800000001


001001001001001001001001001001001001001001


Generic Buffering

SAP AG

R

Generic Buffering

Application server

Buffer contents

0000000100000002000000030000000400000005000000060000000700000008

LHLHLHLHLHLHLHLH

001001001001001001001001

BERDENFRALCYLGWLHRMUCRTM

Generic key

Database table SCOUNTERMANDT CARRID COUNTNUM

0000000100000001000000020000000300000004 000000010000000200000003000000040000000500000006000000070000000800000001


001001001001001001001001001001001001001001


AIRPORT

SELECT * FROM SCOUNTER WHEREMANDT = ‘001’ AND CARRID = ‘LH’AND COUNTNUM = '00000004'.

Single Record Buffering

SAP AG

R

Single-Record Buffering

Buffer contents

00000004 LH001 LCY

Database table SCOUNTERMANDT CARRID COUNTNUM

0000000100000001000000020000000300000004 000000010000000200000003000000040000000500000006000000070000000800000001


001001001001001001001001001001001001001001


AIRPORT

Application serverSELECT SINGLE * FROM SCOUNTER WHEREMANDT = ‘001’ AND CARRID = ‘LH’ ANDCOUNTNUM = '00000004'.

Table Buffering • IMPORTANCE:• Means of keeping the table data in the buffer of the application

server after the first access.• Buffering allows you to read the data from main memory next

time it is accessed, thus saving a further database access. Using buffered tables improves the performance considerably.

• STATEMENTS BYPASSING BUFFER:• SELECT DISTINCT• ORDER BY / GROUP BY / HAVING CLAUSE• ANY WHERE CLAUSE THAT CONTAINS A SUB QUERY OR IS

NULL EXPRESSION. • JOINS• A SELECT …………. FOR UPDATE

Result Analyzing of STAT Tool To analyze individual objects such as programs and transactions. First examine

the statistics records for each transaction step. Remember to perform the

analysis under production-like conditions (with representative data and, in the

production system, with representative user activity).

If in the single statistics records you find that much CPU time is used ( > 40 %), If in the single statistics records you find that much CPU time is used ( > 40 %),

look for optimization potential in application server processing (for example, look for optimization potential in application server processing (for example,

processing internal tables) using the ABAP runtime analysis.processing internal tables) using the ABAP runtime analysis.

If in the single statistics records you find that there is a problem during

database server processing, (DB time > 40 %) perform an SQL Performance

Trace.

Runtime Analysis Overview

Application ServerABAP Trace File

Local Trace File

ABAP runtime environmentSET RUNTIME ANALYZER ONLOOP AT itab…ENDLOOPSET RUNTIME ANALYZER OFF

The three phases of the ABAP runtime analysis: Limiting the analysis Obtaining the run data Evaluating the results

Limiting the Analysis

SELECT

PERFORM

READ TABLE

Gross Net

• Gross time is the total time required to execute the relevant functions.

• Net time is the gross time minus the time taken by any modularization units and separate statements (which can be limited in the ABAP runtime initial screen using variants).

•The net time is the time that is not otherwise accounted for.

• If the gross time is the same as the net time, these times are not indicated separately.

• You can display times either as a percentage or as absolute times in microseconds.

Initial situation: You need to analyze a performance-critical individual object that shows poor database performance

“Limit analysis” set to full aggregation with no other filter

Obtaining the run data in the current user session

Are there critical program parts ort statements that contribute more than 10% of the total runtime?

Limit analysis to not aggregated or aggregated per calling position, and limit filter to critical program parts or statements

Obtaining the run data in the current user session

Are there problems during the use of internal tables?

Internal table: Wrong Table Type or Wrong Access method

ABAP OPTIMIZATION

Documents

Transcript of ABAP OPTIMIZATION