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.
Bethtis 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
MarkYou 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,
DineshINNER 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,
DineshI 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 PMhave 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 -
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,
KarthikHi 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
-
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
-
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