Performance in Inner Join on VBAK

HI,
For a customized report the select statement was written like this which is giving time out error for large data. How one can improve performance of following Inner Joins.
  SELECT  *
      INTO CORRESPONDING FIELDS OF TABLE it_tab
       FROM vbak as A INNER JOIN vbuk as B
              ON Avbeln = Bvbeln
            INNER JOIN vbkd as C
             ON Avbeln = Cvbeln
  WHERE    A~vbeln      IN  so_vbeln
     AND   A~audat      IN  so_audat
     AND   A~auart      IN  so_auart
     AND   A~augru      IN  so_augru
     AND   A~faksk    IN  so_faksp
     AND   A~vkorg      IN  so_vkorg
     AND   A~vtweg      IN  so_vtweg
     AND   A~spart      IN  so_spart
     AND   A~vkbur      IN  so_vkbur
     AND   A~vkgrp      IN  so_vkgrp
     AND   A~vsbed      IN  so_vsbed
     AND   A~kunnr      IN  so_kunnr
     and   B~gbstk      IN  so_gbstx
     AND   C~posnr       =  '000000'.
Thanks
anya
Moderator message: FAQ, it all depends on the content of the so_ ranges at runtime.
Please Read before Posting in the Performance and Tuning Forum
Edited by: Thomas Zloch on Nov 1, 2010 11:57 AM

Others have already responded, and I would only like to dwell on the answers for a short while. Or maybe rather the question.
This question is typical for the inexperienced developer. This particular question is actually a little different, because there is a straight answer: there is no difference. For most questions of this type the answer is "it depends", because one
particular syntax can happen to perform better with one set of data and indexes, but with a different data/index profile another syntax gives better result.
Ideally, as long as two queries are logically equivalent, the syntax should not matter at all, because the optimizer should always figure out the best way to achieve the result. In practice, this is not the case, because there are lots of limitaitons in
an optimizer in an RDBMS.
While it certainly can matter for performance how you write your queries, that is not what you should focus on. What you should focus is to express your query as clearly as possible, and make sure that you have the relevant indexes in place. There is one
rule when it comes to query-writing you should take your heart: never entable a column in a condition in an expression, because that is likely to render index on that column useless.
For this particular question, the answer is that as you long as you write code for SQL Server, use the JOIN syntax. But if you use that in the Oracle world, you may get funny looks from people. It's a different culture over there...
Erland Sommarskog, SQL Server MVP, [email protected]

Similar Messages

  • Inner Join. How to improve the performance of inner join query

    Inner Join. How to improve the performance of inner join query.
    Query is :
    select f1~ablbelnr
             f1~gernr
             f1~equnr
             f1~zwnummer
             f1~adat
             f1~atim
             f1~v_zwstand
             f1~n_zwstand
             f1~aktiv
             f1~adatsoll
             f1~pruefzahl
             f1~ablstat
             f1~pruefpkt
             f1~popcode
             f1~erdat
             f1~istablart
             f2~anlage
             f2~ablesgr
             f2~abrdats
             f2~ableinh
                from eabl as f1
                inner join eablg as f2
                on f1ablbelnr = f2ablbelnr
                into corresponding fields of table it_list
                where f1~ablstat in s_mrstat
                %_HINTS ORACLE 'USE_NL (T_00 T_01) index(T_01 "EABLG~0")'.
    I wanted to modify the query, since its taking lot of time to load the data.
    Please suggest : -
    Treat this is very urgent.

    Hi Shyamal,
    In your program , you are using "into corresponding fields of ".
    Try not to use this addition in your select query.
    Instead, just use "into table it_list".
    As an example,
    Just give a normal query using "into corresponding fields of" in a program. Now go to se30 ( Runtime analysis), and give the program name and execute it .
    Now if you click on Analyze button , you can see, the analysis given for the query.The one given in "Red" line informs you that you need to find for alternate methods.
    On the other hand, if you are using "into table itab", it will give you an entirely different analysis.
    So try not to give "into corresponding fields" in your query.
    Regards,
    SP.

  • Poor Performance on Inner Join of VBUP and VBAK

    The following select is performing poorly, i.e., ST05 Execution is 1, Records is 246, but Time/Exec 94,499,272. Very poor.
    SELECT VBUPVBELN VBUPPOSNR VBAK~KUNNR
             FROM VBUP INNER JOIN VBAK
             ON VBUPVBELN = VBAKVBELN
             WHERE VBAK~VBTYP EQ 'C'     
               AND VBUP~LFSTA NE 'C'
               AND VBUP~LFGSA NE 'C'.
    VBUP has a custom index, Z01, on MANDT, LFSTA, LFGSA. There is no index on VBAK.
    The Explain under ST05 indicates an Est. I/O cost of 73.94 for a Clustered Index Seek on [VBAK].[VBAK0], and an Est. I/O cost of 81.34 for an Index Seek on [VBUP].[VBUPZ01].
    There is no index on VBAK, so I assume that's the first problem. But I don't understand why the index on VBUP does not appear to be helping. This the ST05 Explain: Index Seek WHERE: [PCI].[pci].[VBUP].[LFGSA] as [T_00].[LFGSA]<[@P4] OR [PCI].[pci].[VBUP].[LFGSA] as [T_00].[LFGSA]>[@P4] : [VBUP].MANDT EQ [@P1] ORDERED 1.
    Is my index even being used?  Any ideas how I can speed this up?
    Thanks in advance for your help.
    Beth

    tis the negative selection which is causing the problem..try to avoid selection using not equal to.
    try this.
    ranges : r_lfsta for vbup-lfsta.
    r_lfsta-sign = 'I'.
    r_lfsta-option = 'EQ'.
    r_lfsta-low = ' '.
    append r_lfsta.
    r_lfsta-low = 'A'.
    append r_lfsta.
    r_lfsta-low = 'B'.
    append r_lfsta.
    do similar for r_lfgsa also.
    SELECT VBUP~VBELN
                 VBUP~POSNR
                 VBAK~KUNNR
    FROM VBUP INNER JOIN VBAK
    into corresponding fields of table t_vbakvbup
    ON VBUPVBELN = VBAKVBELN
    WHERE VBAK~VBTYP EQ 'C'
    AND VBUP~LFSTA in r_lfsta
    AND VBUP~LFGSA in r_lfgsa. 
    or
    SELECT VBUP~VBELN
                 VBUP~POSNR
                 VBAK~KUNNR
    vbup~lfsta
    vbup~lfgsa
    FROM VBUP INNER JOIN VBAK
    into corresponding fields of table t_vbakvbup
    ON VBUPVBELN = VBAKVBELN
    WHERE VBAK~VBTYP EQ 'C' .
    delete t_vbakvbup where lfsta ne 'C'.
    delete t_vbakvbup where lfgsa ne 'C'.

  • Performance on select join vbap/vbak/vbep

    Hello,
    I would like to know how improve the performance (time-reponse) of my select :
    SELECT
    apmatkl  approdh apmatnr  aparktx  apvbeln apposnr  apnetwr  apkzwi3  apkzwi1  apmwsbp
    epbmeng  epwmeng  epedatu  apvrkme  ap~brgew
    INTO CORRESPONDING FIELDS OF TABLE p_tvbapcache
    FROM vbap AS ap
    INNER JOIN vbep AS ep ON  apvbeln = epvbeln AND apposnr = epposnr
    INNER JOIN vbak AS ak ON  akvbeln = epvbeln AND apvbeln = akvbeln
    WHERE ak~vbeln NOT LIKE '0005%'
    AND ep~vbeln NOT LIKE '0005%'
    AND ap~vbeln NOT LIKE '0005%'
    AND ep~edatu IN date
    AND ap~prodh IN nomencla
    AND ak~auart IN canal
    AND ap~matnr IN numero
    AND apnetwr <> 0 AND apnetwr <> '0'
    AND epwmeng <> 0 AND epwmeng <> '0'
    AND epbmeng <> 0 AND epbmeng <> '0'
    AND apkzwi1 <> 0 AND apkzwi1 <> '0'
    AND ak~faksk <> 'Z3'.
    The performance are very very very poor...
    For information, there are 18.329.040 entries in VBAP table; VBAK : 485.437 entries ; VBEP : 18.304.173 entries
    Many thanks for yours ideas,

    Hi Coppalle,
    Sometimes you need to have a bit more confidence.
    Your WHERE-clause checks VBELN for all tables, but in an inner join they are already checked if VBELN is used in the relation.
    To check number fields <> 0 <u>AND</u> also <> '0' is not required. Use either one (what you find easy to use), allthough <> 0 is slightly faster.
    Since many records are in your tables, consider the following program detail.
    DATA: p_tvbapcache_buf LIKE p_tvbapcache OCCURS 0,
          w_tvbapcache_buf LIKE p_tvbapcache.
    SELECT ap~vbeln ap~posnr ap~matnr ap~matkl ap~prodh ap~arktx
           ap~netwr ap~kzwi3 ap~kzwi1 ap~mwsbp ap~vrkme ap~brgew
           ep~bmeng ep~wmeng ep~edatu
      INTO CORRESPONDING FIELDS OF TABLE p_tvbapcache_buf
      FROM vbap AS ap PACKAGE SIZE 10000
    INNER JOIN vbep AS ep
        ON ap~vbeln = ep~vbeln
       AND ap~posnr = ep~posnr
    INNER JOIN vbak AS ak
        ON ak~vbeln = ep~vbeln
       AND ap~vbeln = ak~vbeln
    WHERE ak~auart IN canal
       AND ak~faksk <> 'Z3'.
      LOOP AT p_tvbapcache_buf INTO w_tvbapcache_buf.
        CHECK: vbeln NOT LIKE '0005%',
               prodh IN nomencla,
               matnr IN numero,
               netwr <> 0,
               kzwi1 <> 0,
               edatu IN date,
               wmeng <> 0,
               bmeng <> 0.
        APPEND w_tvbapcache_buf TO p_tvbapcache.
      ENDLOOP.
    ENDSELECT.
    And as last suggestion: I see that you use a lot of 'NEGATIVE' selections (this is selection by exclusion). In the database world this is a very bad way of selecting data, because it will not follow any key in a table. In my opinion you try and find a way of using at least a selection that can use a key.
    Hope this gives you some directions,
    Regards,
    Rob.

  • Perform an Inner Join in Oracle 8

    We have to make our application (that runs with Oracle 9i) backward compatible with Oracle 8.
    There are certain SQL statements that were introduced in Oracle 9i, such as Inner Join (Oracle 9i now allows more of the ANSI standard SQL that MS SQL also uses)
    Does anyone know of the other differences I should look out for, or any documentation that lists the new 9i differences that we may already be using.
    I have trawled through lots of OTN documentation, but not been able to find anything that highlights even the Inner Join problem.
    If there are any documents that also suggest a solution, that would be even better.
    Thanks in advance for any help/suggestion
    Mark

    You have a parameter called "COMPATIBLE", and if you set to, for example 8.1.7 in your 9i database, then your application should be compatible with 8.1.7. It is that easy!
    Of course, by doing so, you renounce to use the 9i features.
    There is a book called "New Features" in the book list in your oracle documentation.
    Regards
    Laurent Schneider

  • Inner join and select for all entries with respect to performance

    Hi Friends,
    I just want to know which is more efficient with respect to performance the Inner join or select for all entries?which is more efficient? and how? can you explain me in detail ?
    Regards,
    Dinesh

    INNER JOIN->
    The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.
    http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ec77446011d189700000e8322d00/content.htm
    FOR ALL ENTRIES->
    Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
    Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
    If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
    If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
    Not Recommended
    Loop at int_cntry.
    Select single * from zfligh into int_fligh
    where cntry = int_cntry-cntry.
    Append int_fligh.
    Endloop.
    Recommended
    Select * from zfligh appending table int_fligh
    For all entries in int_cntry
    Where cntry = int_cntry-cntry.

  • Inner join and select for all entries with respect to performance in SAP

    Hi Friends,
    I just want to know which is more efficient with respect to performance the Inner join or select for all entries?which is more efficient?
    Regards,
    Dinesh

    I did some testing a while ago and found that a JOIN is usually a bit more efficient than FOR ALL ENTRIES. This wasn't always the case though, so the best thing to do is to write it both ways and see which is faster.
    Rob

  • Performance difference between left outer join / inner join

    Hi,
    I've got a complex query which among other things accesses quite a large table. If I use inner join to join this table, the response is quite fast and execution plan shows it uses nested loops to gather the data.
    If I change inner join to left outer join, I get a big performance drop. Cost of query goes from 1441 to 28544.
    I don't uderstand why there's such a difference. For inner join, database has to remove all the rows that don't have match in inner-joined table. For left join it can keep all records and just return NULL values for records that don't have a match. In my mind left join should be faster, as it seems simpler. And the access plan could be the same, couldn't it?
    Execution plan for inner join:
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 288 | 1441 (1)| 00:00:18 |
    | 1 | HASH GROUP BY | | 1 | 288 | 1441 (1)| 00:00:18 |
    | 2 | NESTED LOOPS OUTER | | 1 | 288 | 1440 (1)| 00:00:18 |
    | 3 | NESTED LOOPS | | 1 | 261 | 1438 (1)| 00:00:18 |
    | 4 | NESTED LOOPS | | 318 | 74412 | 508 (1)| 00:00:07 |
    | 5 | NESTED LOOPS | | 318 | 51834 | 189 (0)| 00:00:03 |
    | 6 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | 1 (0)| 00:00:01 |
    |* 7 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | 0 (0)| 00:00:01 |
    | 8 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | 188 (0)| 00:00:03 |
    |* 9 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | 3 (0)| 00:00:01 |
    | 10 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | 1 (0)| 00:00:01 |
    |* 11 | INDEX UNIQUE SCAN | TASK_PK | 1 | | 0 (0)| 00:00:01 |
    | 12 | TABLE ACCESS BY INDEX ROWID | TASK_WORK_HISTORY | 1 | 27 | 3 (0)| 00:00:01 |
    |* 13 | INDEX RANGE SCAN | TASK_WORK_HISTORY_INDEX1 | 1 | | 2 (0)| 00:00:01 |
    | 14 | TABLE ACCESS BY INDEX ROWID | TASK_USES_RESURCE | 1 | 27 | 2 (0)| 00:00:01 |
    |* 15 | INDEX UNIQUE SCAN | TASK_USES_RESURCE_UK1 | 1 | | 1 (0)| 00:00:01 |
    For left outer join:
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 318 | 1596K| | 28544 (2)| 00:05:43 |
    |* 1 | HASH JOIN OUTER | | 318 | 1596K| 1584K| 28544 (2)| 00:05:43 |
    | 2 | VIEW | | 318 | 1580K| | 508 (1)| 00:00:07 |
    | 3 | NESTED LOOPS | | 318 | 74412 | | 508 (1)| 00:00:07 |
    | 4 | NESTED LOOPS | | 318 | 51834 | | 189 (0)| 00:00:03 |
    | 5 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | | 1 (0)| 00:00:01 |
    |* 6 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | | 0 (0)| 00:00:01 |
    | 7 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | | 188 (0)| 00:00:03 |
    |* 8 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | | 3 (0)| 00:00:01 |
    | 9 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | | 1 (0)| 00:00:01 |
    |* 10 | INDEX UNIQUE SCAN | TASK_PK | 1 | | | 0 (0)| 00:00:01 |
    | 11 | VIEW | | 1480K| 73M| | 23431 (2)| 00:04:42 |
    |* 12 | HASH JOIN RIGHT OUTER | | 1480K| 76M| 38M| 23431 (2)| 00:04:42 |
    | 13 | TABLE ACCESS FULL | TASK_USES_RESURCE | 1486K| 21M| | 2938 (2)| 00:00:36 |
    | 14 | VIEW | | 1445K| 53M| | 15031 (2)| 00:03:01 |
    | 15 | HASH GROUP BY | | 1445K| 37M| 110M| 15031 (2)| 00:03:01 |
    | 16 | TABLE ACCESS FULL | TASK_WORK_HISTORY | 1445K| 37M| | 3897 (2)| 00:00:47 |
    --------------------------------------------------------------------------------------------------------------------------

    ...continued
    Complete execution plan for left join:
    | Id  | Operation                       | Name                           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                                                                                                                                                                  
    |   0 | SELECT STATEMENT                |                                |   318 |  1594K|       | 28544   (2)| 00:05:43 |                                                                                                                                                                                  
    |*  1 |  HASH JOIN OUTER                |                                |   318 |  1594K|  1584K| 28544   (2)| 00:05:43 |                                                                                                                                                                                  
    |   2 |   VIEW                          |                                |   318 |  1578K|       |   508   (1)| 00:00:07 |                                                                                                                                                                                  
    |   3 |    NESTED LOOPS                 |                                |   318 | 74412 |       |   508   (1)| 00:00:07 |                                                                                                                                                                                  
    |   4 |     NESTED LOOPS                |                                |   318 | 51834 |       |   189   (0)| 00:00:03 |                                                                                                                                                                                  
    |   5 |      TABLE ACCESS BY INDEX ROWID| RESURCE                        |     1 |   106 |       |     1   (0)| 00:00:01 |                                                                                                                                                                                  
    |*  6 |       INDEX UNIQUE SCAN         | RESURCE_PRINCIPAL_NAME_INDEX   |     1 |       |       |     0   (0)| 00:00:01 |                                                                                                                                                                                  
    |   7 |      TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE              |   318 | 18126 |       |   188   (0)| 00:00:03 |                                                                                                                                                                                  
    |*  8 |       INDEX RANGE SCAN          | TASK_USES_RESUR_IDX$$_0CDC0002 |   318 |       |       |     3   (0)| 00:00:01 |                                                                                                                                                                                  
    |   9 |     TABLE ACCESS BY INDEX ROWID | TASK                           |     1 |    71 |       |     1   (0)| 00:00:01 |                                                                                                                                                                                  
    |* 10 |      INDEX UNIQUE SCAN          | TASK_PK                        |     1 |       |       |     0   (0)| 00:00:01 |                                                                                                                                                                                  
    |  11 |   VIEW                          |                                |  1480K|    73M|       | 23431   (2)| 00:04:42 |                                                                                                                                                                                  
    |* 12 |    HASH JOIN RIGHT OUTER        |                                |  1480K|    76M|    38M| 23431   (2)| 00:04:42 |                                                                                                                                                                                  
    |  13 |     TABLE ACCESS FULL           | TASK_USES_RESURCE              |  1486K|    21M|       |  2938   (2)| 00:00:36 |                                                                                                                                                                                  
    |  14 |     VIEW                        |                                |  1445K|    53M|       | 15031   (2)| 00:03:01 |                                                                                                                                                                                  
    |  15 |      HASH GROUP BY              |                                |  1445K|    37M|   110M| 15031   (2)| 00:03:01 |                                                                                                                                                                                  
    |  16 |       TABLE ACCESS FULL         | TASK_WORK_HISTORY              |  1445K|    37M|       |  3897   (2)| 00:00:47 |                                                                                                                                                                                  
    Query Block Name / Object Alias (identified by operation id):                                                                                                                                                                                                                                               
       1 - SEL$1AFB0324                                                                                                                                                                                                                                                                                         
       2 - SEL$58A6D7F6 / from$_subquery$_005@SEL$8                                                                                                                                                                                                                                                             
       3 - SEL$58A6D7F6                                                                                                                                                                                                                                                                                         
       5 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2                                                                                                                                                                                                                                                                   
       6 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2                                                                                                                                                                                                                                                                   
       7 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1                                                                                                                                                                                                                                                                 
       8 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1                                                                                                                                                                                                                                                                 
       9 - SEL$58A6D7F6 / TASK@SEL$1                                                                                                                                                                                                                                                                            
      10 - SEL$58A6D7F6 / TASK@SEL$1                                                                                                                                                                                                                                                                            
      11 - SEL$7EBCC247 / TRW@SEL$3                                                                                                                                                                                                                                                                             
      12 - SEL$7EBCC247                                                                                                                                                                                                                                                                                         
      13 - SEL$7EBCC247 / TUR@SEL$4                                                                                                                                                                                                                                                                             
      14 - SEL$6        / TRW_IN@SEL$5                                                                                                                                                                                                                                                                          
      15 - SEL$6                                                                                                                                                                                                                                                                                                
      16 - SEL$6        / TWH@SEL$6                                                                                                                                                                                                                                                                             
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                                         
       1 - access("TRW"."RESURCE_ID"(+)="TASKUSESRESURCE"."RESURCE_ID" AND "TRW"."TASK_ID"(+)="TASK"."ID")                                                                                                                                                                                                      
       6 - access("RESURCEWORKER"."USER_PRINCIPAL_NAME"=U'jernej')                                                                                                                                                                                                                                              
       8 - access("TASKUSESRESURCE"."RESURCE_ID"="RESURCEWORKER"."ID")                                                                                                                                                                                                                                          
      10 - access("TASKUSESRESURCE"."TASK_ID"="TASK"."ID")                                                                                                                                                                                                                                                      
      12 - access("TUR"."RESURCE_ID"(+)="TRW_IN"."RESURCE_ID" AND "TUR"."TASK_ID"(+)="TRW_IN"."TASK_ID")                                                                                                                                                                                                         Jonathan, I've been to one of your workshops in Ljubljana. I'm still trying to understand everything you explained and use it, but there's much I have to learn and understand.
    The way I see this query it should fist join and filter the first three tables and only then join the trw subquery. The problem with this subqrey is task_work_history table, which is accessed in very different ways in different places, so there will always be many reads to gather required data. For now, however, I'd be hapy to just bring the performance of inner join to left join...

  • Performance Impovement for Join

    I have the following join statement. I have 220,000 records ... when I run this program, it times out. Can any one suggest performance impovement?
      SELECT vbapvbeln  vbapposnr  vbapkwmeng  vbapmatnr
             vbapwerks  vbapkdmat  vbapposex   vbakauart
             vbakkunnr  vbakvdatu  vbepedatu   lipsvbeln
             lipsposnr  lipslfimg  marcdispo   marcbeskz "--> PV
             maktmaktx  marameins  vbkdihrez   vbkdempst
             vbkdbstkd  vbkdbstkd_e vbpa~ablad
      INTO TABLE lt_orders_t
      FROM vbak INNER JOIN vbap
                  ON ( vbakvbeln = vbapvbeln )
                INNER JOIN vbep
                  ON ( vbapposnr = vbepposnr AND vbapvbeln = vbepvbeln )
                LEFT OUTER JOIN lips
                  ON ( vbapvbeln = lipsvgbel AND vbapposnr = lipsvgpos )
                LEFT OUTER JOIN marc
                  ON ( vbapmatnr = marcmatnr AND vbapwerks = marcwerks )
                LEFT OUTER JOIN makt
                  ON ( vbapmatnr = maktmatnr AND makt~spras = 'E'        )
                LEFT OUTER JOIN mara
                  ON ( vbapmatnr = maramatnr )
                LEFT OUTER JOIN vbkd
                  ON ( vbapvbeln = vbkdvbeln AND vbapposnr = vbkdposnr )
                LEFT OUTER JOIN vbpa
                  ON ( vbapvbeln = vbpavbeln AND vbpa~posnr = '000010' AND
                       vbpa~parvw = 'WE'       )
      WHERE vbak~vbeln IN s_vbeln AND
            vbep~etenr = '0001'   AND
            vbap~posnr IN s_posnr AND
            vbap~werks IN s_werks AND
            vbak~auart IN s_auart AND
            vbak~kunnr IN s_kunnr AND
            vbak~vbtyp IN s_vbtyp AND
            vbap~matnr IN s_matnr AND
            vbep~ettyp IN s_ettyp AND
            vbep~edatu IN s_edatu.

    Hi PV,
    As others have mentioned you really need to break the statement down. 3 joins is usually pushing it (depending on the tables). By the way, you can go to SE12 and look up each table. On the main screen you will see a pushbutton saying Indexes I think. Click on it and it will show you the secondary indexes for that table. There may be some or none defined. They may be SAP defined or customer defined (Z).
    Keep your inner joins on vbak, vbap and vbep. The resulting table will be used as your driver for the other tables.
    You can create another inner join of mara, marc and makt.
    Use your driver table as For All Entries for the other tables.
    If you keep your driver table to be as shown, create another table with the first 5 fields.( vbeln, posnr, kwmeng, matnr, werks). The reason for this is so you can load the table with:
    It_newtab[] = It_orders_t[].
    All you want from the new table is matnr werks.
    Sort it_newtab by matnr werks.
    Delete adjacent duplicates from i_newtab comparing matnr werks.
    Now you can use it_newtab as your driver for marc-mara-makt join. The reason is that if you have 220,000 records, when you narrow down the material/plant combinations you will probably have only a few hundred materials. So your For All entries will be a table of a few hundred instead of 200 thousand.
    The result will be in a new table it_materials. When you read this table, don't forget to sort it by matnr and plant first. And READ with Binary Search.
    Once you have all your other smaller tables created. As with it_materials, SORT and READ with BINARY SEARCH, as you loop through your driver table and populate the missing data from the smaller tables.
    I think you will end up with 5 Select statements.
    Indexes are important. Once you have split out the Select statements, if the code is still running unacceptably slow, you can use ST05 to see what indexes are being used and see if new indexes need to be created to help your cause.
    You'll probably have to involve the Basis team to help you with your new indexes and they can help with the analysis of your ST05 results as well. Indexes must be created correctly in the proper order, or they may not be effective.
    Hope this helps.
    Filler

  • Relationship between tables while using inner joins.

    Hi,
    I had a few clarifications on "inner joins", and as i was going through the forum, i came across two points,
    1. In one of the threads it said " inner joins is applicable for tables that have a parent child relationship.
    2. In another thread it said " inner join is established from master table (the table on the left) to the transcation table (the table on the right)".
    I have two clarifications based on the above points.
    1. Is it necessary that the tables on which im performing an inner join should have a parent-child/children relationship or is it enough that the tables just have a common field.
    2.  Also is it necessary that the master table should come first, (or can i use any child table from where i can fetch the records when there is a mater table in my report) as shown below.
    Eg: select * <fields> from <master table> inner join <table> on <field> into <itab>.
    Edited by: Narayananchandran on Dec 27, 2010 12:31 PM

    have two clarifications based on the above points.
    1. Is it necessary that the tables on which im performing an inner join should have a parent-child/children relationship or is it enough that the tables just have a common field.
    2. Also is it necessary that the master table should come first, (or can i use any child table from where i can fetch the records when there is a mater table in my report) as shown below.
    Eg: select * <fields> from <master table> inner join <table> on <field> into <itab>
    1) NO
                      2) NO

  • Short Dump on Inner Join

    Hello Experts,
    I'm trying to write a Inner join on VBAK and VBAP because i need to get data from both tables.  When I try to execute the following code I'm getting a short dump "Error in module RSQL of the database Interface". Can anybody see what's wrong with this select.
           begin of t_sales_order,
             vbeln  type vbak-vbeln,    "Sales Order
             auart  type vbak-auart,     "Order Type
             audat  type vbak-audat,     "Shipment Creation date field
             posnr  type vbap-posnr,    "Items
             kdmat  type vbap-matnr,    "Lead Pin
             cuobj  type vbap-cuobj,    "Configuration Object ID
             end of t_sales_order,
    data: lwa_sales_order           type t_Sales_Order.
          select single avbeln aaudat a~auart
                        bposnr bkdmat b~cuobj
                          into lwa_sales_order
                             from vbak as a inner join vbap as b
                                  on avbeln = bvbeln
                                     where b~kdmat = pv_pin_number.
    Many thanks in advance.

    Hi
    Your internal table fields sequences are not followed in Inner Join.
    begin of t_sales_order,
    vbeln type vbak-vbeln, "Sales Order
    auart type vbak-auart, "Order Type
    audat type vbak-audat, "Shipment Creation date field
    posnr type vbap-posnr, "Items
    kdmat type vbap-matnr, "Lead Pin
    cuobj type vbap-cuobj, "Configuration Object ID
    end of t_sales_order,
    select single a~vbeln *a~auart* a~audat
    b~posnr b~kdmat b~cuobj
    into lwa_sales_order
    from vbak as a inner join vbap as b
    on a~vbeln = b~vbeln
    where b~kdmat = pv_pin_number.
    Please check the above code
    Shiva

  • Inner Joins vs For All Entries - performance query

    Hi All,
    I'm a bit confused here...  I see lots and lots (and lots...) of postings from people asking how to get data from multiple tables.
    To me the immediate answer is to use joins in my select statement to reduce the database load but more and more I see people suggesting FOR ALL ENTRIES is better from a performance perspective.
    Now, simple question time, which is more efficient in the real world when doing something like the following:- (this is a basic example but I'm sure you know what I mean.)
    Select  *
      into  table lt_sales_data
      from  vbap as vbap
    inner  join vbak as vbak
         on vbak~vbeln eq vbap~vbeln
      where  vbak~vbeln in so_vbeln.
    or
    Select  *
      into  table lt_vbak_data
      from  vbak
    where  vbeln in so_vbeln.
    if lt_vbak_data[] is not initial.
    select  *
      into  table lt_vbap_data
      from  vbap
      for all entries in lt_vbak_data
    where  vbeln eq lt_vbak_data-vbeln.
    endif.
    Basically I want to know whether joins or for all entries is better from a database performance perspective.
    I want to know why as well so please don't just post links, random cut and paste answers or one liners.  I'm convinced for all entries is slower but am willing to be persuaded otherwise if someone can show me proof.
    Thanks,
    Gareth.

    Thanks to all the opinions so far...  You've backed up what I suspected although I maybe wasn't clear enough with my question and desired result.  I was hoping someone could produce some hard and fast guidelines from SAP themselves dictating which is the better method.  I know 10 years ago I was taught to use joins and to keep my database access to minimal levels, using keyed reads where applicable and using internal tables to filter data where I couldn't use key fields.
    Gautham, I am aware of SM30 but that doesn't answer the general question I was asking.  I've obviously used SM30 to run some comparisons but I was really hoping someone could give me a definitive answer based on hard facts or from attending some training at SAP recently.  And no points for asking for them
    Tamás, I agree with what you are saying about runing many comparisons - it appears to be dependant on any number of criteria which means each case may require different code.  I've not managed to find a consistent comparison of the two methods that would lead me to use one method or the other...
    Karan, thanks for your feelings but it doesn't really help me!  Why/how does it retrieve the data faster than a join?  Have you got testing/proof to back this up?
    Raam, thanks for those links - they are interesting reads and seem to go through the same arguments I'm currently considering.  Although I still don't have a definitie answer!
    Amit, I understand exactly what yuo are saying about myths and urban legends   That was my motivation for this post.  To bo honest, it seems to me that a lot of the "newer" ABAP coders always go for FOR ALL ENTRIES but I wanted to know - is there a reason or do they all just cut and paste off SDN?!  Are they all just scared of complex inner joins?!  What would you all make of this Select statement for example? -   
    select  afvc~arbid
                afko~aufnr
                aufk~objnr
                afko~plnnr
                afko~plnal
                afko~aufpl
                afko~zaehl
                afpo~matnr
                makt~maktx
                afvc~vornr
                afvc~ltxa1
                afvu~aplzl
                afvu~usr10
                afvv~meinh
                afvv~bmsch
                afvv~vge02
                afvv~vgw02
                afvv~mgvrg
                afab~aplzl_vor
          into  table lt_recipe_orders
          from  afko as afko
         inner  join aufk as aufk
            on  aufk~aufnr eq afko~aufnr
         inner  join afpo as afpo
            on  afpo~aufnr eq afko~aufnr
         inner  join makt as makt
            on  makt~matnr eq afpo~matnr
         inner  join afvc as afvc
            on  afvc~aufpl eq afko~aufpl
         inner  join afvu as afvu
            on  afvu~aufpl eq afvc~aufpl
           and  afvu~aplzl eq afvc~aplzl
         inner  join afvv as afvv
            on  afvv~aufpl eq afvu~aufpl
           and  afvv~aplzl eq afvu~aplzl
          left  outer join afab as afab
            on  afab~aufpl_nch eq afvu~aufpl
           and  afab~aplzl_nch eq afvu~aplzl
           for  all entries in t_resources
         where  afko~gltrs ge v_start_date
           and  afko~gstrs le v_start_date
           and  afko~plnty eq gc_task_list_type_2
           and  afpo~dwerk eq v_werks
           and  makt~spras eq sy-langu
           and  afvc~arbid eq t_resources-objid.
    Twinkal, I've always thought less DB hits is a better performing program too - the above example compares 2 db hits to 1...  I don't have issues with complex joins because I've used them so long so can discount that problem but do agree that less DB hits is the ultimate goal.  Providing of course the Selects you write are actually efficient in themselves.
    Murthy, if you build your select statement correctly duplicate records can be avoided in most cases.  How can you say a join statement will hit the database more when in my example there is 1 DB hit compared to 2 for a for all entries?  And I'd love to know the reasoning behind never using a join on more than 2 tables?!  Is that just an urban myth?!
    Thomas, I've just been looking at some of Siegfried's posts and like what I am reading.  As you say, using full keys via joins is essential.
    Gareth.

  • Alternate for inner join to improve performance

    Hi all,
    I have used an inner join query to fetch data from five different tables into an internal table with where clause conditions.
    The execution time is almost 5-6 min for this particular query(I have more data in all five DB tables- more than 10 million records in every table).
    Is there any alternate for inner join to improve performance.?
    TIA.
    Regards,
    Karthik

    Hi All,
    Thanks for all your interest.
    SELECT  a~object_id a~description a~descr_language
                a~guid AS object_guid a~process_type
                a~changed_at
                a~created_at AS created_timestamp
                a~zzorderadm_h0207 AS cpid
                a~zzorderadm_h0208 AS submitter
                a~zzorderadm_h0303 AS cust_ref
                a~zzorderadm_h1001 AS summary
                a~zzorderadm_h1005 AS summary_uc
                a~zzclose_date     AS clsd_date
                d~stat AS status
                f~priority
                FROM crmd_orderadm_h AS a INNER JOIN crmd_link AS b ON  a~guid = b~guid_hi
                INNER JOIN crmd_partner AS c ON b~guid_set = c~guid
                INNER JOIN crm_jest AS d ON objnr  = a~guid
                INNER JOIN crmd_activity_h AS f ON f~guid = a~guid
                INTO CORRESPONDING FIELDS OF TABLE et_service_request_list
                WHERE process_type IN lt_processtyperange
                AND   a~created_at IN lt_daterange
                AND   partner_no IN lr_partner_no
                AND   stat IN lt_statusrange
                AND   object_id IN lt_requestnumberrange
                AND   zzorderadm_h0207 IN r_cpid
                AND   zzorderadm_h0208 IN r_submitter
                AND   zzorderadm_h0303 IN r_cust_ref
                AND   zzorderadm_h1005 IN r_trans_desc
                AND   d~inact = ' '
                AND   b~objtype_hi = '05'
                AND   b~objtype_set = '07'.
                f~priority
                FROM crmd_orderadm_h AS a INNER JOIN crmd_link AS b ON  a~guid = b~guid_hi
                INNER JOIN crmd_partner AS c ON b~guid_set = c~guid
                INNER JOIN crm_jest AS d ON objnr  = a~guid
                INNER JOIN crmd_activity_h AS f ON f~guid = a~guid
                INTO CORRESPONDING FIELDS OF TABLE et_service_request_list
                WHERE process_type IN lt_processtyperange
                AND   a~created_at IN lt_daterange
                AND   partner_no IN lr_partner_no
                AND   stat IN lt_statusrange
                AND   object_id IN lt_requestnumberrange
                AND   zzorderadm_h0207 IN r_cpid
                AND   zzorderadm_h0208 IN r_submitter
                AND   zzorderadm_h0303 IN r_cust_ref
                AND   zzorderadm_h1005 IN r_trans_desc
                AND   d~inact = ' '
                AND   b~objtype_hi = '05'
                AND   b~objtype_set = '07'.

  • 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

  • Inner Join with For All Entries - 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><b></b>

    An Inner Join with for all entries should be done if you add this....
    IF NOT gi_sales[] IS INITIAL.
    SELECT k~ebeln k~ebelp k~vbeln k~vbelp
    FROM ekkn AS k INNER JOIN ekbe AS b ON k~ebeln = b~ebeln
    AND k~ebelp = b~ebelp
    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.
    ENDIF.
    Also, while you use an index or the complete key for the SELECT, your not going to suffer from lack of performance -;)
    Greetings,
    Blag.

Maybe you are looking for

  • Ejb 3.0 with List as parameter

    Hello, I have deployed an ejb to a weblogic 10.0 server. The method has a list as parameter. public void testMethod(List<String> strings){ When I call this remotely i get the following exception: javax.ejb.EJBException: nested exception is: java.rmi.

  • Check for available downloads did not download my library

    i requested to transfer my itunes playlist which is quite considerable, when i requested to reload my puchases from the itunes store a list of songs appeared but i am unable to play them, nor see or hear my tv, movie files because they were never ori

  • Error compiling IDL to C++: LIBORB_CAT:147: ERROR: Registry `REG_KEY_SYSTEM' not found.

    I'm trying to compile a simple IDL file into C++ using idl.exe, and am seeing the following output: LIBORBCMD_CAT:27: ERROR: An internal software error occurred. -LIBORB_CAT:147: ERROR: Registry `REG_KEY_SYSTEM' not found. I'm using Tuxedo 8.1 on a W

  • Webservice returning bean

    Hello All, I have one web service which returns java bean, this bean internally incorporated different beans so my response is like this: <S:Envelope xmlns:S=" http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:GetConfigResponse xmlns:ns2=" ht

  • Having trouble converting AVCHD files in AME CS4

    I have a bunch of AVCHD video file I shot and amn trying to convert them to Quicktime with the Adobe Media Encoder CS4. The files are really large and are about 2GB in size. I can load them into AME fine, but it errors about a quarter of the way in t