Merge cartesian join in query plan

Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.

user8650395 wrote:
Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.Interesting.
There was a a thread a day or two ago about when dynamic sampling does not work. You can search OTN for it if you like. Also check the docs to make sure that dynamic sampling works with GTTS
One problem with GTTS is getting accurate statistics. Have you considered using DBMS_STATISTICS to set the statistics on the table to adjust the cardinality?
Your cardinality of 1 sounds incorrect. In theory a cartesian join against one row should be painelss; unfortunately your cardinality figure seems to be off! Sometimes in cases like yours the cost-based optimizer will choose a Cartesian join even when the table joins are properly specified.

Similar Messages

Merge Cartesian Join

Hi,
I'm having this plan, But I'm not able to understand as to which table/view it's producing the MERGE CARTESIAN JOIN, and BUFFER SORT, is it from CM_PAY_TRANS_VW but then which column it's referring to?
Please advice
| Id | Operation                           | Name                 | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                      |     1 |   249 |    24 (13)| 00:00:01 |
|* 1 | HASH JOIN                          |                      |     1 |   249 |    24 (13)| 00:00:01 |
|   2 |   VIEW                              | CM_PAY_TRANS_VW      |     1 |   160 |    12   (9)| 00:00:01 |
|   3 |    HASH GROUP BY                    |                      |     1 |   179 |    12   (9)| 00:00:01 |
|   4 |     NESTED LOOPS OUTER              |                      |     1 |   179 |    11   (0)| 00:00:01 |
|   5 |      NESTED LOOPS                   |                      |     1 |   149 |    10   (0)| 00:00:01 |
|   6 |       MERGE JOIN CARTESIAN          |                      |    19 | 2242 |     9   (0)| 00:00:01 |
|   7 |        TABLE ACCESS BY INDEX ROWID | CI_PAY_SEG           |     1 |    28 |     1   (0)| 00:00:01 |
|   8 |         NESTED LOOPS                |                      |     1 |    78 |     2   (0)| 00:00:01 |
|   9 |          TABLE ACCESS BY INDEX ROWID| CI_PAY               |     1 |    50 |     1   (0)| 00:00:01 |
|* 10 |           INDEX RANGE SCAN          | XT156S2              |     1 |       |     1   (0)| 00:00:01 |
|* 11 |          INDEX RANGE SCAN           | XT165S1              |     3 |       |     1   (0)| 00:00:01 |
| 12 |        BUFFER SORT                  |                      |    30 | 1200 |     8   (0)| 00:00:01 |
|* 13 |         TABLE ACCESS FULL           | CI_SA_TYPE_L         |    30 | 1200 |     7   (0)| 00:00:01 |
|* 14 |       TABLE ACCESS BY INDEX ROWID   | CI_SA                |     1 |    31 |     1   (0)| 00:00:01 |
|* 15 |        INDEX UNIQUE SCAN            | XM199P0              |     1 |       |     1   (0)| 00:00:01 |
| 16 |      TABLE ACCESS BY INDEX ROWID    | CI_PAY_CAN_RSN_L     |     1 |    30 |     1   (0)| 00:00:01 |
|* 17 |       INDEX UNIQUE SCAN             | XC557P0              |     1 |       |     1   (0)| 00:00:01 |
| 18 |   VIEW                              | CM_PAY_TNDR_TYPES_VW |   174 | 15486 |    11 (10)| 00:00:01 |
| 19 |    HASH GROUP BY                    |                      |   174 | 15660 |    11 (10)| 00:00:01 |
| 20 |     NESTED LOOPS OUTER              |                      |   174 | 15660 |    10   (0)| 00:00:01 |
| 21 |      NESTED LOOPS OUTER             |                      |   160 | 10080 |     9   (0)| 00:00:01 |
| 22 |       TABLE ACCESS FULL             | CI_PAY_EVENT         |   160 | 4640 |     7   (0)| 00:00:01 |
| 23 |       TABLE ACCESS BY INDEX ROWID   | CI_PAY_TNDR          |     1 |    34 |     1   (0)| 00:00:01 |
|* 24 |        INDEX RANGE SCAN             | XT265S3              |     1 |       |     1   (0)| 00:00:01 |
| 25 |      TABLE ACCESS BY INDEX ROWID    | CI_TENDER_TYPE_L     |     1 |    27 |     1   (0)| 00:00:01 |
|* 26 |       INDEX UNIQUE SCAN             | XC583P0              |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("A"."PAY_EVENT_ID"="B"."PAY_EVENT_ID")
10 - access("P"."PAY_EVENT_ID"='010253513440')
11 - access("P"."PAY_ID"="PSEG"."PAY_ID")
13 - filter("SA_TYP"."LANGUAGE_CD"='ENG')
14 - filter("SA"."SA_TYPE_CD"="SA_TYP"."SA_TYPE_CD")
15 - access("PSEG"."SA_ID"="SA"."SA_ID")
17 - access("P"."CAN_RSN_CD"="RSN"."CAN_RSN_CD"(+) AND "RSN"."LANGUAGE_CD"(+)='ENG')
24 - access("EVT"."PAY_EVENT_ID"="TDR"."PAY_EVENT_ID"(+))
26 - access("TDR"."TENDER_TYPE_CD"="TT"."TENDER_TYPE_CD"(+) AND "TT"."LANGUAGE_CD"(+)='ENG')

is it CM_PAY_TRANS_VWYou know your data model, we don't. You also haven't posted the query, so it's a bit difficult to tell but it looks to me as though it's CI_SA_TYPE_L which is responsible. FULL TABLE ACCESS with a filter rather than an access predicate.
As to why this happening, you might find this article by Jonathan Lewis sheds some light.
Cheers, APC
Blog : http://radiofreetooting.blogspot.com/

Puzzled By Cartesian Join In Query

If I do this query:
SELECT count(*)
FROM
mode_change_history psch
JOIN mode_link psl USING (mode_index)
WHERE
psch.date_changed >= TO_TIMESTAMP ('2008-03-03 05:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF');
The query takes less than a second and I get the desired results. If I modify the query by adding an additional join to the analysts table, like this:
SELECT count(*)
FROM
mode_change_history psch
JOIN mode_link psl USING (mode_index)
JOIN analysts a USING (analyst_id)
WHERE
psch.date_changed >= TO_TIMESTAMP ('2008-03-03 05:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF');
The query takes too long (about a minute) and generates a cartesian product(according to the explain plan) when joining the analysts table.
Notes:
I've removed the column names from the SELECT clause and replaced it with a count(*) just to simply this example.
Relevant info on the tables being joined:
mode_change_history columns
mode_index
date_changed
analyst_id
justification
change_type
Primary key on this table: mode_index,date_changed,analyst_id
Approximate rows in table: 50,000
mode_link columns
mode_index
mode_name
parameter_set_id
Primary key on this table is: mode_index
Approximate rows in table: 20,000
analysts columns
analyst_id
user_name
full_name
Primary key on this table is: analyst_id
Approximate rows in table: 500
As you can see, none of the tables have many rows.
After joining the first two tables listed in the query the result of the join would have rows containing mode_index (from mode_change_history and mode_link tables) that satisfy the WHERE clause. This intermediate result set should include the additional column analyst_id from the mode_change_history table. Then I would expect the RDBMS to join the rows from the analysts table that have analyst_id's in the intermediate result set. This does not appear to be happening since I'm seeing the cartesian join line show up in the execution plan.
Any ideas on what's going on?
I would post the explain plans but the Oracle instance is on a network that is not connected to the Internet so I can't easily post any output.
Thank you

I don't use them myself. but I did have to debug somebody else's code which was giving all kinds of random results. natural three way join (sounds dirty) - ha!
also, I've seen discrepancies between the manuals for different versions on the syntax and rules. one manual states that the USING clause is only valid for outer joins. another release states that it's good for inner and outer. I've also seen differences regarding the use of the word NATURAL.
the bug it isn't that the optimizer uses a merge join carteian to resolve it (which could still give the correct answer, but possibly not with optimal performance). it's that it screws up the join criteria and returns a cartesian product result set.
my opinion - screw ansi, I'm using oracle syntax. and if some new guy with a t-sql background doesn't like it, tough. I came from a C & Pascal background and had an oracle manual thrown in my lap (it was long enough ago that manuals were still printed, and luckily, being v5, the manuals were small and didn't damage anything).

Merge Cartesian in query

Hi
below query is running 1 minutes on test server however it is stucking on production for more than 8 hours .
I compared explain plan for both queries ,on test server,optimizer is using hash join however on production ,optimizer is using Merge Cartesian join .
I tried query with ordered hit ,we get rid of mergecartesian join but cost got increased
now please advice ,if we should go by this ordered hit method on production or not not
or suggets any other ways .
below is query
SELECT DISTINCT acct_promo_hdr.row_id, '401000', 'EXPORTED',
acct_promo_hdr.src_num, 'PLAN_ACCOUNT_PROMOTION',
promo_hdr_org.NAME
FROM siebel.s_src acct_promo_hdr,
siebel.s_mdf_alloc deal,
siebel.s_bu promo_hdr_org
-- siebel.s_contact contact,
-- siebel.s_user usr
WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
AND acct_promo_hdr.row_id = deal.promo_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
-- AND acct_promo_hdr.created_by = contact.row_id
-- AND contact.row_id = usr.row_id
AND EXISTS (
SELECT 1
FROM approval acb_approval
WHERE acb_approval.status NOT IN
('11', '12', '65', '77')
AND acct_promo_hdr.src_num =
acb_approval.commit_num)
AND deal.status_cd IN
('Cancel',
'Cancelled',
'Committed',
'On Hold',
'Processing Claim',
'Paid In Part',
'Paid In Full',
'Hold'
explain plan on production
PLAN_TABLE_OUTPUT
Plan hash value: 115701554
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 133 | 207 (2)| 00:00:03 |
| 1 | HASH UNIQUE | | 1 | 133 | 207 (2)| 00:00:03 |
| 2 | NESTED LOOPS | | | | | |
| 3 | NESTED LOOPS | | 1 | 133 | 206 (1)| 00:00:03 |
| 4 | NESTED LOOPS | | 1 | 112 | 205 (1)| 00:00:03 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 57 | 67 (2)| 00:00:01 |
| 6 | SORT UNIQUE | | 1 | 30 | 64 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | APPROVAL | 1 | 30 | 64 (0)| 00:00:01 |
| 8 | BUFFER SORT | | 3 | 81 | 3 (34)| 00:00:01 |
| 9 | TABLE ACCESS FULL | S_BU | 3 | 81 | 2 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 55 | 137 (0)| 00:00:02 |
|* 11 | INDEX RANGE SCAN | S_SRC_U2 | 1 | | 137 (0)| 00:00:02 |
|* 12 | INDEX RANGE SCAN | S_MDF_ALLOC_F8 | 12 | | 1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | S_MDF_ALLOC | 11 | 231 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
7 - filter("ACB_APPROVAL"."STATUS"<>'11' AND "ACB_APPROVAL"."STATUS"<>'12' AND
"ACB_APPROVAL"."STATUS"<>'65' AND "ACB_APPROVAL"."STATUS"<>'77')
11 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID" AND
"ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION')
filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
"ACB_APPROVAL"."COMMIT_NUM"=TO_NUMBER("ACCT_PROMO_HDR"."SRC_NUM"))
12 - access("ACCT_PROMO_HDR"."ROW_ID"="DEAL"."PROMO_ID")
13 - filter("DEAL"."STATUS_CD"='Cancel' OR "DEAL"."STATUS_CD"='Cancelled' OR
"DEAL"."STATUS_CD"='Committed' OR "DEAL"."STATUS_CD"='Hold' OR "DEAL"."STATUS_CD"='On
Hold' OR "DEAL"."STATUS_CD"='Paid In Full' OR "DEAL"."STATUS_CD"='Paid In Part' OR
"DEAL"."STATUS_CD"='Processing Claim')
35 rows selected.

pujakhetan wrote:
Tables are analysed on production .Well, the stats are indicating to the optimizer that the filter at #7 (<tt>ACB_APPROVAL_STATUS {noformat}<{noformat}> '11'</tt> etc) will return 1 row (usually indicating it thinks there are no rows to process), so if that is not the case then something has gone wrong. I'm guessing the 'good' plan you see in test has higher cardinality figures?
I tried query with ordered hit, we get rid of merge cartesian join but cost got increased nowIgnore the 'cost', it is just a figure calculated by the optimizer to indicate the relative resources required by different query plans - according to the available stats - and if those stats are out or something else is confusing it then the figure will be meaningless. Look at it this way - if the cost calculation was right, your query would already have the best plan.
Also the problem was not the join order but the join method, so I don't see an 'ordered' hint necessarily helping.
btw placing <tt></tt> tags around your code and execution plan will make it a lot easier to read.

Merge Join Cartesian in XML query

Hi Sir
I am getting Merge join cartesian in the below XML query
SELECT
x.empno,
x1.empno AS INDEXempno
FROM
emp_vw x,
emp_index x1,
table (xmlsequence(extract(x1.xml_data,'/emp/org/constituent/'))) c
WHERE x.empno = extractvalue(VALUE(c),'/constituent/code/text()');
I am getting Merge join cartesian in XML query. whereeas below query i am running by I am not getting merge join cartesian
SELECT
x.empno,
x1.empno AS INDEXempno
FROM
emp_vw_v6 x,
emp_index_v6 x1,
table (xmlsequence(extract(x1.xml_data,'/emp/org/constituent/'))) c
WHERE x.empno = extractvalue(VALUE(c),'/constituent/code/text()');
Here emp_vw is a view and emp_index is a table.This is not giving merge join cartesian
However both the view and table are interdependent.
Please help me to resolve the performance of the first query as it is taking a lot of time to execute.?
Thanks & Regards
Thakur Manoj R

Please post a working test case, and follow the guidelines here : {message:id=9360002}
What are the differences between the view and table in the first query and the two others (*_v6) in the second query?

Query taking long because of merge cartesion join

Hi,
please suggest me to tune this query.
SELECT DISTINCT acct_promo_hdr.row_id, '401000', 'EXPORTED',
acct_promo_hdr.src_num, 'PLAN_ACCOUNT_PROMOTION',
promo_hdr_org.NAME
FROM siebel.s_src acct_promo_hdr,
siebel.s_mdf_alloc deal,
siebel.s_bu promo_hdr_org
-- siebel.s_contact contact,
-- siebel.s_user usr
WHERE -- acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
deal.promo_id =acct_promo_hdr.row_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
-- AND acct_promo_hdr.created_by = contact.row_id
-- AND contact.row_id = usr.row_id
AND EXISTS (
SELECT 1
FROM approval acb_approval
WHERE acb_approval.status NOT IN
('11', '12', '65', '77')
AND acct_promo_hdr.src_num =
acb_approval.commit_num)
AND deal.status_cd IN
('Cancel', 'Cancelled', 'Committed', 'On Hold',
'Processing Claim', 'Paid In Part',
'Paid In Full', 'Hold')
explain plan
PLAN_TABLE_OUTPUT
Plan hash value: 115701554
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 | 105 | 206 (2)| 00:00:03 |
| 1 | HASH UNIQUE | | 1 | 105 | 206 (2)| 00:00:03 |
| 2 | NESTED LOOPS | | | || |
| 3 | NESTED LOOPS | | 1 | 105 | 205(1)| 00:00:03 |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 1 | 84 | 204 (1)| 00:00:03 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 57 | 67(2)| 00:00:01 |
| 6 | SORT UNIQUE | | 1 | 30 | 64 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | APPROVAL | 1 | 30 | 64 PLAN_TABLE_OUTPUT--(0)| 00:00:01 |
| 8 | BUFFER SORT | | 3 | 81 | 3(34)| 00:00:01 |
| 9 | TABLE ACCESS FULL | S_BU | 3 | 81 | 2(0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 27 | 136(0)| 00:00:02 |
PLAN_TABLE_OUTPUT
|* 11 | INDEX RANGE SCAN | S_SRC_U2 | 1 | | 136(0)| 00:00:02 |
Thanks,
|* 12 | INDEX RANGE SCAN | S_MDF_ALLOC_F8 | 12 | | 1(0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | S_MDF_ALLOC | 10 | 210 | 1(0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
7 - filter("ACB_APPROVAL"."STATUS" <>'11' AND "ACB_APPROVAL"."STATUS"<> '12' AN
D
"ACB_APPROVAL"."STATUS"<> '65' AND "ACB_APPROVAL"."STATUS"<> '77')
11 - access("ACCT_PROMO_HDR"."BU_ID" ;="PROMO_HDR_ORG"."ROW_ID")
filter("ACB_APPROVAL"."COMMIT_NUM&q uot;=TO_NUMBER("ACCT_PROMO_HDR"."SRC_N UM"))
PLAN_TABLE_OUTPUT

Please format your code and stick between tags to preserve the formatting.
From the look of it, merge cartesian is not unreasonable given the low cardinality.
However I suspect that the number of rows the optimiser is estimating may be wrong.
Have you analysed your tables recently?

Could anyone help me to avoid Cartesian join in this query?

Hi, guys:
Could you help me on this query? I must generate a Cartesian join, but I do not know why it happens. dt.debtorkey, cl.clientkey, inv.invoicekey, ag.agingkey are primary keys of each table. The problem is: I got same tuple for 8 times.
select dt.debtorkey, cl.clientkey, inv.invoicekey, ag.agingkey, dt.DebtorNo, dt.Name as "debtor Name", dt.State, cl.ClientNo, cl.Name as "Client Name", inv.InvNo, inv.PurchOrd, inv.Amt,
to_char(inv.InvDate, 'MM-DD-YY') invoice_date, to_char(ag.DateLastBuy, 'MM-DD-YY') aging_lastbuy, to_char(ag.DateLastPmt, 'MM-DD-YY') aging_lastpmt
from aging ag, invoices inv, debtors dt, clients cl
where ag.clientkey=cl.clientkey
and ag.debtorkey=dt.debtorkey
and inv.clientkey=cl.clientkey
and inv.debtorkey=dt.debtorkey
and ((inv.InvDate>=to_date(:P16_DP_IDF_START_DATE, 'MM/DD/YYYY')
and inv.InvDate<=to_date(:P16_DP_IDF_END_DATE, 'MM/DD/YYYY')
and ag.DateLastBuy=to_date(:P16_DP_IDF_LAST_BUY,'MM/DD/YYYY')
order by dt.name;Thanks a lot!

Hi,
Thanks for help. I am sorry for that I do not know how to upload a picture of explain plan. I am struggling to find how to provide sample data. I hope this data format could be at least useful.
"DEBTORKEY","CLIENTKEY","INVOICEKEY","AGINGKEY","DEBTORNO","debtor Name","STATE","CLIENTNO","Client Name","INVNO","PURCHORD","AMT","INVOICE_DATE"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744212,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960590","LK1-17225",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744213,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960591","LK1-17241",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"
8,2741,744214,276807,"0538","MJN Services, Inc.","UT","2696","Pompano Logistics, LLC","26960592","LK1-17224",1700,"09-25-12"I do not know why the tuples with same primary key repeat 8 times.
Edited by: lxiscas on Oct 24, 2012 4:08 PM
Edited by: lxiscas on Oct 24, 2012 4:10 PM

Query Plan Question for Outer Join

I have the following join query:
select unique ep.ACT_UID,
ep.SE_REQ_TS,
sr.SERVICE_NM
from
eaisvcs.Service_requests sr,
eaisvcs.SERVICE_EPISODE ep
where
ep.ACT_UID = sr.ACT_UID;
I have an index on the act_uid in both tables, and the statistics are up-to-date. There are about 3.2 million rows in each table. 10% of the act_uid's that are in the ep table that do not have a match in the sr table. Other than that, most id's match up between the tables.
Here is the query plan:
ID PARENT_ID OPERATION OPTIONS
0 SELECT STATEMENT
1 0 SORT UNIQUE
2 1 MERGE JOIN
3 2 SORT JOIN
4 3 TABLE ACCESS FULL
5 2 SORT JOIN
6 5 TABLE ACCESS FULL
I cannot figure out why a table scan is being performed every time on both tables. The Act_UID is the PK in the ep table. There is a composite index (act_uid, sev_seq_no) in the sr table. the act_id is a varchar2 column in both tables. The sev_seq_no column is numeric.
Any ideas or insights about this would be greatly appreciated.
Thanks!

The plan can be good.
Oracle choose a full table scan for these reason too:
- sr.SERVICE_NM is not a part of the index and so a full table scan is less expensive. If you will add this field to your composite index Oracle will probably take this new index.
Bye, Aron

Cartesian Join query optimization

Hello Experts!
I have a question about cartesian join query which might look a bit weird.
Assume the SQL query like that:
SELECT DISTINCT A.NAME
FROM A, B, C;
Here we have cartesian join for 3 tables A, B and C.
It looks to me, in order to get the result for such a particular SQL tables/sets B and C need to be accessed only to ensure they return at least 1 row (otherwise result set is empty), query table A, but there is no actual need to join the data.
If you run such a query Oracle is doing full table scans and actually joins the data.
Yes, DBMS is doing exactly what you are asking for, but I wonder if there is any way (SQL hint or db parameter or anything else) to enforce more optimal access path here?
Obvious solution to remove B and C tables from the SELECT statement is not acceptable. :-)
Thank you!

Your statement in the other thread indicates you don't understand how the BI prompts actually work because you say you want it to do something that doesn't make sense for it to do.
Of course Product and Account levels will be constrained to the interval you specified. It wouldn't make sense for them not to be. Because that would mean returning data for based on product and account levels that has a different open data range than what you specified.
All UI prompt dialogs I have seen use AND relationships between the parameters. If there are three parameters (A, B, C) then the ultimate relationship is 'A AND B AND C'; not 'A OR (B AND C)', 'A AND (B OR C)', 'A OR (B OR C).
Unless the tool allows you to select OR relationships you need to use a separate dialog box (parameter dialog) for each condition set.:-)
I understand how BI prompts work and basically agree on your comment, but there are two problems here:
1. I need to convince the customer his original requirements are not valid. Customer want it to work different way and there are some reasons why.
2. There are pretty large dimensions and fact tables used here, so when I choose filter criteria for the Product (which is small table) to populate/recalculate prompt values, large SR dimension and fact tables are joined too, and if there are Account dimension filters added, huge Account dimension will be added as well. This looks to be a bit sub-optimal for just populating the Product prompt values.
Of course, technically this is solvable, but requires to put some extra effort and does not solve the 1st issue.
That other link doesn't explain the sample code you posted in this thread. Post the actual query that is being generated and the query that you want to actually use.This is what is generated:
>
select distinct T311691.X_CUST_SUBTYPE as c1
from
WC_LOV_SR_AREA_H T311695,
WC_LOV_PROD_H T311687,
WC_LOV_CUST_TYPE_H T311691,
W_SRVREQ_D T302384 /* Dim_W_SRVREQ_D */
where ( T311687.LEV1 = 'Product X' and T311691.X_CUST_TYPE = 'Business' and T302384.OPEN_DT between TO_DATE('2012-03-01 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') and TO_DATE('2012-03-31 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') )
order by c1
>
This is what is actually needed to query this data:
>
select distinct T311691.X_CUST_SUBTYPE as c1
from
WC_LOV_CUST_TYPE_H T311691
where ( T311691.X_CUST_TYPE = 'Business' )
order by c1

Can users see the query plan of a SQL query in Oracle?

Hi,
I wonder for a given sql query, after the system optimization, can I see the query plan in oracle? If yes, how to do that? thank you.
Xing

You can use explain plan in SQLPlus
SQL> explain plan for select * from user_tables;
Explained.
Elapsed: 00:00:01.63
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 806004009
| Id | Operation                       | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|* 1 | HASH JOIN RIGHT OUTER          |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|   2 |   TABLE ACCESS FULL             | SEG$     | 4809 |   206K|    34   (3)| 00:00:01 |
|* 3 |   HASH JOIN RIGHT OUTER         |          | 1697 |   873K|   472   (6)| 00:00:06 |
|   4 |    TABLE ACCESS FULL            | USER$    |    74 | 1036 |     3   (0)| 00:00:01 |
|* 5 |    HASH JOIN OUTER              |          | 1697 |   850K|   468   (6)| 00:00:06 |
|   6 |     NESTED LOOPS OUTER          |          | 1697 |   836K|   315   (6)| 00:00:04 |
|* 7 |      HASH JOIN                  |          | 1697 |   787K|   226   (8)| 00:00:03 |
|   8 |       TABLE ACCESS FULL         | TS$      |    13 |   221 |     5   (0)| 00:00:01 |
|   9 |       NESTED LOOPS              |          | 1697 |   759K|   221   (8)| 00:00:03 |
| 10 |        MERGE JOIN CARTESIAN     |          | 1697 |   599K|   162 (10)| 00:00:02 |
|* 11 |         HASH JOIN               |          |     1 |   326 |     1 (100)| 00:00:01 |
|* 12 |          FIXED TABLE FULL       | X$KSPPI |     1 |    55 |     0   (0)| 00:00:01 |
| 13 |          FIXED TABLE FULL       | X$KSPPCV |   100 | 27100 |     0   (0)| 00:00:01 |
| 14 |         BUFFER SORT             |          | 1697 | 61092 |   162 (10)| 00:00:02 |
|* 15 |          TABLE ACCESS FULL      | OBJ$     | 1697 | 61092 |   161 (10)| 00:00:02 |
|* 16 |        TABLE ACCESS CLUSTER     | TAB$     |     1 |    96 |     1   (0)| 00:00:01 |
|* 17 |         INDEX UNIQUE SCAN       | I_OBJ#   |     1 |       |     0   (0)| 00:00:01 |
| 18 |      TABLE ACCESS BY INDEX ROWID| OBJ$     |     1 |    30 |     1   (0)| 00:00:01 |
|* 19 |       INDEX UNIQUE SCAN         | I_OBJ1   |     1 |       |     0   (0)| 00:00:01 |
| 20 |     TABLE ACCESS FULL           | OBJ$     | 52728 |   411K|   151   (4)| 00:00:02 |
Predicate Information (identified by operation id):
   1 - access("T"."FILE#"="S"."FILE#"(+) AND "T"."BLOCK#"="S"."BLOCK#"(+) AND
              "T"."TS#"="S"."TS#"(+))
   3 - access("CX"."OWNER#"="CU"."USER#"(+))
   5 - access("T"."DATAOBJ#"="CX"."OBJ#"(+))
   7 - access("T"."TS#"="TS"."TS#")
11 - access("KSPPI"."INDX"="KSPPCV"."INDX")
12 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled')
15 - filter("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0)
16 - filter(BITAND("T"."PROPERTY",1)=0)
17 - access("O"."OBJ#"="T"."OBJ#")
19 - access("T"."BOBJ#"="CO"."OBJ#"(+))
42 rows selected.
Elapsed: 00:00:03.61
SQL> If your plan table does not exist, execute the script $ORACLE_HOME/RDBMS/ADMIN/utlxplan.sql to create the table.

SQL 2012 SP1 - How to determine a query that causes Error 8623 in SQL Log: The query processor ran out of internal resources and could not produce a query plan. This is a rare event...

We are getting multiple 8623 Errors in SQL Log while running Vendor's software.
How can you catch which Query causes the error?
I tried to catch it using SQL Profiler Trace but it doesn't show which Query/Sp is the one causing an error.
I also tried to use Extended Event session to catch it, but it doesn't create any output either.
Error:
The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that
reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
Extended Event Session that I used;
CREATE EVENT SESSION
overly_complex_queries
ON SERVER
ADD EVENT sqlserver.error_reported
ACTION (sqlserver.sql_text, sqlserver.tsql_stack, sqlserver.database_id, sqlserver.username)
WHERE ([severity] = 16
AND [error_number] = 8623)
ADD TARGET package0.asynchronous_file_target
(SET filename = 'E:\SQLServer2012\MSSQL11.MSSQLSERVER\MSSQL\Log\XE\overly_complex_queries.xel' ,
metadatafile = 'E:\SQLServer2012\MSSQL11.MSSQLSERVER\MSSQL\Log\XE\overly_complex_queries.xem',
max_file_size = 10,
max_rollover_files = 5)
WITH (MAX_DISPATCH_LATENCY = 5SECONDS)
GO
-- Start the session
ALTER EVENT SESSION overly_complex_queries
ON SERVER STATE = START
GO
It creates only .xel file, but not .xem
Any help/advice is greatly appreciated

Hi VK_DBA,
According to your error message, about which query statement may fail with error message 8623, as other post, you can use trace flag 4102 & 4118 for overcoming this error. Another way is looking for queries with very long IN lists, a large number of
UNIONs, or a large number of nested sub-queries. These are the most common causes of this particular error message.
The error 8623 occurs when attempting to select records through a query with a large number of entries in the "IN" clause (> 10,000). For avoiding this error, I suggest that you could apply the latest Cumulative Updates media for SQL Server 2012 Service
Pack 1, then simplify the query. You may try divide and conquer approach to get part of the query working (as temp table) and then add extra joins / conditions. Or You could try to run the query using the hint option (force order), option (hash join), option
(merge join) with a plan guide.
For more information about error 8623, you can review the following article.
http://blogs.technet.com/b/mdegre/archive/2012/03/13/8623-the-query-processor-ran-out-of-internal-resources-and-could-not-produce-a-query-plan.aspx
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

CacheSplitMemoryReader - Cartesian join?

Hi,
We have a process where we run multiple matches on the input file, and then group number from each match is sent to a query transform to do an outer join before it is sent to associative match transform.
The process runs fine with small data set, but when we ran it for a production size file, the process ran for about 15 hours.
Looking at the monitor logs, we see a very large number against "CacheSplitMemoryReader".
While testing it with small set (say, 11 records in the input file), I see "121" rowcount against "CacheSplitMemoryReader".
Though I am not sure what "CacheSplitMemoryReader" means, my guess is that it is related to the join. And for some reason, while joining all the four input streams, DS decides to do a Cartesian join?
Though, the output is fine - with 11 records coming out of associative match.
We have tried changing outer join order in the query transform to see if that makes any difference. But so far, everytime it ends up with 121 records for "CacheSplitMemoryReader".
Any insight into what is happening and how to avoid it?
Thanks,
Gaurav
Edit: This is for DataService 12.2.0.1
Edited by: Gaurav Pandit on Nov 4, 2009 2:53 PM

Hello Gaurav,
I am curious why you are doing this join at all.
If you are trying to optimize the peformance of Associate, I recommend bypassing the rows that have no group number. In other words Associate should receive only the rows that have at least one group number populated. And then you will have to Merge back the rows.
I also recommend referring our bluprints posted here SAP Data Services Blueprints for example usage of Match and Associate. Please take a look at jobs named *_MatchAssociative. Here you will see how specific rows are bypassed and merged back for different Match transform. Similar principle can be applied for Associate. The Case condition will be based on Group Numbers.
Thanks,
Abhiram

Query plan and negative value in where

I have a question about this query:
select g.col1,
g.col2
from tab1 g,
tab2 part
where part.col3 <> 0
and g.col4 = 'PRO3'
and g.col2 = part.col5
and g.cod7 = -1
This is the execution plan:
SELECT STATEMENT, GOAL = ALL_ROWS
HASH JOIN
INDEX FAST FULL SCAN     SYS_C00254422     14     22453     516419
TABLE ACCESS FULL     TAB2     920     67458     1079328
If I change the select in this way:
select g.col1,
g.col2
from tab1 g,
tab2 part
where part.col3 <> 0
and g.col4 = 'PRO3'
and g.col2 = part.col5
and -g.cod7 = 1
I have a new query plan:
SELECT STATEMENT, GOAL = ALL_ROWS
NESTED LOOPS
INDEX FAST FULL SCAN     SYS_C00254422
TABLE ACCESS BY INDEX ROWID          TAB2
INDEX UNIQUE SCAN          SYS_C00254336
Oralce use a nested loop and the index of the table TAB1 and doesn't do the hash join.
Why?
I use oracle 10g
Message was edited by:
user613483
Message was edited by:
user613483

SQL> desc TAB1
Name Null? Type
COL1 NOT NULL VARCHAR2(5)
COL4 NOT NULL VARCHAR2(5)
COL2 NOT NULL VARCHAR2(15)
COL7 NOT NULL NUMBER(3)
DTCOL8 NOT NULL DATE
DRcol9 DATE
LEVcol10 NUMBER(3)
COL11 VARCHAR2(30)
COD12 VARCHAR2(15)
LEV13 NUMBER(3)
COD14 VARCHAR2(15)
LEV15 NUMBER(3)
COD16 VARCHAR2(15)
LEVN17 NUMBER(3)
COD18 VARCHAR2(15)
LEV19 NUMBER(3)
CODNOD20 VARCHAR2(15)
LEVNO21 NUMBER(3)
CODNOD22 VARCHAR2(15)
LEVN23 NUMBER(3)
COD24 VARCHAR2(15)
LEV25 NUMBER(3)
CODNOD26 VARCHAR2(15)
L27 NUMBER(3)
CODN28 VARCHAR2(15)
LEV28 NUMBER(3)
D30 DATE
SQL> desc tab2
Name Null? Type
COL5 NOT NULL VARCHAR2(15)
DESY1 VARCHAR2(60)
DESPA VARCHAR2(60)
CODS VARCHAR2(5)
CODNI VARCHAR2(5)
CODZO VARCHAR2(10)
CODC VARCHAR2(5)
CDFIS VARCHAR2(30)
CO VARCHAR2(30)
CODVATI VARCHAR2(30)
COT1 VARCHAR2(15)
COT2 VARCHAR2(15)
DCAT3 VARCHAR2(15)
CAT4 VARCHAR2(15)
COD VARCHAR2(15)
COU VARCHAR2(5)
FLG NOT NULL NUMBER(1)
COT VARCHAR2(20)
FLGCUSTD NOT NULL NUMBER(1)
CODMOE VARCHAR2(5)
FLG NOT NULL NUMBER(1)
FLGC NOT NULL NUMBER(1)
CODMOP VARCHAR2(5)
CODC VARCHAR2(15)
COELIV VARCHAR2(15)
CONC VARCHAR2(15)
COGMT VARCHAR2(10)
COR VARCHAR2(5)
COOUP VARCHAR2(15)
VALDIT NUMBER(14,2)
DTREDIT DATE
DTRE DATE
DTD DATE
DST DATE
DK DATE
COCK VARCHAR2(5)
CMOD VARCHAR2(5)
FNN NOT NULL NUMBER(1)
PGDCL VARCHAR2(60)
PDB VARCHAR2(60)
CXTEL VARCHAR2(15)
ILCK VARCHAR2(15)
DTTART DATE
PVERY NUMBER(9)
FLTUAL NOT NULL NUMBER(1)
DVER DATE
RIFE_INTERNO VARCHAR2(15)
DATADATE
ESENZIONE DATE
NMSENZIONE VARCHAR2(15)
VSED NUMBER(14,2)
EORD NOT NULL NUMBER(1)
EM VARCHAR2(30)
COTER VARCHAR2(15)
COUST VARCHAR2(15)
CORINT VARCHAR2(15)
TURFACE NUMBER(6)
ODSURFACE NUMBER(6)
ALINDEXPOT NUMBER(6)
SSE NUMBER(6)
NUSEATTR NUMBER(6)
NUETTI NUMBER(6)
CORTY VARCHAR2(15)
DESEC VARCHAR2(60)
QTEARI NUMBER(6)
TOFACE NUMBER(6)
COD VARCHAR2(30)
FLGCI NUMBER(1)
FLGC NUMBER(1)
COL3 NUMBER(1)
FLGCOL33 NUMBER(1)
Query plan of the original select:
1     SQL_ID 51kgr2x36h3y4, child number 0
2     -------------------------------------
3     select g.col1, g.col2 from tab1 g, tab2 part
4     where part.col3 <> 0 and g.col4 = 'PRO3' and g.col2 =
5     part.col5 and g.col7 = -1
6
7     Plan hash value: 2145701647
8
9     ---------------------------------------------------------------------------------------
10     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11     ---------------------------------------------------------------------------------------
12     | 0 | SELECT STATEMENT | | | | 938 (100)| |
13     |* 1 | HASH JOIN | | 22485 | 856K| 938 (17)| 00:00:05 |
14     |* 2 | INDEX FAST FULL SCAN| SYS_C00254422 | 22453 | 504K| 14 (8)| 00:00:01 |
15     |* 3 | TABLE ACCESS FULL | TAB2 | 67458 | 1054K| 920 (16)| 00:00:05 |
16     ---------------------------------------------------------------------------------------
17
18     Predicate Information (identified by operation id):
19     ---------------------------------------------------
20
21     1 - access("G"."COL2"="PART"."COL5")
22     2 - filter(("G"."COL7"=(-1) AND "G"."COL4"='PRO3'))
23     3 - filter("PART"."COL3"<>0)
24
Sql plan of the second quesry:
1     SQL_ID g1hc2xj88sc7x, child number 0
2     -------------------------------------
3     select g.col1, g.col2 from tab1 g, tab2 part where
4     part.col3 <> 0 and g.col4 = 'PRO3' and g.col2 = part.col5
5     and -g.col7 = 1
6
7     Plan hash value: 601419963
8
9     ----------------------------------------------------------------------------------------------
10     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11     ----------------------------------------------------------------------------------------------
12     | 0 | SELECT STATEMENT | | | | 512 (100)| |
13     | 1 | NESTED LOOPS | | 249 | 9711 | 512 (1)| 00:00:03 |
14     |* 2 | INDEX FAST FULL SCAN | SYS_C00254422 | 248 | 5704 | 15 (14)| 00:00:01 |
15     |* 3 | TABLE ACCESS BY INDEX ROWID| TAB2 | 1 | 16 | 2 (0)| 00:00:01 |
16     |* 4 | INDEX UNIQUE SCAN | SYS_C00254336 | 1 | | 1 (0)| 00:00:01 |
17     ----------------------------------------------------------------------------------------------
18
19     Predicate Information (identified by operation id):
20     ---------------------------------------------------
21
22     2 - filter(((-"G"."COL7")=1 AND "G"."COL4"='PRO3'))
23     3 - filter("PART"."COL3"<>0)
24     4 - access("G"."COL2"="PART"."COL5")
25
Index used:
Primary key on tab2 SYS_C00254336:
alter table TAB2
add primary key (COL5)
using index
tablespace name_tablespace;
Primary key on tab1 SYS_C00254422;
alter table TAB1
add primary key (COL1, COL4, COL2, COL7, DTCOL8 )
using index
tablespace name_tablespace;
Message was edited by:
user613483
Message was edited by:
user613483

How to setup a query plan in effective at any time for SP or SQL query?

I have a SP which include a group by SQL statement. It retrieve data from a couple of tables which are over 1G size,
When I run this SP at first time, it take more than 5 minutes to get the result. then I run it again and again, Finally, it become very quick, I can get the result within second.
Not sure why. I guess it is because of query plan.
How to make it running at first time to get result within second? How to force a better best query plan in effective at first time to run the query?
If the engine has better plan in memory, could it be lost at some point? because I have the complain from end user said some times it is fast, sometime it is very slow.
How to resolve this problem?

thanks, kevin. Here is the pesudo query( I modify table name as business rule from my company). you are right, mytab3 is a lookup table.
Select d.stock,i.description,c.categoryname,
Round(IsNull(Sum(d.qty),0),2) AS qty,
From mytab1 d,mytab2 s,invent i,mytab3 c
Where
d.stock != 'param1'
And d.id1 = s.id1    --id1: univarchar(11)
And i.code = c.code   --code:univarchar(2)
And d.stock = i.stock --stock: univarchar(12)
And i.code2 = d.code2 --code2: univarchar(2)
And d.code2 = 'param2'
And s.id2 = 'param3'   --id2: univarchar(6)
Group By c.categoryname,d.stock,i.description
Order By d.stock
here is the query plan when run this query:
The command completed with no results returned
QUERY PLAN FOR STATEMENT 1 (at line 1).
Executed in parallel by coordinating process and 4 worker processes.
    STEP 1
        The type of query is SELECT (into Worktable1).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Executed in parallel by coordinating process and 4 worker processes.
        FROM TABLE
            mytab2
            s
        Nested iteration.
        Index : ind_mytab2 _id2
        Forward scan.
        Positioning by key.
        Keys are:
            id2 ASC
        Executed in parallel with a 4-way hash scan.
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab1
            d
        Nested iteration.
        Index : ind_det_inv
        Forward scan.
        Positioning by key.
        Keys are:
            id1 ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            invent
            i
        Nested iteration.
        Using Clustered Index.
        Index : invent_pk
        Forward scan.
        Positioning by key.
        Keys are:
            stock ASC
            code2 ASC
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab3
            c
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
        Parallel work table merge.
    STEP 2
        The type of query is INSERT.
        The update mode is direct.
        Executed by coordinating process.
        Worktable2 created, in allpages locking mode, for ORDER BY.
        FROM TABLE
            Worktable1.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable2.
    STEP 3
        The type of query is SELECT.
        Executed by coordinating process.
        This step involves sorting.
        FROM TABLE
            Worktable2.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
Total estimated I/O cost for statement 1 (at line 1): 1409882.
The sort for Worktable2 is done in Serial

Grus help needed in finding the queries with Cartesian joins

Hi
I have a reporting tool in which users are allowed to put the joins on the views and add some sub queries that produces a Cartesian product. Is there any tool or way that I can stop the execution of those query before it is being executed for example
Step 1 ) user creates a query
step2 ) user submits it
step 3) by any tool or any check if Cartesian join is found the query execution is stopped and notify the user that the query is not good if no problem executes the query.
I really need help in step 3. I am on 9i release2.
Any help or suggestions will be highly appreciated.

I Agree with Gasparotto, you should limit the resource consume.
You must understand that cartesian join, isn´t always a BAD guy, sometimes you need it.
If your developers are in trouble with handle the join , think about NATURAL JOIN, may be it helps you
Regards
Helio Dias

Merge cartesian join in query plan

Similar Messages

Maybe you are looking for