FOR ALL ENTRIES IN Memory Dump Issue

We have a "TSV_TNEW_BLOCKS_NO_ROLL_MEMORY" dump that is confusing me. The dump shows the SELECT (copied below) results in a gt_ekko_total table with over 70 million records (from the dump - Table IT_58[70324288x66]). The problem is since EKKO has 294,000 rows and EKPO has 4.5 million rows, and a FOR ALL ENTRIES IN automatically changes the SELECT to a SELECT DISTINCT, the result table can have at most 4.5 million records. On a FOR ALL ENTRIES IN, does the database return all the rows and then SAP "deletes adjacent duplicates"?
The only solution I can think of is to change the SELECT to a SELECT DISTINCT, so perhaps when SAP builds the receiving itab, it may have many fewer rows. Let me know if you have seen this before.
SELECT ekkoebeln ekkobsart ekkolponr ekkolifnr ekpo~werks
FROM ekko
INNER JOIN ekpo ON ekkoebeln = ekpoebeln
INTO TABLE gt_ekko_total
   FOR ALL ENTRIES IN pt_sched_agrm
WHERE ekko~lifnr = pt_sched_agrm-vendor
   AND ekko~bsart = pt_sched_agrm-doc_type
   AND ekpo~werks = pt_sched_agrm-plant
   AND ekko~loekz = space.

Hi Mike,
If did all the pre-requisite for for all entries and failed to improve the performance, you use the following way.
Instead of directly select from ekko you can select the po number(EBELN) from VIEW M_MEKKL based on LIFNR, BSART and BSTYP (what ever the fields you have) . Then do the joining select based on EBELN not LIFNR. It will surely improve your performance. For more details take reference of sap note: 0000191492.
Thanks
Subhankr

Similar Messages

About for all entries in itab usage issue

hi
i will get a lot of material information first.
the next i will get inforamtion about table MARC AND MBEW.
one statement i use sap function to get MARC:
CALL FUNCTION 'MARC_ARRAY_READ'
    EXPORTING
      KZRFB                = ' '
      NEUFLAG              = ' '
      SPERRMODUS           = ' '
      STD_SPERRMODUS       = ' '
      EXCEPTION_ON_LOCK    = ' '
    IMPORTING
      RETC                 = ret
    TABLES
      IPRE01               = ipre
      MARC_TAB             = disp
    EXCEPTIONS
      ENQUEUE_MODE_CHANGED = 1
      LOCK_ON_MARC         = 2
      LOCK_SYSTEM_ERROR    = 3
      OTHERS               = 4.
two statement if i use:
    select matnr dispo ekgrp plifz
into table disp
from marc
for all entries in ipre
where werks = ipre-werks and
        matnr = ipre-matnr.
which one will get better performce.
and
if ipre table have a lot of data, so in sap what about for all entries of Limit?
and will lose data to use for all entries of statements?
have function in sap to get data like 'MARC_ARRAY_READ' about MEBW.
THANK YOU!

thank you!
what about for all entries of Limit?
and will lose data to use for all entries of statements?
exist function about get MEBW ARRAY??

Performance issue with select query and for all entries.

hi,
i have a report to be performance tuned.
the database table has around 20 million entries and 25 fields.
so, the report fetches the distinct values of two fields using one select query.
so, the first select query fetches around 150 entries from the table for 2 fields.
then it applies some logic and eliminates some entries and makes entries around 80-90...
and then it again applies the select query on the same table using for all entries applied on the internal table with 80-90 entries...
in short,
it accesses the same database table twice.
so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
is around 80-90 entries too much for using "for all entries"?
the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
i really cant find the way out...
please help.

chinmay kulkarni wrote:Chinmay,
Even though you tried to ask the question with detailed explanation, unfortunately it is still not clear.
It is perfectly fine to access the same database twice. If that is working for you, I don't think there is any need to change the logic. As Rob mentioned, 80 or 8000 records is not a problem in "for all entries" clause.
>
> so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
>
It is not clear what you tried to do here. Did you try to bring all 20 million records into an internal table? That will certainly cause the program to short dump with memory shortage.
> the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
>
That is fine. Actually, it is better (performance wise) to do much of the work in ABAP than writing a complex WHERE clause that might bog down the database.

For all entries issue

Hi All,
Below is the select query I have which is taking more time when the records in the internal table is touching to almost 2 million.
SELECT paledger vrgar versi
        perio paobjnr pasubnr
        belnr posnr gjahr perde
    FROM   ce1ec01
    APPENDING TABLE t_ce1ec01 PACKAGE SIZE 10000
    FOR ALL ENTRIES IN t_arixco2_tmp
    WHERE paobjnr EQ t_arixco2_tmp-paobjnr
      AND PERIO gt p_perio.
ENDSELECT.
The secondary index is created with fields PAOBJNR and PERIO fields.
I have used ST05 and it is using the secondary index.
Regards,
Pratyusha.

the second thing (after Rob's suggestion) to do is to try it like this:
SELECT paledger vrgar versi
perio paobjnr pasubnr
belnr posnr gjahr perde
FROM ce1ec01
INTO TABLE t_ce1ec01
FOR ALL ENTRIES IN t_arixco2_tmp
WHERE paobjnr EQ t_arixco2_tmp-paobjnr
AND PERIO gt p_perio.
since the package size will not save memory for the FAE we can try it directly
since all the data is selected before the package size is applied in any case.
if this fails we have a configuration issue. (your memory demand is higher than what
your configuration allows). You have to think of alternative solutions than... e.g.
divide the entries in t_arixco2_tmp in packages and process one after the other with FAE.
Kind regrds,
Hermann

Performance Issue in Select Statement (For All Entries)

Hello,
I have a report where i have two select statement
First Select Statement:
Select A B C P Q R
     from T1 into Table it_t1
          where ....
Internal Table it_t1 is populated with 359801 entries through this select statement.
Second Select Statement:
Select A B C X Y Z
     from T2 in it_t2 For All Entries in it_t1
          where A eq it_t1-A
             and B eq it_t1-B
             and C eq it_t1-C
Now Table T2 contains more than 10 lac records and at the end of select statement it_t2 is populated with 844003 but it takes a lot of time (15 -20 min) to execute second select statement.
Can this code be optimized?
Also i have created respective indexes on table T1 and T2 for the fields in Where Condition.
Regards,

If you have completed all the steps mentioned by others, in the above thread, and still you are facing issues then,.....
Use a Select within Select.
First Select Statement:
Select A B C P Q R package size 5000
     from T1 into Table it_t1
          where ....
Second Select Statement:
Select A B C X Y Z
     from T2 in it_t2 For All Entries in it_t1
          where A eq it_t1-A
             and B eq it_t1-B
             and C eq it_t1-C
do processing........
endselect
This way, while using for all entries on T2, your it_t1, will have limited number of entries and thus the 2nd select will be faster.
Thanks,
Juwin

Performance issue fetching huge number of record with "FOR ALL ENTRIES"

Hello,
We need to extract an huge amount of data (about 1.000.000 records) from VBEP table, which overall dimension is about 120 milions records.
We actually use this statements:
CHECK NOT ( it_massive_vbep[] IS INITIAL ) .
SELECT (list of fields) FROM vbep JOIN vbap
             ON vbepvbeln = vbapvbeln AND
              vbepposnr = vbapposnr
             INTO CORRESPONDING FIELDS OF w_sched
             FOR ALL ENTRIES IN it_massive_vbep
             WHERE    vbep~vbeln   = it_massive_vbep-tabkey-vbeln
                AND    vbep~posnr   = it_massive_vbep-tabkey-posnr
                AND    vbep~etenr   = it_massive_vbep-tabkey-etenr.
notice that internal table it_massive_vbep contains always records with fully specified key.
Do you think this query could be further optimized?
many thanks,
-Enrico

the are 2 option to improve performance:
+ you should work in blocks of 10.000 to 50.000
+ you should check archiving options, does this really make sense
> VBEP table, which overall dimension is about 120 milions records.
it_massive_vbep into it_vbep_notsomassive (it_vbep_2)
CHECK NOT ( it_vbep_2[] IS INITIAL ) .
get runtime field start.
SELECT (+list of fields+)
              INTO CORRESPONDING FIELDS OF TABLE w_sched
              FROM vbep JOIN vbap
              ON vbep~vbeln = vbap~vbeln AND
                   vbep~posnr = vbap~posnr
              FOR ALL ENTRIES IN it_vbep_2
              WHERE vbep~vbeln = it_vbep_2-vbeln
              AND      vbep~posnr = it_vbep_2-posnr
              AND      vbep~etenr = it_vbep_2-etenr.
get runtime field stop.
t = stop - start.
write: / t.
Be aware that even 10.000 will take some time.
Other question, how did you get the 1.000.000 records in it_massive_vbep. They are not typed in, but somehow select.
Change the FAE into a JOIN and it will be much faster.
Siegfried

Issue with FOR ALL ENTRIES

Hi All,
I have used FOR ALL ENTRIES statement in while selecting data based on some other internal table (to avoid select within loop).
While using FOR ALL ENTRIES, the target table (internal table in which data is getting stored) is getting affected.
The other fields are becoming zero and several rows gets delerted from the internal table after performing select query.
How to avoid this bug?
Kindly help me out....
Regards
Pavan

hi after the for all entries statement did you used the read statement .
if not you will not get any data ..check this program..
tables:mara,marc.
data:begin of itab occurs 0,
     matnr like mara-matnr,
     end of itab.
data:begin of itab1 occurs 0,
     matnr like marc-matnr,
     werks like marc-werks,
     end of itab1.
select   matnr
      from mara
      into corresponding fields of table itab.
      if   itab is initial.
      select matnr
              werks
             from marc
             into table itab1
             for all entries in itab
             where matnr = itab-matnr.
             loop at itab1.
             read table itab with key matnr = itab-matnr.
             write:/ itab1-matnr,itab1-werks.
             endloop.
             endif.

Performance issue in 'Selelect statement with for all entries'

Hi,
The following SELECT statement is taking too much time.
         SELECT * FROM /rb04/yc5_mver
         INTO TABLE g_it_mver
         FOR ALL ENTRIES IN l_it_inva
         WHERE matnr EQ l_it_inva-matnr AND
                      werks EQ l_it_inva-werks AND
                      indei EQ l_it_inva-indei AND
                      gjahr IN g_r_gjahr.
     Internal table l_it_inva is having too many records.
    Is there any way to optimize it.
Regards,
Tintu

Hi Tintu,
check table l_it_inva for initial.
sort internal table l_it_inva with key matnr werks indei gjahr.
delete adjacent duplicates from l_it_inva comparing   matnr werks indei gjahr.
Then use following select query.
SELECT * FROM /rb04/yc5_mver
INTO TABLE g_it_mver
FOR ALL ENTRIES IN l_it_inva
WHERE matnr EQ l_it_inva-matnr AND
werks EQ l_it_inva-werks AND
indei EQ l_it_inva-indei AND
gjahr IN g_r_gjahr.
Regards,
Vijay

Is "Joins & For all entries" in same SQL Query Possible?

Hi all Professional,
Can we use "Inner Joins" and "For All Entries In" in the same SQL Query. if possible then pls clarify this query.
Here I am using three Transparent Table and fetching data from them.
SELECT abukrs abelnr ahkont axref2 ashkzg awrbtr agsber azfbdt azterm amwskz asgtxt axref1 agjahr abuzei
           bkunnr bwerks bmenge bmeins bmatnr bkoart
           cbukrs cbelnr cblart cbldat cbudat cxblnr cgjahr cstgrd cstblg cstblg c~xreversal
           INTO CORRESPONDING FIELDS OF TABLE it_bsid FROM ( ( bsid AS a
           INNER JOIN acctit AS b ON abukrs = bbukrs )
           INNER JOIN bkpf AS c ON cbukrs = abukrs
                               AND cbelnr = abelnr
                               AND cgjahr = agjahr )
           FOR ALL ENTRIES IN it_bkpf
              WHERE
                a~belnr EQ it_bkpf-belnr
            AND a~gjahr EQ it_bkpf-gjahr
            AND a~bukrs EQ it_bkpf-bukrs
            AND a~gsber IN so_bus.
After executing this query, I'm getting Dump Error.
Error analysis
    When the program was running, it was established that more
    memory was needed than the operating system is able to provide savely.
    To avoid a system crash, you must prevent this
    situation.
               Last error logged in SAP kernel
    Component............ "EM"
    Place................ "SAP-Server Development_DVL_01 on host Development (wp
     2)"
    Version.............. 37
    Error code........... 7
    Error text........... "Warning: EM-Memory exhausted: Workprocess gets PRIV "
    Description.......... " "
    System call.......... " "
    Module............... "emxx.c"
    Line................. 1886
Pls resolve, if anybody knows.
Thanks
Devinder

Hi,
During testing i notice that splitting into multiple selects does improve performance. But the best performance I achieved using DB Hints instead of splitting the select statements.
Generally performance of joins together with for all entries is bad.
However if you will look into SAP note 1662726 you will notice that this issue (bad performance in using join and for all entries together) has been addressed.
Even though the note is for HANA DB, FM RSDU_CREATE_HINT_FAE can be used independent of DB.
On HANA DB performance improvement is huge (i achieved 62 seconds using DB Hints compared to 1656 seconds using for all entries). On Oracle DB the same code initially run in 99 seconds with for all entries and with DB Hints in 82 seconds for ~ 1.000.000 records and ~660 seconds compared to 1349 seconds for ~8.000.000 records..
Sample code from SAP Note below:
Original statement:
SELECT COL1 COL2 COL3 COL4 COL5
FROM TAB1
INTO CORRESPONDING FIELDS OF TABLE LT_RESULT
FOR ALL ENTRIES IN LT_SOURCE_TMP
WHERE COL3 = LT_SOURCE_TMP-COL3
AND   COL4 = LT_SOURCE_TMP-COL4
AND   COL5 = LT_SOURCE_TMP-COL5
Revision:
DATA: L_T_TABLNM TYPE RSDU_T_TABLNM,
      L_LINES TYPE I,
      L_HINT TYPE RSDU_HINT.
APPEND 'TAB1' TO L_T_TABLNM.
L_LINES = LINES( LT_SOURCE_TMP ).
CALL FUNCTION 'RSDU_CREATE_HINT_FAE'
EXPORTING
    I_T_TABLNM   = L_T_TABLNM
    I_FAE_FIELDS = 3
    I_FAE_LINES = L_LINES
    I_EQUI_JOIN = RS_C_TRUE
IMPORTING
    E_HINT       = L_HINT
EXCEPTIONS
    OTHERS       = 0.
SELECT COL1 COL2 COL3 COL4 COL5
FROM TAB1
INTO CORRESPONDING FIELDS OF TABLE LT_RESULT
FOR ALL ENTRIES IN LT_SOURCE_TMP
WHERE COL3 = LT_SOURCE_TMP-COL3
AND   COL4 = LT_SOURCE_TMP-COL4
AND   COL5 = LT_SOURCE_TMP-COL5
          %_HINTS ADABAS L_HINT.
Best regards,
Octavian

For all entries problem

Hi experts,
I have a below statement in my code
"SELECT on EKPO for all entries on ITAB (which is having 4 hundread thousand recods )"
giving dump saying "MEMORY_PGFREE_FAILED" and "Error releasing memory block in paging"
i need your suggestion to avoid the memory problem
"MEMORY_PGFREE_FAILED" ?
can we go ahead with EXTRACT logic, does this solve the memory problem?
thoughts will be appriciated,
Thanks,
Shaik bhasha

See the example code :
REPORT ZSPFLI LINE-SIZE 132 LINE-COUNT 65(3)
                                             NO STANDARD PAGE HEADING.
TABLES:SPFLI,SCARR, SFLIGHT, SBOOK.
SELECT-OPTIONS: MYCARRID FOR SPFLI-CARRID.
FIELD-GROUPS: HEADER, SPFLI_FG, SFLIGHT_FG, SBOOK_FG.
INSERT:
        SPFLI-CARRID
        SPFLI-CONNID
        SFLIGHT-FLDATE
        SBOOK-BOOKID
       INTO HEADER,
        SPFLI-CARRID
        SPFLI-CONNID
        SPFLI-CITYFROM
        SPFLI-AIRPFROM
        SPFLI-CITYTO
        SPFLI-AIRPTO
        SPFLI-DEPTIME
        SCARR-CARRNAME
      INTO SPFLI_FG,
        SFLIGHT-FLDATE
        SFLIGHT-SEATSMAX
        SFLIGHT-SEATSOCC
        SFLIGHT-PRICE
      INTO SFLIGHT_FG,
        SBOOK-BOOKID
        SBOOK-CUSTOMID
        SBOOK-CUSTTYPE
        SBOOK-SMOKER
       INTO SBOOK_FG.
SELECT * FROM SPFLI WHERE CARRID IN MYCARRID.
SELECT SINGLE * FROM SCARR WHERE CARRID = SPFLI-CARRID.
EXTRACT SPFLI_FG.
SELECT * FROM SFLIGHT
   WHERE CARRID = SPFLI-CARRID AND CONNID = SPFLI-CONNID.
    EXTRACT SFLIGHT_FG.
    SELECT * FROM SBOOK
           WHERE CARRID = SFLIGHT-CARRID AND
           CONNID = SFLIGHT-CONNID AND FLDATE = SFLIGHT-FLDATE.
      EXTRACT SBOOK_FG.
      CLEAR SBOOK.
    ENDSELECT.
    CLEAR SFLIGHT.
ENDSELECT.
CLEAR SPFLI.
ENDSELECT.
SORT.
LOOP.
AT SPFLI_FG.
    FORMAT COLOR COL_HEADING.
    WRITE: / SCARR-CARRNAME,
             SPFLI-CONNID, SPFLI-CITYFROM,
             SPFLI-AIRPFROM, SPFLI-CITYTO, SPFLI-AIRPTO, SPFLI-DEPTIME.
    FORMAT COLOR OFF.
ENDAT.
AT SFLIGHT_FG.
    WRITE: /15 SFLIGHT-FLDATE, SFLIGHT-PRICE, SFLIGHT-SEATSMAX,
               SFLIGHT-SEATSOCC.
ENDAT.
AT SBOOK_FG.
    WRITE: /30 SBOOK-BOOKID, SBOOK-CUSTOMID,
                 SBOOK-CUSTTYPE, SBOOK-SMOKER.
ENDAT.
ENDLOOP.

Select For all entries with multiple keys

Dear Developers,
im writing a program which reads the last the last mseg entry with bwart 101 and bwart 201 an writes it into different fields of a table. In dependance of the bwart the max-value of mkpf-budat should be moved into field wedat or wadat.
At the moment i use this coding:
loop at gt_daten assigning <fs_daten>.
    select distinct max( budat ) from wb2_v_mkpf_mseg2 into <fs_daten>-wedat
      where matnr_i = <fs_daten>-matnr
        and werks_i = <fs_daten>-werks
        and lgort_i = <fs_daten>-lgort
        and bwart_i = '101'.
    select distinct max( budat ) from wb2_v_mkpf_mseg2 into <fs_daten>-wadat
    where matnr_i = <fs_daten>-matnr
      and werks_i = <fs_daten>-werks
      and lgort_i = <fs_daten>-lgort
      and bwart_i = '201'.
endloop.
wb2_v_mkpf_mseg2 is a view combining mkpf an mseg by primary keys.
Searching the internet i read, using FOR ALL ENTRIES should be prefered to selectstatements in loops.
So i tried:
*selectstatement
select budat matnr_i werks_i lgort_i bwart_i from wb2_v_mkpf_mseg2 into table lt_mseg for all entries in gt_daten
    where matnr_i = gt_daten-matnr
      and werks_i = gt_daten-werks
      and lgort_i = gt_daten-lgort
      and ( bwart_i = '101' or bwart_i = '201' )
*Substitute the MAX( )-Function
sort lt_mseg descending by matnr werks lgort bwart budat.
delete adjacent duplicates from lt_mseg comparing matnr werks lgort bwart.
*Differ between wedat and wadat
loop at gt_daten assigning <fs_daten>.
    loop at lt_mseg assigning <fs_mseg>
      where matnr = <fs_daten>-matnr
        and werks = <fs_daten>-werks
        and lgort = <fs_daten>-lgort.
      case <fs_mseg>-bwart.
        when '101'.
          <fs_daten>-wedat = <fs_mseg>-budat.
        when '201'.
          <fs_daten>-wadat = <fs_mseg>-budat.
      endcase.
    endloop.
Even in the dev-system this takes twice the time of the "nested" selects.
Imho this is because of the internal OR interpretation of the FOR ALL ENTRIES-statement and the size of the result.
Can somebody give me a hint, how to tune this code?
Select Inner join should be difficult because the target field differs, dependent of the value in bwart...
Thanks in advance!

I understand that you are trying to capture the maximum value of posting date MKPF-BUDAT for movement types 101 and 201 for each combination of material, plant and storage location.
Few things, that makes the below coding more efficient at both application and database level and I confirmed this on an IDES sandbox
1. Along with MKPF and MSEG, there is another table WBGT, in the view WB2_V_MKPF_MSEG join and also WBGT has select condition restrictions imposed on its fields. So if this restriction impacts your selection you may want to do a INNER JOIN of MSEG with MKPF only (with MSEG as leading table, as it has an active secondary index with MATNR, WERKS, LGORT and BWART ) and also there won't be overhead from the unnecessary join with WBGT table whose fields you are not using.
2. The below SORT on lt_mseg will ensure that the record having greatest BUDAT will be at the top of all rows (least index) for each combination of MATNR, WERKS, LGORT and BWART.
3. DELETE ADJACENT DUPLICATES will ensure that only the top row (having greatest BUDAT) remains in the table lt_mseg for each combination of MATNR, WERKS, LGORT and BWART. This will ensure that subsequent READs with BINARY SEARCH will always and efficiently read the row with maximum value of BUDAT for each unique combination of MATNR, WERKS, LGORT and BWART.
4. The below logic will require more memory (even though it is more efficient performance wise) compared to direct SELECT with MAX for each MATNR, WERKS, LGORT and BWART in a LOOP the way you were doing before. So if the size of lt_mseg is causing memory issues, your logic with aggregate function MAX at database level will be your only option.
So, I propose you revise your coding like below for most optimal results
CHECK NOT gt_daten[] IS INITIAL.
*selectstatement
*SELECT budat matnr_i werks_i lgort_i bwart_i
* FROM wb2_v_mkpf_mseg2
* INTO TABLE lt_mseg
*    FOR ALL ENTRIES IN gt_daten
*    WHERE matnr_i = gt_daten-matnr
*      AND werks_i = gt_daten-werks
*      AND lgort_i = gt_daten-lgort
*      AND ( bwart_i = '101' OR bwart_i = '201' ).
* The below SELECT is more economical than the one commented above
SELECT mkpf~budat mseg~matnr mseg~werks mseg~lgort mseg~bwart
FROM mseg INNER JOIN mkpf
    ON mseg~mblnr = mkpf~mblnr AND
       mseg~mjahr = mkpf~mjahr
    INTO TABLE lt_mseg
      FOR ALL ENTRIES IN gt_daten
        WHERE mseg~matnr = gt_daten-matnr
          AND mseg~werks = gt_daten-werks
          AND mseg~lgort = gt_daten-lgort
          AND ( mseg~bwart = '101' OR mseg~bwart = '201' ).
*Substitute the MAX( )-Function
SORT lt_mseg BY matnr werks lgort bwart DESCENDING budat.
DELETE ADJACENT DUPLICATES FROM lt_mseg COMPARING matnr werks lgort bwart.
*Differ between wedat and wadat
LOOP AT gt_daten ASSIGNING <fs_daten>.
READ TABLE lt_mseg ASSIGNING <fs_mseg>
    WITH KEY matnr = <fs_daten>-matnr
             werks = <fs_daten>-werks
             lgort = <fs_daten>-lgort
             bwart = '101' BINARY SEARCH.
IF sy-subrc = 0.
    <fs_daten>-wedat = <fs_mseg>-budat.
ENDIF.
READ TABLE lt_mseg ASSIGNING <fs_mseg>
    WITH KEY matnr = <fs_daten>-matnr
             werks = <fs_daten>-werks
             lgort = <fs_daten>-lgort
             bwart = '201' BINARY SEARCH.
IF sy-subrc = 0.
    <fs_daten>-wadat = <fs_mseg>-budat.
ENDIF.
ENDLOOP.

For all entries or join

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.

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.Janani

Hi,
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

Dynamic Select Query including Dynamic Tables with For all Entries

Hello everyone,
I need to create a select query which involves using of Dynamic Tables.
Suppose I have a dynamic table <d1> which consist of let say 10 records.
Now i need to make a select query putting data into another dynamic table <d2>
CONCATENATE keyfield '=' '<d1>' INTO g_condition SEPARATED BY space.
CONCATENATE g_condition '-' keyfield INTO g_condition.
SELECT * FROM (wa_all_tables-name) INTO CORRESPONDING FIELDS OF TABLE <d1>
        FOR ALL ENTRIES IN <d1>
WHERE (g_condition).
But it is giving dump.
Please help me on this....

Short text
    A condition specified at runtime has an unexpected format.
What happened?
    Error in the ABAP Application Program
    The current ABAP program "ZNG_CUSTOMWRITE" had to be terminated because it has
    come across a statement that unfortunately cannot be executed.
Error analysis
    An exception occurred that is explained in detail below.
    The exception, which is assigned to class 'CX_SY_DYNAMIC_OSQL_SEMANTICS', was
     not caught in
    procedure "WRITE_ARCHIVE_PROD" "(FORM)", nor was it propagated by a RAISING
     clause.
    Since the caller of the procedure could not have anticipated that the
    exception would occur, the current program is terminated.
    The reason for the exception is:
    The current ABAP program has tried to execute an Open SQL statement
    which contains a WHERE, ON or HAVING condition with a dynamic part.
    The part of the WHERE, ON or HAVING condition specified at runtime in
    a field or an internal table, contains the invalid value "ZCOURIER-ZCOURIERID".
CONCATENATE keyfield '=' g_header INTO g_condition SEPARATED BY space.
CONCATENATE g_condition '-' keyfield INTO g_condition.
SELECT * FROM (wa_all_tables-name) INTO CORRESPONDING FIELDS OF TABLE <dyn_table1>
FOR ALL ENTRIES IN <dyn_table>
WHERE (g_condition).

Which is better group by or for all entries in

We have more than 11 Lac Records in AUFM table.
I am working on a Report to find SO to Production Order to AUFM (for raw material).
It's ALV OOP.
Which code will give better result - For AUFM fetch with key AUFNR.
GROUP BY matnr
OR
FOR ALL ENTRIES IN it_previous
Moderator message: too vague to give decent advice, please try yourself first and compare runtimes, re-post including all relevant information if required, please use international units only when posting again.
Please Read before Posting in the Performance and Tuning Forum
locked by: Thomas Zloch on Sep 8, 2010 10:13 AM

that oracle wont work if we have group by on a column which is character data type instead of number data typeEither he has been taught wrongly OR he has come across one specific case where it seems that there was an issue but he doesn't know enough about that case and is making a generalisation.
Hemant K Chitale

FOR ALL ENTRIES IN Memory Dump Issue

Similar Messages

Maybe you are looking for