8/3/2019 Tuning Optimization Concepts
1/119
July 10, 2010 1
Performance Tuning andOptimization Techniques -
Concepts
8/3/2019 Tuning Optimization Concepts
2/119
July 10, 2010 2
Agenda
Overview Analyzing Individual Objects :
o Analyzing transaction stepso SQL Performance Analysiso ABAP Runtime Analysis: Overviewo ABAP Debugger
Database Accesses :
o Overviewo Unsuitable Access Patho Suitable Access Path
8/3/2019 Tuning Optimization Concepts
3/119
July 10, 2010 3
Agenda
Internal Tables R/3 system Analysis
o Overviewo R/3 Workload Analysis
8/3/2019 Tuning Optimization Concepts
4/119July 10, 2010 4
R/3 Client / Server Architecture
8/3/2019 Tuning Optimization Concepts
5/119July 10, 2010 5
DBMS Architecture
8/3/2019 Tuning Optimization Concepts
6/119July 10, 2010 6
Analyzing Individual Objects
8/3/2019 Tuning Optimization Concepts
7/119July 10, 2010 7
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 workprocess.
4. Rolling the user context in to the R/3 workprocess.
5. Attempting to satisfy the SQL statement fromthe R/3 buffer.
6. Sending the SQL statement to the databaseserver.
7. Attempting to satisfy the SQL statement fromthe database buffer.
8. Importing from the database the data blocksmissing 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.
8/3/2019 Tuning Optimization Concepts
8/119July 10, 2010 8
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. timeHelps decide whether SQL Performance Trace or ABAP Runtime analysis isrequired
Analyzing transactionsteps
8/3/2019 Tuning Optimization Concepts
9/119July 10, 2010 9
Analyzing Transaction Steps: Response Time
Analyzing transactionsteps
8/3/2019 Tuning Optimization Concepts
10/119July 10, 2010 10
Analyzing Transaction Steps: Roadmap
Analyzing transactionsteps
8/3/2019 Tuning Optimization Concepts
11/119July 10, 2010 11
SQL traceo A record of SQL statements that access the database system
Buffer trace *o A record of data requests that access buffered tables
Enqueue traceo A record of enqueue requests received by the enqueue server
RFC traceo A record of received and sent Remote Function Calls
SQL Performance Trace :Basics
SQL T O i
8/3/2019 Tuning Optimization Concepts
12/119July 10, 2010 12
SQL Trace - Overview
8/3/2019 Tuning Optimization Concepts
13/119
July 10, 2010 13
SQL Performance Trace: DatabaseOperations
Problem Classification Roadmap
8/3/2019 Tuning Optimization Concepts
14/119
July 10, 2010 14
Problem Classification Roadmap
SQL Performance Trace Roadmap
8/3/2019 Tuning Optimization Concepts
15/119
July 10, 2010 15
SQL Performance Trace Roadmap
ABAP R i A l i
8/3/2019 Tuning Optimization Concepts
16/119
July 10, 2010 16
ABAP Runtime Analysis:Overview
Example Roadmap Runtime Analysis
8/3/2019 Tuning Optimization Concepts
17/119
July 10, 2010 17
Example Roadmap Runtime Analysis
ABAP
8/3/2019 Tuning Optimization Concepts
18/119
July 10, 2010 18
The debugger is used to identify errors in source code. There are some attributes of this toolthat are used for runtime analyses as well. It is used to run through an object step by step. Acommonly used function is to check for memory usage during statements that access largeinternal tables.For example, statements such as LOOP ATENDLOOP require extensive CPU time andincrease object runtime while slowing down the system at the same time. Checking the memoryuse of an internal table is therefore useful.To see how much memory is allocated for and used by an internal table, chooseSettings>>Table memory*from the ABAP Debugger screen. Place the cursor on the specific
table and choose Table.To display a list of the properties of internal tables accessed in the current program, chooseGoto>>System>>system areas, and in the Areafield, enter ITAB. (not the internal tablename)The resulting list displays information such as column width or the current number of rows.These can be used to calculate memory use.TIP: The debugger should only be used to investigate object performance in the development
or test system and not in the production system. This is because using the debugger maycause errors such as implicit database commits resulting in database inconsistencies.
ABAPDebugger
8/3/2019 Tuning Optimization Concepts
19/119
July 10, 2010 19
Database Accesses
D t b A O i C t b d
8/3/2019 Tuning Optimization Concepts
20/119
July 10, 2010 20
Database Accesses : Overview - Cost basedOptimizer
8/3/2019 Tuning Optimization Concepts
21/119
July 10, 2010 21
Overview: Database SQLCache
Overview Suitable / Unsuitable Access
8/3/2019 Tuning Optimization Concepts
22/119
July 10, 2010 22
Overview Suitable / Unsuitable Access
Overview
unsuitable Access path
8/3/2019 Tuning Optimization Concepts
23/119
July 10, 2010 23
Overview
unsuitable Access path
OverviewSuitable Access Path 1
8/3/2019 Tuning Optimization Concepts
24/119
July 10, 2010 24
Overview
Suitable Access Path 1
OverviewSuitable Access Path 2
8/3/2019 Tuning Optimization Concepts
25/119
July 10, 2010 25
Unsuitable Access Path Introduction to DB
8/3/2019 Tuning Optimization Concepts
26/119
July 10, 2010 26
Unsuitable Access Path - Introduction to DBIndexes: Overview (1)
Introduction to DB Indexes:
8/3/2019 Tuning Optimization Concepts
27/119
July 10, 2010 27
Introduction to DB Indexes:Overview (2)
Introduction to DB Indexes: Index
8/3/2019 Tuning Optimization Concepts
28/119
July 10, 2010 28
Introduction to DB Indexes: IndexUnique Scan
Introduction to DB Indexes: Index
8/3/2019 Tuning Optimization Concepts
29/119
July 10, 2010 29
Range Scan
Introduction to DB Indexes: Full
8/3/2019 Tuning Optimization Concepts
30/119
July 10, 2010 30
Introduction to DB Indexes: FullTable Scan
ROW ID MANDT VBELN POSNR MATNR 65873 002 0000546 01829742 210429 Index
SELECT * FROM VBAP WHERE MATNR =000815ENDSELECT.
ROW ID MANDT VBELN POSNR MATNR 75892 001 0000163 04006149 055123 95883 002 0000646 03429737 310529
Index not used for full table scanEach table block is read once onlyMax. no. of logical read accessesperexecution = 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 310529
Table VBAP
Introduction to DB Indexes:
8/3/2019 Tuning Optimization Concepts
31/119
July 10, 2010 31
t oduct o to de esConcatenation
Important Access Strategies for Tables
8/3/2019 Tuning Optimization Concepts
32/119
July 10, 2010 32
Important Access Strategies for Tables
Index Unique Scan: The index selected is unique (primary index or unique secondaryindex) 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 uniqueindex, not all index fields are specified in the WHERE clause. A range of the index isread 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 rangefrom none to all.
Concatenation: An index is used more than once. Various areas of the index are readand checked. To ensure that the application reads each table record only once, thesearch results are concatenated, and duplicate entries are eliminated. The tablerecords returned can range from none to all.
Introduction to DB Joins: Overview
8/3/2019 Tuning Optimization Concepts
33/119
July 10, 2010 33
Introduction to DB Joins: Overview
Introduction to DB Joins: Nested Loop
8/3/2019 Tuning Optimization Concepts
34/119
July 10, 2010 34
Introduction to DB Joins: Nested Loop
Introduction to DB Joins: Sort Merge Join
8/3/2019 Tuning Optimization Concepts
35/119
July 10, 2010 35
Introduction to DB Joins: Sort Merge Join
Important Access Strategies for DB Joins
8/3/2019 Tuning Optimization Concepts
36/119
July 10, 2010 36
p g
Nested Loop: This strategy is relevant for database views and ABAP JOINs.First, the WHERE clause is used as a basis for selecting the (outer) table tobe used for access. Next, starting from the outer table, the table records forthe inner tables are selected according to the JOIN condition.
Sort Merge Join: First, the WHERE clause is evaluated for all tables in thejoin, and a resulting set is produced for each table. Each resulting set issorted according to the JOIN conditions and then merged, also according to
the JOIN condition.
ang ng o ng
ss ng on on 1
8/3/2019 Tuning Optimization Concepts
37/119
July 10, 2010 37
ang ng o ng
ss ng on on 2
8/3/2019 Tuning Optimization Concepts
38/119
July 10, 2010 38
Critical Operators (NOTd )
8/3/2019 Tuning Optimization Concepts
39/119
July 10, 2010 39
and)
Critical Operators (BETWEEN,
8/3/2019 Tuning Optimization Concepts
40/119
July 10, 2010 40
p (LIKE, > and
8/3/2019 Tuning Optimization Concepts
41/119
July 10, 2010 41
LIKE, > and
8/3/2019 Tuning Optimization Concepts
42/119
July 10, 2010 42
in ABAP?
Changing The ABAP Coding - Roadmap
8/3/2019 Tuning Optimization Concepts
43/119
July 10, 2010 43
Changing Index
8/3/2019 Tuning Optimization Concepts
44/119
July 10, 2010 44
Design
General rulesDisjunct indexes onlyNo unintentionally used indexesAs few indexes as possible per table (as few as possible,but as many asnecessary)Selection of index fieldsAs few fields as possible in indexAs selective fields as possible in indexSelective fields as near to the beginning as possibleDo not change SAP standard indexesunless recommended by SAP
Changing Index Design : SelectivityAnalysis
8/3/2019 Tuning Optimization Concepts
45/119
July 10, 2010 45
Semantic Typing
Type of fieldExampleSelectivityIdentifier KNA1-KUNNR ++customer numberOrganisational unit VBAK-VKORG --Sales organizationStatus VBUK-LFSTK ++/--Delivery StatusClassifier VBAK-AUART --Order typeText field KNA1-NAME1 -Name
Analysis
Selectivity Analysis -Roadmap
8/3/2019 Tuning Optimization Concepts
46/119
July 10, 2010 46
8/3/2019 Tuning Optimization Concepts
47/119
July 10, 2010 47
Suitable Access Path
Suitable Access Path General Methods
8/3/2019 Tuning Optimization Concepts
48/119
July 10, 2010 48
General Methods : Reducing Records
8/3/2019 Tuning Optimization Concepts
49/119
July 10, 2010 49
Reducing The Columns to be Transferred
8/3/2019 Tuning Optimization Concepts
50/119
July 10, 2010 50
Accessing IndividualTables
8/3/2019 Tuning Optimization Concepts
51/119
July 10, 2010 51
Tables
Aggregate Functions
8/3/2019 Tuning Optimization Concepts
52/119
July 10, 2010 52
Having Clause
8/3/2019 Tuning Optimization Concepts
53/119
July 10, 2010 53
Array Fetch
8/3/2019 Tuning Optimization Concepts
54/119
July 10, 2010 54
UP TO nROWS
8/3/2019 Tuning Optimization Concepts
55/119
July 10, 2010 55
SELECTENDSELECT
SELECTUP TO nROWS
ROWS
UPDATE..SET Field =Value
8/3/2019 Tuning Optimization Concepts
56/119
July 10, 2010 56
Value
Create, Change and Delete MassData
8/3/2019 Tuning Optimization Concepts
57/119
July 10, 2010 57
Inner and Outer JoinLogic
8/3/2019 Tuning Optimization Concepts
58/119
July 10, 2010 58
Logic
ImplementationinABAP
8/3/2019 Tuning Optimization Concepts
59/119
July 10, 2010 59
ABAP
Nested Selects
8/3/2019 Tuning Optimization Concepts
60/119
July 10, 2010 60
Problems with NestedSELECTs
8/3/2019 Tuning Optimization Concepts
61/119
July 10, 2010 61
Inefficient transfer Data records from inner table are transferred record by record Lots of small fetches, instead of fewer and more compact
fetchesIdentical SELECTs Data records from inner table are re-read unnecessarily
Incorrect order of access Whether a table is an inner or outer table is defined in coding Dynamic WHERE conditions are ignored
Database View
8/3/2019 Tuning Optimization Concepts
62/119
July 10, 2010 62
SELECT vbeln kunnr adrnr FROMvbak_kna1INTO TABLE g_itab_vvbak_kkna1WHERE vbeln IN g_vbeln.
Create DB view inDictionary
CREATE VIEWvbak_kna1
SELECT STATEMENT (Estimated costs = )NESTED LOOPS
TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN
V V B A K
V V B A K
K K N A 1
K K N A 1 0
ABAP Inner Join
8/3/2019 Tuning Optimization Concepts
63/119
July 10, 2010 63
SELECT t1~ vbeln t2~kunnr t2~adrnr
INTO TABLE
g_itab_vbak_kna1FROM vbak AS t1INNER JOIN kna1 AS t2ON t1~kunnr = t2~kunnrWHERE t1~vbeln IN g_vbeln.
SELECT STATEMENT (Estimated costs = )
NESTED LOOPS
TABLE ACCESS BY INDEX ROW
IDINDEX RANGE SCAN
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN
VBAK
VBAK-0
KNA1
KNA1-0
001 0000120 0000100001 0000121 0000100001 0000122 0000101001 0000123 0000101001 0000124 0000102001 0000125 0000103001 0000126 0000103001 0000127 0000104
MANDT VBELN KUNNR
VBAK MANDT KUNNR 001 0000100 001 0000103 001 0000104 KNA1
FOR ALL ENTRIES over TwoDatabase Tables
8/3/2019 Tuning Optimization Concepts
64/119
July 10, 2010 64
SELECT Vbeln kunnr FROM vbak INTO TABLEg_itab_vbak
WHERE vbeln IN g_vbeln. SELECT STATEMENT (Estimated Costs = )
CONCATENATION
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN
TABLE ACCESS BY INDEX ROWID
INDEX UNIQUE SCAN
KNA1
KNA1-0
KNA1
KNA1-0
SELECT TABLE g_itab_vbak
LINES g_itab_kna1.SORT g_itab_kna1 BY kunnr.
DELETE ADJACENT DUPLICATES
FROM g_itab_kna1.SELECT Kunnr adrnr
FROM kna1INTO (g_wa_kna1-kunnr, g_wa_kna1-adrnrFOR ALL ENTRIES IN g_itab_kna1
WHERE kunnr = g_itab_kna1-kunnr.MODIFY g_itab_kna1 FROM g_wa_kna1 INDEX sy-dbcnt.ENDSELECT.LOOP AT g_itab_vbak INTO g_wa_vbakENDLOOP.
Subquery
8/3/2019 Tuning Optimization Concepts
65/119
July 10, 2010 65
SELECT kunnr adrnrINO TABLE g-itab_vvbak_kkna1FROM kkna1WHERE kunnr IN ( SELECT DISTINCT kunnr FROM vvbak WHERE
vbeln IN g_vbeln)..
SELECT STATEMENT (Estimated Costs = )NESTED LOOPS
TABLE ACCESS BY INDEX ROWID VVBAK
INDEX RANGE SCAN VVBAK-0
TABLE ACCESS BY INDEX ROWID KKNA1
INDEX UNIQUE SCAN KKNA1~0
ABAP OUTER JOIN
8/3/2019 Tuning Optimization Concepts
66/119
July 10, 2010 66
Creating JOINs Over theDatabase
8/3/2019 Tuning Optimization Concepts
67/119
July 10, 2010 67
Possible access strategies:o Nested Loopo Sorted merge Join
Database optimizer determines order of access Access to outer table should be as selective as possible
(selective WHERE conditions) For each data record in the outer table, as few records as
possible should exist in the inner table (selective JOINconditions)
An index for the JOIN conditions should exist on the inner table(at least)
The structure of a database determines the node hierarchy, and thus the order
LogicalDatabase
8/3/2019 Tuning Optimization Concepts
68/119
July 10, 2010 68
in which nodes are read. The read depth depends on the GET eventsspecified in the program. The logical database reads all nodes on the directaccess path until the deepest GET event.
A GET event is like loop processing as they are processed several times in theprogram.Because it is very much like a nested SELECT, formulating aSELECT statement within a GET event can create problems.
Program a GET event referring to a node lower down in the hierarchy only ifthe data above it is also required. The logical database reads the key fields ofall superior nodes as well. In this situation, do not use logical databases, butprogram the SELECT statements yourself.
If the fields in your table are wide and if you do not require all the fields in yourprograms, use a FIELDS addition when you formulate a GET statement. Thestatement GET dbtab FIELDS fields is like a SELECT field list and has thesame level of performance
Accessing Several Tables - Roadmap
8/3/2019 Tuning Optimization Concepts
69/119
July 10, 2010 69
Pooled and ClusterTablesDepending on how they are physically implemented, the ABAP dictionary has
8/3/2019 Tuning Optimization Concepts
70/119
July 10, 2010 70
LOGICAL VIEW
PHYSICAL VIEW
TRANSPARENT TABLES CLUSTER TABLESPOOLED TABLES
TAB_B CLUST_A
CLUST_B
POOL_A
POOL_B
DATABASE TABLES
p g y p y y p ythreecategories of tables: Transparent, Pooled and Clustered
Pooled and clustered tables group several logically defined tables from the ABAPdictionaryin a physical database table. In pooled tables, data is located in a table pool whereasin aclustered pool, data is located in a table cluster.
Pooled &Cluster Tables: Pros andCons
8/3/2019 Tuning Optimization Concepts
71/119
July 10, 2010 71
ADVANTAGES DISADVANTAGES
Data compressionLess memory spaceLess network loadFewer tables and table fieldsFewer different SQL statementsLess load on database dictionaryand database bufferSimpler administrationFor cluster tablesFewer database accesses
Limitations on database functionalitiesNo views or ABAP JOINsNo secondary indexesNo GROUP BY, ORDER BY,No native SQLNo table appendsFor cluster tablesLimited selection on cluster key fieldsFor pooled tablesLonger keys than necessary
ClusterTables
8/3/2019 Tuning Optimization Concepts
72/119
July 10, 2010 72
Cluster 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 keyVARDATA field
Structure description of
VARDATA fieldPAGNO
A
Key fields
SELECT b k b l j h k
Selective Access to ClusterTables
8/3/2019 Tuning Optimization Concepts
73/119
July 10, 2010 73
SELECT bukrs belnr gjahr kunnrFROM bsegINTO TABLE g_itab_bsidWHERE bukrs = 0001AND belnr = 0000000022.
SQL statement in ABAP
SELECT MANDT, BUKRS, BELNR,GJAHR,PAGENO,TIMESTMP,PAGELG,VARDATAFROM RFBLGWHERE MANDT = :A0AND BUKRS = : A1AND BE;NR = :A2ORDER BY MANDT, BUKRS, BELNR,GJAHR, PAGENO
SQL statement at DB level
UNSELECTIVE ACCESS SELECTIVE ACCESS
Unselective Access on Cluster Tables
8/3/2019 Tuning Optimization Concepts
74/119
July 10, 2010 74
SELECT bukrs belnr SELECT bukrs belnrFROM bseg FROM bsidINTO TABLE g_itab_bsid INTO TABLE g_itab_bsidWHERE kunnr = 0000000100. WHERE KUNNR = 0000000100SELECT MANDT,BUKRS,.. SELECT BURKS, MANDT,FROM RFBLG FROM BSID
WHERE MANDT = :A0 WHERE MANDT = :A0ORDER BY MANDT, BUKRS, AND KUNNR = :A1.
UNSELECTIVE ACCESS SELECTIVE ACCESS
Pooled Tables
8/3/2019 Tuning Optimization Concepts
75/119
July 10, 2010 75
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
Selective Access on Pooled TablesData is read from pooled table aa005. The SQL statement is transferred to the databaseinterface and converted into an SQL statement for table pool KAPOL
8/3/2019 Tuning Optimization Concepts
76/119
July 10, 2010 76
SQL STATEMENTS IN ABAPSQL STATEMENTS AT DB LEVELSELECT kappl kschl vkorg vtweg matnr FROM aa005 SELECT TABNAME, VARKEY, INTOTABLE g_itab_aa005 DATALN, VARDATAWHERE kappl = CS and kschl = SAPZ FROM KAPOL AND vkorg = 0001 AND vtweg = 01 WHEREAND kunnr = 0000000009 TABNAME = :AO AND VARKEYAND matnr = 000000000000000027 LIKE :A1ORDER 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 interfaceincorporates the ORDER BY clause for fields TABNAME and VARKEY which are key fields inthe table pool.
UnSelective Access on Pooled Tables
SELECT kappl, kschl, vkorg SELECT TABNAME, VARKEYFROM aa005 FROM KAPOL
8/3/2019 Tuning Optimization Concepts
77/119
July 10, 2010 77
FROM aa005 FROM KAPOLINTO TABLE g_itab_aa005 WHERE TABNAME = :AO ANDWHERE matnr =000000000000000027. VARKY LIKE : A1ORDER BY TABNAME, . .
Unselective access
AA005 fully buffered on application server Remove AA05 from table pool KAPOLand create index for MATNRRepeated database read is not necessaryEfficient data read is possible
Selective access
R/3 TableBuffering
8/3/2019 Tuning Optimization Concepts
78/119
July 10, 2010 78
NETWORK
Table bufferProgram bufferDictionary bufferNumber rangebufferRoll and pagingbuffers
R/3 buffer R/3 buffer
Application server A Application server B
Database
Databasemanagementsystem
DBMSprocesses
Databasebuffer
SAP GUI SAP GUI
Types ofBuffering
8/3/2019 Tuning Optimization Concepts
79/119
July 10, 2010 79
In work area mode, changes on the database are made by accessing single records.You can perform single record accessing by using ABAP statements like
Degree ofInvalidation
8/3/2019 Tuning Optimization Concepts
80/119
July 10, 2010 80
You can perform single record accessing by using ABAP statements likeUPDATE/INSERT/MODIFY/DELETE dbtab (FROM wa) or INSERT dbtab VALUES wa.
You can do mass processing by changing the database table in set mode. To
implement mass processing, use ABAP statementsUPDATE/INSERT/MODIFY/DELETE dbab FROM itab, UPDATE dbtab SET field = valueWHERE field = condition or DELETE dbtab WHERE field = condition.
In fully buffered tables, all records are invalidated by database changes. In generically buffered tables, in work area mode, those records are invalidated that
have the same specific instance in the generic area as the fields in the work area ofthe SQL statement executed. All data records are invalidated for a generically
buffered table accessed in set mode In single record buffering, only the changed single record is invalidated by databasechanges in work area mode. In set mode, the whole table with single record bufferingis invalidated by database changes.
The degree of invalidation corresponds to the degree to which the table buffers arefilled.
Native SQL
SQL Statements that Bypass the Buffer (1)
8/3/2019 Tuning Optimization Concepts
81/119
July 10, 2010 81
Sub queries, ABAP JOINs SELECTBYPASSING BUFFER SELECT FOR UPDATE Aggregate functions(COUNT, MIN, MAX, SUM, AVG) SELECT DISTINCT WHERE clause with IS NULL ORDER BY, GROUP BY (HAVING) For tables with single record buffering:
All SQL statements except SELECT SINGLE For tables with generic buffering:
All SQL statements except SELECT *.. If WHERE clause is field =value for all fields included in generic area
=> Database = > Table buffer
SQL Statements that Bypass the Buffer(2)
8/3/2019 Tuning Optimization Concepts
82/119
July 10, 2010 82
SELECT * FROM tcurr SELECT * FROM tcurrCLIENT SPECIFIED INTO TABLE g_itab_tcurrINTO TABLE g_itab_tcurr WHERE kurst = EUROWHERE kurst = EURO
> Database > Table buffer
Generic Buffering
=> Database = > Table buffer
SELECT * FROM t100 SELECT SINGLE * FROM t100INTO TABLE g_itab_t100 INTO g_wa_t100WHERE sprs1=D WHERE sprs1 = DAND argb = BC490 AND arbgb = BC490AND msgnr = 050. AND msgnr = 050.
Single Record Buffering
Technical criteria
BufferingStrategy
8/3/2019 Tuning Optimization Concepts
83/119
July 10, 2010 83
Technical criteria Small, usually < 1 MB Read but hardly changed Temporary data inconsistency acceptable Access mainly from key fields Buffer tables>10 MB in exceptional cases only Table buffers cannot be accessed via secondary indexes Check available memory space before buffering more tables
BufferingStrategy
8/3/2019 Tuning Optimization Concepts
84/119
July 10, 2010 84
Semantic CriteriaDo not buffer transaction dataBig tablesFrequently changed tablesAvoid buffering master dataBig tablesDifferent access paths to dataBuffer customizing dataSmall tablesFew changes to tables
Buffering in theProgramSELECT.FROM vvbak INTO g_wa_vvbak_kknal WHERE PERFORM READ_KKNA1
8/3/2019 Tuning Optimization Concepts
85/119
July 10, 2010 85
_.ENDSELECT.Form routine READ_KKNA1:READ TABLE g_itab_kknal WITH TABLE KEYkunnr = g_wa_v vbak_kknal-kunnr INTO l_wa_kknal.IF sy-subrc NE 0.SELECT SINGLE FROM kknal INTO (l_wa_kknal-kunnr,.)WHERE kunnr = g_wa_vvbak_kknal-kunnr.IF sy-subrc EQ 0.l_wa_kknal-exist =XELSECLEAR: l_wa_kknal-exist, l_wa_kknal_namel,ENDIF.APPEND l_wa_kknal TO g_itab_kknal.ENDIF.
Robust User Interface
8/3/2019 Tuning Optimization Concepts
86/119
July 10, 2010 86
Define minimum requirements for entries on selection screens and search help(end user training, operation concept)
Customer owned selection screen Define selective fields (PARAMETER, SELECT-OPTIONS) as required entry fields Check user entries for minimum requirements Implement appropriate SQL statements depending on user entries Customer-owned search help Create customer owned search help following SAP standard If necessary, define input fields as required entry fields
SELECT f1 f2 SELECT f2 f3SELECT vbeln posnr SELECT posnr matnr
Similar SQL Statements
8/3/2019 Tuning Optimization Concepts
87/119
July 10, 2010 87
SELECT vbeln posnr SELECT posnr matnrFROM vvbap FROM vvbapINTO INTOWHERE vbeln = 0000000001. WHERE vbeln = 0000000001DIFFERENT WHERE CLAUSESSELECT vbeln posnr SELECT vbelN posnrFROM vvbap FROM vvbapINTO INTOWHERE vbeln IN(0000000001, 0000000002) WHERE vbeln = (0000000001,0000000002,0000000003).
Suitable Access Path - Roadmap
8/3/2019 Tuning Optimization Concepts
88/119
July 10, 2010 88
8/3/2019 Tuning Optimization Concepts
89/119
July 10 2010 89
Internal Tables
Internal Table Attributes
8/3/2019 Tuning Optimization Concepts
90/119
July 10 2010 90
Table Types
8/3/2019 Tuning Optimization Concepts
91/119
July 10 2010 91
Internal TableOperations
8/3/2019 Tuning Optimization Concepts
92/119
July 10 2010 92
Overview : Suitable AccessPath
8/3/2019 Tuning Optimization Concepts
93/119
July 10 2010 93
Improving performance Reduce number of lines used Reduce search area Implement mass processing Reduce copy costs in a work area or header line
Index operations on Internal Tables
8/3/2019 Tuning Optimization Concepts
94/119
July 10 2010 94
Key Operations on InternalTables
8/3/2019 Tuning Optimization Concepts
95/119
July 10 2010 95
Execution Times Per Access Type
8/3/2019 Tuning Optimization Concepts
96/119
July 10 2010 96
Efficient loading of internal tables: ArrayFetches
8/3/2019 Tuning Optimization Concepts
97/119
July 10 2010 97
Inserting InternalTables
8/3/2019 Tuning Optimization Concepts
98/119
July 10 2010 98
Filling an Internal Table with Cumulative Values
8/3/2019 Tuning Optimization Concepts
99/119
July 10 2010 99
You can load an internal table using a SELECTINTO, so that the table hasfewer key fields than a database table. This may lead to redundancy.If h h d bl h i b i Y ld l
Loading Unique Internal Tables
8/3/2019 Tuning Optimization Concepts
100/119
July 10, 2010 100
If you use a hashed table, the entries must be unique. You could also use a non-
unique sorted or standard table, delete the duplicates, and then use a MOVE tothe hashed table.
This process can be time consuming. A faster way is to load a unique table withARRAY FETCH and then deleting any duplicates. Do not use a SELECTDISTINCT if you want all key fields of the database table to appear in the internaltable but not in the key.
Use the DELETE ADJACENT DUPLICATES FROM to optimize. This
checks whether adjacent rows have the same key. It can be used tosubsequently aggregate internal tables.
The internal table must be first sorted. COMPARING lets you define duplicates in terms of other fields.
Efficient Accessing of Data in Internal Tables
8/3/2019 Tuning Optimization Concepts
101/119
July 10, 2010 101
Selective Field Transfer
8/3/2019 Tuning Optimization Concepts
102/119
July 10, 2010 102
Using FieldSymbols
8/3/2019 Tuning Optimization Concepts
103/119
July 10, 2010 103
No Field Transfer
8/3/2019 Tuning Optimization Concepts
104/119
July 10, 2010 104
Reading Single Records
8/3/2019 Tuning Optimization Concepts
105/119
July 10, 2010 105
Hashed Tables
8/3/2019 Tuning Optimization Concepts
106/119
July 10, 2010 106
Sorted Tables
8/3/2019 Tuning Optimization Concepts
107/119
July 10, 2010 107
Standard Tables
8/3/2019 Tuning Optimization Concepts
108/119
July 10, 2010 108
Reading NestedTables
8/3/2019 Tuning Optimization Concepts
109/119
July 10, 2010 109
Mass Processing using a WHEREClause
Only access the table lines you really need
8/3/2019 Tuning Optimization Concepts
110/119
July 10, 2010 110
LOOP AT WHERE MODIFY WHERE DELETE WHERESELECT-OPTIONS :s_vbeln FOR vbak-vbeln.SORT AT stan_vbap INTO wa.IF wa-vbeln IN s_vbeln.*.ENDIF.ENDLOOP.
SELECT-OPTIONS :s_vbeln FOR vbak-vbeln.LOOP AT stan_vbap INTOwaWHERE mandt = sy-mandtAND vbeln IN s_vbeln.ENDLOOP.
Mass Processing using an Index Interval
8/3/2019 Tuning Optimization Concepts
111/119
July 10, 2010 111
Secondary Index
Reading Data
8/3/2019 Tuning Optimization Concepts
112/119
July 10, 2010 112
Secondary Index
Modifying Data
8/3/2019 Tuning Optimization Concepts
113/119
July 10, 2010 113
8/3/2019 Tuning Optimization Concepts
114/119
July 10, 2010 114
R/3 System Analysis
R/3 systems analysis: Identifies performance critical objects Collates information for further analysis of objects
R/3 SYSTEM ANALYSIS : Overview
8/3/2019 Tuning Optimization Concepts
115/119
July 10, 2010 115
Collates information for further analysis of objects Should be performed only on the production system To be performed by developers, system or database administrators,
performance tunersPrerequisites: Absence of basic problems (R/3 basis, database, hardware) Functioning R/3 and database monitors Representative user activity
R/3 Work processOverview
8/3/2019 Tuning Optimization Concepts
116/119
July 10, 2010 116
Database Process Monitor
To access the Database Process Monitor, from the initial screen of theDatabase Monitor choose Detailed analysis menu ORACLE session
8/3/2019 Tuning Optimization Concepts
117/119
July 10, 2010 117
(Informix session or SQL processes , and so on as appropriate)
This monitor lists the database processes and corresponding R/3 workprocesses. Also shows status information and the text of the SQLstatements.If a program with poor database performance is identified in the WorkProcess overview, note the R/3 work process ID to locate the corresponding
SQL statement in the Database Process Monitor.
To access a detailed view of the SQL statement, double-click the linecontaining the statement or position the cursor and choose Detail. To findout the execution plan of an SQL statement, choose Explain
Database Process Monitor
To call the database Lock Monitor, use Transaction code DB01 or from theR/3 initial screen, choose Tools, Administration, Monitor, Performance,
8/3/2019 Tuning Optimization Concepts
118/119
July 10, 2010 118
Database, Exclusive lock waits.If there is a lock situation, you can see the user causing the lock and contactthem to release it. If the database lock cannot be released by the user,delete it so that other users can resume work. If you delete the lock, thetransaction lock that caused it is rolled back and must be repeated.Database locks are normally released at the end of a transaction step to
enable an implicit database commit. If you want data records to be lockedfor more than one transaction step, you can use R/3 enqueues.Database locks should usually be requested as late as possible. After thelock, long running SQL statements or internal-table processing should nolonger be possible.
Thank You
8/3/2019 Tuning Optimization Concepts
119/119
July 10, 2010 119