Perfomance issue : inner join on buffered db dable

I have done a inner join between 2 tables . one of the table is fully buffered.
i get a performance error
"(H) SELECT on buffered table in a JOIN"
kindly help

SELECT *
INTO CORRESPONDING FIELDS OF TABLE lt_obj_links BYPASSING BUFFER
FROM rpm_obj_link AS p
INNER JOIN
rpm_obl_obtyp AS f
ON f~object_type = p~object_type
WHERE p~project_guid = lv_item_guid
AND f~application = i_application
AND f~logsys = i_system.
and one more suggestion if you are using into corresponding why can't you select the requirefields rather than selecting all fields..
and specify into table

Similar Messages

Inner join on Buffred table and not buffered table.

Hi guys,
   Can you suggest me how can i write select query using inner join on buffered table and not buffered table. i written like this. is it right?
SELECT a~vbeln
         a~vkorg
         a~kunnr
         a~kunag
         a~wadat_ist
         a~xblnr
         b~bukrs
   FROM likp AS a INNER JOIN tvko AS b
    ON avkorg = bvkorg BYPASSING BUFFER
INTO TABLE itab_likp
WHERE vbeln = s_vbeln.
Thanks.
RAJ

Hi Raj ,
Please find below my Commentes :
1. When you use "Bypassing buffer" clause in Select statement , the data what is there in the buffer of application sever is always ignored and Read is performed from the Physical database always. This Clause is advisable where you require realtime data (Not recommended generally in reporting)
2. It is advisable that you should not use small table in the innerjoin with big table. In the query you have written there are 2 tables:- LIKP and TVKO outof which TVKO is a master table containing very few records than LIKP (Contains huge data for Delivery header).
So my recommendation will be : -
1. Eliminate the "Bypassing Buffer" clause from your Query
2. Break the select query into 2 select queries breaking the join and with some ABAP logic populate the Internal table "itab_likp".
This will be optimum way inwhich you can write the select query for your senarion. Also Ensure that indexes are being used for better selectivity.
Hope this will help to you.
Regards,
Nikhil

Issue with the inner join on EKKO and EKPO.

Dear All,
The report using this join takes a long time to execute.
Does this inner join have an issue?
Do i need to code this in a different way for lesser execution time?
Please give me your inputs.
SELECT
        a~ebeln
        b~ebelp
        a~bukrs
        a~bstyp
        a~bsart
        a~ekorg
        a~ekgrp
        a~kdatb
        a~kdate
        FROM ekko AS a JOIN ekpo AS b
        ON aebeln = bebeln
        INTO TABLE t_ekpo
        WHERE
        a~bukrs EQ p_bukrs
        AND a~bstyp EQ c_k
        AND a~bsart IN s_bsart
        AND a~ekorg IN s_ekorg
        AND a~ekgrp IN s_ekgrp
        AND a~kdate GE s_fdate-low
        AND a~loekz EQ space
        AND b~loekz EQ space.
Regards,
SuryaD.

Index EKKO~D consists top-down of BSTYP and BEDAT. BSTYP is already an EQ-condition in your selection, but not very selective (many rows with the same value). So including BEDAT should help in efficiently reducing the data that needs to be scanned for finding the relevant rows. However, just a new optional S_BEDAT select option that can be left empty by the user would not help, you must force a narrow selection (one month, one week, even one day? the less the better).
This is just a quick guess from my side, there might be other options that occur to you once you have analysed the available indexes. Sometimes alternative tables could be the solution, and even less sometimes introducing a new secondary index for a standard table might be the last option (takes up space and adds processing time to insert/update/delete operations).
Thomas

Issue when suming the field in Select query using inner join

Hi All,
SELECT A~OI_SHNUM
       A~FORWAGENT
       A~ROUTE
       A~SHTYP
       A~DTSHP_EACT
       A~/BIC/GTCLICENS
       A~/BIC/GTCADD04
       A~COMP_CODE
       SUM( C~GRS_WGT_DL )
       C~UNIT_OF_WT
INTO TABLE I_LAYONE
FROM ( ( /BIC/ANTCD000200 AS A
INNER JOIN /BIC/AGSSD000700 AS B ON BOI_SHNUM = AOI_SHNUM )
INNER JOIN /BIC/AGSSD000600 AS C ON CDELIV_NUMB = BDELIV_NUMB ).
I need to sum the field C~GRS_WGT_DL
While compiling it show the error given below
The field "C~UNIT_OF_WT" from the SELECT list is is missing in the
GROUP BY clause. is missing in the GROUP BY clause. is missing in the
GROUP BY clause. is missing in the GROUP BY clause. is missing in the
GROUP BY clause. is "C~UNIT_OF_W
with regards,
Thambe

Hi,
Try the following SQL statement. Hope it helps you.
SELECT A~OI_SHNUM
A~FORWAGENT
A~ROUTE
A~SHTYP
A~DTSHP_EACT
A~/BIC/GTCLICENS
A~/BIC/GTCADD04
A~COMP_CODE
SUM( C~GRS_WGT_DL )
C~UNIT_OF_WT
INTO TABLE I_LAYONE
FROM ( ( /BIC/ANTCD000200 AS A
INNER JOIN /BIC/AGSSD000700 AS B ON BOI_SHNUM = AOI_SHNUM )
INNER JOIN /BIC/AGSSD000600 AS C ON CDELIV_NUMB = BDELIV_NUMB )
GROUP BY
A~OI_SHNUM
A~FORWAGENT
A~ROUTE
A~SHTYP
A~DTSHP_EACT
A~/BIC/GTCLICENS
A~/BIC/GTCADD04
A~COMP_CODE.
Murthy.

Query Issue with Inner JOIN

I need to create the following SQL query in Toplinks, but cannot figure out how to do it. I just want to get all Contacts that have their InitialEventID set to some integer, or have a mapping in the ContactEvents table set to that integer. The mapping between Contacts and ContactEvents is @OnetoMany.
Select DISTINCT Contacts.* from Contacts JOIN ContactEvents ON (Contacts.ID = ContactEvents.ContactID) WHERE (ContactEvents.EventID = 34 OR Contacts.InitialEventID = 34);
I'm trying the following, but it obviouly doesn't work.
SELECT DISTINCT c FROM Contacts c INNER JOIN c.contactEventsCollection ce WHERE ce.eventID = 34
What should I do?

Other than the query missing the 'or' clause, why isn't the query working, and what SQL gets generated? You can turn TopLink logging to Fine or Finest to get the SQL logged. You might also want to use OUTER JOIN intead since I assume that Contacts with an InitialEventID=34 may or may not have any ContactEvents associated with it:
SELECT DISTINCT c FROM Contacts c OUTER JOIN c.contactEventsCollection ce WHERE ( (ce.eventID = 34) OR (c.InitialEventID = 34) )
Best Regards,
Chris

Inner join-select -primary key in table issue

Hi ,
Iam using FEBKO(header) and FEBEP(item) in inner join select .But the datas fetching by this selct in not correct.The analysis is the is no common primary fields in the both table.
Question 1-> Can i use inner join without common primary key in the both tables, weather it possible to make a select without common primary key in both table. Please kindly let me know.
Question 2-> What is the other possible way to give the selct for both table(better performance)
Regards,
Veera

Hi,
When you use INNER JOIN in this case, link your tables based on KUKEY and ESNUM fields, bcoz there can be many items under a single header. So this will work for you, even from the performance point of view.
Hope this is helpful to you. If you need further information, revert back.
Reward all the helpful answers.
Regards
Nagaraj T

Inner join issue

i was microsft sql 2000 user.
where is use join like this
select max(Date) from Table1 , table2
where table1.field = abc
and table2.field = table1.field.
but in abap it says santax error like comma with select???

HI
here i am giving inner join sample code for if we join 3 tables please check and correct for you question
Select single VbrkBukrs VbrkKunrg    Vbrk~Vbeln
                   VbrkFkdat VbrkBstnk_Vf Vbrk~Zterm
                   Tvzbt~Vtext
                   VbakVbeln VbakBstdk
                   LikpVbeln Likplfdat    Likp~Lfuhr
       into w_vbrk
       from vbrk
      inner join       Tvzbt on TvzbtZterm        = VbrkZterm      and
                                Tvzbt~Spras        = sy-langu
      Inner join       Vbfa as SalesLnk
                             on SalesLnk~vbeln     = pu_vbeln        and
                                SalesLnk~vbtyp_v   = c_order
            inner join Vbak on VbakVbeln           = SalesLnkVbelv
      Inner join       Vbfa as DeliveryLnk
                             on DeliveryLnk~vbeln   = pu_vbeln       and
                                DeliveryLnk~vbtyp_v = c_Delivery
            inner join Likp on LikpVbeln          = DeliveryLnkVbelv
      where vbrk~vbeln = pu_Vbeln.
Thanks and regards
Durga.K

INNER JOIN Display Issues

Hello,
I am haing troubles displaying the author_name using the
author_id in a testcase table and author table were author_id is
the primary key in the author table and the foreign key in the
author table. Here is my INNER JOIN SQL:
$query_rsListAuthor = "SELECT author_name FROM author INNER
JOIN testcase WHERE author.author_id = testcase.author_id";
$rsListAuthor = mysql_query($query_rsListAuthor, $QA) or
die(mysql_error());
$row_rsListAuthor = mysql_fetch_assoc($rsListAuthor);
$totalRows_rsListAuthor = mysql_num_rows($rsListAuthor);
I can't seem to display the author_name when I use this:
<?php echo $row_rsListAuthor['author_name'];
?>
Any thoughts as to what I am doing wrong?
Thanks,
Ron

How many matching records do you actually have between the 2
tables?
Are you seeing only 1 match on the web page or when you hit
test in the recordset dialog window? If it is the web page you may
need to slap a repeat region on it. Also make sure you have the
correct recordset selected in the repeat region from the drop down
menu. If you have multiple recordsets on the page because it always
defaults to the first one in the menu

Update statement with inner join issues

I have searched for the answer on this and not really 100%....so figured I would ask...be nice :)
what have I done wrong? Or am I just going about this the wrong way? I have looked at the oracle docs and I can't find an example showing me this. I do see where you SET values based on the select query results. I want to update the result of a query based on the join with static values....
UPDATE table.a
SET table.a_STATUS=9,table.a.INDEX = 'N'
WHERE (SELECT table.a INNER JOIN table.b ON (table.a.COMPANY = table.b.COMPANY) AND (table.a.PO_NUMBER =table.b.PO_NUMBER) AND (table.a.PO_RELEASE =table.b.PO_RELEASE) AND (table.a.PO_CODE =table.b.PO_CODE) AND (table.a_STATUS=1) AND (table.b.CLOSED_FL = 'Y'));

Hi,
Welcome to the forum!
user11360811 wrote:
I have searched for the answer on this and not really 100%....so figured I would ask...be nice :)
what have I done wrong? Or am I just going about this the wrong way? I have looked at the oracle docs and I can't find an example showing me this. I do see where you SET values based on the select query results. I want to update the result of a query based on the join with static values....
UPDATE table.aThat's updating a table called A in a schema called TABLE (which is not a good name for any user-named object). Are those really your table and schema names? Perhaps you meant to have an underscore instead of a dot:
UPDATE table_ais much, much more reasonable. It means the table name is TABLE_A (a perfectly good name) in the current schema.
SET table.a_STATUS=9,table.a.INDEX = 'N'
WHERE ( ...There's a syntax error. You can't just say
"WHERE (sub-query)"; it has to be
"WHERE EXISTS (sub-suery)" or
"WHERE (sub-query) = some_value" or
"WHERE some_value IN (sub_query)", or something similar. WHERE can never be used without some kind of comparison operator, such as EXISTS, = or IN.
SELECT table.a INNER JOIN table.b ON ...Here are some more syntax errors. The correct syntax for any query is
SELECT column_list
FROM table_name ...If table.a is your (first) table name, then you're missing the list of columns to SELECT, and the mandatory keyword FROM.
(table.a.COMPANY = table.b.COMPANY) AND (table.a.PO_NUMBER =table.b.PO_NUMBER) AND (table.a.PO_RELEASE =table.b.PO_RELEASE) AND (table.a.PO_CODE =table.b.PO_CODE) AND (table.a_STATUS=1) AND (table.b.CLOSED_FL = 'Y'));Some general advice about UPDATE:
If it's not obvious how to use UPDATE to do what you want, then there's a good chance that UPDATE is the wrong tool for the job. MERGE might be much simpler, and more efficient as well. This is especially likely if you need to join the table that's being updated to some other table.
Whenever you have a problem, please post a little sample data (CREATE TABLE and INSERT statements, relevant columns only) from all tables involved. That way, the people who want to help you can re-create the problem and test their ideas.
Also post the results you want from that data, and an explanation of how you get those results from that data, with specific examples.
Simplify the problem as much as possible. Remove all tables and columns that play no role in this problem.
If you're asking about a DML statement, such as UPDATE, the CREATE TABLE and INSERT statements should re-create the tables as they are before the DML, and the results will be the contents of the changed table(s) when everything is finished.
Always say which version of Oracle you're using (for example, 11.2.0.2.0).
See the forum FAQ {message:id=9360002}
Edited by: Frank Kulash on Jan 17, 2013 4:58 PM

For All Entries is NOT better than INNER JOIN in most cases

I quote from Siegfried Boes' excellent post here: Will writing an inner join be better or creating a view?
For all the FOR ALL ENTRIES lovers ... there is no proof for these reappearing recommendation.
There is nearly nobody who receives forum points, who recommends FOR ALL ENTRIES instead of Joins. What is the reason ???
It is easier to prove the opposite. A Join is a nested loop inside the database, a FOR ALL ENTRIES is partly outside of the database. FOR ALL ENTRIES works in blocks, joins on totals.
FOR ALL ENTRIES are not recommded on really large tables, because the chances are too high that
too many records are transferred.
People prefer FOR ALL ENTRIES, because JOINs are not so easy to understand. Joins can go wrong, but with a bit of understanding they can be fixed.
Some Joins are slow and can not be fixed, but then the FOR ALL ENTRIES would be extremely slow.
There are several kinds of views:
- projection views, i.e. only one table involved just fields reduced
- join views, several tables, joins conditions stored in dictionary
- materialized views, here the joined data are actually stored in the database. Storing and synchronisation has to be done manually.
Only the last one creates real overhead. It should be the exception.
Join Views and Joins are nearly identical. The view is better for reuse. The join is better in complicated, becuase if the access goes wrong, it can often be fixed by adding a hint. Hints can not be added to views.
Abraham Bukit points out:
If it is cluster table, (you can't use join). If it is buffered table, I would also say avoid join.
If they all are transaction table which are not buffered and are not cluster tables.
He further supports Siegfried's statement that FAE is easier to undestand than INNER JOINs.
Thomas Zloch says, regarding buffered tables:
At least think twice, maybe compare runtimes if in doubt.
So, unless someone has some EVIDENCE that FOR ALL ENTRIES is better, I don't think we want to see this discussed further.
Kind regards
Matt

To give food for thought here's an example I gave in a thread:
If you have a statement like
SELECT ... FOR ALL ENTRIES IN FAE_itab WHERE f = FAE_itab-f.
SAP sends it to the database depending how the parameter rsdb/prefer_union_all is set:
rsdb/prefer_union_all = 0 =>
SELECT ... WHERE f = FAE_itab[1]-f
          OR    f = FAE_itab[2]-f
          OR    f = FAE_itab[N]-f
You have some influence of the generated statement type: Instead of OR'ed fields an IN list can be used
if you have only a single coulmn N to compare:
rsdb/prefer_in_itab_opt parameter:
SELECT ... WHERE f IN (itab[1]-f, itab[2]-f, ..., itab[N]-f)
rsdb/prefer_union_all = 1 =>
SELECT ... WHERE f = FAE_itab[1]-f
UNION ALL SELECT ... WHERE f = FAE_itab[2]-f
UNION ALL SELECT ... WHERE f = FAE_itab[N]-f
see: Note 48230 - Parameters for the SELECT ... FOR ALL ENTRIES statement
As you can see for the 2nd parameter several statements are generated and combined with a UNION ALL,
the first setting generates statements with OR's (or uses IN if possible) for the entries in FAE_itab.
I give you a little example here (my parameters are set in a way that the OR's are translated to IN lists; i traced the execution in ST05)
Select myid into table t_tabcount from mydbtable
for all entries in t_table    " 484 entries
    where myid = t_table-myid .
ST05 trace:
|Transaction SEU_INT|Work process no 0|Proc.type DIA|Client 200|User |
|Duration |Obj. name |Op.    |Recs.|RC    |Statement|
| 640|mydbtable |PREPARE|   | 0|SELECT WHERE "myid" IN ( :A0 , :A1 , :A2 , :A3 , :A4 ) AND "myid" = :A5|
| 2|mydbtable |OPEN   |   | 0|SELECT WHERE "myid" IN ( 1 , 2 , 3 , 4 , 5 ) AND "myid" = 72 |
| 2.536|mydbtable |FETCH |    0| 1403|   |
| 3|mydbtable |REOPEN |   | 0|SELECT WHERE "myid" IN ( 6 , 7 , 8 , 9 , 10 ) AND "myid" = 72 |
| 118|mydbtable |FETCH | 0| |
| 2|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 11 , 12 , 13 , 14 , 15 ) AND "myid" = 72     |
| 3|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 475 , 476 , 477 , 478 , 479 ) AND "myid" = 72 |
| 94|mydbtable |FETCH | 0| 1403|   |
| 2|mydbtable |REOPEN |   | 0|SELECT WHERE "myid" IN ( 480 , 481 , 482 , 483 , 484 ) AND "myid" = 72 |
You see the IN list contained 5 entries each , wich made up about 97 statements for all 484 entries.
For every statment you have a single fetch operation wich means a separate access to the database.
If you would replace the FAE with a join you would only have one fetch to the database.
With the example above we can derive these observations:
1. From database point of view these settings kill performance when you access a big table and/or have a lot of entries or columns in your FAE_itab. Furthermore, you hide information what data you will access
at all and thus you block the database from creating a more efficient execution plan because it DOESN'T KNOW wich data you will select in the next step. I.e. it may be more efficient to scan the table in one shot instead of having many index accesses - but the database can make this decision only if it can examine ONE statement that has ALL the information of what data to retrieve.
2. A second impact is that with every statement execution you trigger the allocation of database resources
wich will contribute to the overhead described above.
Said that, FAE can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table )
Edited by: kishan P on Nov 2, 2010 2:16 PM - Format Fixed

Inner Join of 3 tables is correct or not?

Hi Guys ,
 I have a requirement where i have to join 3 tables i dont know whether the inner Join which i wrote for 3 tables is correct or not.I am not getting any Syntax error but whether the logci below which i wrote gets all the records or not.
The Requirement is
"c. Select the BOL Number entered in the screen and query the table LIKP with the BOL number in the field LIKP-BOLNR. Gather the list of ALL delivery documents (LIKP-VBELN) that is outputted.
d. Query the list of the delivery documents obtained into the table VBFA in the field VBFA- VBELV. From the output that is displayed, select the Follow-On Document Field (VBFA-VBELN) for that item whose Subsequent Document Category (VBFA- VBTYP_N) is R and the Movement Type (VBFA- BWART) is 641. Get the Follow-On document number for each of the above Delivery Document number.
e. Query the table EKBE with the Follow On document obtained above in the field Material Document (EKBE- BELNR). Perform this activity for each of the follow on document obtained above. Get the resultant Purchase Order (EKBE-EBELN) and Item Number (EKBE-EBELP) from the query. After querying will all the Follow-On Documents, get the unique list of PO number and Item Number.
The logic which i wrote is
 Begin of t_PoolSTO_out,
 BOLNR type LIKP-BOLNR,
 EBELN type EKBE-EBELN,
 EBELP type EKBE-EBELP,
 VBELN type LIKP-VBELN,
 VBELNV type VBFA-VBELN,
 End of t_PoolSTO_out.
 Data: i_PoolSTO type Standard table of t_PoolSTO_out.
Select
 a~BOLNR
 c~EBELN
 c~EBELP
 a~VBELN
 b~VBELN
 from LIKP as a
 Inner Join VBFA as b on aVBELN = bVBELV
 Inner Join EKBE as c on bVBELN = cBELNR
 into Table i_PoolSTO
 Where a~BOLNR in S_LBLNE and
 b~VBTYP_N = 'R' and
 b~BWART = '641'.
 My doubt is whether the logic works or not i Mean does i getall the rrecords based on the requirement.?
 If not please tell any alternative logic?
Thanks,
Gopi Anne.

Hi Gopi,
Your code is Good.
But try to avoid Inner join with more number of Tables ...because this is a performance issue..
try to use..
select (primary key fields mainly,other fields) from LIKP into itab where bolnr in p_bolnr(paramater).
next try to use for all entries option..
select (primary key fields mainly,other fields) from VBFA for all entries in itab where (give the condition)....
simillarly do for the other select ....ok this will try to reduce the performance issue....
<REMOVED BY MODERATOR>
Message was edited by:
 Alvaro Tejada Galindo

Why can't i use "INNER JOIN" in a query for SQL Server with JDBC??????

Hi,
I'm trying to execute some SQL queries and I just don't understand what's wrong.
I�m using Tomcat and SQL Server in order to do this, but when I�m try to execute a query with a INNER JOIN statements Tomcat raise a SQL exception... at the very first time I thought there was a problem with database connection but I realize that a simple query to a table works pretty well. then I found out some problems with JDBC:ODBC.... so I install JDBC for SQL Server 2000 and test with the same simple query and works..... so, I come to a conclusion.... INNER JOIN or JOIN statements can't be used in JDBC..... please... somebody tell I�m wrong and give me a hand...
I'm using TOMCAT 4 and JDK 1.4 SQL Server 2000
Error occurs when executeQuery() is called.... not prepareStatement().... ??????
Driver DriverRecResult = (Driver)Class.forName(driver).newInstance();
Connection ConnRecResult = DriverManager.getConnection(DSN,user,password);
PreparedStatement StatementRecResult = ConnRecResult.prepareStatement(query);
ResultSet RecResult = StatementRecResult.executeQuery(); <---- Exception raise here
So much tahnks in advance,

That's exactly what I think, driver it's raising the exception, but I don't know why.... i test the same query with INNER JOIN directly from SQL Query Analyser and it's works perfectly, my problem ain't SQL, but JSP and JDBC 'cause i'm a newbie about these issues.
Common sense tell me possible problems lie in SQLServer drivers 'cause i run the same pages on JRUN through jdbc:odbc and do works well, but by now i just depend on Tomcat.....
I've installed SQL Server drivers for JDBC but i just find it doesn't work fully... could be the version of JDK i've installed? what version do i need?
( I'm running Tomcat 4 with JDK 1.4 & SQL Server 2000 W2K )
thanks for reply.

Sequence of inner join

Will the sequence of inner join...
eg. joining kna1, knb1, bkpf, bsid
affect performance?
or does it matter when choosing the field to be in the where clause from one of the 4 tables affect performance.. when considering the use of index?

Hi Charles,
the system will take care of this. Important is the correct use of join conditions. Make sure that the relation is 1 : n for any join. If you have two rows in one table matching 3 rows in the second table, the database will retrieve all possible combinations ( 6 rows) This causes unnecessary overhead, memory space waste, performance issues, duplicates and confusion.
A good rule is to join from more to less record, i.e.
select vkan~vbeln vbap~posnr vbap~menge
into corresponding fields of table ...
from vbap
join vbak
on vbap~vbeln
= vbak~vbeln
where ...
Regards,
Clemens

Query Rewrite ISSUE (ANSI JOINS do not work, traditional join works ) 11gR2

For some types of queries constructed with ANSI JOINS, materialized views are not being used.
This is currently increasing time on various reports since we cannot control the way the queries are generated(Tableau Application generates and runs queries against the STAR Schema).
Have tried to debug this behavior using DBMS_MVIEW.EXPLAIN_REWRITE and mv_capabilities function without any success.
The database is configured for query rewrite: REWRITE INTEGRITY, QUERY REWRITE ENABLED and other settings are in place.
Have successfully reproduced the issue using SH Sample schema:
Q1 and Q2 are logically identical the only difference between them being the type of join used:
Q1: ANSI JOIN
Q2: Traditional join
Below is an example that can be validated on SH sample schema.
Any help on this will be highly appreciated.
-- Q1: the query is generated by an app and needs to be rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
-- Q2: the query with traditional join is rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Tested both queries with the following materialized views:
CREATE MATERIALIZED VIEW MVIEW_TEST_1
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
CREATE MATERIALIZED VIEW MVIEW_TEST_2
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Explain Plans showing that Q1 does not use materialized view and Q2 uses materialized view
SET AUTOTRACE TRACEONLY
--Q1 does not use MVIEW_TEST_1
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4    5
511 rows selected.
Execution Plan
Plan hash value: 1218164197
| Id | Operation           | Name       | Rows | Bytes |TempSpc| Cost (%CPU)| Time       |
|   0 | SELECT STATEMENT      |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   1 | HASH GROUP BY           |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   2 |   VIEW                | VM_NWVW_1 | 55500 | 1571K|       |   916   (1)| 00:00:11 |
|   3 |    HASH GROUP BY      |        | 55500 | 1842K| 2408K|   916   (1)| 00:00:11 |
|* 4 |     HASH JOIN           |        | 55500 | 1842K|       |   409   (1)| 00:00:05 |
|   5 |      TABLE ACCESS FULL| COUNTRIES |    23 |   414 |       |     3   (0)| 00:00:01 |
|   6 |      TABLE ACCESS FULL| CUSTOMERS | 55500 |   867K|       |   405   (1)| 00:00:05 |
--Q2 uses MVIEW_TEST_2
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4
511 rows selected.
Execution Plan
Plan hash value: 2126022771
| Id | Operation               | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |              |     511 | 21973 |       3   (0)| 00:00:01 |
|   1 | MAT_VIEW REWRITE ACCESS FULL| MVIEW_TEST_2 |     511 | 21973 |       3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------Database version 11gR1 (Tested also on 11gR2)
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

Thanks for the formatting tips.
Just found an Oracle Bug which explains the above behavior.
Unfortunately the bug will be fixed only in 12.1 Release so as a workaround will try to use traditional joins.
For those who have metalink access see [Bug 10145667 : ERRORS TRYING TO REWRITE QUERY WITH EXACT TEXT MATCH TO MVIEW]

Very Slow Query with CTE inner join

I have 2 tables (heavily simplified here to show relevant columns):
CREATE TABLE tblCharge
(ChargeID int NOT NULL,
ParentChargeID int NULL,
ChargeName varchar(200) NULL)
CREATE TABLE tblChargeShare
(ChargeShareID int NOT NULL,
ChargeID int NOT NULL,
TotalAmount money NOT NULL,
TaxAmount money NULL,
DiscountAmount money NULL,
CustomerID int NOT NULL,
ChargeShareStatusID int NOT NULL)
I have a very basic View to Join them:
CREATE VIEW vwBASEChargeShareRelation as
Select c.ChargeID, ParentChargeID, s.CustomerID, s.TotalAmount, isnull(s.TaxAmount, 0) as TaxAmount, isnull(s.DiscountAmount, 0) as DiscountAmount
from tblCharge c inner join tblChargeShare s
on c.ChargeID = s.ChargeID Where s.ChargeShareStatusID < 3
GO
I then have a view containing a CTE to get the children of the Parent Charge:
ALTER VIEW [vwChargeShareSubCharges] AS
WITH RCTE AS
SELECT ParentChargeId, ChargeID, 1 AS Lvl, ISNULL(TotalAmount, 0) as TotalAmount, ISNULL(TaxAmount, 0) as TaxAmount,
ISNULL(DiscountAmount, 0) as DiscountAmount, CustomerID, ChargeID as MasterChargeID
FROM vwBASEChargeShareRelation Where ParentChargeID is NULL
UNION ALL
SELECT rh.ParentChargeID, rh.ChargeID, Lvl+1 AS Lvl, ISNULL(rh.TotalAmount, 0), ISNULL(rh.TaxAmount, 0), ISNULL(rh.DiscountAmount, 0) , rh.CustomerID
, rc.MasterChargeID
FROM vwBASEChargeShareRelation rh
INNER JOIN RCTE rc ON rh.PArentChargeID = rc.ChargeID and rh.CustomerID = rc.CustomerID
Select MasterChargeID as ChargeID, CustomerID, Sum(TotalAmount) as TotalCharged, Sum(TaxAmount) as TotalTax, Sum(DiscountAmount) as TotalDiscount
from RCTE
Group by MasterChargeID, CustomerID
GO
So far so good, I can query this view and get the total cost for a line item including all children.
The problem occurs when I join this table. The query:
Select t.* from vwChargeShareSubCharges t
inner join
tblChargeShare s
on t.CustomerID = s.CustomerID
and t.MasterChargeID = s.ChargeID
Where s.ChargeID = 1291094
Takes around 30 ms to return a result (tblCharge and Charge Share have around 3.5 million records).
But the query:
Select t.* from vwChargeShareSubCharges t
inner join
tblChargeShare s
on t.CustomerID = s.CustomerID
and t.MasterChargeID = s.ChargeID
Where InvoiceID = 1045854
Takes around 2 minutes to return a result - even though the only charge with that InvoiceID is the same charge as the one used in the previous query.
The same thing occurs if I do the join in the same query that the CTE is defined in.
I ran the execution plan for each query. The first (fast) query looks like this:
The second(slow) query looks like this:
I am at a loss, and my skills at decoding execution plans to resolve this are lacking.
I have separate indexes on tblCharge.ChargeID, tblCharge.ParentChargeID, tblChargeShare.ChargeID, tblChargeShare.InvoiceID, tblChargeShare.ChargeShareStatusID
Any ideas? Tested on SQL 2008R2 and SQL 2012

>> The database is linked [sic] to an established app and the column and table names can't be changed. <<
Link? That is a term from pointer chains and network databases, not SQL. I will guess that means the app came back in the old pre-RDBMS days and you are screwed.
>> I am not too worried about the money field [sic], this is used for money and money based calculations so the precision and rounding are acceptable at this level. <<
Field is a COBOL concept; columns are totally different. MONEY is how Sybase mimics the PICTURE clause that puts currency signs, commas, period, etc in a COBOL money field.
Using more than one operation (multiplication or division) on money columns will produce severe rounding errors. A simple way to visualize money arithmetic is to place a ROUND() function calls after
every operation. For example,
Amount = (Portion / total_amt) * gross_amt
can be rewritten using money arithmetic as:
Amount = ROUND(ROUND(Portion/total_amt, 4) *
gross_amt, 4)
Rounding to four decimal places might not seem an
issue, until the numbers you are using are greater
than 10,000.
BEGIN
DECLARE @gross_amt MONEY,
@total_amt MONEY,
@my_part MONEY,
@money_result MONEY,
@float_result FLOAT,
@all_floats FLOAT;
SET @gross_amt = 55294.72;
SET @total_amt = 7328.75;
SET @my_part = 1793.33;
SET @money_result = (@my_part / @total_amt) *
@gross_amt;
SET @float_result = (@my_part / @total_amt) *
@gross_amt;
SET @Retult3 = (CAST(@my_part AS FLOAT)
/ CAST( @total_amt AS FLOAT))
* CAST(FLOAT, @gross_amt AS FLOAT);
SELECT @money_result, @float_result, @all_floats;
END;
@money_result = 13525.09 -- incorrect
@float_result = 13525.0885 -- incorrect
@all_floats = 13530.5038673171 -- correct, with a -
5.42 error
>> The keys are ChargeID(int, identity) and ChargeShareID(int, identity). <<
Sorry, but IDENTITY is not relational and cannot be a key by definition. But it sure works just like a record number in your old COBOL file system.
>> .. these need to be int so that they are assigned by the database and unique. <<
No, the data type of a key is not determined by physical storage, but by logical design. IDENTITY is the number of a parking space in a garage; a VIN is how you identify the automobile.
>> What would you recommend I use as keys? <<
I do not know. I have no specs and without that, I cannot pull a Kabbalah number from the hardware. Your magic numbers can identify Squids, Automobile or Lady Gaga! I would ask the accounting department how they identify a charge.
>> Charge_Share_Status_ID links [sic] to another table which contains the name, formatting [sic] and other information [sic] or a charge share's status, so it is both an Id and a status. <<
More pointer chains! Formatting? Unh? In RDBMS, we use a tiered architecture. That means display formatting is in a presentation layer. A properly created table has cohesion – it does one and only one data element. A status is a state of being that applies
to an entity over a period time (think employment, marriage, etc. status if that is too abstract).
An identifier is based on the Law of Identity from formal logic “To be is to be something in particular” or “A is A” informally. There is no entity here! The Charge_Share_Status table should have the encoded values for a status and perhaps a description if
they are unclear. If the list of values is clear, short and static, then use a CHECK() constraint.
On a scale from 1 to 10, what color is your favorite letter of the alphabet? Yes, this is literally that silly and wrong.
>> I understand what a CTE is; is there a better way to sum all children for a parent hierarchy? <<
There are many ways to represent a tree or hierarchy in SQL. This is called an adjacency list model and it looks like this:
CREATE TABLE OrgChart
(emp_name CHAR(10) NOT NULL PRIMARY KEY,
boss_emp_name CHAR(10) REFERENCES OrgChart(emp_name),
salary_amt DECIMAL(6,2) DEFAULT 100.00 NOT NULL,
<< horrible cycle constraints >>);
OrgChart
emp_name boss_emp_name salary_amt
==============================
'Albert' NULL 1000.00
'Bert' 'Albert' 900.00
'Chuck' 'Albert' 900.00
'Donna' 'Chuck' 800.00
'Eddie' 'Chuck' 700.00
'Fred' 'Chuck' 600.00
This approach will wind up with really ugly code -- CTEs hiding recursive procedures, horrible cycle prevention code, etc. The root of your problem is not knowing that rows are not records, that SQL uses sets and trying to fake pointer chains with some
vague, magical non-relational "id".
This matches the way we did it in old file systems with pointer chains. Non-RDBMS programmers are comfortable with it because it looks familiar -- it looks like records and not rows.
Another way of representing trees is to show them as nested sets.
Since SQL is a set oriented language, this is a better model than the usual adjacency list approach you see in most text books. Let us define a simple OrgChart table like this.
CREATE TABLE OrgChart
(emp_name CHAR(10) NOT NULL PRIMARY KEY,
lft INTEGER NOT NULL UNIQUE CHECK (lft > 0),
rgt INTEGER NOT NULL UNIQUE CHECK (rgt > 1),
CONSTRAINT order_okay CHECK (lft < rgt));
OrgChart
emp_name lft rgt
======================
'Albert' 1 12
'Bert' 2 3
'Chuck' 4 11
'Donna' 5 6
'Eddie' 7 8
'Fred' 9 10
The (lft, rgt) pairs are like tags in a mark-up language, or parens in algebra, BEGIN-END blocks in Algol-family programming languages, etc. -- they bracket a sub-set. This is a set-oriented approach to trees in a set-oriented language.
The organizational chart would look like this as a directed graph:
Albert (1, 12)
Bert (2, 3) Chuck (4, 11)
/ | \
/ | \
/ | \
/ | \
Donna (5, 6) Eddie (7, 8) Fred (9, 10)
The adjacency list table is denormalized in several ways. We are modeling both the Personnel and the Organizational chart in one table. But for the sake of saving space, pretend that the names are job titles and that we have another table which describes the
Personnel that hold those positions.
Another problem with the adjacency list model is that the boss_emp_name and employee columns are the same kind of thing (i.e. identifiers of personnel), and therefore should be shown in only one column in a normalized table. To prove that this is not
normalized, assume that "Chuck" changes his name to "Charles"; you have to change his name in both columns and several places. The defining characteristic of a normalized table is that you have one fact, one place, one time.
The final problem is that the adjacency list model does not model subordination. Authority flows downhill in a hierarchy, but If I fire Chuck, I disconnect all of his subordinates from Albert. There are situations (i.e. water pipes) where this is true, but
that is not the expected situation in this case.
To show a tree as nested sets, replace the nodes with ovals, and then nest subordinate ovals inside each other. The root will be the largest oval and will contain every other node. The leaf nodes will be the innermost ovals with nothing else inside them
and the nesting will show the hierarchical relationship. The (lft, rgt) columns (I cannot use the reserved words LEFT and RIGHT in SQL) are what show the nesting. This is like XML, HTML or parentheses.
At this point, the boss_emp_name column is both redundant and denormalized, so it can be dropped. Also, note that the tree structure can be kept in one table and all the information about a node can be put in a second table and they can be joined on employee
number for queries.
To convert the graph into a nested sets model think of a little worm crawling along the tree. The worm starts at the top, the root, makes a complete trip around the tree. When he comes to a node, he puts a number in the cell on the side that he is visiting
and increments his counter. Each node will get two numbers, one of the right side and one for the left. Computer Science majors will recognize this as a modified preorder tree traversal algorithm. Finally, drop the unneeded OrgChart.boss_emp_name column
which used to represent the edges of a graph.
This has some predictable results that we can use for building queries. The root is always (left = 1, right = 2 * (SELECT COUNT(*) FROM TreeTable)); leaf nodes always have (left + 1 = right); subtrees are defined by the BETWEEN predicate; etc. Here are
two common queries which can be used to build others:
1. An employee and all their Supervisors, no matter how deep the tree.
SELECT O2.*
FROM OrgChart AS O1, OrgChart AS O2
WHERE O1.lft BETWEEN O2.lft AND O2.rgt
AND O1.emp_name = :in_emp_name;
2. The employee and all their subordinates. There is a nice symmetry here.
SELECT O1.*
FROM OrgChart AS O1, OrgChart AS O2
WHERE O1.lft BETWEEN O2.lft AND O2.rgt
AND O2.emp_name = :in_emp_name;
3. Add a GROUP BY and aggregate functions to these basic queries and you have hierarchical reports. For example, the total salaries which each employee controls:
SELECT O2.emp_name, SUM(S1.salary_amt)
FROM OrgChart AS O1, OrgChart AS O2,
Salaries AS S1
WHERE O1.lft BETWEEN O2.lft AND O2.rgt
AND S1.emp_name = O2.emp_name
GROUP BY O2.emp_name;
4. To find the level and the size of the subtree rooted at each emp_name, so you can print the tree as an indented listing.
SELECT O1.emp_name,
SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt
THEN O2.sale_amt ELSE 0.00 END) AS sale_amt_tot,
SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt
THEN 1 ELSE 0 END) AS subtree_size,
SUM(CASE WHEN O1.lft BETWEEN O2.lft AND O2.rgt
THEN 1 ELSE 0 END) AS lvl
FROM OrgChart AS O1, OrgChart AS O2
GROUP BY O1.emp_name;
5. The nested set model has an implied ordering of siblings which the adjacency list model does not. To insert a new node, G1, under part G. We can insert one node at a time like this:
BEGIN ATOMIC
DECLARE rightmost_spread INTEGER;
SET rightmost_spread
= (SELECT rgt
FROM Frammis
WHERE part = 'G');
UPDATE Frammis
SET lft = CASE WHEN lft > rightmost_spread
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= rightmost_spread
THEN rgt + 2
ELSE rgt END
WHERE rgt >= rightmost_spread;
INSERT INTO Frammis (part, lft, rgt)
VALUES ('G1', rightmost_spread, (rightmost_spread + 1));
COMMIT WORK;
END;
The idea is to spread the (lft, rgt) numbers after the youngest child of the parent, G in this case, over by two to make room for the new addition, G1. This procedure will add the new node to the rightmost child position, which helps to preserve the idea
of an age order among the siblings.
6. To convert a nested sets model into an adjacency list model:
SELECT B.emp_name AS boss_emp_name, E.emp_name
FROM OrgChart AS E
LEFT OUTER JOIN
OrgChart AS B
ON B.lft
= (SELECT MAX(lft)
FROM OrgChart AS S
WHERE E.lft > S.lft
AND E.lft < S.rgt);
7. To find the immediate parent of a node:
SELECT MAX(P2.lft), MIN(P2.rgt)
FROM Personnel AS P1, Personnel AS P2
WHERE P1.lft BETWEEN P2.lft AND P2.rgt
AND P1.emp_name = @my_emp_name;
I have a book on TREES & HIERARCHIES IN SQL which you can get at Amazon.com right now. It has a lot of other programming idioms for nested sets, like levels, structural comparisons, re-arrangement procedures, etc.
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL

Perfomance issue : inner join on buffered db dable

Similar Messages

Maybe you are looking for