SAP R/3 форум ABAP консультантов

[admin]

Some useful transactions related for Performance Analysis
SM51 - App. Servers Overview
STAT
ST05
SE30
ST03
DB02
DB05
ST04
SM66
SM50

ABAP Performance and Tuning

Q. What tools can be used to help with performance tuning?

A. ST05 is the SQL Trace transaction and can be used to measure the performance of the select statements of the program. SE30 (SAT) is the Runtime Analysis transaction and can be used to measure the application performance. It also gives some tips on how to improve the performance through efficient code.

One of the best tools for static performance analyzing is Code Inspector (SCI). There are many options for finding common mistakes and possible performance bottlenecks.

Q. What are the steps to optimise the ABAP Code?
- Avoid using SELECT...ENDSELECT... construct and use SELECT ... INTO TABLE.
- Use WHERE clause in your SELECT statement to restrict the volume of data retrieved.
- Design your Query to Use as much index fields as possible from left to right in your WHERE statement
- Use FOR ALL ENTRIES in your SELECT statement to retrieve the matching records at one shot.
- Avoid using nested SELECT statement, SELECT within LOOPs.
- Avoid using INTO CORRESPONDING FIELDS OF TABLE. Instead use INTO TABLE.
- Avoid using SELECT * and Select only the required fields from the table.
- Avoid nested loops when working with large internal tables.
- Use assign instead of into in LOOPs for table types with large work areas
- When in doubt call transaction SE30 and use the examples and check your code
- Whenever using READ TABLE use BINARY SEARCH addition to speed up the search. Be sure to sort the internal table before binary search. This is a general thumb rule but typically if you are sure that the data in internal table is less than 200 entries you need not do SORT and use BINARY SEARCH since this is an overhead in performance.
- Use "CHECK" instead of IF/ENDIF whenever possible.
- Use "CASE" instead of IF/ENDIF whenever possible.
- Use "MOVE" with individual variable/field moves instead of "MOVE-CORRESPONDING", creates more coding but is more effcient.
- TABLE BUFFERING : This can help in improving the performance but this has to be used with caution. Buffering of tables leads to data being read from the buffer rather than from table. Buffer sync with table happens periodically. If this table is a transaction table chances are that the data is changing for a particular selection criteria. Using table buffering in such cases is not recommended. Use Table Buffering for Master Data or data which is having low transaction. Also, when using a table with buffering ensure that the general criteria which is used for buffering is also being used. If the criteria of buffering is not same as the one used in your code, it has no effect and buffering will not be useful instead it will cause a overhead on performance since evrytime it will fill the buffer. In such cases use 'BYPASSING BUFFER' to speed up the SQL's.
- INDEX: Creation of Index for improving performance should not be taken without thought. Index speeds up the performance but at the same time adds two overheads namely; memory and insert/append performance. When INDEX is created, memory is used up for storing the index and index sizes can be quite big on large transaction tables! When inserting new entry in the table, all the index's are updated. More index more time. More the amount of data, bigger the indices, larger the time for updating all the indices.
- PERFORM : When writing a subroutine, always provide type for all the paramters. This reduces the overhead which is present when system determines on it's own each type from the formal parameters that are passed.
- Updating/Modifying internal tables: In case the amount of entries are more than 200 in an internal table and some field's are being manipulated or some column of the internal table being filled based on some logic, usage of FIELD-SYMBOLS is recommended. This removes the overhead of moving the operation via a seperate memory area (work area).

Q. What is the difference between SELECT SINGLE and SELECT ... UP TO 1 ROWS?

A. SELECT SINGLE returns the first matching row for the given condition and it may not be unique, if there are more matching rows for the given condition.

SELECT ... UP TO 1 ROWS retrieves all the matching records and applies aggregation and ordering and returns the first record.

Inorder to check for the existence of a record then it is better to use SELECT SINGLE than using SELECT ... UP TO 1 ROWS since it uses low memory and has better performance.

Q. Which is the better - JOINS or SELECT... FOR ALL ENTRIES...?

A. The effect of FOR ALL ENTRIES need to be observed first by running a test program and analyzng SQL trace. Certain options set by BASIS can cause FOR ALL ENTRIES to execute as an 'OR' condition. This means if the table being used FOR ALL ENTRIES has 3 records, SQL Trace will show 3 SQL's getting executed. In such a case using FOR ALL ENTRIES is useless. However of the SQL Trace shows 1 SQL statement it's beneficial since in this case FOR ALL ENTRIES is actually getting executed as an IN List.

JOINS are recommended to be used till 5 joins. If the JOIN is being made on fields which are key fields in both the tables, it reduced program overhead and increases performance. So, if the JOIN is between two tables where the JOINING KEYS are key fields JOIN is recommended over FOR ALL ENTRIES.

Performance Notes

The performance of an ABAP program is largely determined by the efficiency of its database accesses. It is therefore worth analyzing your SQL statements closely. To help you to do this, you should use the Performance Trace and Runtime Analysis tools (Test menu in the ABAP Workbench). In particular, the SQL Trace in the Performance Trace shows you which parts of Open SQL statements are processed where, and how long they take.

Keep the Result Set Small

Minimize the Amount of Data Transferred

Minimize the Number of Data Transfers

Minimize the Search Overhead

Reduce the Database Load

Указания %_HINTS базе данных в ABAP Open SQL - http://www.sapbasis.ru/articles/opensqlhints/

Анализ таблиц и пересбор статистики
DB05 - Index Analysis
DB20 - Optimizer and Edit table Statistcis