<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Performance tuning in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268366#M781182</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Please rethink your SELECT statement whether it is really correct,&lt;/P&gt;&lt;P&gt;you ha´ve 3 INNER JOINs plus 2 OUTER JOINs, this is defiinitely too hard.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;But why do need OUTER JOINS.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The FOR ALL ENTRIES can not be used for the OUTER JOINS.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You must check which order opf execution would be optimal and check whether it is index supported or&lt;/P&gt;&lt;P&gt;can be made index-support (new fields in WHERE or ON  or new index). Then it might be possible to find&lt;/P&gt;&lt;P&gt;a performant subset of joins.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The rest must be added manually. It is also possible to write an OUTER JOIN in ABAP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Siegfried&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 21 Jan 2008 09:19:41 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2008-01-21T09:19:41Z</dc:date>
    <item>
      <title>Performance tuning</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268363#M781179</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi... &lt;/P&gt;&lt;P&gt;It may sound absurd pasting the whole select query but I could not help out. Please guide if the following select query can be corrected. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt; SELECT t1&lt;SUB&gt;matnr t1&lt;/SUB&gt;werks t4&lt;SUB&gt;charg t1&lt;/SUB&gt;fevor t1&lt;SUB&gt;dispo t1&lt;/SUB&gt;lzeih&lt;/P&gt;&lt;P&gt;         t7&lt;SUB&gt;berid  t2&lt;/SUB&gt;mhdhb t2&lt;SUB&gt;mhdrz  t3&lt;/SUB&gt;maktx t3&lt;SUB&gt;spras t4&lt;/SUB&gt;hsdat t4&lt;SUB&gt;vfdat t4&lt;/SUB&gt;cuobj_bm&lt;/P&gt;&lt;P&gt;         t5&lt;SUB&gt;lgort  t6&lt;/SUB&gt;aufnr&lt;/P&gt;&lt;P&gt;      FROM marc AS t1 INNER JOIN mara AS t2&lt;/P&gt;&lt;P&gt;       ON t2&lt;SUB&gt;matnr = t1&lt;/SUB&gt;matnr&lt;/P&gt;&lt;P&gt;         INNER JOIN makt AS t3&lt;/P&gt;&lt;P&gt;         ON t3&lt;SUB&gt;matnr = t1&lt;/SUB&gt;matnr&lt;/P&gt;&lt;P&gt;           INNER JOIN mcha AS t4&lt;/P&gt;&lt;P&gt;           ON t4&lt;SUB&gt;matnr = t1&lt;/SUB&gt;matnr AND&lt;/P&gt;&lt;P&gt;              t4&lt;SUB&gt;werks = t1&lt;/SUB&gt;werks&lt;/P&gt;&lt;P&gt;           INNER JOIN mchb AS t5&lt;/P&gt;&lt;P&gt;            ON t5&lt;SUB&gt;matnr = t4&lt;/SUB&gt;matnr AND&lt;/P&gt;&lt;P&gt;               t5&lt;SUB&gt;werks = t4&lt;/SUB&gt;werks AND&lt;/P&gt;&lt;P&gt;               t5&lt;SUB&gt;charg = t4&lt;/SUB&gt;charg&lt;/P&gt;&lt;P&gt;         LEFT OUTER JOIN mdlg AS t7                             " MKA&lt;/P&gt;&lt;P&gt;                  ON t7&lt;SUB&gt;werks = t5&lt;/SUB&gt;werks                        " MKA&lt;/P&gt;&lt;P&gt;                 AND t7&lt;SUB&gt;lgort = t5&lt;/SUB&gt;lgort                        " MKA&lt;/P&gt;&lt;P&gt;                LEFT OUTER JOIN afpo AS t6&lt;/P&gt;&lt;P&gt;                   ON t6&lt;SUB&gt;matnr = t4&lt;/SUB&gt;matnr AND&lt;/P&gt;&lt;P&gt;                      t6&lt;SUB&gt;charg = t4&lt;/SUB&gt;charg&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;               INTO CORRESPONDING FIELDS OF TABLE t_data&lt;/P&gt;&lt;P&gt;                WHERE &amp;lt;select options&amp;gt;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I tried by splitting all the select queries using &amp;lt;for all entries&amp;gt;. But its causing incorrect and incomplete data to be fetched.&lt;/P&gt;&lt;P&gt;Kindly guide if the above can be corrected without losing data.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Points for sure&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;Dinesh&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 20 Jan 2008 10:09:02 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268363#M781179</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-01-20T10:09:02Z</dc:date>
    </item>
    <item>
      <title>Re: Performance tuning</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268364#M781180</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;There are possiblities to direct program your own select in mySAP 2005 (at least 2006) which have higher performance.&lt;/P&gt;&lt;P&gt;Otherwise this is difficult.&lt;/P&gt;&lt;P&gt;I would always reduce the additional selects such as texts. Doesn't the query tool does this itself ... ???&lt;/P&gt;&lt;P&gt;Further more you can read texts in own form routine (before selection) into an internal table and use "READ" command with own routine on own field. SAP generates this into the list preparation LOOP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;But SAP Query tool is not made to have high performance when you link tables / join them (my experience).&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 20 Jan 2008 10:31:30 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268364#M781180</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-01-20T10:31:30Z</dc:date>
    </item>
    <item>
      <title>Re: Performance tuning</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268365#M781181</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Ways of Performance Tuning&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.	Selection Criteria &lt;/P&gt;&lt;P&gt;2.	Select Statements&lt;/P&gt;&lt;P&gt;&amp;#149;	Select Queries&lt;/P&gt;&lt;P&gt;&amp;#149;	SQL Interface&lt;/P&gt;&lt;P&gt;&amp;#149;	Aggregate Functions&lt;/P&gt;&lt;P&gt;&amp;#149;	For all Entries&lt;/P&gt;&lt;P&gt;Select Over more than one internal table&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Selection Criteria&lt;/P&gt;&lt;P&gt;1.	Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.  &lt;/P&gt;&lt;P&gt;2.	Select with selection list.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM SBOOK INTO SBOOK_WA.&lt;/P&gt;&lt;P&gt;  CHECK: SBOOK_WA-CARRID = 'LH' AND&lt;/P&gt;&lt;P&gt;         SBOOK_WA-CONNID = '0400'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT  CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK&lt;/P&gt;&lt;P&gt;  WHERE SBOOK_WA-CARRID = 'LH' AND&lt;/P&gt;&lt;P&gt;              SBOOK_WA-CONNID = '0400'.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Select Statements   Select Queries&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.	Avoid nested selects&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM EKKO INTO EKKO_WA.&lt;/P&gt;&lt;P&gt;  SELECT * FROM EKAN INTO EKAN_WA&lt;/P&gt;&lt;P&gt;      WHERE EBELN = EKKO_WA-EBELN.&lt;/P&gt;&lt;P&gt;  ENDSELECT.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The above code can be much more optimized by the code written below.&lt;/P&gt;&lt;P&gt;SELECT P&lt;SUB&gt;F1 P&lt;/SUB&gt;F2 F&lt;SUB&gt;F3 F&lt;/SUB&gt;F4 INTO TABLE ITAB&lt;/P&gt;&lt;P&gt;    FROM EKKO AS P INNER JOIN EKAN AS F&lt;/P&gt;&lt;P&gt;      ON P&lt;SUB&gt;EBELN = F&lt;/SUB&gt;EBELN.&lt;/P&gt;&lt;P&gt;Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.&lt;/P&gt;&lt;P&gt;2.	Select all the records in a single shot using into table clause of select statement rather than to use Append statements. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM SBOOK INTO SBOOK_WA.&lt;/P&gt;&lt;P&gt;  CHECK: SBOOK_WA-CARRID = 'LH' AND&lt;/P&gt;&lt;P&gt;         SBOOK_WA-CONNID = '0400'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table&lt;/P&gt;&lt;P&gt;SELECT  CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK&lt;/P&gt;&lt;P&gt;  WHERE SBOOK_WA-CARRID = 'LH' AND&lt;/P&gt;&lt;P&gt;              SBOOK_WA-CONNID = '0400'.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;3.	When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields. In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;4.	For testing existence, use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.  &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM SBOOK INTO SBOOK_WA&lt;/P&gt;&lt;P&gt;  UP TO 1 ROWS&lt;/P&gt;&lt;P&gt;  WHERE CARRID = 'LH'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above code is more optimized as compared to the code mentioned below for testing existence of a record.&lt;/P&gt;&lt;P&gt;SELECT * FROM SBOOK INTO SBOOK_WA&lt;/P&gt;&lt;P&gt;    WHERE CARRID = 'LH'.&lt;/P&gt;&lt;P&gt;  EXIT.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;5.	Use Select Single if all primary key fields are supplied in the Where condition .&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If all primary key fields are supplied in the Where conditions you can even use Select Single. &lt;/P&gt;&lt;P&gt;Select Single requires one communication with the database system, whereas Select-Endselect needs two. &lt;/P&gt;&lt;P&gt;Select Statements SQL Interface&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.	Use column updates instead of single-row updates &lt;/P&gt;&lt;P&gt;to update your database tables.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM SFLIGHT INTO SFLIGHT_WA.&lt;/P&gt;&lt;P&gt;  SFLIGHT_WA-SEATSOCC =&lt;/P&gt;&lt;P&gt;    SFLIGHT_WA-SEATSOCC - 1.&lt;/P&gt;&lt;P&gt;  UPDATE SFLIGHT FROM SFLIGHT_WA.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above mentioned code can be more optimized by using the following code&lt;/P&gt;&lt;P&gt;UPDATE SFLIGHT&lt;/P&gt;&lt;P&gt;       SET SEATSOCC = SEATSOCC - 1.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2.	For all frequently used Select statements, try to use an index.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA&lt;/P&gt;&lt;P&gt;  WHERE CARRID = 'LH'&lt;/P&gt;&lt;P&gt;    AND CONNID = '0400'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above mentioned code can be more optimized by using the following code&lt;/P&gt;&lt;P&gt;SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA&lt;/P&gt;&lt;P&gt;  WHERE MANDT IN ( SELECT MANDT FROM T000 )&lt;/P&gt;&lt;P&gt;    AND CARRID = 'LH'&lt;/P&gt;&lt;P&gt;    AND CONNID = '0400'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;3.	Using buffered tables improves the performance considerably.&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;Bypassing the buffer increases the network considerably&lt;/P&gt;&lt;P&gt;SELECT SINGLE * FROM T100 INTO T100_WA&lt;/P&gt;&lt;P&gt;  BYPASSING BUFFER&lt;/P&gt;&lt;P&gt;  WHERE     SPRSL = 'D'&lt;/P&gt;&lt;P&gt;        AND ARBGB = '00'&lt;/P&gt;&lt;P&gt;        AND MSGNR = '999'.&lt;/P&gt;&lt;P&gt;The above mentioned code can be more optimized by using the following code&lt;/P&gt;&lt;P&gt;SELECT SINGLE * FROM T100  INTO T100_WA&lt;/P&gt;&lt;P&gt;  WHERE     SPRSL = 'D'&lt;/P&gt;&lt;P&gt;        AND ARBGB = '00'&lt;/P&gt;&lt;P&gt;        AND MSGNR = '999'.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Select Statements  Aggregate Functions&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself. &lt;/P&gt;&lt;P&gt;Some of the Aggregate functions allowed in SAP are  MAX, MIN, AVG, SUM, COUNT, COUNT( * )&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Consider the following extract.&lt;/P&gt;&lt;P&gt;            Maxno = 0.&lt;/P&gt;&lt;P&gt;            Select * from zflight where airln = &amp;#145;LF&amp;#146; and cntry = &amp;#145;IN&amp;#146;.&lt;/P&gt;&lt;P&gt;             Check zflight-fligh &amp;gt; maxno.&lt;/P&gt;&lt;P&gt;             Maxno = zflight-fligh.&lt;/P&gt;&lt;P&gt;            Endselect.&lt;/P&gt;&lt;P&gt;The  above mentioned code can be much more optimized by using the following code.&lt;/P&gt;&lt;P&gt;Select max( fligh ) from zflight into maxno where airln = &amp;#145;LF&amp;#146; and cntry = &amp;#145;IN&amp;#146;. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Select Statements  For All Entries&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause. &lt;/P&gt;&lt;P&gt;	The plus &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	Large amount of data &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	Mixing processing and reading of data &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	Fast internal reprocessing of data &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	Fast &lt;/P&gt;&lt;P&gt;	The Minus &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	Difficult to program/understand &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;#149;	Memory could be critical (use FREE or PACKAGE size) &lt;/P&gt;&lt;P&gt;	&lt;/P&gt;&lt;P&gt;Points to be must considered FOR ALL ENTRIES &lt;/P&gt;&lt;P&gt;&amp;#149;	Check that data is present in the driver table&lt;/P&gt;&lt;P&gt;&amp;#149;	Sorting the driver table &lt;/P&gt;&lt;P&gt;&amp;#149;	Removing duplicates from the driver table&lt;/P&gt;&lt;P&gt;Consider the following piece of extract&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;          Loop at int_cntry.&lt;/P&gt;&lt;P&gt;  Select single * from zfligh into int_fligh&lt;/P&gt;&lt;P&gt;  where cntry = int_cntry-cntry.&lt;/P&gt;&lt;P&gt;  Append int_fligh. &lt;/P&gt;&lt;P&gt;                      Endloop.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The above mentioned can be more optimized by using the following code.&lt;/P&gt;&lt;P&gt;Sort int_cntry by cntry.&lt;/P&gt;&lt;P&gt;Delete adjacent duplicates from int_cntry.&lt;/P&gt;&lt;P&gt;If NOT int_cntry[] is INITIAL.&lt;/P&gt;&lt;P&gt;            Select * from zfligh appending table int_fligh&lt;/P&gt;&lt;P&gt;            For all entries in int_cntry &lt;/P&gt;&lt;P&gt;            Where cntry = int_cntry-cntry.&lt;/P&gt;&lt;P&gt;Endif.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Select Statements Select Over more than one Internal table&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.	Its better to use a views instead of nested Select statements.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM DD01L INTO DD01L_WA&lt;/P&gt;&lt;P&gt;  WHERE DOMNAME LIKE 'CHAR%'&lt;/P&gt;&lt;P&gt;        AND AS4LOCAL = 'A'.&lt;/P&gt;&lt;P&gt;  SELECT SINGLE * FROM DD01T INTO DD01T_WA&lt;/P&gt;&lt;P&gt;    WHERE   DOMNAME    = DD01L_WA-DOMNAME&lt;/P&gt;&lt;P&gt;        AND AS4LOCAL   = 'A'&lt;/P&gt;&lt;P&gt;        AND AS4VERS    = DD01L_WA-AS4VERS&lt;/P&gt;&lt;P&gt;        AND DDLANGUAGE = SY-LANGU.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The above code can be more optimized by extracting all the data from view DD01V_WA &lt;/P&gt;&lt;P&gt;SELECT * FROM DD01V INTO  DD01V_WA&lt;/P&gt;&lt;P&gt;  WHERE DOMNAME LIKE 'CHAR%'&lt;/P&gt;&lt;P&gt;        AND DDLANGUAGE = SY-LANGU.&lt;/P&gt;&lt;P&gt;ENDSELECT&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2.	To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SELECT * FROM EKKO INTO EKKO_WA.&lt;/P&gt;&lt;P&gt;  SELECT * FROM EKAN INTO EKAN_WA&lt;/P&gt;&lt;P&gt;      WHERE EBELN = EKKO_WA-EBELN.&lt;/P&gt;&lt;P&gt;  ENDSELECT.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above code can be much more optimized by the code written below.&lt;/P&gt;&lt;P&gt;SELECT P&lt;SUB&gt;F1 P&lt;/SUB&gt;F2 F&lt;SUB&gt;F3 F&lt;/SUB&gt;F4 INTO TABLE ITAB&lt;/P&gt;&lt;P&gt;    FROM EKKO AS P INNER JOIN EKAN AS F&lt;/P&gt;&lt;P&gt;      ON P&lt;SUB&gt;EBELN = F&lt;/SUB&gt;EBELN.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;3.	Instead of using nested Select loops it is often better to use subqueries. &lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;SELECT * FROM SPFLI&lt;/P&gt;&lt;P&gt;  INTO TABLE T_SPFLI&lt;/P&gt;&lt;P&gt;  WHERE CITYFROM = 'FRANKFURT'&lt;/P&gt;&lt;P&gt;    AND CITYTO = 'NEW YORK'.&lt;/P&gt;&lt;P&gt;SELECT * FROM SFLIGHT AS F&lt;/P&gt;&lt;P&gt;    INTO SFLIGHT_WA&lt;/P&gt;&lt;P&gt;    FOR ALL ENTRIES IN T_SPFLI&lt;/P&gt;&lt;P&gt;    WHERE SEATSOCC &amp;lt; F~SEATSMAX&lt;/P&gt;&lt;P&gt;      AND CARRID = T_SPFLI-CARRID&lt;/P&gt;&lt;P&gt;      AND CONNID = T_SPFLI-CONNID&lt;/P&gt;&lt;P&gt;      AND FLDATE BETWEEN '19990101' AND '19990331'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;The above mentioned code can be even more optimized by using subqueries instead of for all entries.&lt;/P&gt;&lt;P&gt;SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA&lt;/P&gt;&lt;P&gt;    WHERE SEATSOCC &amp;lt; F~SEATSMAX&lt;/P&gt;&lt;P&gt;      AND EXISTS ( SELECT * FROM SPFLI&lt;/P&gt;&lt;P&gt;                     WHERE CARRID = F~CARRID&lt;/P&gt;&lt;P&gt;                       AND CONNID = F~CONNID&lt;/P&gt;&lt;P&gt;                       AND CITYFROM = 'FRANKFURT'&lt;/P&gt;&lt;P&gt;                       AND CITYTO = 'NEW YORK' )&lt;/P&gt;&lt;P&gt;      AND FLDATE BETWEEN '19990101' AND '19990331'.&lt;/P&gt;&lt;P&gt;ENDSELECT.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.	Table operations should be done using explicit work areas rather than via header lines.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;READ TABLE ITAB INTO WA WITH KEY K = 'X&amp;#145; BINARY SEARCH.&lt;/P&gt;&lt;P&gt;IS MUCH FASTER THAN USING&lt;/P&gt;&lt;P&gt;READ TABLE ITAB INTO WA WITH KEY K = 'X'.&lt;/P&gt;&lt;P&gt;If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ). &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2.	Always try to use binary search instead of linear search. But don&amp;#146;t forget to sort your internal table before that.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING &lt;/P&gt;&lt;P&gt;READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;3.	A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.&lt;/P&gt;&lt;P&gt;4.	A binary search using secondary index takes considerably less time.&lt;/P&gt;&lt;P&gt;5.	LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;LOOP AT ITAB INTO WA WHERE K = 'X'.&lt;/P&gt;&lt;P&gt;  " ...&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;The above code is much faster than using &lt;/P&gt;&lt;P&gt;LOOP AT ITAB INTO WA.&lt;/P&gt;&lt;P&gt;  CHECK WA-K = 'X'.&lt;/P&gt;&lt;P&gt;  " ...&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;6.	Modifying selected components using &amp;#147; MODIFY itab &amp;#133;TRANSPORTING f1 f2.. &amp;#147; accelerates the task of updating  a line of an internal table.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;WA-DATE = SY-DATUM.&lt;/P&gt;&lt;P&gt;MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.&lt;/P&gt;&lt;P&gt;The above code is more optimized as compared to &lt;/P&gt;&lt;P&gt;WA-DATE = SY-DATUM.&lt;/P&gt;&lt;P&gt;MODIFY ITAB FROM WA INDEX 1.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;7.	Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Modifying selected components only makes the program faster as compared to Modifying all lines completely.&lt;/P&gt;&lt;P&gt;e.g,&lt;/P&gt;&lt;P&gt;LOOP AT ITAB ASSIGNING &amp;lt;WA&amp;gt;.&lt;/P&gt;&lt;P&gt;  I = SY-TABIX MOD 2.&lt;/P&gt;&lt;P&gt;  IF I = 0.&lt;/P&gt;&lt;P&gt;    &amp;lt;WA&amp;gt;-FLAG = 'X'.&lt;/P&gt;&lt;P&gt;  ENDIF.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt; The above code works faster as compared to&lt;/P&gt;&lt;P&gt;LOOP AT ITAB INTO WA.&lt;/P&gt;&lt;P&gt;  I = SY-TABIX MOD 2.&lt;/P&gt;&lt;P&gt;  IF I = 0.&lt;/P&gt;&lt;P&gt;    WA-FLAG = 'X'.&lt;/P&gt;&lt;P&gt;    MODIFY ITAB FROM WA.&lt;/P&gt;&lt;P&gt;  ENDIF.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;8.    If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;LOOP AT ITAB1 INTO WA1.&lt;/P&gt;&lt;P&gt;  READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.&lt;/P&gt;&lt;P&gt;  IF SY-SUBRC = 0.&lt;/P&gt;&lt;P&gt;    ADD: WA1-VAL1 TO WA2-VAL1,&lt;/P&gt;&lt;P&gt;         WA1-VAL2 TO WA2-VAL2.&lt;/P&gt;&lt;P&gt;    MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.&lt;/P&gt;&lt;P&gt;  ELSE.&lt;/P&gt;&lt;P&gt;    INSERT WA1 INTO ITAB2 INDEX SY-TABIX.&lt;/P&gt;&lt;P&gt;  ENDIF.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by&lt;/P&gt;&lt;P&gt;LOOP AT ITAB1 INTO WA.&lt;/P&gt;&lt;P&gt;  COLLECT WA INTO ITAB2.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;SORT ITAB2 BY K.&lt;/P&gt;&lt;P&gt;COLLECT, however, uses a hash algorithm and is therefore independent &lt;/P&gt;&lt;P&gt;of the number of entries (i.e. O(1)) .&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;9.    "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to &amp;#147; LOOP-APPEND-ENDLOOP.&amp;#148; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;APPEND LINES OF ITAB1 TO ITAB2.&lt;/P&gt;&lt;P&gt; This is more optimized as compared to&lt;/P&gt;&lt;P&gt;LOOP AT ITAB1 INTO WA.&lt;/P&gt;&lt;P&gt;  APPEND WA TO ITAB2.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;10.   &amp;#147;DELETE ADJACENT DUPLICATES&amp;#147; accelerates the task of deleting duplicate entries considerably as compared to &amp;#147; READ-LOOP-DELETE-ENDLOOP&amp;#148;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.&lt;/P&gt;&lt;P&gt;This is much more optimized as compared to&lt;/P&gt;&lt;P&gt;READ TABLE ITAB INDEX 1 INTO PREV_LINE.&lt;/P&gt;&lt;P&gt;LOOP AT ITAB FROM 2 INTO WA.&lt;/P&gt;&lt;P&gt;  IF WA = PREV_LINE.&lt;/P&gt;&lt;P&gt;    DELETE ITAB.&lt;/P&gt;&lt;P&gt;  ELSE.&lt;/P&gt;&lt;P&gt;    PREV_LINE = WA.&lt;/P&gt;&lt;P&gt;  ENDIF.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;11.   "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to &amp;#147;  DO -DELETE-ENDDO&amp;#148;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;DELETE ITAB FROM 450 TO 550.&lt;/P&gt;&lt;P&gt;This is much more optimized as compared to&lt;/P&gt;&lt;P&gt;DO 101 TIMES.&lt;/P&gt;&lt;P&gt;  DELETE ITAB INDEX 450.&lt;/P&gt;&lt;P&gt;ENDDO.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;12.   Copying internal tables by using &amp;#147;ITAB2[ ] = ITAB1[ ]&amp;#148; as compared to &amp;#147;LOOP-APPEND-ENDLOOP&amp;#148;.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;ITAB2[] = ITAB1[].&lt;/P&gt;&lt;P&gt;This is much more optimized as compared to&lt;/P&gt;&lt;P&gt;REFRESH ITAB2.&lt;/P&gt;&lt;P&gt;LOOP AT ITAB1 INTO WA.&lt;/P&gt;&lt;P&gt;  APPEND WA TO ITAB2.&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;13.   Specify the sort key as restrictively as possible to run the program faster. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt; &amp;#147;SORT ITAB BY K.&amp;#148; makes the program runs faster as compared to &amp;#147;SORT ITAB.&amp;#148;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Internal Tables         contd&amp;#133;&lt;/P&gt;&lt;P&gt; Hashed and Sorted tables&lt;/P&gt;&lt;P&gt;1.	For single read access hashed tables are more optimized as compared to sorted tables.&lt;/P&gt;&lt;P&gt;2.	 For partial sequential access sorted tables are more optimized as compared to hashed tables&lt;/P&gt;&lt;P&gt;Hashed And Sorted Tables&lt;/P&gt;&lt;P&gt;Point # 1&lt;/P&gt;&lt;P&gt;Consider the following example where HTAB is a hashed table and STAB is a sorted table&lt;/P&gt;&lt;P&gt;DO 250 TIMES.&lt;/P&gt;&lt;P&gt;  N = 4 * SY-INDEX.&lt;/P&gt;&lt;P&gt;  READ TABLE HTAB INTO WA WITH TABLE KEY K = N.&lt;/P&gt;&lt;P&gt;  IF SY-SUBRC = 0.&lt;/P&gt;&lt;P&gt;    " ...&lt;/P&gt;&lt;P&gt;  ENDIF.&lt;/P&gt;&lt;P&gt;ENDDO.&lt;/P&gt;&lt;P&gt;This runs faster for single read access as compared to the following same code for sorted table&lt;/P&gt;&lt;P&gt;DO 250 TIMES.&lt;/P&gt;&lt;P&gt;  N = 4 * SY-INDEX.&lt;/P&gt;&lt;P&gt;  READ TABLE STAB INTO WA WITH TABLE KEY K = N.&lt;/P&gt;&lt;P&gt;  IF SY-SUBRC = 0.&lt;/P&gt;&lt;P&gt;    " ...&lt;/P&gt;&lt;P&gt;  ENDIF.&lt;/P&gt;&lt;P&gt;ENDDO.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Point # 2&lt;/P&gt;&lt;P&gt;Similarly for Partial Sequential access the STAB runs faster as compared to HTAB&lt;/P&gt;&lt;P&gt;LOOP AT STAB INTO WA WHERE K = SUBKEY.&lt;/P&gt;&lt;P&gt;  " ...&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;P&gt;This runs faster as compared to&lt;/P&gt;&lt;P&gt;LOOP AT HTAB INTO WA WHERE K = SUBKEY.&lt;/P&gt;&lt;P&gt;  " ...&lt;/P&gt;&lt;P&gt;ENDLOOP.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 21 Jan 2008 05:43:25 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268365#M781181</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-01-21T05:43:25Z</dc:date>
    </item>
    <item>
      <title>Re: Performance tuning</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268366#M781182</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Please rethink your SELECT statement whether it is really correct,&lt;/P&gt;&lt;P&gt;you ha´ve 3 INNER JOINs plus 2 OUTER JOINs, this is defiinitely too hard.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;But why do need OUTER JOINS.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The FOR ALL ENTRIES can not be used for the OUTER JOINS.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;You must check which order opf execution would be optimal and check whether it is index supported or&lt;/P&gt;&lt;P&gt;can be made index-support (new fields in WHERE or ON  or new index). Then it might be possible to find&lt;/P&gt;&lt;P&gt;a performant subset of joins.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The rest must be added manually. It is also possible to write an OUTER JOIN in ABAP.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Siegfried&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 21 Jan 2008 09:19:41 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268366#M781182</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-01-21T09:19:41Z</dc:date>
    </item>
    <item>
      <title>Re: Performance tuning</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268367#M781183</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The JOIN on MDLG is not using the index very well; you migh consider removing that from the SELECT for testing purposes. Also, the SELECT on AFPO is using a secondary index, but may return a lot of entries. You might try removing both of these from the JOIN just to see what happens.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The problem is likely in the WHERE clause. Can you post it?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Rob&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 21 Jan 2008 14:48:11 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268367#M781183</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-01-21T14:48:11Z</dc:date>
    </item>
    <item>
      <title>Re: Performance tuning</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268368#M781184</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;solved on own&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 26 Jun 2009 08:32:08 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/performance-tuning/m-p/3268368#M781184</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2009-06-26T08:32:08Z</dc:date>
    </item>
  </channel>
</rss>

