Performance of ABAP query program

Question

Hi All,
A custom program AQNWZ_TALAT=====TCS_AP_ITEMS== is taking lot of time running. And when checked the cost of the select statement is very high.
I guessed it must be some custom abap query. Correct me if I am wrong.
Also please let me know how to do the performance tuning on this code? Should I be editing the program directly or should I edit at the abap query level.
Regards,
Pooja
Moderator message: Please Read before Posting in the Performance and Tuning Forum
Edited by: Thomas Zloch on Dec 3, 2010 11:01 AM

Answer 1

>A few tips you can use for finetuning a Report
The actually a good collection of the most important pain points. But the recommendations are unfortunately quite poor, and even wrong. I have updated them a little bit.
And for German speaking people I have added a reference to a textbook, where arll my recommendations are explained in detail.
Siegfried
1) Use mostly primary key to access data.
... nonsense, the task determines the WHERE clause, it is not your choice
2) Before READ u sort the itab
No
3) use mostly the indexes fields in ur where clause.
... as 1, it is the other way, the task determines the WHERE-clause, make surwe that there is an index which
supports it
4) Restrict the the fields retrieved by your select sentences to the minimal set. (Avoid select *)
nonsense, most SELECT use and must use *, use field list in wide tables
5) try to use specify where clause so the abap sql optimizer chooses the right index.
o.k., but who understands that in depth?
6) Avoid sentences like select lifnr name1 into corresponding fields of lfa1 from lfa1 where....
feel free to use if required
(You should declare a working area and select into the working area, is twice faster)
... such general statements are always incorrect
7) use hashed tables instead of standard tables. They are faster
no, use sorted tables, hashed are very special and can only be used if there is a unique key
8) avoid the use of collect as much as you can.
total nonsense, use collect with hashed tables, works perfect, if you use it with standard tables, do not mix it with other statements
1 Always check the driver internal tables is not empty , while using FOR ALL ENTRIES
100% correct
2 Avoid for all entries in JOINS
... not generally true
3 Try to avoid joins and use FOR ALL ENTRIES.
... hmmm, there are pages of discussions, this statement was wrong, is wrong and will be wrong!!!
4 Try to restrict the joins to 1 level only ie only for 2 tables
nonsense, joins are complicated, you must know hw indexes are used, if everything is fine, then 10 or 20 tables can be joined
5 Avoid using Select *.
see 4)
6 Avoid having multiple Selects from the same table in the same object.
... try to avoid to SELECT the same data, different criteria can be necessary
7 Try to minimize the number of variables to save memory.
... obvious,
8 The sequence of fields in 'where clause' must be as per primary/secondary index ( if any)
... no is must not the optimizer will not be influenced be the order , but do it, it increases readability
9 Avoid creation of index as far as possible
... no, o.k. if you are not experienced than avoid ... otherwise the creation of the required indexes is absolutely mandatory for new tables, for SAP standard tables most indexes are already there. But still if very new accesses are added, then new indexes can become necessary.
10 Avoid operators like , > , < & like % in where clause conditions
... no, you must add them, but be aware that the search is only poorly supported by them, but the result set is reduced.
11 Avoid select/select single statements in loops.
... if they are going to the database! If the tables are buffered, then these statements are perfect!
12 Try to use 'binary search' in READ internal table. Ensure table is sorted before using BINARY SEARCH.
.... Actually try to avoid standard tables, use sorted tables instead. If you must use a standard table, than the recommendation is true.
13 Avoid using aggregate functions (SUM, MAX etc) in selects ( GROUP BY , HAVING,)
.... no, use them if required. Again, if table is buffered, then they MUST be avoided.
14 Avoid using ORDER BY in selects
... if it is not ORDER BY PRIMARY KEY. Again, if the table is buffered, then other orders MUST be avoided.
15 Avoid Nested Selects
... use join. Again, if the tables are buffered, then Nested SELECTs are fine!
16 Avoid Nested Loops of Internal Tables
.... impossible, there is no other option. Use sorted tables and verything is fine!
17 Try to use FIELD SYMBOLS.
... what means try? Use ASSIGNING fieldsymbol in LOOPs, but use it in READs only for very wide tables (>1kB). Use it always for tables with tables in the workarea!
18 Try to avoid into Corresponding Fields of
... see 6) is wrong!
19 Avoid using Select Distinct, Use DELETE ADJACENT.
.... no, use it if required and if it can reduce the result set by a factor of 2 or more. Again, if table is buffered, then it MUST be avoided.
Wenn Sie mit der Performance Ihres ABAP Programms nicht zufrieden sind, werfen Sie doch einen Blick in mein neues Buch:
Siegfried Boes: Performance-Optimierung von ABAP®-Programmen Nov. 2009 464 Seiten  59u20AC
Leseproben und weitere Informationen: http://www.dpunkt.de/buecher/3096.html
Edited by: Thomas Zloch on Dec 3, 2010 10:53 AM