Performance Tuning and Optimization Techniques Concepts

July 10, 2010 1

Agenda
Overview Analyzing Individual Objects : o Analyzing transaction steps o SQL Performance Analysis o ABAP Runtime Analysis: Overview o ABAP Debugger Database Accesses : o Overview o Unsuitable Access Path o Suitable Access Path

July 10, 2010 2

Agenda
Internal Tables R/3 system Analysis o Overview o R/3 Workload Analysis

July 10, 2010 3

R/3 Client / Server Architecture

July 10, 2010 4

DBMS Architecture

July 10, 2010 5

Analyzing Individual Objects

July 10, 2010 6

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.

July 10, 2010 7

Analyzing transaction steps Statistics Records for a transaction step Single

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

July 10, 2010 8

Analyzing transaction steps

Analyzing Transaction Steps: Response Time

July 10, 2010 9

Analyzing transaction steps

Analyzing Transaction Steps: Roadmap

July 10, 2010 10

SQL Performance Trace : Basics

SQL trace o A record of SQL statements that access the database system Buffer trace * o A record of data requests that access buffered tables Enqueue trace o A record of enqueue requests received by the enqueue server

RFC trace o A record of received and sent Remote Function Calls

July 10, 2010 11

SQL Trace - Overview

July 10, 2010 12

SQL Performance Trace: Database Operations

July 10, 2010 13

Problem Classification Roadmap

July 10, 2010 14

SQL Performance Trace Roadmap

July 10, 2010 15

ABAP Runtime Analysis: Overview

July 10, 2010 16

Example Roadmap Runtime Analysis

July 10, 2010 17

ABAP Debugger
The debugger is used to identify errors in source code. There are some attributes of this tool that are used for runtime analyses as well. It is used to run through an object step by step. A commonly used function is to check for memory usage during statements that access large internal tables. For example, statements such as LOOP ATENDLOOP require extensive CPU time and increase object runtime while slowing down the system at the same time. Checking the memory use of an internal table is therefore useful. To see how much memory is allocated for and used by an internal table, choose Settings>>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, choose Goto>>System>>system areas , and in the Area field, enter ITAB. (not the internal table name) 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 may cause errors such as implicit database commits resulting in database inconsistencies.

July 10, 2010 18

Database Accesses

July 10, 2010 19

Database Accesses : Overview - Cost based Optimizer

July 10, 2010 20

Overview: Database SQL Cache

July 10, 2010 21

Overview Suitable / Unsuitable Access

July 10, 2010 22

Overview unsuitable Access path

July 10, 2010 23

Overview Suitable Access Path 1

July 10, 2010 24

Overview Suitable Access Path 2

July 10, 2010 25

Unsuitable Access Path - Introduction to DB Indexes: Overview (1)

July 10, 2010 26

Introduction to DB Indexes: Overview (2)

July 10, 2010 27

Introduction to DB Indexes: Index Unique Scan

July 10, 2010 28

Introduction to DB Indexes: Index Range Scan

July 10, 2010 29

Introduction to DB Indexes: Full Table Scan

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

Index

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 ROW ID MANDT VBELN POSNR MATNR 75892 001 0000163 04006149 055123 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

July 10, 2010 30

Introduction to DB Indexes: Concatenation

July 10, 2010 31

Important Access Strategies for Tables

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.

July 10, 2010 32

Introduction to DB Joins: Overview

July 10, 2010 33

Introduction to DB Joins: Nested Loop

July 10, 2010 34

Introduction to DB Joins: Sort Merge Join

July 10, 2010 35

Important Access Strategies for DB Joins

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 to be used for access. Next, starting from the outer table, the table records for the inner tables are selected according to the JOIN condition. Sort Merge Join: First, the WHERE clause is evaluated for all tables in the join, and a resulting set is produced for each table. Each resulting set is sorted according to the JOIN conditions and then merged, also according to the JOIN condition.

July 10, 2010 36

Changing ABAP Coding Missing WHERE Condition 1

July 10, 2010 37

Changing ABAP Coding Missing WHERE Condition 2

July 10, 2010 38

Critical Operators (NOT and<>)

July 10, 2010 39

Critical Operators (BETWEEN, LIKE, > and <)

July 10, 2010 40

Critical Operators (BETWEEN, LIKE, > and <)

July 10, 2010 41

Sort at Database Level or in ABAP?

July 10, 2010 42

Changing The ABAP Coding - Roadmap

July 10, 2010 43

Changing Index Design

General rules Disjunct 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

July 10, 2010 44

Changing Index Design : Selectivity Analysis

Semantic Typing
Type of field Example Selectivity Identifier KNA1-KUNNR ++ customer number Organisational unit VBAK-VKORG -Sales organization Status VBUK-LFSTK ++/-Delivery Status Classifier VBAK-AUART -Order type Text field KNA1-NAME1 Name

July 10, 2010 45

Selectivity Analysis -Roadmap

July 10, 2010 46

Suitable Access Path

July 10, 2010 47

Suitable Access Path General Methods

July 10, 2010 48

General Methods : Reducing Records

July 10, 2010 49

Reducing The Columns to be Transferred

July 10, 2010 50

Accessing Individual Tables

July 10, 2010 51

Aggregate Functions

July 10, 2010 52

Having Clause

July 10, 2010 53

Array Fetch

July 10, 2010 54

UP TO n ROWS

SELECTENDSELEC T

SELECTUP TO n ROWS

July 10, 2010 55

UPDATE..SET Field = Value

July 10, 2010 56

Create, Change and Delete Mass Data

July 10, 2010 57

Inner and Outer Join Logic

July 10, 2010 58

Implementation in ABAP

July 10, 2010 59

Nested Selects

July 10, 2010 60

Problems with Nested SELECTs

Inefficient transfer Data records from inner table are transferred record by record Lots of small fetches, instead of fewer and more compact fetches Identical 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

July 10, 2010 61

Database View
SELECT vbeln kunnr adrnr FROM vbak_kna1 INTO TABLE g_itab_vvbak_kkna1 WHERE vbeln IN g_vbeln. SELECT STATEMENT (Estimated costs = )
NESTED LOOPS TABLE ACCESS BY INDEX ROW ID INDEX RANGE SCAN V V B A K
VVBAK

Create DB view in Dictionary

TABLE ACCESS BY INDEX ROW ID INDEX UNIQUE SCAN K K N A 1 0

KKNA1

CREATE VIEW vbak_kna1

July 10, 2010 62

ABAP Inner Join

SELECT t1~ vbeln t2~kunnr t2~adrnr

INTO TABLE g_itab_vbak_kna1 FROM vbak AS t1 INNER JOIN kna1 AS t2 ON t1~kunnr = t2~kunnr WHERE t1~vbeln IN g_vbeln.
MANDT VBELN KUNNR

SELECT STATEMENT (Estimated costs = ) NESTED LOOPS

001 0000120 0000100 001 0000121 0000100 001 0000122 0000101 001 0000123 0000101 001 0000124 0000102 001 0000125 0000103 001 0000126 0000103 001 0000127 0000104

TABLE ACCESS BY INDEX ROW ID INDEX RANGE SCAN VBAK-0

VBAK

TABLE ACCESS BY INDEX ROW ID INDEX UNIQUE SCAN KNA1-0

MANDT KUNNR 001 0000100 001 0000103 001 0000104

KNA1

VBAK

KNA1

July 10, 2010 63

FOR ALL ENTRIES over Two Database Tables

Vbeln kunnr FROM vbak INTO TABLE g_itab_vbak WHERE vbeln IN g_vbeln. SELECT STATEMENT (Estimated Costs = ) SELECT TABLE g_itab_vbak CONCATENATION LINES g_itab_kna1. TABLE ACCESS BY INDEX ROW
SELECT
ID

KNA1

SORT g_itab_kna1 BY kunnr. DELETE ADJACENT DUPLICATES FROM g_itab_kna1. SELECT Kunnr adrnr

INDEX UNIQUE SCAN

KNA1-0 KNA1

TABLE ACCESS BY INDEX ROW ID INDEX UNIQUE SCAN KNA1-0

FROM kna1 INTO (g_wa_kna1-kunnr, g_wa_kna1adrnr ALL ENTRIES IN FOR 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_vbak ENDLOOP.

July 10, 2010 64

Subquery
SELECT kunnr adrnr INO TABLE g-itab_vvbak_kkna1 FROM kkna1 WHERE 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

July 10, 2010 65

ABAP OUTER JOIN

July 10, 2010 66

Creating JOINs Over the Database

Possible access strategies: o Nested Loop o 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 JOIN conditions) An index for the JOIN conditions should exist on the inner table (at least)

July 10, 2010 67

Logical Database a database determines the node hierarchy, and thus the order The structure of
in which nodes are read. The read depth depends on the GET events specified in the program. The logical database reads all nodes on the direct access path until the deepest GET event. A GET event is like loop processing as they are processed several times in the program.Because it is very much like a nested SELECT, formulating a SELECT statement within a GET event can create problems. Program a GET event referring to a node lower down in the hierarchy only if the data above it is also required. The logical database reads the key fields of all superior nodes as well. In this situation, do not use logical databases, but program the SELECT statements yourself. If the fields in your table are wide and if you do not require all the fields in your programs, use a FIELDS addition when you formulate a GET statement. The statement GET dbtab FIELDS fields is like a SELECT field list and has the same level of performance

July 10, 2010 68

Accessing Several Tables - Roadmap

July 10, 2010 69

Pooled and Cluster Tables on how they are physically implemented, the ABAP dictionary has Depending
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.
July 10, 2010 70

Pooled &Cluster Tables: Pros and Cons

ADVANTAGES DISADVANTAGES

Data compression Less memory space Less network load Fewer tables and table fields Fewer different SQL statements Less load on database dictionary and database buffer Simpler administration For cluster tables Fewer database accesses

Limitations on database functionalities No views or ABAP JOINs No secondary indexes No GROUP BY, ORDER BY, No native SQL No table appends For cluster tables Limited selection on cluster key fields For pooled tables Longer keys than necessary

July 10, 2010 71

Cluster Tables
Cluster table TABA TIMESTAMP
Table cluster

PAGELG

A A

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

July 10, 2010 72

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

July 10, 2010 73

Unselective Access on Cluster Tables

UNSELECTIVE ACCESS SELECTIVE ACCESS

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.

July 10, 2010 74

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

TABA Key Pooled table TABB TABB

A E

C F

D G H I

TABNAME

VARKEY

VARDATA

Key

July 10, 2010 75

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

July 10, 2010 76

UnSelective 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 access
AA005 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

July 10, 2010 77

R/3 Table Buffering

SAP GUI SAP GUI Table buffer Program buffer Dictionary buffer Number range buffer Roll and paging buffers

Application server A R/3 buffer

Application server B R/3 buffer

NETWORK

Database management system

DBMS processes

Database buffer

Database

July 10, 2010 78

Types of Buffering

July 10, 2010 79

Degree of Invalidation

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 UPDATE/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 statements UPDATE/INSERT/MODIFY/DELETE dbab FROM itab, UPDATE dbtab SET field = value WHERE 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 of the 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 database changes in work area mode. In set mode, the whole table with single record buffering is invalidated by database changes. The degree of invalidation corresponds to the degree to which the table buffers are filled.

July 10, 2010 80

SQL Statements that Bypass the Buffer (1)

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

July 10, 2010 81

SQL Statements that Bypass the Buffer (2)

=> Database
SELECT * FROM tcurr SELECT * FROM tcurr CLIENT SPECIFIED INTO TABLE g_itab_tcurr INTO TABLE g_itab_tcurr WHERE kurst = EURO WHERE kurst = EURO

= > Table buffer

Generic Buffering
=> Database
SELECT * FROM t100 SELECT SINGLE * FROM t100 INTO TABLE g_itab_t100 INTO g_wa_t100 WHERE sprs1=D WHERE sprs1 = D AND argb = BC490 AND arbgb = BC490 AND msgnr = 050. AND msgnr = 050.

= > Table buffer

Single Record Buffering

July 10, 2010 82

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

July 10, 2010 83

Buffering Strategy
Semantic Criteria Do not buffer transaction data Big tables Frequently changed tables Avoid buffering master data Big tables Different access paths to data Buffer customizing data Small tables Few changes to tables

July 10, 2010 84

Buffering in the Program

SELECT .FROM vvbak INTO g_wa_vvbak_kknal WHERE PERFORM READ_KKNA1 . ENDSELECT. Form routine READ_KKNA1: READ TABLE g_itab_kknal WITH TABLE KEY kunnr = 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 =X ELSE CLEAR: l_wa_kknal-exist, l_wa_kknal_namel, ENDIF. APPEND l_wa_kknal TO g_itab_kknal. ENDIF.

July 10, 2010 85

Robust User Interface

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

July 10, 2010 86

Similar SQL Statements

SELECT f1 f2 SELECT f2 f3
SELECT vbeln posnr SELECT posnr matnr FROM vvbap FROM vvbap INTO INTO WHERE vbeln = 0000000001. WHERE vbeln = 0000000001

DIFFERENT WHERE CLAUSES

SELECT vbeln posnr SELECT vbelN posnr FROM vvbap FROM vvbap INTO INTO WHERE vbeln IN(0000000001, 0000000002) WHERE vbeln = (0000000001,0000000002,0000000003).

July 10, 2010 87

Suitable Access Path - Roadmap

July 10, 2010 88

Internal Tables

July 10, 2010 89

Internal Table Attributes

July 10, 2010 90

Table Types

July 10, 2010 91

Internal Table Operations

July 10, 2010 92

Overview : Suitable Access Path

Improving performance Reduce number of lines used Reduce search area Implement mass processing Reduce copy costs in a work area or header line

July 10, 2010 93

Index operations on Internal Tables

July 10, 2010 94

Key Operations on Internal Tables

July 10, 2010 95

Execution Times Per Access Type

July 10, 2010 96

Efficient loading of internal tables: Array Fetches

July 10, 2010 97

Inserting Internal Tables

July 10, 2010 98

Filling an Internal Table with Cumulative Values

July 10, 2010 99

Loading Unique Internal Tables

You can load an internal table using a SELECTINTO, so that the table has fewer key fields than a database table. This may lead to redundancy. If you use a hashed table, the entries must be unique. You could also use a nonunique sorted or standard table, delete the duplicates, and then use a MOVE to the hashed table. This process can be time consuming. A faster way is to load a unique table with ARRAY FETCH and then deleting any duplicates. Do not use a SELECT DISTINCT if you want all key fields of the database table to appear in the internal table but not in the key. Use the DELETE ADJACENT DUPLICATES FROM <itab> to optimize. This checks whether adjacent rows have the same key. It can be used to subsequently aggregate internal tables. The internal table must be first sorted. COMPARING lets you define duplicates in terms of other fields.

July 10, 2010 100

Efficient Accessing of Data in Internal Tables

July 10, 2010 101

Selective Field Transfer

July 10, 2010 102

Using Field Symbols

July 10, 2010 103

No Field Transfer

July 10, 2010 104

Reading Single Records

July 10, 2010 105

Hashed Tables

July 10, 2010 106

Sorted Tables

July 10, 2010 107

Standard Tables

July 10, 2010 108

Reading Nested Tables

July 10, 2010 109

Mass Processing using a WHERE Clause

Only access the table lines you really need LOOP AT <itab> WHERE MODIFY <itab> WHERE DELETE <itab> WHERE SELECT-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 INTO wa WHERE mandt = sy-mandt AND vbeln IN s_vbeln. ENDLOOP.

July 10, 2010 110

Mass Processing using an Index Interval

July 10, 2010 111

Secondary Index Reading Data

July 10, 2010 112

Secondary Index Modifying Data

July 10, 2010 113

R/3 System Analysis

July 10, 2010 114

R/3 SYSTEM ANALYSIS : Overview

R/3 systems analysis: Identifies performance critical objects 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 tuners Prerequisites: Absence of basic problems (R/3 basis, database, hardware) Functioning R/3 and database monitors Representative user activity

July 10, 2010 115

R/3 Work process Overview

July 10, 2010 116

Database Process Monitor

To access the Database Process Monitor, from the initial screen of the Database Monitor choose Detailed analysis menu ORACLE session (Informix session or SQL processes , and so on as appropriate) This monitor lists the database processes and corresponding R/3 work processes. Also shows status information and the text of the SQL statements. If a program with poor database performance is identified in the Work Process 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 line containing the statement or position the cursor and choose Detail. To find out the execution plan of an SQL statement, choose Explain

July 10, 2010 117

Database Process Monitor

To call the database Lock Monitor, use Transaction code DB01 or from the R/3 initial screen, choose Tools, Administration, Monitor, Performance, Database, Exclusive lock waits. If there is a lock situation, you can see the user causing the lock and contact them 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, the transaction 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 locked for more than one transaction step, you can use R/3 enqueues. Database locks should usually be requested as late as possible. After the lock, long running SQL statements or internal-table processing should no longer be possible.

July 10, 2010 118

Thank You

July 10, 2010 119