Preformance tuning,its urgent,i would appreciate ur help

Question

hi
    I have some problem with performance tuning
SELECT stlty
           stlnr
           stlkn
           stpoz
           idnrk
      FROM stpo
      INTO TABLE t_detail
       FOR ALL ENTRIES IN t_header
*MOD04{
       WHERE stlnr eq t_header-stlnr
        AND postp EQ p_postp
        AND lkenz NE c_pos
        AND stlty NE c_null.
      WHERE
      stlty IN s_stlty
       AND stlnr EQ t_header-stlnr
      AND postp EQ p_postp
      AND lkenz EQ space.
*}MOD04
*}MOD03
    IF sy-subrc <> 0.  "t_detail[] IS INITIAL.
      MESSAGE s045.  "No Data found for the given selection criteria
      LEAVE LIST-PROCESSING.
    ELSE.
      SORT t_detail BY stlnr.
    ENDIF.  "t_detail[] IS INITIAL.
iam getting some problem in performance tuning,its displaying as fetch request as 65% from stpo
i have to use some other table other than stpo,there is no other table than stpo,how to do it.even i cheked the indexes used as well
i would be extremely thankfull for ur valuable answers

Answer 1

Hi,
chk this you might get some idea...
Performance Analysis
Interpreting and correcting performance violations
PURPOSE
Each and every rule is outlined that results in a performance violation and explained in detail as to what to avoid while coding a program and correcting such performance violations if they exist in the code.
It is a general practice to use           Select  *  from <database>…     This statement populates all the values of the structure in the database.
The effect is many fold:-
•     It increases the time to retrieve data from database
•     There is large amount of unused data in memory
•     It increases the processing time from work area or internal tables
It is always a good practice to retrieve only the required fields. Always use the syntax      Select f1  f2  …  fn  from <database>…      
e.g.     Do not use the following statement:-
     Data: i_mara like mara occurs 0 with header line.
     Data: i_marc like marc occurs 0 with header line.
     Select * from mara
          Into table i_mara
          Where matnr in s_matnr.
     Select * from marc
          Into table i_marc
          For all entries in i_mara
          Where matnr eq i_mara-matnr.
     Instead use the following statement:-
                                   Data: begin of i_mara occurs 0,
                                        Matnr like mara-matnr,
                                              End of i_mara.
     Data: begin of i_marc occurs 0,
          Matnr like marc-matnr,
                                        Werks like marc-werks,
                                             End of i_marc.
     Select matnr from mara
          Into table i_mara
          Where matnr in s_matnr.
                                                                                The objective here is to identify all select statements in the program where there is a possibility to restrict the data retrieval from database. It identifies all select statements, which do not use the where condition effectively. It is a good practice to restrict the amount of data as this reduces the data retrieval time, improves the processing time and occupies less memory. Always use as many conditions in the where clause as possible.
e.g.     Do not use the following statement:-
     Select matnr from mara
          Into table i_mara.
Loop at i_mara.
          If i_mara-matnr+0(1) ‘A’.
               Delete i_mara index sy-tabix.
          Endif.
     Endloop.
     Instead use the following statement:-
                                        Select matnr from mara
                                             Into table i_mara
                                             Where matnr like ‘A%’.
Limit the access to database as far as possible. Accessing the same table multiple times increases the load on the database and may affect other programs accessing the same table. It is a good practice to retrieve all the relevant data from database in a single select statement into an internal table. All the processing should be done with this internal table.
e.g.     Do not use the following statement:-
     Select vbeln vkorg from vbak
          Into table i_vbak
          Where vbeln in s_vbeln.
     Loop at i_vbak.
          Case i_vbak-vkorg.
          When ‘IJI1’.
               Select hkunnr from kunh
                    Into table i_kunh
                    Where vkorg = ‘IJI1’.
          When ‘IJI2’.
               Select hkunnr from kunh
                    Into table i_kunh
                    Where vkorg = ‘IJI2’.
          When ‘IJI3’.
               Select hkunnr from kunh
                    Into table i_kunh
                    Where vkorg = ‘IJI3’.
          When ‘IJI4’.
               Select hkunnr from kunh
                    Into table i_kunh
                    Where vkorg = ‘IJI4’.
          Endcase.
     Endloop.
     Instead use the following statement:-
          Select vbeln vkorg from vbak
               Into table i_vbak
               Where vbeln in s_vbeln.
          Select hkunnr from kunh
               Into table i_kunh
               Where vkorg in (‘IJI1’,’IJI2’,’IJI3’,’IJI4’).
          Loop at i_vbak.
               Case i_vvbak-vkorg.
                    When ‘IJI1’.
                         Read table i_kunh where vkorg = i_vbak-vkorg.
                    When ‘IJI2’.
                         Read table i_kunh where vkorg = i_vbak-vkorg.
                    When ‘IJI3’.
                         Read table i_kunh where vkorg = i_vbak-vkorg.
                    When ‘IJI4’.
                         Read table i_kunh where vkorg = i_vbak-vkorg.
               Endcase.
          Endloop.
When the size of the record or the number of records in the internal table is large, doing a linear search is time consuming. It is always a good practice to search a record by binary search (Always Sort the table before doing a binary search). The difference is felt especially in the production environment where the live data is usually huge. As of release 4.0 there are new types of internal tables like SORTED and HASHED which can be effectively used to further reduce the search time and processing time.
e.g.     Do not use the following statement:-
Select matnr from mara
Into table i_mara
Where matnr in s_matnr.
     Select matnr werks from marc
          Into table i_marc
          For all entries in i_mara
          Where matnr eq i_mara-matnr.
     Loop at I_mara.
          Read table i_marc with key matnr = I_mara-matnr.
     Endloop.
Instead use the following statement:-
     Select matnr from mara
          Into table i_mara
          Where matnr in s_matnr.
                                   Select matnr werks from marc
                                        Into table i_marc
                                        For all entries in i_mara
                                       Where matnr eq i_mara-matnr.
                                   Sort I_marc by matnr.
                                   Loop at I_mara.
                                        Read table i_marc with key
matnr = I_mara-matnr
binary search.
                                   Endloop.
It is a good practice to search records from internal tables using a binary search. But extreme caution needs to be applied as it may either increase the time or may cause run time termination if it is not sorted.
Always the sort the internal table by the required keys before performing a binary search.                                                                               
e.g.     Do not use the following statement:-
Select matnr from mara
Into table i_mara
Where matnr in s_matnr.
     Select matnr werks from marc
          Into table i_marc
          For all entries in i_mara
          Where matnr eq i_mara-matnr.
     Loop at I_mara.
          Read table i_marc with key matnr = I_mara-matnr binary search.
     Endloop.
Instead use the following statement:-
     Select matnr from mara
          Into table i_mara
          Where matnr in s_matnr.
                                   Select matnr werks from marc
                                        Into table i_marc
                                        For all entries in i_mara
                                       Where matnr eq i_mara-matnr.
                                   Sort I_marc by matnr.
                                   Loop at I_mara.
                                        Read table i_marc with key
matnr = I_mara-matnr
binary search.
                                   Endloop.
It is a general practice to use           Read table <itab>…     This statement populates all the values of the structure in the workarea.
The effect is many fold:-
•     It increases the time to retrieve data from internal table
•     There is large amount of unused data in work area
•     It increases the processing time from work area later
It is always a good practice to retrieve only the required fields. Always use the syntax      Read table <itab> transporting f1 f2  …  FN …          If just a check is being performed for existence of a record use      Read table <itab> transporting no fields …
e.g.     Do not use the following statement:-
data: i_vbak like vbak occurs 0 with header line.
data: i_vbap like vbap occurs 0 with header line.
Loop at i_vbak.
     read table i_vbap with key
vbeln = i_vbak-vbeln binary search.
     If sy-subrc = 0 and i_vbap-posnr = ‘00010’.
     endif.
Endloop.
Instead use the following statement:-
data: i_vbak like vbak occurs 0 with header line.
data: i_vbap like vbap occurs 0 with header line.
Loop at i_vbak.
                              read table i_vbap transporting posnr with key
vbeln = i_vbak-vbeln binary search.
                              If sy-subrc = 0 and i_vbap-posnr = ‘00010’.
                              endif.
Endloop.
There are many ways in which a select statement can be optimized. Effective use of primary and secondary indexes is one of them. Very little attention is paid especially to the secondary indexes. The following points should be noted before writing a select statement:-
•     Always use the fields in the where clause in the same order as the keys in the database table
•     Define the secondary indexes in the database for the fields which are most frequently used in the programs
•     Always try to use the best possible secondary index in the where clause if it exists
•     Do not have many secondary indexes defined for a table
•     Use as many keys both primary and secondary as possible to optimize data retrieval
As of release 4.5 it is now possible to define the secondary index in the where clause using %_HINT.
e.g.     Do not use the following statement:-
     Assuming a secondary index is defined on the field vkorg in table vbak
     Select vbeln vkorg from vbak
          Into table i_vbak
          Where vbeln in s_vbeln.
     Loop at i_vbak.
          Case i_vbak-vkorg.
          When ‘IJI1’.
          When ‘IJI2’.
          Endcase.
     Endloop.
Instead use the following statement:-
                                   Select vbeln vkorg from vbak
                                        Into table i_vbak
                                        Where vbeln in s_vbeln and
                                             Vkorg in (‘IJI1’,’IJI2’).
                                   Loop at i_vbak.
                                        Case i_vbak-vkorg.
                                        When ‘IJI1’.
                                        When ‘IJI2’.
                                        Endcase.
                                   Endloop.
This rule identifies all select statements in the program which use      Select … UP TO 1 ROWS…      It is a general practice to use this syntax to retrieve a single record from database table. If all the primary keys of a table are used in the where clause it is a good practice to use      Select SINGLE …
e.g.     Do not use the following statement:-
     select matnr up to 1 rows from mara
          into mara-matnr
          where matnr = itab-matnr.
Instead use the following statement:-
                                   select single matnr from mara
                                        into mara-matnr
                                        where matnr = itab-matnr.
Table buffering is used to optimize data access from database. However if buffering is used on tables which are updated frequently, it has an adverse effect. The buffer area is updated at regular intervals by the system. If selection is done from this table before the buffer is updated the values are fetched first from the buffer and then from the database as the buffer is outdated.  This increases the load on the system and also the processing time.
It is always a good practice to bypass buffer in the select statement for tables, which are buffered but are updated at regular frequently.
e.g.     Do not use the following statement:-
     select  matnr from mara
          into table i_mara
          where matnr in s_matnr.
Instead use the following statement:-
                                   select matnr bypassing buffer
from mara
                                        into table i_mara
                                        where matnr in s_matnr.
Most of the performance issues are related to database. It should be an inherent practice to reduce the access to database as far as possible and use it in the most optimal manner.
Just as in select statements, database updates also affect the performance. When records are to be inserted in database table do it in once. Populate the internal table completely, with which the records are to be inserted. Then update the table from the internal table instead of updating it for each record within the loop.
e.g.     Do not use the following statement:-
     Loop at i_mara.
          Insert  into mara values i_mara.
     Endloop.
Instead use the following statement:-
Loop at i_mara.
                                        Modify i_mara.
                                   Endloop.
                                   Insert  mara from table i_mara.
Read statement fetches the record from the internal table using implicit key or explicit key. When no key or index is specified for the search criteria the key in the WA of the internal table is used implicitly for searching. SAP recommends explicit search criteria. Here the key or index is explicitly specified which is used for searching the records from internal table. This is faster than an implicit search.
e.g.     Do not use the following statement:-
     Loop at i_mara.
          i_marc-matnr = i_mara-matnr.
          read table i_marc. 
     Endloop.
Instead use the following statement:-
     Loop at i_mara.
          read table i_marc with key 
          matnr = i_mara-matnr.
     Endloop.
When an internal table is sorted without specifying the keys the default is used. This may affect he performance. Always specify the keys when sorting.
e.g.     Do not use the following statement:-
     Data : begin of i_mara occurs 0,
          ersda   like mara-ersda,
ernam  like mara-ernam,
laeda   like mara-laeda,
aenam  like mara-aenam,
vpsta   like mara-vpsta,
               End of i_mara.
     Sort i_mara.
     Loop at i_mara.
     Endloop.
Instead use the following statement:-
     Data : begin of i_mara occurs 0,
          ersda   like mara-ersda,
ernam  like mara-ernam,
laeda   like mara-laeda,
aenam  like mara-aenam,
vpsta   like mara-vpsta,
               End of i_mara.
     Sort i_mara by matnr aenam.
     Loop at i_mara.
     Endloop.
Whenever values need to be passed in a subroutine have type declarations assigned to the formal parameters. If no specific type declaration is possible then use TYPE ANY. This improves the performance. It is also recommended by SAP and can be noticed during extended program check (EPC) for the program.
e.g.     Do not use the following statement:-
perform type_test using p_var1 p_var2 p_var3.
form type_test using p_var1 p_var2 p_var3.
endform.
Instead use the following statement:-
     perform type_test using p_var1 p_var2 p_var3.
     form type_test using   p_var1  type c
p_var2  type any
p_var3  like mara-matnr.
     endform.
This is similar to type declarations for subroutines explained in Rule 13. Except that type declarations need to be maintained for field-symbols. More help is provided by SAP under TYPE ASSIGNMENTS.
e.g.     Do not use the following statement:-
field-symbols: <fs1>, <fs2>, <fs3>.
Instead use the following statement:-
field-symbols:  <fs1>   type  c,
<fs2> like mara-matnr,
<fs3> like marc-werks.
The      Do … Enddo      loop does not have a terminating condition. This has to be handled explicitly within the loop construct. This has some affect on the performance. On the other hand      While … Endwhile      loop has a condition to satisfy before entering the loop. Hence will improve the performance and is also safe to use.
e.g.     Do not use the following statement:-
Do.
If count > 20.
     Exit.
Endif.
Count = count + 1.
Enddo.
Instead use the following statement:-
While ( count < 20 ).
Endwhile.
Do not use the           CHECK           construct within      Loop … Endloop.      The end condition for check statement varies with the type of loop structure. For example within loop … endloop it moves to the next loop pass whereas in form … endform it terminates the subroutine. Thus the outcome may not be as expected. It is always safe to use      If … Endif.
e.g.     Do not use the following statement:-
     Loop at i_mara.
          Check i_mara-matnr = ‘121212’
     Endloop.
Instead use the following statement:-
     Loop at i_mara.
          If i_mara-matnr = ‘121212’
          Endif.
     Endloop.
This rule is similar to rule 16 except that it is for      Select … Endselect      statements. The affect is similar to that in loop … endloop.
e.g.     Do not use the following statement:-
     Select matnr from mara
          Into table i_mara.
          Check i_mara-matnr = ‘121212’
     Endselect.
Instead use the following statement:-
                                   Select matnr from mara
          Into table i_mara.
          If i_mara-matnr = ‘121212’
          Endif.
     Endselect.
This feature is also available in SAP Tips & Tricks. As can be seen the time measured for the same logical units of code using      if… elseif … endif      is almost twice that of      case … endcase.
It is always advisable to use case … endcase as far as possible.
e.g.     Do not use the following statement:-
IF     C1A = 'A'.   WRITE '1'.
ELSEIF C1A = 'B'.   WRITE '2'.
ELSEIF C1A = 'C'.   WRITE '3'.
ELSEIF C1A = 'D'.   WRITE '4'.
ELSEIF C1A = 'E'.   WRITE '5'.
ELSEIF C1A = 'F'.   WRITE '6'.
ELSEIF C1A = 'G'.   WRITE '7'.
ELSEIF C1A = 'H'.   WRITE '8'.
ENDIF.                        
Instead use the following statement:-
CASE C1A.             
WHEN 'A'. WRITE '1'.
WHEN 'B'. WRITE '2'.
WHEN 'C'. WRITE '3'.
WHEN 'D'. WRITE '4'.
WHEN 'E'. WRITE '5'.
WHEN 'F'. WRITE '6'.
WHEN 'G'. WRITE '7'.
WHEN 'H'. WRITE '8'.
ENDCASE.              
Sort by Clause should be used instead of Order by at database level especially in the cases where the number of records is less. When using Order by clause we need to ensure that it uses an index. This is not the case in sort by. Also the performance is significantly high for Sort by Clause especially for small number of records.
e.g.     Do not use the following statement:-
SELECT * FROM SBOOK                
         WHERE                     
           CARRID  = 'LH '      AND
           CONNID  = '0400'     AND
           FLDATE  = '19950228'    
         ORDER BY PRIMARY KEY.  
ENDSELECT.
Instead use the following statement:-
SELECT * FROM SBOOK                
         WHERE                     
           CARRID  = 'LH '      AND
           CONNID  = '0400'     AND
           FLDATE  = '19950228'    
         SORT BY PRIMARY KEY.  
ENDSELECT.
It is observed that break points are hard coded in the program during testing. Some are soft break points some are hard coded and also user specific. These are left in the program during transports and cause production problems later. This rule helps you to identify all the hard coded break points that are left in the program.
This rule is self-explanatory. Hence no examples are provided.