For All Entries is NOT better than INNER JOIN in most cases
I quote from Siegfried Boes' excellent post here: Will writing an inner join be better or creating a view?
For all the FOR ALL ENTRIES lovers ... there is no proof for these reappearing recommendation.
There is nearly nobody who receives forum points, who recommends FOR ALL ENTRIES instead of Joins. What is the reason ???
It is easier to prove the opposite. A Join is a nested loop inside the database, a FOR ALL ENTRIES is partly outside of the database. FOR ALL ENTRIES works in blocks, joins on totals.
FOR ALL ENTRIES are not recommded on really large tables, because the chances are too high that
too many records are transferred.
People prefer FOR ALL ENTRIES, because JOINs are not so easy to understand. Joins can go wrong, but with a bit of understanding they can be fixed.
Some Joins are slow and can not be fixed, but then the FOR ALL ENTRIES would be extremely slow.
There are several kinds of views:
- projection views, i.e. only one table involved just fields reduced
- join views, several tables, joins conditions stored in dictionary
- materialized views, here the joined data are actually stored in the database. Storing and synchronisation has to be done manually.
Only the last one creates real overhead. It should be the exception.
Join Views and Joins are nearly identical. The view is better for reuse. The join is better in complicated, becuase if the access goes wrong, it can often be fixed by adding a hint. Hints can not be added to views.
Abraham Bukit points out:
If it is cluster table, (you can't use join). If it is buffered table, I would also say avoid join.
If they all are transaction table which are not buffered and are not cluster tables.
He further supports Siegfried's statement that FAE is easier to undestand than INNER JOINs.
Thomas Zloch says, regarding buffered tables:
At least think twice, maybe compare runtimes if in doubt.
So, unless someone has some EVIDENCE that FOR ALL ENTRIES is better, I don't think we want to see this discussed further.
Kind regards
Matt
To give food for thought here's an example I gave in a thread:
If you have a statement like
SELECT ... FOR ALL ENTRIES IN FAE_itab WHERE f = FAE_itab-f.
SAP sends it to the database depending how the parameter rsdb/prefer_union_all is set:
rsdb/prefer_union_all = 0 =>
SELECT ... WHERE f = FAE_itab[1]-f
OR f = FAE_itab[2]-f
OR f = FAE_itab[N]-f
You have some influence of the generated statement type: Instead of OR'ed fields an IN list can be used
if you have only a single coulmn N to compare:
rsdb/prefer_in_itab_opt parameter:
SELECT ... WHERE f IN (itab[1]-f, itab[2]-f, ..., itab[N]-f)
rsdb/prefer_union_all = 1 =>
SELECT ... WHERE f = FAE_itab[1]-f
UNION ALL SELECT ... WHERE f = FAE_itab[2]-f
UNION ALL SELECT ... WHERE f = FAE_itab[N]-f
see: Note 48230 - Parameters for the SELECT ... FOR ALL ENTRIES statement
As you can see for the 2nd parameter several statements are generated and combined with a UNION ALL,
the first setting generates statements with OR's (or uses IN if possible) for the entries in FAE_itab.
I give you a little example here (my parameters are set in a way that the OR's are translated to IN lists; i traced the execution in ST05)
Select myid into table t_tabcount from mydbtable
for all entries in t_table " 484 entries
where myid = t_table-myid .
ST05 trace:
|Transaction SEU_INT|Work process no 0|Proc.type DIA|Client 200|User |
|Duration |Obj. name |Op. |Recs.|RC |Statement|
| 640|mydbtable |PREPARE| | 0|SELECT WHERE "myid" IN ( :A0 , :A1 , :A2 , :A3 , :A4 ) AND "myid" = :A5|
| 2|mydbtable |OPEN | | 0|SELECT WHERE "myid" IN ( 1 , 2 , 3 , 4 , 5 ) AND "myid" = 72 |
| 2.536|mydbtable |FETCH | 0| 1403| |
| 3|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 6 , 7 , 8 , 9 , 10 ) AND "myid" = 72 |
| 118|mydbtable |FETCH | 0| |
| 2|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 11 , 12 , 13 , 14 , 15 ) AND "myid" = 72 |
| 3|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 475 , 476 , 477 , 478 , 479 ) AND "myid" = 72 |
| 94|mydbtable |FETCH | 0| 1403| |
| 2|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 480 , 481 , 482 , 483 , 484 ) AND "myid" = 72 |
You see the IN list contained 5 entries each , wich made up about 97 statements for all 484 entries.
For every statment you have a single fetch operation wich means a separate access to the database.
If you would replace the FAE with a join you would only have one fetch to the database.
With the example above we can derive these observations:
1. From database point of view these settings kill performance when you access a big table and/or have a lot of entries or columns in your FAE_itab. Furthermore, you hide information what data you will access
at all and thus you block the database from creating a more efficient execution plan because it DOESN'T KNOW wich data you will select in the next step. I.e. it may be more efficient to scan the table in one shot instead of having many index accesses - but the database can make this decision only if it can examine ONE statement that has ALL the information of what data to retrieve.
2. A second impact is that with every statement execution you trigger the allocation of database resources
wich will contribute to the overhead described above.
Said that, FAE can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table )
Edited by: kishan P on Nov 2, 2010 2:16 PM - Format Fixed
Similar Messages
-
Does 'For All Entries in itab' work exactly like 'Join' statement?
Hi,
I would like to know that if 'For All Entries in itab' work exactly like 'Join' statement?
If yes, then when I use 'For All Entries in itab' and a 'Join' statement seperately with the same logical conditions for both, the number of records returned by the two methods are not same. Ideally, they should both return the same number of recs.
Can somebody help?
With regards.Hi,
for all entries will not work in the same way unless untill it should satisfy some conditions,
it has some pre-requisests...
like in the select clause or in where clause or in both the cluases, there should be entire key..
then only it will behave like the join statement..
hope i am clear.
please revert back if u have any quiries.
Regards,
Sunil Kumar Mutyala. -
FOR ALL ENTRIES IN - Not selecting all Records
Hi,
SELECT obknr ppaufnr ppposnr
FROM ser05
INTO TABLE gi_ser05
FOR ALL ENTRIES IN gi_objkpo
WHERE obknr EQ gi_objkpo-obknr
AND ppaufnr IN so_aufnr
AND ppposnr EQ '0001'.
IF NOT gi_ser05 IS INITIAL.
SELECT bwart matnr menge dmbtr aufnr
FROM aufm
INTO TABLE gi_aufm
FOR ALL ENTRIES IN gi_ser05
WHERE aufnr = gi_ser05-ppaufnr
AND bwart IN ('261','262').
ENDIF.
In debugging, this code is fetching 129 entries in gi_aufm.
Where in AUFM table for same WHERE Conditions there are 139 records.
Why it's skipping Records?HI ,
SELECT obknr ppaufnr ppposnr
FROM ser05
INTO TABLE gi_ser05
FOR ALL ENTRIES IN gi_objkpo
WHERE obknr EQ gi_objkpo-obknr
AND ppaufnr IN so_aufnr
AND ppposnr EQ '0001'.
IF NOT gi_ser05 IS INITIAL.
SELECT bwart matnr menge dmbtr aufnr
FROM aufm
INTO TABLE gi_aufm
FOR ALL ENTRIES IN gi_ser05
WHERE aufnr = gi_ser05-ppaufnr
AND bwart IN ('261','262').
ENDIF.
in above code where you are getting Less Records
Because from above code it seems that you not selected
MANDT
MBLNR
MJAHR
ZEILE from table aufm
which is primary key of table AUFM and all records are depended on entries in table gi_objkpo which you are using for
all entries .
so first check data in table by passing values according to where condition .
Regards
Deepak. -
The select with for all entries is not working correctly
IF NOT i_ekko_ekpo[] IS INITIAL.
SELECT ebeln
ebelp
zekkn
vgabe
bewtp
menge
bpmng
shkzg
INTO TABLE i_ekbe
FROM ekbe
FOR ALL ENTRIES IN i_ekko_ekpo
WHERE ebeln EQ i_ekko_ekpo-ebeln.
AND ebelp EQ i_ekko_ekpo-ebelp.
IF sy-subrc EQ 0.
SORT i_ekbe.
ENDIF.
ENDIF.
I have a PO with 2 line items in i_ekko_ekpo. In EKBE, I have 49 recs for this PO and this select is returning only 13 recs.
I tried by commenting EBELP and still the same result.
Thanks
Kiran
Edited by: kiran dasari on May 22, 2009 9:56 PMHi Sudhi, I added these now but still no charm
SELECT ebeln
ebelp
zekkn
vgabe
bewtp
menge
bpmng
shkzg
INTO TABLE i_ekbe
FROM ekbe
FOR ALL ENTRIES IN i_ekko_ekpo
WHERE ebeln EQ i_ekko_ekpo-ebeln
AND ebelp EQ i_ekko_ekpo-ebelp
AND zekkn GE '00'
AND vgabe IN ('1','2').
And as per your note: in the 13 entries, am having duplicate also. This is something weird for me now.
Any more clues.
Thanks
Kiran -
Inner join with for-all entries
Why is the below inner join-for all entries does not result in expected output ?
REPORT ZTST3 .
tables : ztst1,ztst2 .
* table ztst1 has 4 fields : mandt,ebeln,ebelp,etenr,char4. ; ztst2 has
* 3 fields : mandt,ebeln,ebelp,matnr
*Entries in ztst1
* EBELN EBELP ETERN CHAR4
* 5000000000 00010 0001 abc
* 5000000000 00010 0002 cbd
* 5000000000 00010 0003 efg
*Entries in ztst2
* EBELN EBELP matnr
* 5000000000 00010 matabc
*expected itab after inner join
* EBELN EBELP CHAR4 MAtnr
* 5000000000 00010 abc matabc
* 5000000000 00010 cbd matabc
* 5000000000 00010 efg matabc
data : begin of itab1 occurs 0,
ebeln type ebeln,
ebelp type ebelp,
end of itab1.
data : begin of itab occurs 0,
ebeln type ebeln,
ebelp type ebelp,
char4 type char4,
matnr type matnr,
end of itab.
start-of-selection.
itab1-ebeln = '5000000000'.
itab1-ebelp = '00010'.
append itab1.
select ztst1~ebeln
ztst1~ebelp
ztst1~char4
ztst2~matnr into corresponding fields of table itab
from ztst1 inner join ztst2
on ztst1~ebeln = ztst2~ebeln and
ztst1~ebeln = ztst2~ebelp
for all entries in itab1
where
ztst1~ebeln eq itab1-ebeln and
ztst1~ebelp eq itab1-ebelp .
* why does it return no entries;
break-point.For example in the bellow case
*Entries in ztst1
EBELN EBELP ETERN CHAR4
5000000000 00010 0001 abc
5000000000 00010 0002 cbd
5000000000 00010 0003 efg
5000000002 00020 0003 efg
5000000002 00020 0003 efg
*Entries in ztst2
EBELN EBELP matnr
5000000000 00010 matabc
5000000002 00020 abc
may it will return you 2 records yes, than I think you have under stand the working of u201Cfor all entriesu201D ?
And the following case I think it will work fine.
*Entries in ztst1
key EBELN EBELP ETERN CHAR4
1 5000000000 00010 0001 abc
2 5000000000 00010 0002 cbd
3 5000000000 00010 0003 efg
4 5000000002 00020 0003 efg
5 5000000002 00020 0003 efg
*Entries in ztst2
EBELN EBELP matnr
5000000000 00010 matabc
5000000002 00020 abc
select ztst1~key
ztst1~ebeln
ztst1~ebelp
ztst1~char4
ztst2~matnr into corresponding fields of table itab
from ztst1 inner join ztst2
on ztst1~ebeln = ztst2~ebeln and
ztst1~ebelp = ztst2~ebelp
for all entries in itab1
where
ztst1~ebeln eq itab1-ebeln and
ztst1~ebelp eq itab1-ebelp .
Sorry, I donu2019t have system with me right now and I am sending you with out testing but I am sure that it is working the same way.
Please Reply if any problem
Kind Regards,
Faisal -
INNER JOIN with FOR ALL ENTRIES IN Performance ?
I am using following the following <b>Select using Inner join with For All Entries in.</b>
SELECT kebeln kebelp kvbeln kvbelp
FROM ekkn AS k INNER JOIN ekbe AS b ON kebeln = bebeln
AND kebelp = bebelp
INTO TABLE gi_purchase
FOR ALL ENTRIES
IN gi_sales
WHERE k~mandt EQ sy-mandt
AND k~vbeln EQ gi_sales-vbeln
AND k~vbelp EQ gi_sales-posnr
AND b~budat EQ p_date.
If i am not doing inner join then I will have to do 2 select with for all entries in on ekkn and ekbe tables and then compare them.
<b>I want to know which one has better performance
Inner join with for all entries in
or
2 Selects with for all entries in</b>the join is almost aways faster:
<a href="/people/rob.burbank/blog/2007/03/19/joins-vs-for-all-entries--which-performs-better">JOINS vs. FOR ALL ENTRIES - Which Performs Better?</a>
<a href="http://blogs.ittoolbox.com/sap/db2/archives/for-all-entries-vs-db2-join-8912">FOR ALL ENTRIES vs DB2 JOIN</a>
Rob -
Doubt regarding FOR ALL ENTRIES and INDEXES
Hi iam Aslam ..
and i have a doubt ..regrding .. .
1) what are the disadvs of using FOR ALL ENTRIES
2) what are the disadvs of using INDEXES
3) what is the disadvs of using Binary search ..
4) . how can u do performance tuning ...if u have more than one SELECT statements between ... Loop and Endloop .......
please answer to these questions or reply me to [email protected] ..
thanks in advance ..
byeHI
<b>1) what are the disadvs of using FOR ALL ENTRIES</b>
if there is no data available for you condition mentioned in the where condition then it will retrive all the data from the database table , which we don't want , but we can solve that easily
Ways of Performance Tuning
1. Selection Criteria
2. Select Statements
Select Queries
SQL Interface
Aggregate Functions
For all Entries
Select Over more than one Internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
Points # 1/2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
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.
4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
5. Use Select Single if all primary key fields are supplied in the Where condition .
Point # 1
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
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.
Point # 2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
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
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Point # 3
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.
Point # 4
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
Point # 5
If all primary key fields are supplied in the Where condition you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements contd.. SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
2. For all frequently used Select statements, try to use an index.
3. Using buffered tables improves the performance considerably.
Point # 1
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
SET SEATSOCC = SEATSOCC - 1.
Point # 2
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
AND CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
Point # 3
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
Select Statements contd Aggregate Functions
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.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
Maxno = 0.
Select * from zflight where airln = LF and cntry = IN.
Check zflight-fligh > maxno.
Maxno = zflight-fligh.
Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements contd For All Entries
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.
The plus
Large amount of data
Mixing processing and reading of data
Fast internal reprocessing of data
Fast
The Minus
Difficult to program/understand
Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
Check that data is present in the driver table
Sorting the driver table
Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.
Endif.
Select Statements contd Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
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.
3. Instead of using nested Select loops it is often better to use subqueries.
Point # 1
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
WHERE DOMNAME = DD01L_WA-DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS = DD01L_WA-AS4VERS
AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
AND DDLANGUAGE = SY-LANGU.
ENDSELECT
Point # 2
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Point # 3
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
INTO SFLIGHT_WA
FOR ALL ENTRIES IN T_SPFLI
WHERE SEATSOCC < F~SEATSMAX
AND CARRID = T_SPFLI-CARRID
AND CONNID = T_SPFLI-CONNID
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
WHERE SEATSOCC < F~SEATSMAX
AND EXISTS ( SELECT * FROM SPFLI
WHERE CARRID = F~CARRID
AND CONNID = F~CONNID
AND CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK' )
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
1. Table operations should be done using explicit work areas rather than via header lines.
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4. A binary search using secondary index takes considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
Point # 2
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
Point # 3
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
Point # 5
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
Point # 6
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
Point # 7
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
<WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
WA-FLAG = 'X'.
MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
Point # 8
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
ADD: WA1-VAL1 TO WA2-VAL1,
WA1-VAL2 TO WA2-VAL2.
MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
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
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
Point # 9
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 10
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
DELETE ITAB.
ELSE.
PREV_LINE = WA.
ENDIF.
ENDLOOP.
Point # 11
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12. Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
Point # 12
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 13
SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables contd
Hashed and Sorted tables
1. For single read access hashed tables are more optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP. -
Hi Friends,
please suggest me in performance innerjoin is better or for all entries is better to get data from two transparent tables.
Krishna.hi,
<b>for all entries is the better method.</b>
FOR ALL ENTRIES is an effective way of doing away with using JOIN on two tables.
You can check the below code -
SELECT BUKRS BELNR GJAHR AUGDT
FROM BSEG
INTO TABLE I_BSEG
WHERE BUKRS = ....
SELECT BUKRS BELNR BLART BLDAT
FROM BKPF
INTO TABLE I_BKPF
FOR ALL ENTRIES IN I_BSEG
WHERE BUKRS = I_BSEG-BUKRS
AND BELNR = I_BSEG-BELNR
AND BLDAT IN SO_BLDAT.
*******************************8
look another example
what is the use of FOR ALL ENTRIES
1. INNER JOIN
DBTAB1 <----
> DBTAB2
It is used to JOIN two DATABASE tables
having some COMMON fields.
2. Whereas
For All Entries,
DBTAB1 <----
> ITAB1
is not at all related to two DATABASE tables.
It is related to INTERNAL table.
3. If we want to fetch data
from some DBTABLE1
but we want to fetch
for only some records
which are contained in some internal table,
then we use for alll entries.
1. simple example of for all entries.
2. NOTE THAT
In for all entries,
it is NOT necessary to use TWO DBTABLES.
(as against JOIN)
3. use this program (just copy paste)
it will fetch data
from T001
FOR ONLY TWO COMPANIES (as mentioned in itab)
4
REPORT abc.
DATA : BEGIN OF itab OCCURS 0,
bukrs LIKE t001-bukrs,
END OF itab.
DATA : t001 LIKE TABLE OF t001 WITH HEADER LINE.
itab-bukrs = '1000'.
APPEND itab.
itab-bukrs = '1100'.
APPEND itab.
SELECT * FROM t001
INTO TABLE t001
FOR ALL ENTRIES IN itab
WHERE bukrs = itab-bukrs.
LOOP AT t001.
WRITE :/ t001-bukrs.
ENDLOOP.
Hope this helps!
Regards,
Anver -
For all entries vs. subquery
saw sap help on performance... & saw that using subquery is better than for all entries?
i understand that using join may be the best method for joining a few tables..
for many tables, normally for all entries are used.
so how about subquery?
codes by sap..
Using for all entries...
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
INTO SFLIGHT_WA
FOR ALL ENTRIES IN T_SPFLI
WHERE SEATSOCC < F~SEATSMAX
AND CARRID = T_SPFLI-CARRID
AND CONNID = T_SPFLI-CONNID
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
using subquery...
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
WHERE SEATSOCC < F~SEATSMAX
AND EXISTS ( SELECT * FROM SPFLI
WHERE CARRID = F~CARRID
AND CONNID = F~CONNID
AND CITYFROM = 'FRANKFURT'
AND CITYTO = 'NEW YORK' )
AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.Hi Charles,
It is not at all advised to use SELECT...ENDSELECT to fetch data from the database. It would reduce the performance.
Generally to achieve your query, I will do this.
SELECT * FROM SFLIGHT
INTO TABLE IT_SFLIGHT
WHERE SEATSOCC S_SEATSMAX
AND FLDATE BETWEEN '19990101' AND '20060331'.
IF SY-SUBRC = 0.
LOOP AT IT_SFLIGHT.
V_TABIX = SY-TABIX.
SELECT SINGLE * FROM SPFLI
INTO WA_SPFLI
WHERE CARRID = IT_SFLIGHT-CARRID
AND CONNID = IT_SFLIGHT-CONNID
AND CITYFROM = 'FRANKFRUIT'
AND CITYTO = 'NEW YORK'.
IF SY-SUBRC <> 0.
DELETE IT_SFLIGHT INDEX V_TABIX.
ENDIF.
ENDLOOP. " IT_SFLIGHT
ENDIF. " SFLIGHT
Thanks,
Sreekanth -
Nested statement "for all entries in"
Hi,
is ist possiple to nest "for all entries in" statements ?
At the moment I have the following SELECT-Statement:
select * from /rtc/tm_inusk
appending table gt_zrtc4inusk
for all entries in lt_trkorrdesti
where trkorr = lt_trkorrdesti-trkorr and
objname in lv_selk_copy.
Sometimes the statement dumps because the range table "lv_selk_copy" is to big.
In another thread I was told to use "for all entries in" instead of a range when the range is to big.
If do so I have to use two "for all entries in" statements in my select. But I think this is not possible.
So any idea ?
Thanks
ArnfriedHi,
Using two for all entries in not possible... Its better that you split up your range into smaller chunks..
or..
select * from /rtc/tm_inusk
appending table gt_zrtc4inusk
for all entries in lt_trkorrdesti
where trkorr = lt_trkorrdesti-trkorr .
Once you have selected delete the records where objname Not in lv_selk_copy. -
How to use single buffered table with FOR ALL ENTRIES KEYWORD
Hai,
I'm Using TJ02T Database table, It is single buffered table but at the same time I want to use FOR ALL ENTRIES KEYWORD , Please Help me.
Regards,
S.JananiHi,
FOR ALL ENTRIES will not depend on the buffering nature of the table. The single buffered table will only only buffer one record into memory. You can still use the statement to query the values, but it may have performance problems if the data volume is high since the records are not completely buffered into memory, the time will spent in getting data from DB.
Thanks..
Preetham S -
For All Entries with two tables
Hi All,
Can we use FOR ALL ENTRIES with two tables. for example
SELECT * FROM MKPF INTO TABLE T_MKPF
WHERE BUDAT IN S_BUDAT.
SELECT * FROM MARA INTO TABLE T_MARA
WHERE MTART IN S_MTART AND
MAKTL IN S_MAKTL.
SELECT * FROM MSEG INTO TABLE T_MSEG
FOR ALL ENTRIES IN "T_MKPF AND T_MARA"
WHERE MBLNR EQ T_MKPF-MBLNR AND
MATNR EQ T_MARA-MATNR.
can we do it like this or any other way to do this plz tell. I waitting for your responce.
Thanks
JitendraHi,
u cannot do like this....chek some documentation on it..
1. duplicate rows are automatically removed
2. if the itab used in the clause is empty , all the rows in the source table will be selected .
3. performance degradation when using the clause on big tables.
Say for example you have the following abap code:
Select * from mara
For all entries in itab
Where matnr = itab-matnr.
If the actual source of the material list (represented here by itab) is actually another database table, like:
select matnr from mseg
into corresponding fields of table itab
where .
Then you could have used one sql statement that joins both tables.
Select t1.*
From mara t1, mseg t2
Where t1.matnr = t2.matnr
And T2 ..
So what are the drawbacks of using the "for all entires" instead of a join ?
At run time , in order to fulfill the "for all entries " request, the abap engine will generate several sql statements (for detailed information on this refer to note 48230). Regardless of which method the engine uses (union all, "or" or "in" predicates) If the itab is bigger then a few records, the abap engine will break the itab into parts, and rerun an sql statement several times in a loop. This rerun of the same sql statement , each time with different host values, is a source of resource waste because it may lead to re-reading of data pages.
returing to the above example , lets say that our itab contains 500 records and that the abap engine will be forced to run the following sql statement 50 times with a list of 10 values each time.
Select * from mara
Where matnr in ( ...)
Db2 will be able to perform this sql statement cheaply all 50 times, using one of sap standard indexes that contain the matnr column. But in actuality, if you consider the wider picture (all 50 executions of the statement), you will see that some of the data pages, especially the root and middle-tire index pages have been re-read each execution.
Even though db2 has mechanisms like buffer pools and sequential detection to try to minimize the i/o cost of such cases, those mechanisms can only minimize the actual i/o operations , not the cpu cost of re-reading them once they are in memory. Had you coded the join, db2 would have known that you actually need 500 rows from mara, it would have been able to use other access methods, and potentially consume less getpages i/o and cpu.
In other words , when you use the "for all entries " clause instead of coding a join , you are depriving the database of important information needed to select the best access path for your application. Moreover, you are depriving your DBA of the same vital information. When the DBA monitors & tunes the system, he (or she) is less likely to recognize this kind of resource waste. The DBA will see a simple statement that uses an index , he is less likely to realize that this statement is executed in a loop unnecessarily.
Beore using the "for all entries" clause and to evaluate the use of database views as a means to:
a. simplify sql
b. simplify abap code
c. get around open sql limitations.
check the links
http://www.thespot4sap.com/articles/SAPABAPPerformanceTuning_ForAllEntries.asp
The specified item was not found.
Regards,
Nagaraj -
For all entries in join conditions
Hi All,
Can we use for all entries statement in the selection of joining 4 tables.
If so, please give me an example.
ThanksHello,
U can use it.
Check this:
* Get the material classification details
SELECT A~CUOBJ A~OBJEK A~KLART B~ATINN B~ATZHL B~ATWRT B~ATFLV
B~ATAWE B~ATFLB B~ATAW1 C~CLINT D~CLASS
INTO CORRESPONDING FIELDS OF TABLE G_T_OBJECTS
FROM INOB AS A INNER JOIN AUSP AS B
ON A~CUOBJ = B~OBJEK AND
A~KLART = B~KLART
INNER JOIN KSSK AS C
ON B~OBJEK = C~OBJEK AND
B~KLART = C~KLART
INNER JOIN KLAH AS D
ON C~CLINT = D~CLINT
FOR ALL ENTRIES IN L_T_OBJECT
WHERE A~OBJEK EQ L_T_OBJECT-OBJEK AND
A~OBTAB EQ 'MARA' AND
A~KLART IN S_KLART AND
B~ADZHL EQ '0000' AND
C~LKENZ EQ ' ' AND
D~CLASS IN S_CLASS.
If useful reward.
Vasanth -
Hi,
please which should be used between for all entries or join????All abap programers and most of the dba's that support abap programmers are familiar with the abap clause "for all entries". Most of the web pages I visited recently, discuss 3 major drawbacks of the "for all entries" clause:
1. duplicate rows are automatically removed
2. if the itab used in the clause is empty , all the rows in the source table will be selected .
3. performance degradation when using the clause on big tables.
In this post I'd like to shed some light on the third issue. Specifically i'll discuss the use of the "for all entries" clause as a means to join tables in the abap code instead of in db2.
Say for example you have the following abap code:
Select * from mara
For all entries in itab
Where matnr = itab-matnr.
If the actual source of the material list (represented here by itab) is actually another database table, like:
select matnr from mseg
into corresponding fields of table itab
where �.
Then you could have used one sql statement that joins both tables.
Select t1.*
From mara t1, mseg t2
Where t1.matnr = t2.matnr
And T2�..
So what are the drawbacks of using the "for all entires" instead of a join ?
At run time , in order to fulfill the "for all entries " request, the abap engine will generate several sql statements (for detailed information on this refer to note 48230). Regardless of which method the engine uses (union all, "or" or "in" predicates) If the itab is bigger then a few records, the abap engine will break the itab into parts, and rerun an sql statement several times in a loop. This rerun of the same sql statement , each time with different host values, is a source of resource waste because it may lead to re-reading of data pages.
returing to the above example , lets say that our itab contains 500 records and that the abap engine will be forced to run the following sql statement 50 times with a list of 10 values each time.
Select * from mara
Where matnr in ( ...)
Db2 will be able to perform this sql statement cheaply all 50 times, using one of sap standard indexes that contain the matnr column. But in actuality, if you consider the wider picture (all 50 executions of the statement), you will see that some of the data pages, especially the root and middle-tire index pages have been re-read each execution.
Even though db2 has mechanisms like buffer pools and sequential detection to try to minimize the i/o cost of such cases, those mechanisms can only minimize the actual i/o operations , not the cpu cost of re-reading them once they are in memory. Had you coded the join, db2 would have known that you actually need 500 rows from mara, it would have been able to use other access methods, and potentially consume less getpages i/o and cpu.
In other words , when you use the "for all entries " clause instead of coding a join , you are depriving the database of important information needed to select the best access path for your application. Moreover, you are depriving your DBA of the same vital information. When the DBA monitors & tunes the system, he (or she) is less likely to recognize this kind of resource waste. The DBA will see a simple statement that uses an index , he is less likely to realize that this statement is executed in a loop unnecessarily.
In conclusion I suggest to "think twice" before using the "for all entries" clause and to evaluate the use of database views as a means to:
a. simplify sql
b. simplify abap code
c. get around open sql limitations. -
Maximum number of records for usage of "For all entries"
Hi,
Is there a limit on maximum number of records to be selected from the database using "For all entries" statement ?
Thanks in advanceThere is a UNDOCUMENTED(??) behaviousr
FOR ALL ENTRIES does ahidden SELECT DISTINCT & drops duplicates.
http://web.mit.edu/fss/dev/abap_review_check_list.htm
3 pitfalls
"FOR ALL ENTRIES IN..." (outer join) are very fast but keep in the mind the special features and 3 pitfalls of using it.
(a) Duplicates are removed from the answer set as if you had specified "SELECT DISTINCT"... So unless you intend for duplicates to be deleted include the unique key of the detail line items in your select statement. In the data dictionary (SE11) the fields belonging to the unique key are marked with an "X" in the key column.
^^!!!!
(b) If the "one" table (the table that appears in the clause FOR ALL ENTRIES IN) is empty, all rows in the "many" table (the table that appears in the SELECT INTO clause ) are selected. Therefore make sure you check that the "one" table has rows before issuing a select with the "FOR ALL ENTRIES IN..." clause.
(c) If the 'one' table (the table that appears in the clause FOR ALL ENTRIES IN) is very large there is performance degradation Steven Buttiglieri created sample code to illustrate this.
Maybe you are looking for
-
Small office mono laser budget printer suggestion
For entry level lasers I've pretty much standardized on the Brother. I just installed an HL5470DW and it works like a charm.
-
Exchange server 2010 DAG failover
Hi team , We have configured exchange server 2010 in DAG environment . We have added 3 mailbox server in DAG . but my active mailbox copy failed the database are failover to another passive copy server & status is mounted . after failover emails serv
-
Using third party jars with Oracle Business Rules
Hi I am working on Oracle AS 10g release 2. We are using Oracle Business Rules in integration with Oracle BPEL. While using third party jars however, Oracle Business Rules end is facing errors. Error during unmarshallingProvider com.sun.xml.bind.Cont
-
Limit FPS of multiple instances of vmware on the same machine not over IP
Issue: How can I limit the fps of multiple vmachines on the same machine? (not over IP) I want to run several vmachines on the same physical machine and limit their fps. I'm aware it can be done with PCoIP but this is not over the network. This is fo
-
Cannot find main even there is main ??
Exception in thread "main" java.lang.NoClassDefFoundError: Test class Test { public static void main(String args[]) { System.out.println("HI"); What's the problem..... It can be complied, but when i use java Test in cmd Exception creat