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

Presentation Server
The transaction steps are numbered as follows.

1. 2.

Sending the user request to the application server. Placing the user request in the dispatcher queue if all R/3 work processes are occupied. Assigning the user request to an R/3 work process. Rolling the user context in to the R/3 work process. Attempting to satisfy the SQL statement from the R/3 buffer.

Dispatcher 2 3

3. 4.

Disp Que
Roll Buffer

13

R/3 Work Process

4
User context

Application Server

5.

6.
7. 8.

Sending the SQL statement to the database server.

Attempting to satisfy the SQL statement from the database buffer. Importing from the database the data blocks missing in the database buffer. Displacing data blocks from the database buffer. Sending the results of SQL statements to the application server. Changing buffered table content following database table changes. Rolling the user context out of the R/3 work process. Sending the results of the user request to the presentation server.

12 Roll File
R/3 database interface

5 11

R/3 Table Buffer

9. 10.

10

9
Database Process Database Buffer

11. 12.

Database Server
13.

R/3 CLIENT/SERVER ARCHITECTURE

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

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

Data transfer (block size):

Front-end and Application server Application server and database server 2 KB 32 KB

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

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 Direct read Accesses that change data 10 ms 5 ms 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

Network

Wait time

Roll in

Load Time

Processing Time

Roll Wait time

N E T W O R K

Database Time

Response Time
Presentation Server

Application Server
Database Server

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 database server processing, (DB time > 40 %) perform an SQL Performance Trace.

SQL PERFORMANCE TRACE

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 Trace-Details
Application Server ABAP Program SELECT <field list> FROM vbak WHERE SQL Trace File

R/3 database interface

R/3 table buffering

Data records Database Server

Database files

Database Process

Database buffer

Various Operation In R/3-DB interface

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

SAP Cursor cache

DB Cursor available, no or yes?

Database interface
PREPARE in trace OPEN in trace FETCH in trace REOPEN in trace FETCH in trace

Data Records

Database Server DB SQL cache SELECT mandt FROM VBAK WHERE vbeln = :A1 DB cursor cache A1 Databuffer

Shared memory of the database server

Overview Database SQL cache

DBMS
Database Server Memory
SELECT FROM MARA WHERE.

Data Buffer

Data Blocks (e.g. 8 KB blocks)

DB SQL Cache
R/3 work process

DB Work process

SQL statements with access strategy

Data Base
Database files

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 database performance

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?

Problem classification: Unsuitable Access path

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

Problem classification: Unsuitable Access path

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
Table & Index Statistics

Estimated Costs
SELECT STATEMENT

TABLE ACCESS FULL

Full Table Scan

Cost-based database optimizer

SELECT STATEMENT

SELECT STATEMENT INDEX RANGE SCAN Index access

INDEX UNIQUE SCAN

Overview Suitable Access path

Reducing columns to be transferred Columns corresponding to SELECT clause MANDT Reducing rows to be transferred VBELN OBJNR ERNAM

001 001 001 001 001

001 001 001 002 002 002

000013245 000013246 000013247 000013248 000013249

0000113245 0000113251 0000113252 0000113250 0000013251 0000013252

65487878 69411151 67415441 21702720 68414141

98535153 52525256 32556462 24152562 97653545 54262665

ERNIE FRED JOE VIV SAR

NIRA BERT SIM JIME AMM BAB

Data records corresponding to WHERE clause

Search range (area of table that needs to be searched for required records)

UNSUITABLE ACCESS PATH

Introduction to DB indexes Technical Problems Changing the ABAP Coding Using Database Hints

Index Introduction
Table block
ROW ID MANDT VBELN ERDAT ERZET ERNAM

Index B* tree
Root tree

62522 65873

001 002

0000123 04005199 085123 TOM 0000546 01829742 210429 MICK

Branch blocks

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

Root and branch blocks contain pointers to the next index level Leaf blocks

MANDT 001 001 001 001 001 002 002

VBELN 0000121 0000122 0000123 0000124 0000125 0000126 0000127

ROW ID 65332 65252 Index block 62522 62525 62390 95252 95452

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

Secondary Indexing
Secondary Indexes
Table SCOUNTER
SELECT * FROM SCOUNTER WHERE AIRPORT = LCY.
AIRPORT P MANDT CARRID COUNTNUM AIRPORT

Binary search

ACA ACE BER BER DEN FRA HAM LCY LCY LGW LHR LHR MUC RTM

1 2 3 6 7 8 14 4 9 10 5 11 12 13

001 001 001 001 001 001 001 001 001 001 001 001 001 001

LH BA UA LH BA LH AA LH BA LH LH BA LH LH

00000005 00000004 00000001 00000002 00000003 00000007 00000001 00000003 00000001 00000001 00000004 00000002 00000006 00000008

ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM

Secondary index via AIRPORT

SAP AG

Index Unique Scan

SELECT * FROM VBAK WHERE VBELN = 0000123 ENDSELECT.

Table blocks
ROW ID MANDT VBELN 62522 65873 001 002 ERDAT ERZET ERNAM

Unique index
(Primary index or Unique secondary index)

Branch

0000123 04005199 085123 TOM 0000546 01829742 210429 MICK

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

Index blocks

MANDT 001 001 001 001 001 002 002

VBELN 0000121 0000122 0000123 0000124 0000125 0000126 0000127

ROW ID 65332 65252 62522 62525 62390 95252 95452

Table access using ROW ID 4 blocks maximum must be read

Index Range Scan

SELECT * FROM VBAP WHERE VBELN = 0000123 ENDSELECT. ROW ID MANDT VBELN POSNR MATNR 6 ROW ID MANDT VBELN POSNR MATNR 75892 001 0000163 04006149 055123 95883 002 0000646 03429737 310529

Primary index (unique) 2

65872 65873

001 002

0000123 04005199 085123 0000546 01829742 210429

MANDT 001 001 001 001 001 002 002 VBELN 0000121 0000123 0000123 0000123 0000124 0000126 0000127

POSNR ROW ID 0001 65332 0001 65252 0002 62522 0003 62525 0004 62390 0005 95252 0006 95452

4 MANDT VBELN POSNR ROW ID 001 0000121 0001 65332 001 0000122 0001 65252 Index search string: 0010000123%

Full table Scan

SELECT * FROM VBAP WHERE MATNR = 000815 ENDSELECT. Table VBAP ROW ID MANDT VBELN 65873 002 POSNR MATNR

Index

0000546 01829742 210429

ROW ID MANDT VBELN 75892 95883 001 002

POSNR

MATNR

0000163 04006149 000815 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 310529 ROW ID MANDT VBELN POSNR MATNR 75892 001 0000163 04006149 055123 95883 002 0000646 03429737 000815

to DB In

Concatenation
SELECT * FROM VBAP WHERE VBELN IN ( 0000123, 0000133, 0000143). ENDSELECT. ROW ID MANDT VBELN POSNR MATNR ..

MANDT 001 001 001 001 001 002 002 VBELN 0000121 0000122 0000123 0000124 0000125 0000126 0000127

Primary index (unique)

65872 65873 53552

001 002 002

0000123 04005199 085123 0000546 01829742 210429 0000353 04444442 253535

POSNR ROW ID 0001 65332 0001 65252 0002 62522 0003 62525 0004 62390 0005 95252 0006 95452

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

MANDT VBELN POSNR ROW ID 001 0000121 0001 65332 001 0000122 0001 65252

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

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.

Missing WHERE Conditions (1)

SELECT bukrs belnr gjahr
FROM bkkpf INTO TABLE g_itab_bkkpf WHERE belnr = 0000000100 Specific index fields: MANDT, BELNR => gap in index search string Index search string: 00,1 0000000100

Ineffective use of Index

SELECT bukrs belnr gjahr FROM bkkpf INTO TABLE g_itab_bkkpf WHERE bukrs = 0001 AND belnr = 0000000100 Specific index fields: MANDT, BUKRS, BELNR => index fields specified fully Index search string: 001 0001 0000000100

Effective use of Index

Missing Where condition(2)

SELECT vbeln erdat FROM vbak CLIENT SPECIFIED INTO TABLE g_itab_vvbak WHERE vbeln = 0000000100 Specific index fields: VBELN => index fields not specified Index search string: 0000000100

Ineffective use of Index

SELECT vbeln erdat FROM vbak INTO TABLE g_itab_vvbak WHERE vbaln = 0000000100 *or SELECT vbeln erdat FROM vbak CLIENT SPECIFIED INTO TABLE g_itab_vvbak WHERE mandt = sy-mandt AND vbeln = 0000000100 Specific index fields: MANDT, VBELN => index fields specified fully Index search string: 001 0000000100

Effective use of Index

Critical Operators NOT and <>

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 (BETWEEN, LIKE, > and <)

Critical Operator: Between ,LIKE , < and >

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

BETWEEN operator
SELECT vbeln erdat erzet FROM v v b a k INTO TABLE g_itab_v v b a k WHERE vbeln IN (0000000001, 0000000002, 0000000003, 0000000004, 0000000005).

IN operator
Replace WHERE field LIKE value with WHERE field = value
Omit WHERE field LIKE %

Sort at Database Level or in ABAP?

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 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

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 Typing
Type of field Identifier customer number Organizational unit Sales organization Status Delivery Status Classifier Order type Text field Name Date and Time Posting Date BUDAT ++ KNA1-NAME1 VBAK-AUART VBUK-LFSTK ++/-VBAK-VKORG Example KNA1-KUNNR Selectivity ++

Changing Index Design : Selectivity Analysis

Using Database Hints

Database HINT
SELECT * from vvbap INTO TABLE g_itab_vvbap WHERE ABGRU IN (01,02,03,04,05) %_HINTS ORACLE index(VVBAP VVBAP~

Database hints in OPEN SQL

Examples of database hints: FULL (Table) INDEX(Table) : Full table scan over one table : Index range scans with lower costs

INDEX (TableIndex) : Index range scan over one index FIRST_ROWS ALL_ROWS : Use the access path that returns the first records as fast as possible : Use the access path that returns all records a fast as possible

Pool and Cluster tables

Depending on how they are physically implemented, the ABAP dictionary has three categories of tables: Transparent, Pooled and Clustered
LOGICAL VIEW TRANSPARENT TABLES
TAB_B

CLUSTER TABLES
CLUST_A

POOLED TABLES POOL_A

POOL_B

CLUST_B

PHYSICAL VIEW

DATABASE TABLES

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 Table
Cluster table TABA TIMESTAMP
Table cluster

PAGELG

AA

TABAB

A Key fields A Cluster table TABB

B B

0 1

C G

D H

E I

F J

F A B E

G Cluster key VARDATA field PAGNO Structure description of VARDATA field

Key fields

Selective Access to Cluster Tables

SELECT bukrs belnr gjahr kunnr FROM bseg INTO TABLE g_itab_bsid WHERE bukrs = 0001 AND belnr = 0000000022.

SQL statement in ABAP

SELECT 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

Unselective Access on Cluster Tables

UNSELECTIVE ACCESS SELECTIVE ACCESS

SELECT bukrs belnr FROM bseg INTO TABLE g_itab_bsid WHERE kunnr = 0000000100. SELECT MANDT,BUKRS,.. FROM RFBLG

SELECT bukrs belnr FROM bsid INTO TABLE g_itab_bsid WHERE KUNNR = 0000000100 SELECT BURKS, MANDT, FROM BSID

WHERE MANDT = :A0

ORDER BY MANDT, BUKRS,

WHERE MANDT = :A0

AND KUNNR = :A1.

Pooled table
Pooled table TABA DATALN Table pool TABAB A B C D

TABA Key Pooled table TABB

C F

D G H I

TABB

TABNAME

VARKEY

VARDATA

Key

Selective Access on Pooled Tables

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 SQL STATEMENTS IN ABAP SQL STATEMENTS AT DB LEVEL

SELECT kappl kschl vkorg vtweg matnr FROM aa005 INTO TABLE g_itab_aa005
WHERE kappl = CS and kschl = SAPZ AND vkorg = 0001 AND vtweg = 01 AND kunnr = 0000000009 AND matnr = 000000000000000027

SELECT TABNAME, VARKEY, DATALN, VARDATA

FROM KAPOL WHERE TABNAME = :AO AND VARKEY 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.

Un Selective Access on Pooled Tables

SELECT kappl, kschl, vkorg FROM aa005 INTO TABLE g_itab_aa005 WHERE matnr =000000000000000027. SELECT TABNAME, VARKEY FROM KAPOL WHERE TABNAME = :AO AND VARKY LIKE : A1 ORDER BY TABNAME, . .

Unselective access
AA005 fully buffered on application server Repeated database read is not necessary Remove AA05 from table pool KAPOL and create index for MATNR Efficient data read is possible

Selective access

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
Full Buffering
Database table SCOUNTER
MANDT CARRID COUNTNUM AIRPORT

Buffer contents
001 001 001 001 001 001 001 001 001 001 001 001 001 001 AA BA BA BA BA LH LH LH LH LH LH LH LH UA 00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001 ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM

001 001 001 001 001 001 001 001 001 001 001 001 001 001

AA BA BA BA BA LH LH LH LH LH LH LH LH UA

00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001

ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM

Application server SELECT * FROM SCOUNTER WHERE MANDT = 001 AND CARRID = LH AND COUNTNUM = '00000004'.
R

SAP AG

Generic Buffering
Generic Buffering
Database table SCOUNTER
MANDT CARRID COUNTNUM AIRPORT

Buffer contents
001 001 001 001 001 001 001 001 LH LH LH LH LH LH LH LH 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 BER DEN FRA LCY LGW LHR MUC RTM

001 001 001 001 001 001 001 001 001 001 001 001 001 001

AA BA BA BA BA LH LH LH LH LH LH LH LH UA

00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001

ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM

Application server

Generic key
SAP AG

SELECT * FROM SCOUNTER WHERE MANDT = 001 AND CARRID = LH AND COUNTNUM = '00000004'.
R

Single Record Buffering

Single-Record Buffering
Database table SCOUNTER
MANDT CARRID COUNTNUM AIRPORT

Buffer contents
001 LH 00000004 LCY

001 001 001 001 001 001 001 001 001 001 001 001 001 001

AA BA BA BA BA LH LH LH LH LH LH LH LH UA

00000001 00000001 00000002 00000003 00000004 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000001

ACA ACE BER LCY LHR BER DEN FRA LCY LGW LHR MUC RTM HAM

Application server
SELECT SINGLE * FROM SCOUNTER WHERE MANDT = 001 AND CARRID = LH AND COUNTNUM = '00000004'.
R

SAP AG

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 %), 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 database server processing, (DB time > 40 %) perform an SQL Performance Trace.

Runtime Analysis Overview

Application Server
ABAP Trace File

ABAP runtime environment SET RUNTIME ANALYZER ON LOOP AT itab ENDLOOP SET RUNTIME ANALYZER OFF

Local Trace File

The three phases of the ABAP runtime analysis:

Limiting the analysis Obtaining the run data Evaluating the results

Limiting the Analysis

Limiting the Analysis

Gross Net

SELECT PERFORM READ TABLE

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