performanance issue imp sap abap

SAP TechEd ‘03 Basel

© 2003 SAP AG SM 259, Bernd Lober; Dr. Ulrich Marquard 1

Performance Analysis in a Nutshell

Dr. Ulrich Marquard

Performance, Data Management & Scalability SAP AG

SAP AG 2003, Session SM259_EMEA, Ulrich Marquard, PDMS, SAP AG / 2

Learning Objectives

As a result of this workshop, you will be able to:

Ensure that your programs adhere to the most basic rules of scalabilityAnalyze coding for performanceKeep resource consumption of your programs within reasonable limitsOptimally use the central resources in a systemEnable optimal server-to-server communication




Agenda

Goal of Client Server Programming: Scalability

A little bit of theory and tips and tricksAppropriate indexesUse SAP BuffersNo identical accesses to persistence layerComplete WHERE clausesEnabling parallel processingLinear dependency Two round trips per user interaction

Summary



Small systemone userone server

Thousands of users

Terabytes of data

High throughput

Large objects

7*24h operation

High concurrency

Connected users

worldwide

Many servers

scalabilityScalability




Multi-Tier Architecture – Optimization Potential

Presentation

Application

Database

Internet

Layer

10-20%

60-70%

5-10%

10-20%

Load

Memory & CPU Consumption



Memory & CPU ConsumptionPhysical I/O

Controls

Compression Templates

Process DesignApplications, Customizing

OS

What? Where?Optimization Potential

Network Communication



Techn. InfrastructureDB


Architecture of mySAP Solutions

DBWP DBMS

Database

SQL Trace

SharedMemory

andBuffers

Dispatcher

WP ENQWP

EnqueueTable

SAPGUI

Gateway

SAPGUI

WebServer

Browser

ITS

WP

Dispatcher

SE30BufferTrace

EnqueueTrace

RFC Trace

Browser

ICMAN




The Architecture of mySAP Solutions

DBWP DBMS

Database

SQL Trace

SharedMemory

andBuffers

Dispatcher

WPENQWP

EnqueueTable

SAPGUI

Gateway

SAPGUI

WP

Dispatcher

SE30Buffer Trace

Enqueue Trace

RFC Trace

Browser

Approx. 2.6KB

20KB

10MB

100 MB

10 GB

10GB – 2 TB

0.1ms

1ms

10ms

10ms

0.01ms

WebServer

ITS

Browser

ICMAN


Agenda


A little bit of theory and tips and tricksAppropriate indexes

How to keep the number of searched records small

Use buffers and cachesNo identical accesses to persistence layer (DB) within one transactionComplete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step

Summary




Theory: Layout of Tables and Indexes

TableIndex A

Block 2

Block 3

Block 1

4

5

123

6

7

Record 4

Record 2

Record 5Record 1Record 6

Record 7

Record 3

Index B

217

4

5

3

6


Using Indexes to Limit the Hit List I

Create primary index key1, key2, key3Index is sorted in the order specified at creation

select * from table where key1 = 002 and key2 = A and key3 = 3

key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

002 A 3




Using Indexes to Limit the Hit List II


select * where key1 = 002 and key2 = A

key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

002002002002

AAAA

1368


Using Indexes to Limit the Hit List III


select * from table where key1 = 002 and key3 = 3 (range scan for key2)

select * from table where key1 = 002 and key2 BETWEEN A and D and key3 = 3)

key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

002002002002002002002002002002

AAAABBBC

DC

13681230

53

Exercise 1




Logon Information

System name: Dev

Server: iwdf9260.wdf.sap.corp

Router: sapgate.wdf.sap.corp

Sytem number: 00

SAP user: BC490-xx (xx team number)

Passwd: init

Client: 900


Exercise 1: Where Can an Index be Used?

A table has the following columns: NAME, FIRST NAME, CITY, CITY CODE, and STREET

A secondary index has been created with the structure NAME, CITY, STREET

In the table, the columns and operators for the WHERE clauses are given

Example: SELECT ... WHERE NAME = ' ...' and STREET = '..'

To what extent can an index be used for each statement?

NAME CITY STREET Comment1 = =2 = =3 = =4 = IN =5 = BETWEEN =6 = LIKE =7 = IN IN8 = < > =




Exercise 1

Exercise 1AOn the previous slide there is a table for which a secondary index is defined. The primary index for this table is not needed for this exercise. Using the columns of the index and the column operators, determine how the database processes the different queries.

Exercise 1B Create an ABAP report program to confirm your results from 1 A. Copy the sample program ZDS400_DB_EXERCISE1_TEMPLATE and name it ZDS400_DB_EXERCISE1_##. ## is your group number. Program the eight different operators according to the information provided. Use transaction ST05 to analyze the eight different SELECTs. Then use the database explain to determine the access path. The NAMEcolumn in the theoretical part of the exercise corresponds to the LNAMEcolumn in the hands-on exercise. As transaction ST05 is activated for the entire server, before activating the trace make sure that another user has not already started the trace.


Design Rules: Table Design vs. Index DesignKeep the Area to Be Searched Small

All frequently executed statements (selects, updates and deletes) on large tables must be supported by indexes

A highly modified table should not have too many indexes. The more columns an index has, the higher the chance that an update will affect one of the indexed columns

Columns frequently specified with ‘=‘ should be at the beginning of the index

Most selective columns firstNot selective: bukrs

Highly selective: belnr, matnr, kunnr, objnr (to bring the optimizer as soon as possible to the right index)

MANDT - as an exception - should still be part of every index at the first position

A proper index design ensures that the search time is nearly independent of the number of table rows




Agenda


A little bit of theory and tips and tricksAppropriate indexesUse buffers and caches

How to read data and make them available for other programs

No identical accesses to persistence layerComplete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step

Summary


Program Buffer

Screen BufferCUA Buffer

DDIC buffersDDIC buffersDDIC buffersNametab Buffers

Export/Import

Calendar Buffer

DDIC buffersDDIC buffersDDIC buffersTable Buffers

Buffering Data

OTR Buffer

Export/Import SHM

DBWP DBMS

Database

SQL Trace

SharedMemory

andBuffers

Dispatcher

WPENQWP

SAPGUI

SAPGUI

SE30Buffer Trace

Enqueue Trace

Browser

WebServer

ITS

Browser

ICMAN




Screenshot of Transaction ST02


Buffered Objects – Detail Screen




Buffer Types

Single Record Buffer

key1 key2 key3 data001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

key1 key2 key3 data

key1 key2 key3 data

Fully Buffering(100%)

Generic Buffering1 Key Field

Generic Buffering2 Key Fields

001001001001002002002002002002003003003003003003003003

key1 key2 key3 data001001001001002002002002002002002002003003003003003003003003003003003

AA

BB

AABBBC

DC

AAABBCCCDDD

Generic Buffers


Screenshot of Transaction SE13




Table Buffers – Checklist

In a production system, the following tables may be considered for buffering

Small tablesTables that are mainly accessed for readingFor example, control tables, Customizing tables, or 'small' master data tables

Check whether buffering allowedNo, 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 bufferChoose the right buffering typeBe aware that not all statements can make use of the bufferAvoid displacement or synchronization

Some statements may bypass the buffers

Consider granularity of invalidation


Statements that Bypass the Buffer

SELECT ... BYPASSING BUFFER

SELECT ... FOR UPDATE

Any aggregate function (COUNT, MIN, MAX, SUM, AVG), GROUP BYSELECT MIN(F1) FROM T1 WHERE ...

SELECT DISTINCT ...

WHERE clause contains ... IS [NOT] NULL

ORDER BY (other than PRIMARY KEY)

Joins in Open SQL (SELECT ... JOIN ON ...)

Any native SQL statement

For single-record buffering, every statement where the key is not fully specified (key word: SELECT SINGLE required)

For generic buffering, the generic key must be specified




Granularity of Invalidation

Resident (100%) Bufferable TablesAny change invalidates the entire buffered table on all other application servers and updates the local buffer

Generic Bufferable TablesGeneric Key

Fully specified: Only the corresponding generic area is marked as invalid on other application servers and updated in the local bufferNot fully specified: The entire table is marked as invalid on other application servers and updated in the local buffer

Single Record Bufferable TablesA change in the work area invalidates one buffered recordOther changes invalidate the whole table

Bufferable ViewsInvalidated whenever a base table is changedAlways completely invalidatedSynchronization with transport layer supported since SAP R/3 Release 4.6C


Exercise 2 on Buffering

Exercise 2Would you buffer the table that contains the currency conversiondata?Would you buffer the table that contains the material stock information?

For both questions 1. Reflect on the pros and cons with your partner 2. Check the settings of tables TCURR and MARD in the SAP System




Agenda


A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layer

How to avoid several accesses to the same data within one transaction

Complete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step

Summary


...FG1 FG2 FG3 FG4 FG5Consumers during one transaction

Read Modules = Buffers in Application Program

Database (Disks)

DBMS

Application Server

Table(s)

Database (Disks)

DBMS

Application Server

Table(s)

Buffer (Table Buffer and Read Modules)

...FG1 FG2 FG3 FG4 FG5Consumers during one transaction




Read Modules = ABAP Buffers

Read modules are special function groups or classes that store information read from the database in global internal tables.

The visibility of the data is restricted to one SAP Logical Unit of Work (LUW)

Read modules should be used:When buffering the information using the technical settings of the table is not feasibleTo prevent unnecessary database calls when the same data record is used in different program units of the transactionTo ensure consistent data within one transaction


Requirements for Read Modules

Read Modules mustSupport different access types to the data to

Allow flexible useSupport a prefetch technique

Be designed to operate well in long-running transactions and programs; the size of the buffer needs to be controllable, both internally and externallyBuffer: No Record FoundWork both for dirty read and selects protected by an enqueue.

To check for identical SELECT statementsUse transaction ST05Statement Summary

Second column "No. Of identical selects in percent




Exercise 3 on Read Modules

What is the use of writing a read module with buffering for the table TCURR?

Discuss the pros and cons with your partner in view of exercise 2


Agenda


A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clauses

How to keep the number of transferred data records small

Enable parallel processingLinear dependency Two round trips per user interaction step

Summary




Keep the Amount of Transferred Data Small

Read only needed rows of a table

Use WHERE clauses to filter dataDon't use CHECK statements

To check the number of selected recordsUse transaction ST05 Statement SummarySort column "Records"

Also possibleUse field listsUse aggregate functions


Use WHERE Clauses Whenever Possible

SELECT * FROM tableWHERE field1 = '001’ AND field2 >= 'ABC'.

... do something ...ENDSELECT.

SELECT * FROM table.CHECK field1 = '001'.CHECK field2 >= 'ABC'.... do something...

ENDSELECT.




Use Projection Views and Field Lists

Use projection views defined in ABAP Dictionary

Use field list (SELECT clause)

Reduce Amount of Data Transferred

Exercise 4

SELECT column1 column2 INTO (f1, f2) FROM table WHERE condition.

... do something ...

ENDSELECT.


Exercise 4: Automatic Use of DB Array Interfaces

Copy the sample ABAP report program DS400_DB_EXERCISE2_TEMPLATE to ZDS400_DB_EXERCISE2_##,where ## is your group number.

Program two selects of the ZDS400_TAB1 table, one using SELECT/ENDSELECT and one using SELECT INTO TABLE.

Use transaction ST05 to see what the differences are.




Use Aggregate Functions - COUNT, SUM, MAX, MIN, AVG

SELECT SUM( amount ) INTO sum FROM tab WHERE year = '1996'.

sum = 0.SELECT amount INTO amt FROM tab WHERE year = '1996'.

sum = sum + amt. ENDSELECT.

Note: Aggregate functions bypass the buffer



Use Aggregate Functions - GROUP BY/HAVING

SELECT year SUM( amount ) INTO (y, sum) FROM tableWHERE company = '0001'GROUP BY year.... do something ...

ENDSELECT.

SELECT year SUM( amount ) INTO (y, sum) FROM tableWHERE company = '0001'GROUP BY yearHAVING sum( amount ) > 1000000.... do something ...

ENDSELECT.





Use Aggregate Functions - Problems

Database may round differently than ABAP Dictionary

Databases can handle null values - ABAP does notAVG (1, 3, null, null) = 2 DBAVG (1, 3, 0, 0) = 1 ABAP

Choose the correct type for the target columnFor AVG, use a floating point typeFor SUM, use a type larger than the original to handle overflows



Use Aggregate Functions to Update

Use UPDATE SET when possible:

UPDATE tab SET f3 = f3 + c “sometimes no SELECTWHERE f1 = A and f2 = B. “necessary

SELECT * from tab WHERE f1 = A and f2 = B.ADD c TO tab-f3. UPDATE tab. “every index must be maintained

ENDSELECT. “rollback/redo is written for all columns

Also possible:UPDATE tab SET tab~f3 = tab~f3 + tab~f4

WHERE f1 = A and f2 = B.





Agenda


A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clausesEnable parallel processing

How to make proper use of database locks and SAP enqueues

Linear dependency Two round trips per user interaction step

Summary


Workload Balancing

idle

idle

idle

Parallel processing (optimal load distribution)

Sequential processing

Parallel processing (not optimized load distribution)

time

WP1

WP4WP3WP2WP1

WP4

WP3WP2

WP1




Parallel Processing in a Process Chain

A balanced load distribution is especially important for processes in a process chain.

Each step must be finished completely before starting the next one.

Reduce processing time of each single step to reduce the processing time of the whole chain ( total time ≈ t1 + t2 + t3 + t4)

Do not waste time or leave resources unused

t2 t3 t4

time

t1

active

active

active

active

idle

idle

idle

POS Upload Replenishment Deliveries Transfer Orders


Load Distribution on Several Processes: Static Approach

Start and define parallel processes manuallyDivide your work completely into several fixed packages (e.g. bynumber intervals or site groups) beforehandStart several sessions of the same report as batch jobs, each with different parameters

Batch Process 1

Batch Process 2

Batch Process 3

Batch Process 4

Batch Process 5




Run one report that starts other processes with fixed packagesHand over all the work to one report The report divides it completely into suitable packages (e.g. same number of IDOCs)Further processes are started with fixed packages

Load Distribution on Several Processes: Improved Static Approach

Dialog/Batch Process 1






Load Distribution on Several Processes: Dynamic Approach

Dynamic Workload DistributionHand over all work to a report The report starts other processes and distributes the work in small packages dynamically (next item after completion of previous)

Dialog Process 5

Dialog Process 1

Dialog Process 2

Dialog Process 3

Dialog Process 4

"Distributor"




How to parallelize

Schedule multiple batch jobsOptimal for long-running, independent tasks

Use tRFCs Useful for short, independent tasks that may run on other systems

Use aRFCsUseful for short tasks that must be synchronized

Use parallel query, parallel sort, ...Only useful for very specific "administrative" tasks due to database dependencies


Locking Problems

Processes can block each other by enqueue locks, semaphore locks or (as in this graphic) a database lock.

Time

WP1

WP2

WP3

Update record 1 Commit



Wait time

Wait time




Exercise 5: On Parallelization

Assume, the processing time for an elementary task is 1 second, including a minimum locking time of 0.5 seconds

How many parallel processes achieve optimal throughput?


Agenda


A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clausesEnable parallel processingLinear dependency

How to make optimal use of internal tablesTwo round trips per user interaction step

Summary




Internal Tables and “Linear” Programming

Linear extrapolation from small arrays

Size of internal tables n, m

Non-linear behavior for large tables

Linear extrapolation from small non-array processing

xxx

100 10.00010

T


Using Internal Tables

Avoid too large internal tablesFor example, process you data in packages instead of one large chunk

Choose the right internal table type

To check the size of internal tablesUse transaction SE30, Runtime AnalysisUse special screens in the ABAP Debugger11




Overview: Table Types

most flexibletype

Remark

must be unique

unique ornon unique

non uniqueKey

only by keyby keyby indexMain Access Type

for single linesfor key rangesvariableMain Access Range

HashedSortedStandard


Review: Accessing Internal Tables

Work area versus header lineTry to avoid header lines, they can cause errors

TRANSPORTINGREAD TABLE works with TRANSPORTING fieldlist and ‘NO FIELDS’LOOP AT ITAB does not work with TRANSPORTING fieldlistUse fieldlist if amount of transported data is reduced considerably Use TRANPORTING NO FIELDS if only SY-INDEX or SY-SUBRC is needed

ASSIGNING (from SAP R/3 4.5)Direct table access without copying to work areaAlso no MODIFY necessary




Runtimes for Table Accesses

Slowest table access are sequential and grow linearly with n READ standard table with (table) key (no BINARY SEARCH)LOOP at table where READ hashed table with key (not table key)

Faster access use a sorted index and have a weak dependence on nREAD standard table with key with BINARY SEARCH (must be sorted)READ sorted table with table key

Fastest accesses are independent of nREAD hashed table with table keyREAD standard table with indexREAD sorted table with index

Note: n = number of lines in itabExercise 6


Program: ZDS400_ABAP_EX_1Task: Runtimes for different table accesses should be measured. Your task: Start the program from SE38, then you can select up to 6 out of the following 9 access types which can be measured in parallel:

Note, on a standard table the READ standard table WITH TABLE KEYdoes not use binary search, but the READ standard table WITH KEYBINARY SEARCH (table must be sorted).Note, 3-1 does not make sense, as a hashed table has no index.

Exercise 6: Reading Internal Tables I

Read with Key

Read with Index

Standard Table

1-1

Sorted Table

2-1

3-1

Read with Table Key

1-2 1-3

2-2 2-3

3-2 3-3Hashed Table




Exercise 6: Reading Internal Tables II

Further parameters

The number of lines of the table is determined by N, with N = N_init + N_inc * N_i and N_i = 1,... N_loops

For better statistics the whole procedure can be repeated S_loops times

The detail level of the result can be determined by detail parameters detail_1, detail_2 and detail_3:

If detail_1 is active, then the runtimes for individual reads are shown. This allows to check whether runtime of the read depends on the address of the read, i.e. whether it is shorter if the wanted entry is at the beginning of the table and longer if it is at the end (that is true with sequential reads). Ten reads to equidistant locations are programmed.If detail_2 is active, then the average over these 10 reads is shown.If detail_3 is active, then the overall-average 10 * s_loops is shown.

Start the program with the default parameters and increase the table size


Runtimes for Table Accesses (Scaling)

O(1) Read with Generic

Key => O(n)!

after Sorting Read with Key

BINARY SEARCH

Remarks

O(1)O(log n)O(n)Read with Key

impossibleO(1)O(1)Read Index

HashedSortedStandard




Review: Filling Internal Tables

Internal tables can be filled

From DB tables Best with array fetch INTO TABLE or APPENDING TABLEIf possible, try to use identical line types, as the command INTO CORRESPONDING FIELDS signifies an overhead for accesses to buffered tables

From other internal tablesBest with array fetch APPEND LINES OF or INSERT LINES OFBeware that MOVE-CORRESPONDING works only on the work area

With COLLECT lines with identical key are aggregated to one line, all numeric fields are summed up automatically


Runtimes for Filling Tables

APPENDOnly for standard table: independent of n

INSERT : Standard table: ~ n Location (Index) must be determined with READ. Use BINARY SEARCH as insert is only useful on sorted standard tables. Becomes faster for n > 4096 when a B* index is used.Sorted table: ~ log n Direct INSERT with similar cost as above. Rearrangement is lessexpensive as a B* index is usedHashed table: ~ independent of n Finding location is cheap. Rearrangement of the hashed function also.

B* index: see index on database




Internal Tables: Performance Checklist

Use the right table type:Standard table for multiple access types, use BINARY SEARCH for mass accesses and try to SORT only onceSorted table, if generic key access is main access typeHashed table if single line access with fully specified key is only access type

Fill table efficientlyuse array operations and APPEND or INSERT

Use TRANSPORTING fieldlist / NO FIELDS if useful

Use ASSIGNING especially in nested tables

Try to keep internal tables small


Hashed Tables Versus Sorted Tables

Hashed tables can only be used if main access uses full table keyGeneric accesses are very slow Best example: Key contains a GUID

Which single line access is faster ?The scaling of hashed-tables is better However, access costs are similar to sorted tables for sizes up to 100There is a slight advantage for hashed tables for very large tables

However, keep in mind:That internal tables should generally not become too largeMost large tables are large because operations work on generic key ranges and not only on single lines




Sorted Standard Table Versus Sorted Table

Sorted Standard TableAccess with binary search as good as access on sorted tableMost flexible table

Different access types can be supportedFastest filling method:

If it is not necessary that the table is always sorted during fillingUse APPEND , ... , APPEND and one SORT at the endA small number of additions should use INSERT instead of APPEND

Sort is expensive as O(n log n).Every unnecessary extra sort should be avoidedNote: The most expensive SORT is the one on an already sorted table

Sorted tables Are much more convenient if a specific order must be always guaranteed


Agenda


A little bit of theory and tips and tricksAppropriate indexesUse buffers and cachesNo identical accesses to persistence layerComplete WHERE clausesEnable parallel processingLinear dependency Two round trips per user interaction step

How to use controls efficiently

Summary




SAP GUI Interaction Model - Controls

Control Framework

Automation Controller

Frontend

Backend

Automation HandlingJava OLE

ABAP ProgramCALL METHOD1.CALL METHOD2.

RFC

ActiveXControl

Application Server

SAP GUI Client

Automatic Flush

Automation Queue


Controls – Round Trips in a WAN

Improve Performance by Minimizing Round Trips

Particularly important in a WAN environment (high latency times)

Latency times in a WAN environment approx. 0.3 seconds

For satellite connections approx. 0.5 seconds

Increasing bandwidth does not improve round-trip performance

Take WAN users into account by querying the Low Speed Connectionindicator that can be set in SAP GUI

Provide the user an ability to reduce the amount of data, such as by providing an option to only display part of a document

Avoid unnecessary calls of SAPGUI_PROGRESS_INDICATOR

The same arguments hold for RFC communication between applications

Use bulk processing instead of single processing

Reuse existing connections whenever possible

Exercise 7




Exercise 7: Measure Roundtrip Times

Call transaction Performance Trace (ST05). Activate the SQL trace and RFC trace.

Execute program ZDS400_CONTROLS_ALVGRID:With SE38, count the round trips and the runtime of the round tripsFrom SE80, count the round trips and the runtime of the round trips. Why do you see more round trips in the trace ?

Find out who triggers the flushes. Use the debugger and set an breakpoint in function module ‘AC_FLUSH_CALL’.


Agenda


A little bit of theory and tips and tricksAppropriate indexesUse SAP BuffersNo identical accesses to persistence layerComplete WHERE clausesEnabling parallel processingLinear dependency Two round trips per user interaction

Summary




Summary: A Checklist for Scalable Client-Server Programs

Checklist for Adherence to General Programming GuidelinesIn this list,you can tick off whether your test case adheres to the general programming guidelines with respect to performance. If any of these characteristics do not apply to your test case, feel free to skip them. For later regression testing, you can e


Further Information

Service Marketplacehttp://service.sap.com/performancehttp://service.sap.com/sizinghttp://service.sap.com/quicksizing

Public Webwww.sap.com/benchmark

Related Workshops/Lectures at SAP TechEd 2003SM101 Performance, Scalability and Sizing of mySAP Business Solutions

Wed Oct 1 02.00-03.00 pm, Room L3Thu Oct 2 11.00-12.00 am, Room L1

SM205 Capacity Planning when Upgrading to SAP R/3 EnterpriseWed Oct 1 11.00-12.00 am, Room 9




Questions?

Q&A


Feedback

Please complete your session evaluation anddrop it in the box on your way out.

Thank You !

The SAP TechEd ’03 Basel Team




Solution to # 1 - Indexes With Different Operators

The results of index use may be different for different databasesystems.

Case 1: The database checks NAME in the index. Most database systems will not check STREET in the index but instead will read the data blocks.Case 2: The index is not used.Case 3: Both NAME and CITY are checked in the index.Case 4: Most database systems will use all three index columns by splitting the values for CITY. Case 5: Both NAME and CITY are checked in the index. Most database systems will also check STREET in the index. Case 6: All database systems will only check NAME and CITY in the index.Case 7: Most database systems will only check NAME and CITY in the index, but not STREET. Case 8: All database systems will only check NAME in the index.


Solution to # 2 – Buffering

Question no. 1: Yes, it makes sense to buffer a relatively static currency conversion table

In the SAP system, table TCURR is buffered

Question no. 2: No, because a table which includes material stock information is subject to frequent changes

In the SAP system, table MARD is not allowed to be buffered




Solution to # 3 - Read Modules

It does not make sense to write a read module for an already buffered table, because it is a waste of memory.


Solution to # 4 - Array Access

With transaction ST05, you can see that the database behaves exactly the same in both cases.

As long as you do not program an ‘UP TO n rows’ in ABAP, the database gets as many table rows as possible per communication step (as many as fit in 32K).

However, you will notice differences in memory behavior for eachmethod.




Solution to # 5 – Parallel Processes

Two tasks per second.

In this case, and if there is ideal scheduling, two parallel processes are sufficient to achieve optimal throughput.


Solution to # 6 - Internal Tables I

Runtimes for different reads should be comparedTypical runtimes should be seenDependence on N should be discussedDependence on address in table (beginning or end) should be discussed

Fastest read access is independent of table size: read with index on standard or sorted table and read hashed table with full table key

0,0

0,5

1,0

1,5

2,0

2,5

3,0

3,5

4,0

4,5

5,0

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

no of table lines

runt

ime

(mic

ro s

ec)

standard table with index sorted table with index hashed table with table key




Solution to # 6- Internal Tables II

Medium fast read access has a logarithmic dependence of table sizeRead standard table with key binary search, where table must be sorted in advanceRead sorted table with key Read sorted table with table key (slower because table key has an additional dummy field, without extra information, which has to be checked)

0,0

2,0

4,0

6,0

8,0

10,0

12,0

0 1000 2000 3000 4000 5000 6000 7000 8000 9000no of table lines

runt

ime

(mic

ro s

ec)

standard table (binary search) sorted table with table key sorted table with key


Solution to # 6 - Internal Tables III

Slowest read access depends linearly on table size:Read hashed table with key (not full table key). Note, if the key is full table key syntax check requires the usage with ‘table key’!).Read standard table with table key (no binary search)Not tested, but similar. Key for read sorted table with key must be indentical to the table from the start, otherwise runtime is also linear (full scan).

0,0

200,0

400,0

600,0

800,0

1000,0

1200,0

1400,0

1600,0

1800,0

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

no of table lines

ruun

time

(mic

ro s

ec)

standard table with table key hashed table with key




No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA® is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.

Copyright 2003 SAP AG. All Rights Reserved

performanance issue imp sap abap

Documents