Cartesian Product, JOIN

Good Morning Everyone,
We have limited knowledge in DB but we have to work according to needed.
Whenever we working on DB, we have challenges in Cartesian Product, JOIN, and more.
We created reports and looks good. We have to test for our data is accuracy and correct.
If you have experience using Toad, Query Builder, Report Builder, please share your experiences.
Thanks in advance,
NY

New Yorker wrote:
Good Morning Everyone,
We have limited knowledge in DB but we have to work according to needed.
Whenever we working on DB, we have challenges in Cartesian Product, JOIN, and more.
We created reports and looks good. We have to test for our data is accuracy and correct.
If you have experience using Toad, Query Builder, Report Builder, please share your experiences.
I believe you should read the following and gather as much as knowledge possible for all above mentioned operators.
http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/toc.htm
HTH
Aman....

Similar Messages

How Cartesian products affects Sybase IQ performance?

In my IQ message log, I have the following message:
I. 04/21 08:28:22. 0001847919 Exception Thrown from dfo_Root.cxx:822, Err# 0, tid 8 origtid 8
I. 04/21 08:28:22. 0001847919 O/S Err#: 0, ErrID: 9216 (df_Exception); SQLCode: -1005015, SQLState: 'QTA15', Severity: 14
I. 04/21 08:28:22. 0001847919 [20169]: The optimizer was unable to find a query plan that avoided cartesian product joins larger than the Max_Cartesian_Result setting
-- (dfo_Root.cxx 822)
I don´t know if
this situation may affect the overall performance
Thank you

Hi Jairo,
As Cartesian product (no join conditions) selects large number of rows, it requires more exec time, temp space (if order by, group by, etc,..) , temp cache, main cache, threads.
To get close estimations about query resources consumtion, you can generate plans without execution using option NoExec.
Query plan option recommended are : quary_name, query_plan, query_detail, query_plan_as_html, query_plan_as_html_directory, dml_options10.
See Generating Query Plans
Note that other resource monitoring options can be enabled/used , but they require effectivel query exection. The info are collected once execution is finished with success. Eg. query_plan_after_run and query_timing.
Regards,
Tayeb.

Joining DB VIEW and Command result in cartesian product

hello,
My SQL query is joining a DB view and a Command(=ad hoc query).
Nonetheless from the results it appears that CR didn't join the views correctly, it returns a cartesian product.
Any idea what the issue could be, I'm using very simple queries.
Thanks in advance

#1 make sure you are linking everything together properly in the "Links" tab of the Database Expert
#2 In my experience, it's just a bad idea to join SQL commands and other tables. I had poor performance issues in my case. (It prevents server side filtering and grouping) My suggestion is to write out the entire thing in the command. If you are pulling from multiple database, write a separate command for each database and link them.

What is the use of Cartesian Product or Cross join?

Dear friends...
I have done with inner join, self join and outer join. But I m getting confused with cross join. I know it used to produce Cartesian product of two table. But I wanted to know what is the use of Cartesian product in real life? In
which situation we can use Cartesian product or cross join? I wanted some real life examples on Cartesian product. Please help me.

Sometimes you get requirement stating that all combinations should be considered and in this scenario CROSS JOIN comes in play.
If you have Products and Stores table, by using CROSS JOIN you can get the combination of all stores and all products and then you can JOIN this result set to other tables.
Please refer: The power of the Cross Join
Cheers,
Vaibhav Chaudhari
[MCTS],
[MCP]

Joins between two tables generating Cartesian product

Hi All,
I am facing an issue in my report in which, I am getting mismatch as the two subsets which I'm joining is resulting in a cartesian product of individual subset's results. I am doing left join to join those two subsets. Please help in resolving
this issue.
Thank you,
Anu.

Hi,
Can you please post your script to see what is causing the cartesian product?
This way it is difficult to help you.
Regards,
Reshma
Please Vote as Helpful if an answer is helpful and/or Please mark Proposed as Answer or Mark As Answer when question is answered

Cartesian Product from in-line queries

I have the following query:
SELECT AUDIT_MONTH, AUDITS, DEFECTS
FROM
select distinct(to_char(AUDIT_DATE,'MM/YY')) as AUDIT_MONTH
from v_safety_audit_records
select count(distinct(AUDIT_ID)) AUDITS
from v_safety_audit_records
group by to_char(AUDIT_DATE,'MM/YY')
select count(KEY_ID) DEFECTS
from v_safety_audit_records
where SUBAREA_ID NOT LIKE '_98'
and SUBAREA_ID NOT LIKE '_99'
group by to_char(AUDIT_DATE,'MM/YY')
but it keeps giving me a cartesian product. Is there a way to re-write this so that I only get the month, the number of audits, and number of defects on a line rather than number of months x number of months worth of lines? I can't seem to get the join conditions worked out... I can re-write this all using views, but as it is for a single report, I'd rather not bother with more views if I can avoid it.
Thanks in advance.

The problem is that the query doesn't return a single row and isn't meant to. I tried:
SELECT
select distinct(to_char(AUDIT_DATE,'MM/YY'))
from v_safety_audit_records
group by to_char(AUDIT_DATE,'MM/YY')
) AUDIT_MONTH,
select count(distinct(AUDIT_ID))
from v_safety_audit_records
group by to_char(AUDIT_DATE,'MM/YY')
) AUDITS,
select count(KEY_ID)
from v_safety_audit_records
where SUBAREA_ID NOT LIKE '_98'
and SUBAREA_ID NOT LIKE '_99'
group by to_char(AUDIT_DATE,'MM/YY')
) DEFECTS
FROM DUAL;
and got "ORA-01427: single-row subquery returns more than one row". It would be a good idea if I only needed it for one month, however.

Cartesian Product in Select

    Hi all!
I need help.
I have this function that launches a Select. My Oracle Grid tells me, when I tune the Select of this function, that there is a Cartesian Product. I understand what a Cartesian Product is, but I fail to find it. Can you help me by pointing out WHERE is the misteke? Thank you!!
P.s. Oracle EE 10.2.0.4 on windows Server 2003 R2 SP2 64Bit
[code]
create or replace
FUNCTION          "ANA_GETVERBALE"
v_VerbaleId      IN NUMBER DEFAULT NULL,
v_Sezione        IN VARCHAR2 DEFAULT NULL,
v_NumeroVerbale IN VARCHAR2 DEFAULT NULL,
v_DataVerbale    IN DATE DEFAULT NULL,
v_TargaVeicolo   IN VARCHAR2 DEFAULT NULL,
v_Serie          IN VARCHAR2 DEFAULT NULL,
v_LoggedUser IN VARCHAR2 DEFAULT NULL
RETURN SYS_REFCURSOR
AS
   cv_1 SYS_REFCURSOR;
BEGIN
OPEN cv_1 FOR
    SELECT
      ANA_M.VerbaleId,
      ANA_M.Sezione,
      ANA_M.NumeroVerbale,
      ANA_M.DataVerbale,
      ANA_M.TargaVeicolo,
      ANA_M.Serie,
      SCH_C.StatoCartellinoId,
      LOV_StatoCartellino.ListOfValueName StatoCartellino,
      sch_c.cartellinoid
    FROM ANA_Materia_Verbale ANA_M
    INNER JOIN SCH_Cartellini SCH_C ON SCH_C.SoggettoId=ana_m.verbaleid AND SCH_C.TipoSoggettoId = SIS_CONSTANTS_PKG.VB
    INNER JOIN SIC_PROFILO_STATO SIC_PSC ON SIC_PSC.STATOID=SCH_C.STATOCARTELLINOID
    INNER JOIN SIC_PROFILI_USERS SIC_PUC ON SIC_PUC.PROFILOID=SIC_PSC.PROFILOID AND SIC_PUC.PERSONALID=v_LoggedUser
    LEFT JOIN TYP_ListOfValues LOV_StatoCartellino ON LOV_StatoCartellino.ListOfValueId = SCH_C.StatoCartellinoId
    WHERE ( v_VerbaleId = SIS_CONSTANTS_PKG.AnyBigint OR ANA_M.VerbaleId = v_VerbaleId )
      AND ( v_Sezione = SIS_CONSTANTS_PKG.AnyString OR REGEXP_LIKE(ANA_M.Sezione, '^' || v_Sezione || '$', 'i') )
      AND ( v_serie = SIS_CONSTANTS_PKG.AnyString OR REGEXP_LIKE(ANA_M.Serie, '^' || v_Serie || '$', 'i') )
      AND ( v_NumeroVerbale = SIS_CONSTANTS_PKG.AnyString OR ANA_M.NumeroVerbale = v_NumeroVerbale )
      AND ( v_DataVerbale = SIS_CONSTANTS_PKG.AnyDateTime OR ANA_M.DataVerbale = v_DataVerbale )
      AND ( v_TargaVeicolo = SIS_CONSTANTS_PKG.AnyString OR REGEXP_LIKE(ANA_M.TargaVeicolo,'^' || v_TargaVeicolo || '$', 'i') );
RETURN cv_1;
END;
[/code]

....ouch... well that explains a LOT!! The real problem was the Oracle Grid SQL_TUNING that warned me that the SELECT contained a CARTESIAN PRODUCT:
Ristruttura SQL
An expensive cartesian product operation was found at line ID 4 of the execution plan.
Consider removing the disconnected table or view from this statement or add a join condition which refers to it.
A cartesian product should be avoided whenever possible because it is an expensive operation and might produce a large amount of data.
with this EXECUTION PLAN:
Operazione
ID riga
Oggetto
Object type
Ordine
Righe
Dimensione (KB)
Costo
Tempo (sec)
Costo CPU
Costo I/O
SELECT STATEMENT
0
13
1
0,091
460
6
116.852.560
452
NESTED LOOPS OUTER
1
12
1
0,091
460
6
116.852.560
452
NESTED LOOPS
2
9
1
0,079
459
6
116.843.328
451
NESTED LOOPS
3
7
2
0,141
457
6
116.826.984
449
MERGE JOIN CARTESIAN
4
4
2
0,102
451
6
116.781.136
443
INDEX FAST FULL SCAN
5
DOCARK.PK_SIC_PROFILI_USERS
INDEX (UNIQUE)
1
1
0,010
2
1
81.903
2
BUFFER SORT
6
3
2
0,082
449
6
116.699.232
441
TABLE ACCESS FULL
7
DOCARK.ANA_MATERIA_VERBALE
TABLE
2
2
0,082
449
6
116.699.232
441
TABLE ACCESS BY INDEX ROWID
8
DOCARK.SCH_CARTELLINI
TABLE
6
1
0,020
3
1
22.924
3
INDEX RANGE SCAN
9
DOCARK.IDX_SCH_CARTELLINI_SOG_TIPO
INDEX
5
1
2
1
15.493
2
INDEX RANGE SCAN
10
DOCARK.PK_SIC_PROFILO_STATO
INDEX (UNIQUE)
8
1
0,009
1
1
8.171
1
TABLE ACCESS BY INDEX ROWID
11
DOCARK.TYP_LISTOFVALUES
TABLE
11
1
0,012
1
1
9.231
1
INDEX UNIQUE SCAN
12
DOCARK.PK_TYP_LISTOFVALUES
INDEX (UNIQUE)
10
1
0
1
1.900
0
So I started trying to REMOVE the Cartesian Product. But first I had to find it! So apparently I shouldn't worry too much...
The real problem is that I have to work with funtions and DBs created by others, so I am not sure what to expect from most of the Functions. Apparently this execution is correct no matter what that the Tunig Advisor says!
Thanks!

Why is LOWER function producing a cartesian merge join, when UPPER doesn't?

Hi there,
I have an odd scenario that I would like to understand correctly...
We have a query that is taking a long time to run on one of our databases, further investigation of the explain plan showed that the query was in fact producing a Cartesian merge join even though there is clearly join criteria specified. I know that the optimiser can and will do this if it is a more efficient way of producing the results, however in this scenario it is producing the Cartesian merge on two unrelated tables and seemingly ignoring the Join condition...
*** ORIGINAL QUERY ***
SELECT count(*)
FROM    srs_sce sce,
            srs_scj scj,
            men_mre mre,
            srs_mst mst,
            cam_smo cam,
            ins_spr spr,
            men_mua mua,
           temp_webct_users u
WHERE sce.sce_scjc = scj.scj_code
AND sce.sce_stuc = mre.mre_code
AND mst.mst_code = mre.mre_mstc
AND mre.mre_mrcc = 'STU'
AND mst.mst_code = mua.mua_mstc
AND cam.ayr_code = sce.sce_ayrc
AND cam.spr_code = scj.scj_sprc
AND spr.spr_code = scj.scj_sprc
-- Ignored Join Condition
AND LOWER(mua.mua_extu) = LOWER(u.login)
AND SUBSTR (sce.sce_ayrc, 1, 4) = '2008'
AND sce.sce_stac IN ('RCE', 'RLL', 'RPD', 'RIN', 'RSAS', 'RHL_R', 'RCO', 'RCI', 'RCA');
*** CARTESIAN EXPLAIN PLAN ***
SELECT STATEMENT CHOOSECost: 83
     20 NESTED LOOPS Cost: 83 Bytes: 176 Cardinality: 1
          18 NESTED LOOPS Cost: 82 Bytes: 148 Cardinality: 1
               15 NESTED LOOPS Cost: 80 Bytes: 134 Cardinality: 1
                    13 NESTED LOOPS Cost: 79 Bytes: 123 Cardinality: 1
                         10 NESTED LOOPS Cost: 78 Bytes: 98 Cardinality: 1
                              7 NESTED LOOPS Cost: 77 Bytes: 74 Cardinality: 1
NOTE: The Cartesian product is performed on the men_mre & temp_webct_users tables not the men_mua mua & temp_webct_users tables specified in the join condition.
                                   4 MERGE JOIN CARTESIAN Cost: 74 Bytes: 32 Cardinality: 1
                                        1 TABLE ACCESS FULL EXETER.TEMP_WEBCT_USERS Cost: 3 Bytes: 6 Cardinality: 1
                                        3 BUFFER SORT Cost: 71 Bytes: 1,340,508 Cardinality: 51,558
                                             2 TABLE ACCESS FULL SIPR.MEN_MRE Cost: 71 Bytes: 1,340,508 Cardinality: 51,558
                                   6 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCE Cost: 3 Bytes: 42 Cardinality: 1
                                        5 INDEX RANGE SCAN SIPR.SRS_SCEI3 Cost: 2 Cardinality: 3
                              9 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCJ Cost: 1 Bytes: 24 Cardinality: 1
                                   8 INDEX UNIQUE SCAN SIPR.SRS_SCJP1 Cardinality: 1
                         12 TABLE ACCESS BY INDEX ROWID SIPR.INS_SPR Cost: 1 Bytes: 25 Cardinality: 1
                              11 INDEX UNIQUE SCAN SIPR.INS_SPRP1 Cardinality: 1
                    14 INDEX UNIQUE SCAN SIPR.SRS_MSTP1 Cost: 1 Bytes: 11 Cardinality: 1
               17 TABLE ACCESS BY INDEX ROWID SIPR.MEN_MUA Cost: 2 Bytes: 14 Cardinality: 1
                    16 INDEX RANGE SCAN SIPR.MEN_MUAI3 Cost: 2 Cardinality: 1
          19 INDEX RANGE SCAN SIPR.CAM_SMOP1 Cost: 2 Bytes: 28 Cardinality: 1                                    After speaking with data experts I realised one of the fields being LOWERed for the join condition generally always had uppercase values so I tried modifying the query to use the UPPER function rather than the LOWER one originally used, in this scenario the query executed in seconds and the Cartesian merge had been eradicated which by all accounts is a good result.
*** WORKING QUERY ***
SELECT count(*)
FROM srs_sce sce,
       srs_scj scj,
       men_mre mre,
       srs_mst mst,
       cam_smo cam,
       ins_spr spr,
       men_mua mua,
       temp_webct_users u
WHERE sce.sce_scjc = scj.scj_code
   AND sce.sce_stuc = mre.mre_code
   AND mst.mst_code = mre.mre_mstc
   AND mre.mre_mrcc = 'STU'
   AND mst.mst_code = mua.mua_mstc
   AND cam.ayr_code = sce.sce_ayrc
   AND cam.spr_code = scj.scj_sprc
   AND spr.spr_code = scj.scj_sprc
-- Working Join Condition
   AND UPPER(mua.mua_extu) = UPPER(u.login)
   AND SUBSTR (sce.sce_ayrc, 1, 4) = '2008'
   AND sce.sce_stac IN ('RCE', 'RLL', 'RPD', 'RIN', 'RSAS', 'RHL_R', 'RCO', 'RCI', 'RCA');
*** WORKING EXPLAIN PLAN ***
SELECT STATEMENT CHOOSECost: 13
     20 SORT AGGREGATE Bytes: 146 Cardinality: 1
          19 NESTED LOOPS Cost: 13 Bytes: 146 Cardinality: 1
               17 NESTED LOOPS Cost: 12 Bytes: 134 Cardinality: 1
                    15 NESTED LOOPS Cost: 11 Bytes: 115 Cardinality: 1
                         12 NESTED LOOPS Cost: 10 Bytes: 91 Cardinality: 1
                              9 NESTED LOOPS Cost: 7 Bytes: 57 Cardinality: 1
                                   6 NESTED LOOPS Cost: 6 Bytes: 31 Cardinality: 1
                                        4 NESTED LOOPS Cost: 5 Bytes: 20 Cardinality: 1
                                             1 TABLE ACCESS FULL EXETER.TEMP_WEBCT_USERS Cost: 3 Bytes: 6 Cardinality: 1
                                             3 TABLE ACCESS BY INDEX ROWID SIPR.MEN_MUA Cost: 2 Bytes: 42 Cardinality: 3
                                                  2 INDEX RANGE SCAN EXETER.TEST Cost: 1 Cardinality: 1
                                        5 INDEX UNIQUE SCAN SIPR.SRS_MSTP1 Cost: 1 Bytes: 11 Cardinality: 1
                                   8 TABLE ACCESS BY INDEX ROWID SIPR.MEN_MRE Cost: 2 Bytes: 26 Cardinality: 1
                                        7 INDEX RANGE SCAN SIPR.MEN_MREI2 Cost: 2 Cardinality: 1
                              11 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCE Cost: 3 Bytes: 34 Cardinality: 1
                                   10 INDEX RANGE SCAN SIPR.SRS_SCEI3 Cost: 2 Cardinality: 3
                         14 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCJ Cost: 1 Bytes: 24 Cardinality: 1
                              13 INDEX UNIQUE SCAN SIPR.SRS_SCJP1 Cardinality: 1
                    16 INDEX RANGE SCAN SIPR.CAM_SMOP1 Cost: 2 Bytes: 19 Cardinality: 1
               18 INDEX UNIQUE SCAN SIPR.INS_SPRP1 Bytes: 12 Cardinality: 1                                    *** RESULT ***
COUNT(*)
83299I am still struggling to understand why this would have worked as to my knowledge the LOWER & UPPER functions are similar enough in function and regardless of that why would one version cause the optimiser to effectively ignore a join condition.
If anyone can shed any light on this for me it would be very much appreciated.
Regards,
Kieron
Edited by: Kieron_Bird on Nov 19, 2008 6:09 AM
Edited by: Kieron_Bird on Nov 19, 2008 6:41 AM

My mistake on the predicate information, was in a rush to run off to a meeting when I posted the entry...
*** UPPER Version of the Explain Plan ***
| Id | Operation                     | Name             | Rows | Bytes | Cost | TQ    |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT              |                   |     1 |   146 |   736 |        |      |            |
|   1 | SORT AGGREGATE               |                   |     1 |   146 |       |        |      |            |
|   2 |   SORT AGGREGATE              |                   |     1 |   146 |       | 86,10 | P->S | QC (RAND) |
|* 3 |    HASH JOIN                  |                   |   241 | 35186 |   736 | 86,10 | PCWP |            |
|* 4 |     HASH JOIN                 |                   |   774 |   105K|   733 | 86,09 | P->P | HASH       |
|* 5 |      HASH JOIN                |                   | 12608 | 1489K|   642 | 86,08 | P->P | BROADCAST |
|   6 |       NESTED LOOPS            |                   | 14657 | 1531K|   491 | 86,07 | P->P | HASH       |
|* 7 |        HASH JOIN              |                   | 14657 | 1359K|   490 | 86,07 | PCWP |            |
|* 8 |         HASH JOIN             |                   | 14371 |   996K|   418 | 86,06 | P->P | HASH       |
|* 9 |          TABLE ACCESS FULL    | SRS_SCE           | 3211 |   106K|   317 | 86,00 | S->P | BROADCAST |
|* 10 |          HASH JOIN            |                   | 52025 | 1879K|   101 | 86,06 | PCWP |            |
|* 11 |           TABLE ACCESS FULL   | MEN_MRE           | 51622 | 1310K|    71 | 86,01 | S->P | HASH       |
| 12 |           INDEX FAST FULL SCAN| SRS_MSTP1         |   383K| 4119K|    30 | 86,05 | P->P | HASH       |
| 13 |         TABLE ACCESS FULL     | SRS_SCJ           |   114K| 2672K|    72 | 86,02 | S->P | HASH       |
|* 14 |        INDEX UNIQUE SCAN      | INS_SPRP1         |     1 |    12 |       | 86,07 | PCWP |            |
| 15 |       TABLE ACCESS FULL       | MEN_MUA           |   312K| 4268K|   151 | 86,03 | S->P | HASH       |
| 16 |      INDEX FAST FULL SCAN     | CAM_SMOP1         |   527K| 9796K|    91 | 86,09 | PCWP |            |
| 17 |     TABLE ACCESS FULL         | TEMP_WEBCT_USERS | 33276 |   194K|     3 | 86,04 | S->P | HASH       |
Predicate Information (identified by operation id):
   3 - access(UPPER("MUA"."MUA_EXTU")=UPPER("U"."LOGIN"))
   4 - access("CAM"."AYR_CODE"="SCE"."SCE_AYRC" AND "CAM"."SPR_CODE"="SCJ"."SCJ_SPRC")
   5 - access("MST"."MST_CODE"="MUA"."MUA_MSTC")
   7 - access("SCE"."SCE_SCJC"="SCJ"."SCJ_CODE")
   8 - access("SCE"."SCE_STUC"="MRE"."MRE_CODE")
   9 - filter(SUBSTR("SCE"."SCE_AYRC",1,4)='2008' AND ("SCE"."SCE_STAC"='RCA' OR "SCE"."SCE_STAC"='RCE' OR
              "SCE"."SCE_STAC"='RCI' OR "SCE"."SCE_STAC"='RCO' OR "SCE"."SCE_STAC"='RHL_R' OR "SCE"."SCE_STAC"='RIN' OR
              "SCE"."SCE_STAC"='RLL' OR "SCE"."SCE_STAC"='RPD' OR "SCE"."SCE_STAC"='RSAS'))
10 - access("MST"."MST_CODE"="MRE"."MRE_MSTC")
11 - filter("MRE"."MRE_MRCC"='STU')
14 - access("SPR"."SPR_CODE"="SCJ"."SCJ_SPRC")
Note: cpu costing is off
40 rows selected.*** LOWER Version of the Explain Plan ***
| Id | Operation                     | Name             | Rows | Bytes | Cost | TQ    |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT              |                   |     1 |   146 |   736 |        |      |            |
|   1 | SORT AGGREGATE               |                   |     1 |   146 |       |        |      |            |
|   2 |   SORT AGGREGATE              |                   |     1 |   146 |       | 88,10 | P->S | QC (RAND) |
|* 3 |    HASH JOIN                  |                   |   257K|    35M|   736 | 88,10 | PCWP |            |
|* 4 |     HASH JOIN                 |                   |   774 |   105K|   733 | 88,09 | P->P | HASH       |
|* 5 |      HASH JOIN                |                   | 12608 | 1489K|   642 | 88,08 | P->P | BROADCAST |
|   6 |       NESTED LOOPS            |                   | 14657 | 1531K|   491 | 88,07 | P->P | HASH       |
|* 7 |        HASH JOIN              |                   | 14657 | 1359K|   490 | 88,07 | PCWP |            |
|* 8 |         HASH JOIN             |                   | 14371 |   996K|   418 | 88,06 | P->P | HASH       |
|* 9 |          TABLE ACCESS FULL    | SRS_SCE           | 3211 |   106K|   317 | 88,00 | S->P | BROADCAST |
|* 10 |          HASH JOIN            |                   | 52025 | 1879K|   101 | 88,06 | PCWP |            |
|* 11 |           TABLE ACCESS FULL   | MEN_MRE           | 51622 | 1310K|    71 | 88,01 | S->P | HASH       |
| 12 |           INDEX FAST FULL SCAN| SRS_MSTP1         |   383K| 4119K|    30 | 88,05 | P->P | HASH       |
| 13 |         TABLE ACCESS FULL     | SRS_SCJ           |   114K| 2672K|    72 | 88,02 | S->P | HASH       |
|* 14 |        INDEX UNIQUE SCAN      | INS_SPRP1         |     1 |    12 |       | 88,07 | PCWP |            |
| 15 |       TABLE ACCESS FULL       | MEN_MUA           |   312K| 4268K|   151 | 88,03 | S->P | HASH       |
| 16 |      INDEX FAST FULL SCAN     | CAM_SMOP1         |   527K| 9796K|    91 | 88,09 | PCWP |            |
| 17 |     TABLE ACCESS FULL         | TEMP_WEBCT_USERS | 33276 |   194K|     3 | 88,04 | S->P | HASH       |
Predicate Information (identified by operation id):
   3 - access(LOWER("MUA"."MUA_EXTU")=LOWER("U"."LOGIN"))
   4 - access("CAM"."AYR_CODE"="SCE"."SCE_AYRC" AND "CAM"."SPR_CODE"="SCJ"."SCJ_SPRC")
   5 - access("MST"."MST_CODE"="MUA"."MUA_MSTC")
   7 - access("SCE"."SCE_SCJC"="SCJ"."SCJ_CODE")
   8 - access("SCE"."SCE_STUC"="MRE"."MRE_CODE")
   9 - filter(SUBSTR("SCE"."SCE_AYRC",1,4)='2008' AND ("SCE"."SCE_STAC"='RCA' OR "SCE"."SCE_STAC"='RCE' OR
              "SCE"."SCE_STAC"='RCI' OR "SCE"."SCE_STAC"='RCO' OR "SCE"."SCE_STAC"='RHL_R' OR "SCE"."SCE_STAC"='RIN' OR
              "SCE"."SCE_STAC"='RLL' OR "SCE"."SCE_STAC"='RPD' OR "SCE"."SCE_STAC"='RSAS'))
10 - access("MST"."MST_CODE"="MRE"."MRE_MSTC")
11 - filter("MRE"."MRE_MRCC"='STU')
14 - access("SPR"."SPR_CODE"="SCJ"."SCJ_SPRC")
Note: cpu costing is off
40 rows selected.As you state something has obviously changed, but nothing obvious has been changed.
We gather statistics via...
exec dbms_stats.gather_schema_stats(ownname => 'USERNAME', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE , degree => 4, granularity => ''ALL'', cascade => TRUE);
We run a script nightly which works out which indexes require a rebuild and rebuild those only it doesn;t just rebuild all indexes.
It would be nice to be able to use the 10g statistics history, but on this instance we aren't yet at that version, hopefully we will be there soon though.
Hope this helps,
Kieron

Ora 00918 normalizing problem using cartesian product

I am using a cartesian product to normalise a table. Is there a better way of doing this to avoid the 00918 error?
Thanks in advance ...
select
/* select clause */
from
z_dvo_proj_milestone_summary t1,
z_dvo_proj_milestone_summary t2
where
/* where clause */
create or replace view z_dvo_proj_milestone_summary as
select
query1.projid
,query1.projname
,query1.projtype
,query1.projcode
,query1.report_month
,query1.report_year
,query1.SubProjID
,query1.DVONUM
,query1.measure_type
,query1.MEASURE
,hier.level0_vosa_prj_type
from
(select
score.project as projid
,srm.name as projname
,hier.level0_vosa_prj_type as projtype
,score.code as projcode
,score.report_month as report_month
,score.report_year as report_year
,CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End as SubProjID
,dvonumtab.dvonum as DVONUM
,typetab.measure_type as measure_Type
,CASE
WHEN (subprojtab.subprojid = 1) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_planned
End
End
WHEN (subprojtab.subprojid = 2) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_planned
End
End
End as MEASURE
from
ODF_CA_PROJSCORE score
left outer join
srm_projects srm on (srm.id = score.project)
left outer join
Z_PROJECT_HIERARCHY hier on (srm.id = hier.level0)
Join
(select 1 as subprojid from dual
union
select 2 as subprojid from dual) subprojtab on (1=1)
/* There will be 11 measures here eventually */
Join
(select 'baseline' as measure_type from dual
union
select 'planned' as measure_type from dual) typetab on (1=1)
Join
(select 1 as dvonum from dual
union
select 2 as dvonum from dual) dvonumtab on (1=1)
WHERE
(CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End) IS NOT NULL) query1
left outer join Z_PROJECT_HIERARCHY hier
on (query1.SubProjID = hier.level0)

I am using a cartesian product to normalise a table. Is there a better way of doing this to avoid the 00918 error?
Thanks in advance ...
select
/* select clause */
from
z_dvo_proj_milestone_summary t1,
z_dvo_proj_milestone_summary t2
where
/* where clause */
create or replace view z_dvo_proj_milestone_summary as
select
query1.projid
,query1.projname
,query1.projtype
,query1.projcode
,query1.report_month
,query1.report_year
,query1.SubProjID
,query1.DVONUM
,query1.measure_type
,query1.MEASURE
,hier.level0_vosa_prj_type
from
(select
score.project as projid
,srm.name as projname
,hier.level0_vosa_prj_type as projtype
,score.code as projcode
,score.report_month as report_month
,score.report_year as report_year
,CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End as SubProjID
,dvonumtab.dvonum as DVONUM
,typetab.measure_type as measure_Type
,CASE
WHEN (subprojtab.subprojid = 1) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_planned
End
End
WHEN (subprojtab.subprojid = 2) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_planned
End
End
End as MEASURE
from
ODF_CA_PROJSCORE score
left outer join
srm_projects srm on (srm.id = score.project)
left outer join
Z_PROJECT_HIERARCHY hier on (srm.id = hier.level0)
Join
(select 1 as subprojid from dual
union
select 2 as subprojid from dual) subprojtab on (1=1)
/* There will be 11 measures here eventually */
Join
(select 'baseline' as measure_type from dual
union
select 'planned' as measure_type from dual) typetab on (1=1)
Join
(select 1 as dvonum from dual
union
select 2 as dvonum from dual) dvonumtab on (1=1)
WHERE
(CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End) IS NOT NULL) query1
left outer join Z_PROJECT_HIERARCHY hier
on (query1.SubProjID = hier.level0)

What is a cartesian product why we need it and where we need it

Hi,
One of my interview they asked this question
Can any one please tell detail about it.
Thanks
Kalpana

>
what is a cartesian product
>
A cartesian join is when you do not specify any join condition between tables.
So for two tables A and B the result is that every row of table B is appended to every row of table A.
If there are 10 rows in Table A and 20 rows in Table b there will be 200 rows in the result set and each row will contain every column from table A and every column from table b unless you specify specific columns.
See Cartesian Products in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/queries006.htm
>
Cartesian Products
If two tables in a join query have no join condition, then Oracle Database returns their Cartesian product. Oracle combines each row of one table with each row of the other. A Cartesian product always generates many rows and is rarely useful. For example, the Cartesian product of two tables, each with 100 rows, has 10,000 rows. Always include a join condition unless you specifically need a Cartesian product. If a query joins three or more tables and you do not specify a join condition for a specific pair, then the optimizer may choose a join order that avoids producing an intermediate Cartesian product.
>
As for when? In earlier versions of Oracle I would use a cartesian join when creating report ready data tables and there needed to be data for every report period. One example is writing a Crystal Report (now business objects) to report sales for 2011 and you want the report to have a section for each month even if there was no data for that month.
Then we would use a cartesian join on a date table that had 12 records (one for each month) with totals of zero. This would make sure that there was at lease one summary record for each month so that every month would show up on the report even if we only had data for March.

What is Cartesian product in Oracle?

"Cartesian product" often appear in the Oracle book, what is it?

Hi Ashish,
Actually it is the other way round. Actually it depends the way you see.. But normal it is stated this way.If you want to get data from two tables depending on one condition you use join. If you don't give a condition for joining it displays the cartesian product of the two tables.
If the condition for joining the table is equality sign then it is called equi join else if it is > or < then non-equi join.
Similary you have outer join, self join(joining table with itself based on a condition), inner join ,etc.
To learn more about joins take a look at the following link
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/queries7.htm
Regards,
Anupama

View creating Cartesian Product.. why....

i am joining 5 tables in a view.. dont know exactly why it is creating Cartesian product.
Below is the query:
PROMPT CREATE OR REPLACE VIEW xxpd_ozf_aff_err_int_v
CREATE OR REPLACE VIEW xxpd_ozf_aff_err_int_v (
row_id,
source_system,
source_process_id,
source_process_date,
ora_process_id,
soa_instance_id,
customer_record_id,
process_status,
insert_update_flag,
process_stage,
process_start_time,
process_end_time,
error_code,
error_message,
error_type,
customer_process_status,
supplier_process_status,
customer_level,
source_customer_ref,
customer_class_code,
customer_type,
business_model_code,
source_parent_cust_ref,
source_parent_cust_type,
customer_name,
account_status,
customer_alias,
person_flag,
person_first_name,
person_last_name,
tax_reg_number,
tax_reg_type,
customer_id,
account_number,
party_id,
party_type,
party_number,
supplier_id,
affiliate_type,
check_payable_name,
payable_flag,
approved_flag,
primary_site,
site_status,
purpose,
address1,
address2,
address3,
address4,
city,
county,
state,
province,
postal_code,
country,
cust_acct_site_id,
party_site_id,
location_id,
reportable_1099,
tax_type_1099,
primary_contact,
contact_role,
contact_status,
first_name,
last_name,
salutation,
job_title,
email_address,
phone_line_type,
phone_number,
phone_extension,
phone_area_code,
phone_country_code,
preferred_language,
customer_profile_class,
profile_acct_status,
profile_active_status,
account_status_reason,
invoice_type
) AS
SELECT acct.ROWID row_id,
CTRL.SOURCE_SYSTEM,
CTRL.SOURCE_PROCESS_ID,
CTRL.SOURCE_PROCESS_DATE,
CTRL.ORA_PROCESS_ID,
CTRL.SOA_INSTANCE_ID,
ACCT.CUSTOMER_RECORD_ID,
CTRL.PROCESS_STATUS,
CTRL.INSERT_UPDATE_FLAG,
CTRL.PROCESS_STAGE,
CTRL.PROCESS_START_TIME,
CTRL.PROCESS_END_TIME,
CTRL.ERROR_CODE,
CTRL.ERROR_MESSAGE,
--ACCOUNT TABLE
ACCT.ERROR_TYPE,
ACCT.CUSTOMER_PROCESS_STATUS,
ACCT.SUPPLIER_PROCESS_STATUS,
ACCT.CUSTOMER_LEVEL,
ACCT.SOURCE_CUSTOMER_REF,
ACCT.CUSTOMER_CLASS_CODE,
ACCT.CUSTOMER_TYPE,
ACCT.BUSINESS_MODEL_CODE,
ACCT.SOURCE_PARENT_CUST_REF,
ACCT.SOURCE_PARENT_CUST_TYPE,
ACCT.CUSTOMER_NAME,
ACCT.ACTIVE_STATUS ACCOUNT_STATUS,
ACCT.CUSTOMER_ALIAS,
ACCT.PERSON_FLAG,
ACCT.PERSON_FIRST_NAME,
ACCT.PERSON_LAST_NAME,
ACCT.TAX_REG_NUMBER,
ACCT.TAX_REG_TYPE,
ACCT.CUSTOMER_ID,
ACCT.ACCOUNT_NUMBER,
ACCT.PARTY_ID,
ACCT.PARTY_TYPE,
ACCT.PARTY_NUMBER,
ACCT.SUPPLIER_ID,
ACCT.AFFILIATE_TYPE,
ACCT.CHECK_PAYABLE_NAME,
ACCT.PAYABLE_FLAG,
ACCT.APPROVED_FLAG,
--SITE TABLE
SITE.PRIMARY_FLAG PRIMARY_SITE,
SITE.ACTIVE_STATUS SITE_STATUS,
SITE.PURPOSE,
SITE.ADDRESS1,
SITE.ADDRESS2,
SITE.ADDRESS3,
SITE.ADDRESS4,
SITE.CITY,
SITE.COUNTY,
SITE.STATE,
SITE.PROVINCE,
SITE.POSTAL_CODE,
SITE.COUNTRY,
SITE.CUST_ACCT_SITE_ID,
SITE.PARTY_SITE_ID,
SITE.LOCATION_ID,
SITE.REPORTABLE_1099,
SITE.TAX_TYPE_1099,
--CONTACT
CONT.PRIMARY_FLAG PRIMARY_CONTACT,
CONT.CONTACT_ROLE,
CONT.ACTIVE_STATUS CONTACT_STATUS,
CONT.FIRST_NAME,
CONT.LAST_NAME,
CONT.SALUTATION,
CONT.JOB_TITLE,
CONT.EMAIL_ADDRESS,
CONT.PHONE_LINE_TYPE,
CONT.PHONE_NUMBER,
CONT.PHONE_EXTENSION,
CONT.PHONE_AREA_CODE,
CONT.PHONE_COUNTRY_CODE,
CONT.PREFERRED_LANGUAGE,
--PRO
PRFL.CUSTOMER_PROFILE_CLASS,
PRFL.ACCOUNT_STATUS PROFILE_ACCT_STATUS,
PRFL.ACTIVE_STATUS PROFILE_ACTIVE_STATUS,
PRFL.ACCOUNT_STATUS_REASON,
PRFL.INVOICE_TYPE
FROM XXEX_AR_CUST_INT_CTRL_T CTRL,
XXEX_AR_CUST_ACCT_INT_T ACCT,
XXEX_AR_CUST_SITE_INT_T SITE,
XXEX_AR_CUST_CONTACT_INT_T CONT,
XXEX_AR_CUST_PROFILE_INT_T PRFL
WHERE CTRL.ORA_PROCESS_ID = ACCT.ORA_PROCESS_ID
AND ACCT.CUSTOMER_RECORD_ID = SITE.CUSTOMER_RECORD_ID
AND SITE.CUSTOMER_RECORD_ID = CONT.CUSTOMER_RECORD_ID
AND CONT.CUSTOMER_RECORD_ID = PRFL.CUSTOMER_RECORD_ID
AND acct.Supplier_process_status = 'E'
How i should join the 6 tables..

Rashmi Gupta wrote:
No all table have records corresponding to each customer ID... But what if one of the table has 1 row..?
I checked the result.. there is a Cartesian product.
Customer_Record_ID is unique identifier in 4 tables -
XXEX_AR_CUST_ACCT_INT_T ACCT,
XXEX_AR_CUST_SITE_INT_T SITE,
XXEX_AR_CUST_CONTACT_INT_T CONT,
XXEX_AR_CUST_PROFILE_INT_T PRFL
XXEX_AR_CUST_INT_CTRL_T CTRL and XXEX_AR_CUST_ACCT_INT_T ACCT tables have ora_process_id column common so joined between them.
We dont use primary keys in Interface tables.. we are just using unique indentifier
Edited by: Rashmi Gupta on Jan 30, 2012 5:58 AMAbove is a very well worded version of what I was getting around to, but in the mean time I've been distracted by your "we don't use primary keys"...when you say "unique identifier" please tell me you mean "unique constraint" ?

Want to avoid cartesian Product but cannot avoid it some how.

Hi,
I am using oracle 10G .
trying to draft a query which is resulting in absurd results.
select i.corr_acc_no, sum(amtsign.amount_6) from item i,
(select corr_Acc_no,flag_2,decode(fund_code,'C',amount_6,amount_6*-1) amount_6 from item
where corr_AcC_no in (select corr_acc_no from bank where local_Acc_no in ('MBL-SEG-NZD'))and flag_2=0) AmtSign
where i.corr_acc_no=amtsign.corr_acc_no
and i.flag_2=0
group by i.corr_acc_no
Basically the inner query, which i am using as the second table in the join, gives 13 results. I want to sum the amount_6 field in main select clause which I want to get from results of
(select corr_Acc_no,flag_2,decode(fund_code,'C',amount_6,amount_6*-1) amount_6 from item
where corr_AcC_no in (select corr_acc_no from bank where local_Acc_no in ('MBL-SEG-NZD'))and flag_2=0)
The sum took too much time so i drafted simple query to check how many rows are returned by removing sum and i noticed it gives a Cartesian product with 169 rows instead of just 13. I have 2 join conditions but the value for corr_Acc_no is same for all 13 rows, i can't use amount_6 as join becuase i am changing it's sign in the inner query. Please advise.

Thanks to both of you. @LakmalRajapakse your answer is bang on right. I did the same way after I posted this. I realized there's no point joining item with itself when I can get it done in single query. It's just that I was having hard time with 'Case' in select to get whatever I want,so I tried this logic. But then gave a try to decode, it worked. Thanks anyways.

CARTESIAN PRODUCT problem

hello,
i m trying to find the difference for calculating the DIFFENCE IN STOCK FOR OPC,PPC,CLINKER BY USING FOLLOWING SQL-QUERY
SELECT TO_CHAR(a.dateofmtrl,'YYYY') YEAR,
SUM(a.rm1) - SUM(b.rm1) - SUM(c.rm1) OPC,
SUM(a.rm2) - SUM(b.rm2) - sum(c.rm2) PPC,
SUM(a.rm3) - SUM(b.rm3) - sum(c.rm3) CLINKER
FROM rawmtrl_graph a
INNER JOIN rawmtrl_graph b ON TO_CHAR(a.dateofmtrl,'YYYY') =TO_CHAR(B.dateofmtrl,'YYYY')
INNER JOIN rawmtrl_graph c ON TO_CHAR(a.dateofmtrl,'YYYY') =TO_CHAR(C.dateofmtrl,'YYYY')
WHERE a.mtrl_flag='P'
AND b.mtrl_flag='D'
AND c.mtrl_flag='CS'
GROUP BY TO_CHAR(a.dateofmtrl,'YYYY')
BUT IT IS GIVING CARTESIAN PRODUCT...
HOW TO MODIFY THE QUERY FOR FINDING EXACT FIGURE??????
THANKS IN ADVENCE FOR ANY HELP.....

Hi,
please always put your code between two lines starting with {noformat}{noformat}.
Additionally when you put insert statement put them entirely and not copying from one table we don't have.
Here the way to get the result you want:SELECT EXTRACT(YEAR FROM dateofmtrl) yr
, SUM(CASE mtrl_flag WHEN 'P' THEN rm1 ELSE -rm1 END) AS opc
, SUM(CASE mtrl_flag WHEN 'P' THEN rm2 ELSE -rm2 END) AS ppc
, SUM(CASE mtrl_flag WHEN 'P' THEN rm3 ELSE -rm3 END) AS clinker
FROM rawmtrlgraph
GROUP BY EXTRACT(YEAR FROM dateofmtrl);
YR OPC PPC CLINKER
2011 50 54 55
2012 -49 -3 -11
Regards.
Al

Hint ordered and cartesian product

I have a query which needs to be tuned.
The initial Query does not show cartesian product in the plan , when I change the order of the tables in the from clause ( I have placed the least # of rows first and the most rows tables in the last) and I get MERGE JOIN CARTESIAN product the where clause remaining the same and the cost escalates from 7180 to 454M .
This happens with ordered hint.

ranjus wrote:
I have a query which needs to be tuned.
The initial Query does not show cartesian product in the plan , when I change the order of the tables in the from clause ( I have placed the least # of rows first and the most rows tables in the last) and I get MERGE JOIN CARTESIAN product the where clause remaining the same and the cost escalates from 7180 to 454M .
This happens with ordered hint.Let's take a look at this with a simple test case. Assume that:
* Table T1 contains 10,000 rows
* Table T2 contains 100 rows
* Table T3 contains 100,000 rows
* Table T4 contains 10 rows
You have the following query:
SELECT
T1.C1,
T2.C2,
T3.C3,
T4.C4
FROM
T1,
T2,
T3,
T4
WHERE
T1.C1=T2.C2
AND T2.C2=T3.C2
AND T3.C3=T4.C3;In the above, you can see that in the WHERE clause:
* Table T1 is joined to table T2
* Table T2 is joined to tables T1 and T3
* Table T3 is joined to tables T2 and T4
* Table T4 is joined to table T3
What it sounds like you are trying to do is something like this based on the number of rows in the tables:
SELECT /*+ ORDERED */
T1.C1,
T2.C2,
T3.C3,
T4.C4
FROM
T4,
T2,
T1,
T3
WHERE
T1.C1=T2.C2
AND T2.C2=T3.C2
AND T3.C3=T4.C3;In the above, we are forcing Oracle's optimizer to join tables T4 and T2 - but there is no direct relationship between the two tables described in the WHERE clause. In such a case, Oracle's optimizer will be forced to perform a Cartesian join between tables T4 and T2. Next, table T1 has a relationship defined in the WHERE clause with table T2, so that join would not result in a Cartesian product. Finally, table T3 has a relationship between tables T2 and T4, so that would not result in a Cartesian product.
Going back to this example, assume that table T4 contained a single row. The execution plan will still show a Cartesian join, but that Cartesian join is no worse than a nested loops join because there is a single row in one of the row sources.
In short, think about what you are attempting to force the optimizer to do. You cannot always join in the order of increasing row cardinality estimates - it simply does not make sense to try in some cases.
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Cartesian Product, JOIN

Similar Messages

Maybe you are looking for