tuning optimization concepts

8/3/2019 Tuning Optimization Concepts

1/119

July 10, 2010 1

Performance Tuning andOptimization Techniques -

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


3/119

July 10, 2010 3

Agenda

Internal Tables R/3 system Analysis

o Overviewo R/3 Workload Analysis


4/119July 10, 2010 4

R/3 Client / Server Architecture


5/119July 10, 2010 5

DBMS Architecture


6/119July 10, 2010 6

Analyzing Individual Objects


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


9/119July 10, 2010 9

Analyzing Transaction Steps: Response Time



10/119July 10, 2010 10

Analyzing Transaction Steps: Roadmap



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


12/119July 10, 2010 12

SQL Trace - Overview


13/119

July 10, 2010 13

SQL Performance Trace: DatabaseOperations

Problem Classification Roadmap


14/119

July 10, 2010 14

Problem Classification Roadmap

SQL Performance Trace Roadmap


15/119

July 10, 2010 15

SQL Performance Trace Roadmap

ABAP R i A l i


16/119

July 10, 2010 16

ABAP Runtime Analysis:Overview

Example Roadmap Runtime Analysis


17/119

July 10, 2010 17

Example Roadmap Runtime Analysis

ABAP


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


19/119

July 10, 2010 19

Database Accesses

D t b A O i C t b d


20/119

July 10, 2010 20

Database Accesses : Overview - Cost basedOptimizer


21/119

July 10, 2010 21

Overview: Database SQLCache

Overview Suitable / Unsuitable Access


22/119

July 10, 2010 22

Overview Suitable / Unsuitable Access

Overview

unsuitable Access path


23/119

July 10, 2010 23

Overview

unsuitable Access path

OverviewSuitable Access Path 1


24/119

July 10, 2010 24

Overview

Suitable Access Path 1

OverviewSuitable Access Path 2


25/119

July 10, 2010 25

Unsuitable Access Path Introduction to DB


26/119

July 10, 2010 26

Unsuitable Access Path - Introduction to DBIndexes: Overview (1)

Introduction to DB Indexes:


27/119

July 10, 2010 27

Introduction to DB Indexes:Overview (2)

Introduction to DB Indexes: Index


28/119

July 10, 2010 28

Introduction to DB Indexes: IndexUnique Scan

Introduction to DB Indexes: Index


29/119

July 10, 2010 29

Range Scan

Introduction to DB Indexes: Full


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



Table VBAP

Introduction to DB Indexes:


31/119

July 10, 2010 31

t oduct o to de esConcatenation

Important Access Strategies for Tables


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


33/119

July 10, 2010 33

Introduction to DB Joins: Overview

Introduction to DB Joins: Nested Loop


34/119

July 10, 2010 34

Introduction to DB Joins: Nested Loop

Introduction to DB Joins: Sort Merge Join


35/119

July 10, 2010 35

Introduction to DB Joins: Sort Merge Join

Important Access Strategies for DB Joins


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


37/119

July 10, 2010 37

ang ng o ng

ss ng on on 2


38/119

July 10, 2010 38

Critical Operators (NOTd )


39/119

July 10, 2010 39

and)

Critical Operators (BETWEEN,


40/119

July 10, 2010 40

p (LIKE, > and


41/119

July 10, 2010 41

LIKE, > and


42/119

July 10, 2010 42

in ABAP?

Changing The ABAP Coding - Roadmap


43/119

July 10, 2010 43

Changing Index


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


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


46/119

July 10, 2010 46


47/119

July 10, 2010 47

Suitable Access Path

Suitable Access Path General Methods


48/119

July 10, 2010 48

General Methods : Reducing Records


49/119

July 10, 2010 49

Reducing The Columns to be Transferred


50/119

July 10, 2010 50

Accessing IndividualTables


51/119

July 10, 2010 51

Tables

Aggregate Functions


52/119

July 10, 2010 52

Having Clause


53/119

July 10, 2010 53

Array Fetch


54/119

July 10, 2010 54

UP TO nROWS


55/119

July 10, 2010 55

SELECTENDSELECT

SELECTUP TO nROWS

ROWS

UPDATE..SET Field =Value


56/119

July 10, 2010 56

Value

Create, Change and Delete MassData


57/119

July 10, 2010 57

Inner and Outer JoinLogic


58/119

July 10, 2010 58

Logic

ImplementationinABAP


59/119

July 10, 2010 59

ABAP

Nested Selects


60/119

July 10, 2010 60

Problems with NestedSELECTs


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


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


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


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


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


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


INDEX UNIQUE SCAN


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


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


66/119

July 10, 2010 66

Creating JOINs Over theDatabase


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


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


69/119

July 10, 2010 69

Pooled and ClusterTablesDepending on how they are physically implemented, the ABAP dictionary has


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


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


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


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


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


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


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


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


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


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


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)


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)


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


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


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


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


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


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


88/119

July 10, 2010 88


89/119

July 10 2010 89

Internal Tables

Internal Table Attributes


90/119

July 10 2010 90

Table Types


91/119

July 10 2010 91

Internal TableOperations


92/119

July 10 2010 92

Overview : Suitable AccessPath


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


94/119

July 10 2010 94

Key Operations on InternalTables


95/119

July 10 2010 95

Execution Times Per Access Type


96/119

July 10 2010 96

Efficient loading of internal tables: ArrayFetches


97/119

July 10 2010 97

Inserting InternalTables


98/119

July 10 2010 98

Filling an Internal Table with Cumulative Values


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


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


101/119

July 10, 2010 101

Selective Field Transfer


102/119

July 10, 2010 102

Using FieldSymbols


103/119

July 10, 2010 103

No Field Transfer


104/119

July 10, 2010 104

Reading Single Records


105/119

July 10, 2010 105

Hashed Tables


106/119

July 10, 2010 106

Sorted Tables


107/119

July 10, 2010 107

Standard Tables


108/119

July 10, 2010 108

Reading NestedTables


109/119

July 10, 2010 109

Mass Processing using a WHEREClause

Only access the table lines you really need


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


111/119

July 10, 2010 111

Secondary Index

Reading Data


112/119

July 10, 2010 112

Secondary Index

Modifying Data


113/119

July 10, 2010 113


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


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


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


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,


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


119/119

July 10, 2010 119

tuning optimization concepts

Documents