SAP Performance & Tuning

quicksandwalleyeInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

91 εμφανίσεις

SAP Performance & Tuning




Bonus material for 201 ABAP Interview Questions

http://www.201interviewquestions.com/books/abap.htm




Material code : BM02





Author : P.Renjith Kumar


Genie Press





The Architecture level to improve performance



The R/3 System has a three
-
layer client/server architecture,



With a
Presentation layer
, an
Application layer

and a
Database layer
.



The presentation layer and the application layer are
scalable
.




This means that if there is a hardware bottleneck, you can extend the system by adding
more front ends and application servers.



The database layer, as the central data repository, is not scalable.






Architecture





One
goal is to reduce the run time of programs on the application server, thereby reducing the
CPU load
.


Another
goal is to reduce the database load. Reducing the database load is particularly important
since the database software is not scalable
.

If the required data is in the
R/3 buffers

on the application server, accessing them requires
approximately
0.1 milliseconds

for each data record.


If the
data records

are read from the database buffer, around
1 millisecond

is required.


When the data is read from the
disk
, this requires
approximately 10 milliseconds

for each data
record.


ABAP performance analysis areas of focus
.


An R/3 work process allocates around
5 MB

of memory.


The R/3 table buffers allocate approximately
120 MB

(40 MB for single record buffers, 80
MB for generic table buffers).


The data buffers of the database use around
500 MB

of memory. The database on the disks
can reach a size of several terabytes.


The data transfer between front end and application server occurs in blocks of
2 KB.



The transfer between application server and database server occurs in blocks of up to
32
KB
.


Memory Allocation in SAP



Work process




WP

WP


WP



WP


Roll area

Work Process

To DB server


Dispatcher

Queue

From presentation server

Application server


Response time:



Time from the receipt of a user request to the sending of a response ( measured on the application
server; does not include network time between the presentation server and the application server).



Dispatcher wait time:

Time spent by the user request in the dispatcher queue.



Roll
-
in:

Time required to roll the user context in to the R/3 work process.



Load time:

Time required for loading and generating R/3 Repository or ABAP Dictionary objects.



Processing time:

= response time
-

dispatcher wait time
-

roll
-
in
-

roll
-
out
-

load time
-

database
time enqueue time
-

roll wait time



Enqueue time:



Time from sending an enqueue request to the R/3 enqueue server to the receipt of the results


General Definitions



Database time:

Time from sending an SQL statement to the receipt of the results (measured on
the application server; includes network time between the application server and the database
server).


Roll wait time:

Time in which the user context is rolled out of the work process pending response
to an RFC call.




Roll
-
out:

Time required to roll the user context in to the roll buffer.


CPU time:

Time spent by the CPU in processing the transaction step (measured by the operating
system; not an additive component of the response time).



Definitions


Work Load Monitor



ST03
-
> Performance Data base (Work Load Monitor )

Select Server , Time .


If DB response > 600 ms then there is fundamental problem with R3 / DB

.


Initial Check’s to be done to measure Performance

ST 03

DB 01

SM 50

SM50

( Snap Shot analysis )

To identify performance critical objects .

To identify long running objects


How to identify long running process ?


Refresh the screen continuously , If a work process is there

for a long time then it is long running process

Important fields to know about the action to be done :
Action / Table



Snap Shot Analysis

Check R3 based WP overview from (
SM50

)


Find long running WP and note its Action / Table field


Find Action ( Sequential / Direct / Insert )


Call DB Monitor (
DB01
)


Check if any lock is there . If so find the user who is responsible and Try

to remove the lock , Or delete the lock .


Then based on the analysis go for SQL Trace / ABAP Run time analysis


General Flow to get into tuning process


Select Proper internal table types



Standard Tables :

Used generally . Can be sorted


Sorted Tables

Sorted automatically based on key


Hashed Tables

Used when I record is to be retreived . Good in performance . Work based on hash

Key


Initial Reporting consideration

Se38
-
>ABAP Debugger
-
> Settings
-
>Memory Display On



Debugger Finding Memory

SE30 (Runtime Analysis)

T
he runtime analysis is an additional development workbench tool that is quite useful for
analyzing performance of an ABAP / 4 Program or transaction. With this tool, the system can
display information about:



Executed instruction


Accessed execution time.


Tables and Types of access.


Chronological execution flow


ST05 (SQL Trace)

he SQL trace is a tool, which allows displaying and analyzing the contents for the database
calls, which are made by the reports and transactions written in ABAP/4. It monitors
programs and transactions on the database level. With the help of this facility for every open
SQL instructions, you can display, about which SQL Embedded (DECLARE, OPEN,
FETCH) Statement have been executed, besides analyzing the system performance.


SLIN

or PROGRAM
-
> CHECK
-
> EXTENDED PROGRAM CHECK


ST03, ST02, ST04

are the tcode for workload, tuning and DB Performance Monitoring
codes.

ST 05
-
>SQL Trace
-
> Activate Trace

Go back to SE 38 .


Then Run The program from SE38 ,


Now again Come back to ST05 ,

Deactivate trace .


Now press Display Trace .


SQL Trace

SQL Trace


Buffer Trace


Enquee Trace


RFC Trace


ST05 Components



SQL Trace Internal Mechanism


The goal of using an SQL Performance Trace is to find SQL statements with a high
optimization potential
. Use three user sessions.


One user session is for the trace list, one for the compressed summary, and one for
identical selects.



From the trace list you can access Explain SQL or the ABAP code.


An expensive SQL statement is indicated when a database operation takes longer
than 200,000 milliseconds, or when more than 10 FETCHes

are required for a
database operation.





In addition, a series of SQL statements that are similar in structure usually indicate
nesting that can be optimized considerably.
If the sum of SQL statements that are
similar in structure take more than 200,000 milliseconds, they can be regarded as
expensive.



SQL Trace Goals


SE30
-
> Give Report name and Execute , Then click
Analyze ,You will get DB time and ABAP run time




Run Time analysis



Run Time Analysis ( SE 30 )











Runtime analysis ( Comparing more 2 programs )



Very effective measure to increase performance in Select queries


REPORT ZPR_PER_T1


TABLES : VBAK .


Data Begin of itab occurs 0


Include structure vbak

data end of ITAB.


Select * from vbak into table
itab .


Read table itab with key
vbeln = '400151' .


REPORT ZPR_PER_T1



TABLES : VBAK .


Data Begin of itab occurs 0 .


Include structure vbak .

data end of ITAB.


Select * from vbak into table
itab .


Read table itab with key
vbeln = '400151'
BINARY
SEARCH.



Binary Search




First see runtime analysis
( SE30 ),

try to make 50% of ABAP time and Database time.



Next SQL Trace
(ST05
), check which table is taking more time and try to minimize it by
using full key or creating index for the where clause.



Next see logic in the program, try to
avoid multiple reads on same table

and try to
minimize unnecessary data



Next try to
remove for all entries if it has large amount of data

in the for all entries
internal table.



Next try to read Header table first than item table.



Next try to
put joins



Next try to
remove nested select's
.




Steps to Improve Performance


Select field in sequence as defined in database



free intrenal table memory wnen table is not required for
further processing.








Steps to Improve Performance



Comparison of select statements

Not Recommended




REFRESH TAB_DEST.



LOOP AT TAB_SRC INTO
TAB_DEST.


APPEND TAB_DEST.




ENDLOOP



Recommended



TAB_DEST[ ] = TAB_SRC[ ].







Some changes to statements to improve performance




Use already provided aggregate functions instead of manually
coding it in ABAP.



Not Recommended


Maxnu = 0.

Select * from zflight where airln = ‘LF’
and cntry = ‘IN’.


Check zflight
-
fligh > maxnu.


Maxnu = zflight
-
fligh.


Endselect.






Recommended



Select max( fligh ) from zflight int

maxnu where airln = ‘LF’ and cntry =
‘IN’.




Similary use MIN, AVG,COUNT,and SUM
as needed.





Aggregate Function





Not Recommended


Refresh: itab_flight.


Select * from zflight into
intab_flight.


Append intab_flight.


Clear intab_flight.


Endselect.





Recommended


Refresh: intab_flight.


Select * from zflight into table
intab_flight



Avoid append statement


Not Recommended


Loop at int_fligh.


If int_fligh
-
flag is initial.


Int_fligh
-
flag = ‘X’.


Endif.


Modify int_fligh.


Endloop.






Recommended


Int_fligh
-
flag = ‘X’.


Modify int_fligh
transporting

flag where flag is initial.







Modifying lines of internal table



1.
Avoid using SELECT...ENDSELECT... construct and use
SELECT ... INTO TABLE.


2.
Use WHERE clause in your SELECT statement to
restrict the volume of data retrieved.


3.
Design your Query to Use as much index fields as
possible from left to right in your WHERE statement


4.
Either enable buffering in your database table or
create Indexes to speed up the query.


5. Use FOR ALL ENTRIES in your SELECT statement to
retrieve the matching records at one shot.



How to improve Performance

6.
Avoid using nested SELECT statement, SELECT within
LOOPs.


7.
Avoid using INTO CORRESPONDING FIELDS OF
TABLE. Instead use INTO TABLE.


8.
Avoid using SELECT * and Select only the required
fields from the table.


9.
Avoid nested loops when working with large internal
tables.


10. Use assign instead of into in LOOPs for table types
with large work areas


How to improve Performance

11.
When in doubt call transaction SE30 and use the examples
and check your code


12.
Whenever using READ TABLE use BINARY SEARCH addition
to speed up the search. Be sure to sort the internal table
before binary search.


13.
Use "CHECK" instead of IF/ENDIF whenever possible.


14.
Use "CASE" instead of IF/ENDIF whenever possible.


15. Use "MOVE" with individual variable/field moves instead of
"MOVE
-
CORRESPONDING", creates more coding but is more
effcient.




How to improve Performance


SM51


App. Servers Overview

STAT


Display Statistical Records

ST05


SQL Trace

SE30


Runtime Analysis

ST03


Analysis of Workload

DB02


Database Performance : Tables and Indexes.

DB05


Analysis of Table w.r.t. Indexed Fields

ST04


Database Performance Analysis : Oracle View

SM66


Global Work Process Overview (Over All App Servers)

SM50


Process Overview




Some useful Transactions related to performance analysis