Tips for ABAP Performance Tunning
1. The average database time for a sequential read (SELECT … ENDSELECT, SELECT … INTO TABLE) should be around 10 milliseconds per data record, while for a direct read (SELECT SINGLE …) it should be around 5 milliseconds per data record.
2. Accesses that change data (UPDATE, INSERT, MODIFY, DELETE) should require around 20 milliseconds per data record. The times stated are for actually reading data from disk in the database.
3. If the data records are read from the database buffer, around 1 millisecond is required instead of approximately 10 milliseconds per data record. If the required data are located in the R/3 buffers on the application server, accessing them requires approximately 0.1 milliseconds (100 microseconds) per data record.
4. As a general rule you should consider any SQL access that exceeds 200,000 ms to be a problem. This includes a single database operation or a nested SQL statement with the same strategy (total of all SQL statements nested together). Likewise a SQL statement with 10 or more FETCHes should generally be considered a problem.
5. Base on the result of Workload Monitor (ST03), if the database time is greater than 40% you should start with the SQL Performance Trace. If the CPU time is greater than 40% you should start with the ABAP Runtime Analysis.
6. In ST03 result, if the average database response time per transaction step is greater than 600ms, the cause is very probably a fundamental R/3 or database problem.
7. On some databases (for example, Oracle and Informix), fragmented indexes may occur. The term fragmented indexes means that index blocks are less than 50% full. Fragmented indexes can occur, for example, if a large number of table records are deleted and then a large number of table records are inserted. If you discover that an index is suitable for a SQL statement, but that executing the SQL statement causes heavy database system load, your database administrator should check whether a fragmented index is causing the problem.
continue...