Presentation is loading. Please wait.

Presentation is loading. Please wait.

SAP Performance & Tuning Bonus material for 201 ABAP Interview Questions Material code : BM02 Author.

Similar presentations

Presentation on theme: "SAP Performance & Tuning Bonus material for 201 ABAP Interview Questions Material code : BM02 Author."— Presentation transcript:

1 SAP Performance & Tuning Bonus material for 201 ABAP Interview Questions Material code : BM02 Author : P.Renjith Kumar Genie Press

2 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

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

4 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

5 Work process WP Roll area Work Process To DB server Dispatcher Queue From presentation server Application server

6 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

7 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

8 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 Checks to be done to measure Performance

9 ST 03

10 DB 01

11 SM 50

12 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

13 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

14 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

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

16 SE30 (Runtime Analysis) The 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.

17 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

18 Buffer Trace Enquee Trace RFC Trace ST05 Components

19 SQL Trace Internal Mechanism

20 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

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

22 Run Time Analysis ( SE 30 )




26 Runtime analysis ( Comparing more 2 programs )

27 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

28 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

29 Select field in sequence as defined in database free intrenal table memory wnen table is not required for further processing. Steps to Improve Performance

30 Comparison of select statements

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

Download ppt "SAP Performance & Tuning Bonus material for 201 ABAP Interview Questions Material code : BM02 Author."

Similar presentations

Ads by Google