Cartesian Or NOT

Hello All,
When I run following query, I got 24 row.SELECT * FROM CLASSES, COURSES, REGISTRATIONS, USERS
WHERE (
(CLASSES.COURSE_ID = COURSES.COURSE_ID)
AND (REGISTRATIONS.CLASS_ID = CLASSES.CLASS_ID)
AND (REGISTRATIONS.USER_ID = USERS.USER_ID)
When I add 2 tables, I got 52 records. SELECT *
FROM CLASSES, COURSES, REGISTRATIONS, USERS, LOCATIONS_RF, LOCATIONS
WHERE ((CLASSES.COURSE_ID = COURSES.COURSE_ID)
AND (REGISTRATIONS.CLASS_ID = CLASSES.CLASS_ID)
AND (REGISTRATIONS.USER_ID = USERS.USER_ID)
and (CLASSES.CLASS_ID = LOCATIONS.CLASS_ID)
AND (LOCATIONS.LOC_ID = LOCATIONS_RF.LOC_ID )
Any help!
Thanks,
NY

If LOCATION is child of CLASSES then a single record of classes can be connected to two records of locations (say LOC1 and LOC2).
Each of these two records of location can be connected to one record of locations_rf, say LOC_RF1 and LOC_RF2.
Hence starting for a single record of classes you can get two distinct records of locations_rf, which one would you like to display?
1) Both of them in a single string? Then is a string aggregation problem there are many exaples on this forum, try to search
2) Both of them in different records? then the query is already ok
3) one of them based on a choise algorithm? Then let us know the algorithm
4) One of them random? You can write something like this:
SELECT col1, col2, col3, col4, min(locations_rf.somecolumn)
FROM CLASSES, COURSES, REGISTRATIONS, USERS, LOCATIONS_RF, LOCATIONS
WHERE ((CLASSES.COURSE_ID = COURSES.COURSE_ID)
AND (REGISTRATIONS.CLASS_ID = CLASSES.CLASS_ID)
AND (REGISTRATIONS.USER_ID = USERS.USER_ID)
and (CLASSES.CLASS_ID = LOCATIONS.CLASS_ID)
AND (LOCATIONS.LOC_ID = LOCATIONS_RF.LOC_ID )
group by col1, col2, col3, col4
)Max
http://oracleitalia.wordpress.com

Similar Messages

  • Geodetic and not

    Hello,
    Does anyone have a good reference that explains the differences between geodetic and non-geodetic coordinate systems? I've read the spatial user's guide and would like to see a more detailed explanation of the differences and rationale behind deciding to use one or the other.
    Regards,
    Steven Pierce

    Steven,
    Probably the easiest way to think about these two concepts is:
    - Non-geodetic data, or projected data is the kind of data you see on flat maps. In otherwords, at the very center of a flat map is where you find the MOST precision. Projections have been around for a LONG time and are typically used for things like State planes, golf courses, airports, cities, topo-maps - where the area(s) you are analyzing tends to be relatively small (when compared to a large state, country, continent, etc.). Non-geodetic coordinate systems typically follow cartesian scales (not longitude/latitude).
    - Geodetic coordinate systems are attempts to model the Earth's shape, taking into account the curvature of a relatively large, oblate ellipsoid - these are made up of longitudes/latitudes. Geodetic data is typically used for large areas like large states, countries, continents etc. The reason: on a flat map, or a projection, there can be quite a bit of distortion as you move from the center. On the other hand, geodetic systems tend to be uniform in their accuracy.
    Today, many people tend to use geodetic coordinate systems for newer projects as there are some pretty accurate systems out there and if you are focusing on one area in particular (like North America) there will be no need to mix and match other State plane coordinate systems. For instance, you will see a lot of Oracle SRIDs like 8307 and 8265 - which are both based on geodetic coordinate systems. However, no matter what you choose to develop with, the nice thing about Oracle10g Locator/Spatial is that it can transform between any two coordinate systems out there. Hope this helps.
    -Justin

  • 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?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Expecting a cartesian join but did not get 1 (try to understand what is hap

    Hello Oracle XML DB gurus,
    I have successfully registered my schemas and inserted about 10,000 XML documents into the repository. Now I need to start reporting on the data that is in the documents. Following is a simplified form of my set-up.
    I have a table that contain a XML_TYPE column that is schema based.
    I will call the table TEST_REF it has two columns: ID number (PK) and XML_DOC which is of the foo schema.
    foo schema has the following structure (foo is unbounded).
    <DataSet>
    <fooList>
    <foo>
    <val1></val1>
    <val2></val2>
    </foo>
    <foo>
    <val1></val1>
    <val2></val2>
    </foo>
    </fooList>
    </DataSet>
    What I would like to do is select the XML document that I want to extract data from using the ID column. After that I wanted to be able to select all of the data values in /DataSet/fooList/foo from that document (val1 & val2).
    I was able to do just that using the following query. However, I do not understand why the following query does not give me a cartesian product when I try to operate on mulitple documents. I'm actually getting exactly what I want, which are the individual data values from each document. I just need to understand what is going on. Does the table() function when used in this fashion perform a inner join for you? I hope this make sense.
    select doc.id, extractvalue(Column_value,'/foo/val1') as VALUE1,
    extractvalue(Column_value,'/foo/val2') as VALUE2
    from test_ref doc,
    table(XMLSequence(extract(doc.XML_DOC,'/DataSet/fooList/foo'))) foobar
    where doc.id ='1'
    ------------------------ second where causes the I thought would cause a cartesian join--------------------
    where doc.id in (1,2)
    Sample data and results when using second where clause:
    ID=1
    <DataSet>
    <fooList>
    <foo>
    <val1>2</val1>
    <val2>22</val2>
    </foo>
    <foo>
    <val1>4</val1>
    <val2>44</val2>
    </foo>
    </fooList>
    </DataSet>
    ID=2
    <DataSet>
    <fooList>
    <foo>
    <val1>1</val1>
    <val2>11</val2>
    </foo>
    <foo>
    <val1>3</val1>
    <val2>33</val2>
    </foo>
    </fooList>
    </DataSet>
    Results:
    ID Value1 Value2
    1 2 22
    1 4 44
    2 1 11
    2 3 33
    If what I'm asking does not make sense please let me know. I'm a newbe with this Oracle XML DB stuff. However, I really like what I have seen so far!
    Thanks in advance
    Derrick

    It's a correlated join...

  • Best performance in a cartesian product

    i've got a select that needs a cartesian product.
    ex:
    SELECT NVL(a.year,cp.year) year, NVL(a.month,cp.month), NVL(a.value,0) value
    FROM
    (select year, month from year, month) cp, values a
    WHERE cp.year = a.year(+) AND cp.month = a.month(+)
    i have to show all records possible even if they don't have any values on the table.
    In the beginning with fewer values, it ran OK.... but now with a lot more it begins to take a little longer (about 10 times longer).
    What is the best way to improve this kind of selects???
    Thank you.

    Best Case :
    No one shold be in red color in analysis is the best runtime.
    All should be in Green.
    or
    OK Case :
    Database level - Red is not acceptable
    ABAP Level - Red can be accepted and can be a good runtime.
    System Level - Red is not acceptable.
    Worst Case:
    All are in Red Color

  • 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

  • Nested subQuery results are not being used by Oracle 10g

    Hello, I'm doing the follow query that has a Nested subquery, The explain plan is showing me that Oracle is doing a INDEX FULL SCAN, but I don't understand why?
    select *
    from rdbmx.resources_vt r
    , rdbmx.rsrc_case_qpmcsis_x_vn rad
    where (rad.resource_id,rad.resource_tp) in (
    select t.item_id
    , t.item_tp
    from rdbmx_site.att_hierarchy_level_vw t
    where t.rootitem_id = r.resource_id)
    and r.resource_id =3780
    and r.resource_tp ='BITUMENPRODUCTION'
    and rad.CASE_ID = 599
    and rad.CASE_TP = 'MEASURED'
    and rad.property_nm ='Liquid Volume Flow'
    and rad.qualifier_nm='n/a'
    ATT_HIERARCHY_LEVEL_VW is a complex view and RSRC_CASE_QPMCSIS_X_VN is a view with a UNION ALL.
    The explain plan I'm getting from above query is the follow:
    If you can see on RSRC_CASE_QPMCSI_X_VN vies Oracle is doing a INDEX FULL SCAN over RESOURCE table instead of INDEX RANGE SCAN but I don't undestand why because I'm providing the right values in order to use the right indexes for ORACLE 10gR2. I made a 10053 trace and look seem that oracle is not using the values from the nested query in order to get the better way to pull the information.
    SELECT STATEMENT, GOAL = ALL_ROWS     Id=0     Position=4917          Cost=4917     Cardinality=1     Bytes=21968
    HASH JOIN     Id=1     Position=1          Cost=4917     Cardinality=1     Bytes=21968
    NESTED LOOPS     Id=2     Position=1          Cost=560     Cardinality=1     Bytes=170
    TABLE ACCESS BY INDEX ROWID     Id=3     Position=1     Object name=RESOURCES     Cost=2     Cardinality=1     Bytes=115
    INDEX UNIQUE SCAN     Id=4     Position=1     Object name=RESOURCES_PK     Cost=1     Cardinality=1     
    SORT UNIQUE     Id=5     Position=2          Cost=558     Cardinality=1     Bytes=55
    VIEW     Id=6     Position=1     Object name=ATT_HIERARCHY_LEVEL_VW     Cost=558     Cardinality=1     Bytes=55
    SORT UNIQUE     Id=7     Position=1          Cost=558     Cardinality=3353     Bytes=1181117
    UNION-ALL     Id=8     Position=1                    
    SORT UNIQUE     Id=9     Position=1          Cost=3     Cardinality=1     Bytes=19
    INDEX RANGE SCAN     Id=10     Position=1     Object name=ATTACHITEM_PK     Cost=2     Cardinality=1     Bytes=19
    TABLE ACCESS BY INDEX ROWID     Id=11     Position=2     Object name=ATTACHITEM     Cost=4     Cardinality=43     Bytes=2623
    INDEX RANGE SCAN     Id=12     Position=1     Object name=ATTACHITEM_F3     Cost=2     Cardinality=43     
    NESTED LOOPS     Id=13     Position=3          Cost=5     Cardinality=61     Bytes=6283
    INDEX RANGE SCAN     Id=14     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=15     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=16     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=17     Position=4          Cost=10     Cardinality=87     Bytes=12615
    NESTED LOOPS     Id=18     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=19     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=20     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=21     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=22     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=23     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=24     Position=5          Cost=17     Cardinality=124     Bytes=23188
    NESTED LOOPS     Id=25     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=26     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=27     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=28     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=29     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=30     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=31     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=32     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=33     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=34     Position=6          Cost=27     Cardinality=176     Bytes=40304
    NESTED LOOPS     Id=35     Position=1          Cost=17     Cardinality=124     Bytes=20832
    NESTED LOOPS     Id=36     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=37     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=38     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=39     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=40     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=41     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=42     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=43     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=44     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=45     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=46     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=47     Position=7          Cost=41     Cardinality=251     Bytes=68021
    NESTED LOOPS     Id=48     Position=1          Cost=27     Cardinality=176     Bytes=36960
    NESTED LOOPS     Id=49     Position=1          Cost=17     Cardinality=124     Bytes=20832
    NESTED LOOPS     Id=50     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=51     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=52     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=53     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=54     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=55     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=56     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=57     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=58     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=59     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=60     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=61     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=62     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=63     Position=8          Cost=60     Cardinality=356     Bytes=111428
    NESTED LOOPS     Id=64     Position=1          Cost=41     Cardinality=251     Bytes=63252
    NESTED LOOPS     Id=65     Position=1          Cost=27     Cardinality=176     Bytes=36960
    NESTED LOOPS     Id=66     Position=1          Cost=17     Cardinality=124     Bytes=20832
    NESTED LOOPS     Id=67     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=68     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=69     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=70     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=71     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=72     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=73     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=74     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=75     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=76     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=77     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=78     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=79     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=80     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=81     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=82     Position=9          Cost=88     Cardinality=507     Bytes=179985
    NESTED LOOPS     Id=83     Position=1          Cost=60     Cardinality=356     Bytes=104664
    NESTED LOOPS     Id=84     Position=1          Cost=41     Cardinality=251     Bytes=63252
    NESTED LOOPS     Id=85     Position=1          Cost=27     Cardinality=176     Bytes=36960
    NESTED LOOPS     Id=86     Position=1          Cost=17     Cardinality=124     Bytes=20832
    NESTED LOOPS     Id=87     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=88     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=89     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=90     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=91     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=92     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=93     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=94     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=95     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=96     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=97     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=98     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=99     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=100     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=101     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=102     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=103     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=104     Position=10          Cost=128     Cardinality=721     Bytes=286237
    NESTED LOOPS     Id=105     Position=1          Cost=88     Cardinality=507     Bytes=170352
    NESTED LOOPS     Id=106     Position=1          Cost=60     Cardinality=356     Bytes=104664
    NESTED LOOPS     Id=107     Position=1          Cost=41     Cardinality=251     Bytes=63252
    NESTED LOOPS     Id=108     Position=1          Cost=27     Cardinality=176     Bytes=36960
    NESTED LOOPS     Id=109     Position=1          Cost=17     Cardinality=124     Bytes=20832
    NESTED LOOPS     Id=110     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=111     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=112     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=113     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=114     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=115     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=116     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=117     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=118     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=119     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=120     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=121     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=122     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=123     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=124     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=125     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=126     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=127     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=128     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    NESTED LOOPS     Id=129     Position=11          Cost=174     Cardinality=1026     Bytes=450414
    HASH JOIN     Id=130     Position=1          Cost=117     Cardinality=721     Bytes=272538
    NESTED LOOPS     Id=131     Position=1          Cost=88     Cardinality=507     Bytes=170352
    NESTED LOOPS     Id=132     Position=1          Cost=60     Cardinality=356     Bytes=104664
    NESTED LOOPS     Id=133     Position=1          Cost=41     Cardinality=251     Bytes=63252
    NESTED LOOPS     Id=134     Position=1          Cost=27     Cardinality=176     Bytes=36960
    NESTED LOOPS     Id=135     Position=1          Cost=17     Cardinality=124     Bytes=20832
    NESTED LOOPS     Id=136     Position=1          Cost=10     Cardinality=87     Bytes=10962
    NESTED LOOPS     Id=137     Position=1          Cost=5     Cardinality=61     Bytes=5124
    INDEX RANGE SCAN     Id=138     Position=1     Object name=ATTACHITEM_X1     Cost=2     Cardinality=43     Bytes=1806
    TABLE ACCESS CLUSTER     Id=139     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=140     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=141     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=142     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=143     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=144     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=145     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=146     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=147     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=148     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=149     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=150     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    TABLE ACCESS CLUSTER     Id=151     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=42
    INDEX UNIQUE SCAN     Id=152     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    INDEX FAST FULL SCAN     Id=153     Position=2     Object name=ATTACHITEM_X1     Cost=28     Cardinality=11318     Bytes=475356
    TABLE ACCESS CLUSTER     Id=154     Position=2     Object name=ATTACHITEM     Cost=1     Cardinality=1     Bytes=61
    INDEX UNIQUE SCAN     Id=155     Position=1     Object name=ITEMCLUSTER_CLK     Cost=0     Cardinality=1     
    VIEW     Id=156     Position=2     Object name=RSRC_CASE_QPMCSIS_X_VN     Cost=4356     Cardinality=2     Bytes=43596
    UNION-ALL     Id=157     Position=1                    
    NESTED LOOPS     Id=158     Position=1          Cost=3730     Cardinality=1     Bytes=561
    NESTED LOOPS     Id=159     Position=1          Cost=3729     Cardinality=1     Bytes=475
    HASH JOIN     Id=160     Position=1          Cost=3727     Cardinality=1     Bytes=372
    TABLE ACCESS BY INDEX ROWID     Id=161     Position=1     Object name=RSRCTP_QPMCS     Cost=45     Cardinality=198     Bytes=13662
    INDEX RANGE SCAN     Id=162     Position=1     Object name=RSRCTP_QPMCS_F6     Cost=2     Cardinality=198     
    MERGE JOIN CARTESIAN     Id=163     Position=2          Cost=3682     Cardinality=101     Bytes=30603
    NESTED LOOPS     Id=164     Position=1          Cost=3682     Cardinality=101     Bytes=28684
    HASH JOIN     Id=165     Position=1          Cost=3682     Cardinality=102     Bytes=27030
    TABLE ACCESS BY INDEX ROWID     Id=166     Position=1     Object name=RESOURCES     Cost=2692     Cardinality=92717     Bytes=7973662
    INDEX FULL SCAN     Id=167     Position=1     Object name=RESOURCES_X1     Cost=196     Cardinality=92717     
    TABLE ACCESS FULL     Id=168     Position=2     Object name=RSRC_CASE_QPMCSI     Cost=556     Cardinality=102     Bytes=18258
    INDEX UNIQUE SCAN     Id=169     Position=2     Object name=RESOURCES_PK     Cost=0     Cardinality=1     Bytes=19
    BUFFER SORT     Id=170     Position=2          Cost=3682     Cardinality=1     Bytes=19
    INDEX UNIQUE SCAN     Id=171     Position=1     Object name=RESOURCES_PK     Cost=0     Cardinality=1     Bytes=19
    TABLE ACCESS BY INDEX ROWID     Id=172     Position=2     Object name=RSRCTP_QPMCS     Cost=2     Cardinality=1     Bytes=103
    INDEX RANGE SCAN     Id=173     Position=1     Object name=RSRCTP_QPMCS_F3     Cost=1     Cardinality=1     
    TABLE ACCESS BY INDEX ROWID     Id=174     Position=2     Object name=RESOURCES     Cost=1     Cardinality=1     Bytes=86
    INDEX UNIQUE SCAN     Id=175     Position=1     Object name=RESOURCES_PK     Cost=0     Cardinality=1     
    NESTED LOOPS ANTI     Id=176     Position=2          Cost=626     Cardinality=1     Bytes=662
    NESTED LOOPS     Id=177     Position=1          Cost=624     Cardinality=1     Bytes=582
    NESTED LOOPS     Id=178     Position=1          Cost=300     Cardinality=162     Bytes=77598
    NESTED LOOPS     Id=179     Position=1          Cost=138     Cardinality=162     Bytes=63666
    HASH JOIN     Id=180     Position=1          Cost=116     Cardinality=2     Bytes=614
    TABLE ACCESS BY INDEX ROWID     Id=181     Position=1     Object name=RSRCTP_QPMCS     Cost=45     Cardinality=198     Bytes=20394
    INDEX RANGE SCAN     Id=182     Position=1     Object name=RSRCTP_QPMCS_F6     Cost=2     Cardinality=198     
    MERGE JOIN CARTESIAN     Id=183     Position=2          Cost=70     Cardinality=263     Bytes=53652
    TABLE ACCESS FULL     Id=184     Position=1     Object name=RSRCTP_CASE_QPMCSI     Cost=70     Cardinality=263     Bytes=48655
    BUFFER SORT     Id=185     Position=2          Cost=0     Cardinality=1     Bytes=19
    INDEX UNIQUE SCAN     Id=186     Position=1     Object name=RESOURCES_PK     Cost=0     Cardinality=1     Bytes=19
    TABLE ACCESS BY INDEX ROWID     Id=187     Position=2     Object name=RESOURCES     Cost=11     Cardinality=101     Bytes=8686
    INDEX RANGE SCAN     Id=188     Position=1     Object name=RESOURCES_F1     Cost=2     Cardinality=138     
    TABLE ACCESS BY INDEX ROWID     Id=189     Position=2     Object name=RESOURCES     Cost=1     Cardinality=1     Bytes=86
    INDEX UNIQUE SCAN     Id=190     Position=1     Object name=RESOURCES_PK     Cost=0     Cardinality=1     
    TABLE ACCESS BY INDEX ROWID     Id=191     Position=2     Object name=RSRCTP_QPMCS     Cost=2     Cardinality=1     Bytes=103
    INDEX RANGE SCAN     Id=192     Position=1     Object name=RSRCTP_QPMCS_F3     Cost=1     Cardinality=1     
    INDEX RANGE SCAN     Id=193     Position=2     Object name=RSRC_CASE_QPMCSI_PK     Cost=2     Cardinality=1     Bytes=80

    Hello, I'm attaching the result from XPLAIN: The point I don't understand is why Oracle is doing INDEX FULL SCAN
    Why is doing it because I'm sending the index part when I'm doing :
    where (rad.resource_id,rad.resource_tp) in (
    6 select t.item_id
    7 , t.item_tp
    8 from rdbmx_site.att_hierarchy_level_vw t
    9 where t.rootitem_id = r.resource_id)
    Thanks for your help, I cannot put all on the same space so I'm putting two messages, the second one with the predicate information.
    SQL> EXPLAIN PLAN FOR
    2 select *
    3 from rdbmx.resources_vt r
    4 , rdbmx.rsrc_case_qpmcsis_x_vt rad
    5 where (rad.resource_id,rad.resource_tp) in (
    6 select t.item_id
    7 , t.item_tp
    8 from rdbmx_site.att_hierarchy_level_vw t
    9 where t.rootitem_id = r.resource_id)
    10 and r.resource_id =3780
    11 and r.resource_tp ='BITUMENPRODUCTION'
    12 and rad.CASE_ID = 599
    13 and rad.CASE_TP = 'MEASURED'
    14 and rad.property_nm ='Liquid Volume Flow'
    15 and rad.qualifier_nm='n/a';
    Explained.
    SQL> set linesize 150
    SQL> set pagesize 0
    SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
    Plan hash value: 3132073840
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 6826 | 216K (1)| 00:43:19 |
    |* 1 | HASH JOIN | | 1 | 6826 | 216K (1)| 00:43:19 |
    | 2 | NESTED LOOPS | | 1 | 170 | 560 (1)| 00:00:07 |
    | 3 | TABLE ACCESS BY INDEX ROWID | RESOURCES | 1 | 115 | 2 (0)| 00:00:01 |
    |* 4 | INDEX UNIQUE SCAN | RESOURCES_PK | 1 | | 1 (0)| 00:00:01 |
    | 5 | SORT UNIQUE | | 1 | 55 | 558 (1)| 00:00:07 |
    |* 6 | VIEW | ATT_HIERARCHY_LEVEL_VW | 1 | 55 | 558 (1)| 00:00:07 |
    | 7 | SORT UNIQUE | | 3353 | 1153K| 558 (100)| 00:00:07 |
    | 8 | UNION-ALL | | | | | |
    | 9 | SORT UNIQUE | | 1 | 19 | 3 (34)| 00:00:01 |
    |* 10 | INDEX RANGE SCAN | ATTACHITEM_PK | 1 | 19 | 2 (0)| 00:00:01 |
    | 11 | TABLE ACCESS BY INDEX ROWID | ATTACHITEM | 43 | 2623 | 4 (0)| 00:00:01 |
    |* 12 | INDEX RANGE SCAN | ATTACHITEM_F3 | 43 | | 2 (0)| 00:00:01 |
    | 13 | NESTED LOOPS | | 61 | 6283 | 5 (0)| 00:00:01 |
    |* 14 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 15 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |* 16 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 17 | NESTED LOOPS | | 87 | 12615 | 10 (0)| 00:00:01 |
    | 18 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |* 19 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 20 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 21 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 22 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |* 23 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 24 | NESTED LOOPS | | 124 | 23188 | 17 (0)| 00:00:01 |
    | 25 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 26 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |* 27 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 28 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 29 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 30 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 31 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 32 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |* 33 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 34 | NESTED LOOPS | | 176 | 40304 | 27 (0)| 00:00:01 |
    | 35 | NESTED LOOPS | | 124 | 20832 | 17 (0)| 00:00:01 |
    | 36 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 37 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |* 38 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 39 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 40 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 41 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 42 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 43 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 44 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 45 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |* 46 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 47 | NESTED LOOPS | | 251 | 68021 | 41 (0)| 00:00:01 |
    | 48 | NESTED LOOPS | | 176 | 36960 | 27 (0)| 00:00:01 |
    | 49 | NESTED LOOPS | | 124 | 20832 | 17 (0)| 00:00:01 |
    | 50 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 51 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |* 52 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 53 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 54 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 55 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 56 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 57 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 58 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 59 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 60 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 61 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |* 62 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 63 | NESTED LOOPS | | 356 | 108K| 60 (0)| 00:00:01 |
    | 64 | NESTED LOOPS | | 251 | 63252 | 41 (0)| 00:00:01 |
    | 65 | NESTED LOOPS | | 176 | 36960 | 27 (0)| 00:00:01 |
    | 66 | NESTED LOOPS | | 124 | 20832 | 17 (0)| 00:00:01 |
    | 67 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 68 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |* 69 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 70 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 71 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 72 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 73 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 74 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 75 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 76 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 77 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 78 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 79 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 80 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |* 81 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 82 | NESTED LOOPS | | 507 | 175K| 88 (0)| 00:00:02 |
    | 83 | NESTED LOOPS | | 356 | 102K| 60 (0)| 00:00:01 |
    | 84 | NESTED LOOPS | | 251 | 63252 | 41 (0)| 00:00:01 |
    | 85 | NESTED LOOPS | | 176 | 36960 | 27 (0)| 00:00:01 |
    | 86 | NESTED LOOPS | | 124 | 20832 | 17 (0)| 00:00:01 |
    | 87 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 88 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |* 89 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 90 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 91 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 92 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 93 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 94 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 95 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 96 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 97 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 98 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |* 99 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 100 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*101 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 102 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |*103 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 104 | NESTED LOOPS | | 721 | 279K| 128 (0)| 00:00:02 |
    | 105 | NESTED LOOPS | | 507 | 166K| 88 (0)| 00:00:02 |
    | 106 | NESTED LOOPS | | 356 | 102K| 60 (0)| 00:00:01 |
    | 107 | NESTED LOOPS | | 251 | 63252 | 41 (0)| 00:00:01 |
    | 108 | NESTED LOOPS | | 176 | 36960 | 27 (0)| 00:00:01 |
    | 109 | NESTED LOOPS | | 124 | 20832 | 17 (0)| 00:00:01 |
    | 110 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 111 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |*112 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 113 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*114 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 115 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*116 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 117 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*118 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 119 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*120 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 121 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*122 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 123 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*124 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 125 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*126 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 127 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |*128 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 129 | NESTED LOOPS | | 1026 | 439K| 174 (1)| 00:00:03 |
    |*130 | HASH JOIN | | 721 | 266K| 117 (1)| 00:00:02 |
    | 131 | NESTED LOOPS | | 507 | 166K| 88 (0)| 00:00:02 |
    | 132 | NESTED LOOPS | | 356 | 102K| 60 (0)| 00:00:01 |
    | 133 | NESTED LOOPS | | 251 | 63252 | 41 (0)| 00:00:01 |
    | 134 | NESTED LOOPS | | 176 | 36960 | 27 (0)| 00:00:01 |
    | 135 | NESTED LOOPS | | 124 | 20832 | 17 (0)| 00:00:01 |
    | 136 | NESTED LOOPS | | 87 | 10962 | 10 (0)| 00:00:01 |
    | 137 | NESTED LOOPS | | 61 | 5124 | 5 (0)| 00:00:01 |
    |*138 | INDEX RANGE SCAN | ATTACHITEM_X1 | 43 | 1806 | 2 (0)| 00:00:01 |
    | 139 | TABLE ACCESS CLUSTER| ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*140 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 141 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*142 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 143 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*144 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 145 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*146 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 147 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*148 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 149 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*150 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 151 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 42 | 1 (0)| 00:00:01 |
    |*152 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 153 | INDEX FAST FULL SCAN | ATTACHITEM_X1 | 11318 | 464K| 28 (0)| 00:00:01 |
    | 154 | TABLE ACCESS CLUSTER | ATTACHITEM | 1 | 61 | 1 (0)| 00:00:01 |
    |*155 | INDEX UNIQUE SCAN | ITEMCLUSTER_CLK | 1 | | 0 (0)| 00:00:01 |
    | 156 | VIEW | RSRC_CASE_QPMCSIS_X_VT | 163 | 1059K| 216K (1)| 00:43:13 |
    | 157 | UNION-ALL | | | | | |
    | 158 | NESTED LOOPS | | 1 | 286 | 185K (1)| 00:37:12 |
    | 159 | NESTED LOOPS | | 1 | 267 | 185K (1)| 00:37:12 |
    | 160 | NESTED LOOPS | | 102 | 20196 | 185K (1)| 00:37:11 |
    | 161 | INDEX FULL SCAN | RESOURCES_PK | 92717 | 1720K| 396 (1)| 00:00:05 |
    | 162 | TABLE ACCESS BY INDEX ROWID | RSRC_CASE_QPMCSI | 1 | 179 | 3 (0)| 00:00:01 |
    |*163 | INDEX RANGE SCAN | RSRC_CASE_QPMCSI_PK | 1 | | 2 (0)| 00:00:01 |
    |*164 | INDEX UNIQUE SCAN | RSRCTP_QPMCS_PK | 1 | 69 | 1 (0)| 00:00:01 |
    |*165 | INDEX UNIQUE SCAN | RESOURCES_PK | 1 | 19 | 0 (0)| 00:00:01 |
    | 166 | NESTED LOOPS ANTI | | 162 | 60264 | 30022 (1)| 00:06:01 |
    | 167 | NESTED LOOPS | | 162 | 47304 | 29698 (1)| 00:05:57 |
    | 168 | NESTED LOOPS | | 26511 | 5773K| 3177 (1)| 00:00:39 |
    | 169 | NESTED LOOPS | | 26511 | 5281K| 3175 (1)| 00:00:39 |
    | 170 | TABLE ACCESS BY INDEX ROWID | RSRCTP_CASE_QPMCSI | 263 | 48655 | 376 (0)| 00:00:05 |
    |*171 | INDEX FULL SCAN | RSRCTP_CASE_QPMCSI_PK | 263 | | 175 (0)| 00:00:03 |
    | 172 | TABLE ACCESS BY INDEX ROWID | RESOURCES | 101 | 1919 | 11 (0)| 00:00:01 |
    |*173 | INDEX RANGE SCAN | RESOURCES_F1 | 138 | | 2 (0)| 00:00:01 |
    |*174 | INDEX UNIQUE SCAN | RESOURCES_PK | 1 | 19 | 0 (0)| 00:00:01 |
    |*175 | INDEX UNIQUE SCAN | RSRCTP_QPMCS_PK | 1 | 69 | 1 (0)| 00:00:01 |
    |*176 | INDEX RANGE SCAN | RSRC_CASE_QPMCSI_PK | 1 | 80 | 2 (0)| 00:00:01 |
    See second message....

  • Resulting in Cartesian Join

    Hi friends,
    I need to restrict the report according to the user who logs in to the application. But only for the ADMIN user i need to show all the records except with the status which is not in "CREATED', i need to show all the records to the admin with other status other than the 'CREATED" status.
    For that i tried with the below query
    select
    '' "Null",
    "REQUEST_ID",
    "REQUEST_TYPE_NAME",
    "REQUEST_NUMBER",
    "REQUEST_CLASS_NAME",
    "REQUEST_STATUS_NAME",
    "REQUEST_DATE"
    from XXHY_AMS_REQ_DET_V , apps.fnd_user xx
    where /*request_number like nvl(:P1_REQUEST_NUMBER,'%')
    and
    REQUEST_STATUS_CODE like nvl(:P1_REQUEST_STATUS,'%')
    and
    lower(REQUEST_DATE) LIKE NVL(lower(:P1_REQUEST_DATE), '%')
    and */requestor_person_id = xx.employee_id or
    lower(xx.user_name) = lower(:APP_USER) or
    exists (select 1 from apps.per_all_people_f papf,
         apps.per_all_assignments_f paaf,
         apps.per_all_people_f supf,
         apps.pqh_roles rls,
         apps.per_people_extra_info pei,
         apps.fnd_user a, XXHY_AMS_REQ_DET_V b
    where  papf.person_id = paaf.person_id and pei.person_id = paaf.person_id
    and nvl(paaf.supervisor_id, papf.person_id) = supf.person_id
    and sysdate between papf.effective_start_date and papf.effective_end_date
    and sysdate between paaf.effective_start_date and paaf.effective_end_date
    and sysdate between supf.effective_start_date and supf.effective_end_date
    and  a.employee_id = papf.person_id
    and lower(a.user_name) = lower(:APP_USER)
    and information_type = 'PQH_ROLE_USERS' and paaf.person_id = b.requestor_person_id and lower(b.request_status_code) not in ('created')
    and rls.role_id = to_number (pei.pei_information3)
    and rls.role_id = to_number (pei.pei_information3) and rls.role_name like 'XXHW_AMS_ADMIN')
    order by 1
    In the above query i used the keyword :APP_USER which identifies the user who logs in APEX.
    Also i have a role named XXHW_AMS_ADMIN, which identifies the user under the admin category.
    So, according to my query, if the user is not in the admin category  means, it has to show only the records raised by him. If the user is in the admin category means then it has to show all the records of all the users other than the status which is not in 'CREATED'.
    But my above query is resulting in cartesian join, if i check with the admin username.
    But it fetches the correct result if i checked with the user who is not in the admin category.
    I dont know why the cartesian join is occuring if i check with the admin user.
    Suppose if i tried to run the query separately which is beneath the EXIST condition* for checking the admin user means, then it is recognizing the admin. But i dont know why it is not working in my above query.*
    select 1 from apps.per_all_people_f papf,
         apps.per_all_assignments_f paaf,
         apps.per_all_people_f supf,
         apps.pqh_roles rls,
         apps.per_people_extra_info pei,
         apps.fnd_user a, XXHY_AMS_REQ_DET_V b
    where  papf.person_id = paaf.person_id and pei.person_id = paaf.person_id
    and nvl(paaf.supervisor_id, papf.person_id) = supf.person_id
    and sysdate between papf.effective_start_date and papf.effective_end_date
    and sysdate between paaf.effective_start_date and paaf.effective_end_date
    and sysdate between supf.effective_start_date and supf.effective_end_date
    and  a.employee_id = papf.person_id
    and lower(a.user_name) = lower(:APP_USER)
    and information_type = 'PQH_ROLE_USERS' and paaf.person_id = b.requestor_person_id and lower(b.request_status_code) not in ('created')
    and rls.role_id = to_number (pei.pei_information3)
    and rls.role_id = to_number (pei.pei_information3) and rls.role_name like 'XXHW_AMS_ADMIN')
    order by 1what might be wrong in my query.
    Brgds,
    Mini

    I was using SQL Developer so i used colon.
    For Sql plus I changed it to & and it is working as expected
    SQL> with t_user as
            select 1 as person_id, 'P1' as user_name from dual union all
            select 2,'P2' from dual union all
            select 3,'P3' from dual union all
            select 4,'P4' from dual union all
            select -1,'ADMIN' from dual
    t_req_data as
            select 1 as person_id, 'created' as request_status_code, sysdate-1 as some_data from dual union all
            select 1 , 'updated' , sysdate-0.5 from dual union all
            select 2 , 'deleted' , sysdate from dual union all
            select -1 , 'created' , sysdate from dual union all
            select -1 , 'updated' , sysdate from dual union all
            select -1 , 'created' , sysdate - 21 from dual union all
            select -1 , 'updated' , sysdate - 21 from dual union all
            select 2 , 'deleted' , sysdate from dual
    SELECT
        tu.person_id,
        tu.user_name,
        trq.request_status_code,
        trq.some_data
    FROM
        t_user tu,
        t_req_data trq
    WHERE
        tu.person_id = trq.person_id
    AND
                &in_user             = 'ADMIN'
            AND request_status_code != 'created'
         OR
                  &in_user != 'ADMIN'
            AND &in_user  = user_name
    Enter value for in_user: 'ADMIN'
    old  33:             &in_user             = 'ADMIN'
    new  33:             'ADMIN'             = 'ADMIN'
    Enter value for in_user: 'ADMIN'
    old  38:             &in_user != 'ADMIN'
    new  38:             'ADMIN' != 'ADMIN'
    Enter value for in_user: 'ADMIN'
    old  39:         AND &in_user  = user_name
    new  39:         AND 'ADMIN'  = user_name
    PERSON_ID USER_ REQUEST SOME_DATA
             1 P1    updated 13-DEC-2011 22:14:32
             2 P2    deleted 14-DEC-2011 10:14:32
            -1 ADMIN updated 14-DEC-2011 10:14:32
            -1 ADMIN updated 23-NOV-2011 10:14:32
             2 P2    deleted 14-DEC-2011 10:14:32
    SQL>

  • Slow SQL output when table alias is NOT used in order by clause

    Hi guys,
    My query is based on Oracle 9208
    I have a table TAB1 with 68000 records with transaction_id as the primary key in this table (unique index).
    I have another TAB2 with the same number of records again with transaction_id in this table (foreign key to above).
    I have the below query that gets executed via an application:-
    SELECT TO_CHAR(V1.TRANSACTION_ID), V1.POLICY_ID, V1.REQUEST_TYPE
    FROM <VIEW> V1 WHERE V1.CERT_SERIAL_NUM=56192 AND
    (V1.AUTH_GROUP_ID=0 OR V1.AUTH_GROUP_ID=1) AND ROWNUM <= 3 ORDER
    BY TRANSACTION_ID ASC
    The above view V1 is created as below:-
    CREATE OR REPLACE FORCE VIEW "V1"
    ("TRANSACTION_ID",
    "PARENT_TRANSACTION_ID",
    "CA_DN_ID",
    "AUTH_GROUP_ID",
    "POLICY_ID",
    "REQUEST_TYPE",
    "REQUEST_STATUS",
    "EE_DN_HASH",
    "EE_DN",
    "EE_EMAIL_HASH",
    "EE_EMAIL",
    "KEY_USAGE",
    "SMART_CARD_SERIAL",
    "CERT_TYPE",
    "CERT_SERIAL_NUM",
    "CERT_INDEX",
    "RENEWAL_FLAG",
    "ARCHIVE_FLAG",
    "TIME_RECEIVED",
    "DOWNLOADED",
    "REQUEST_DATA",
    "ACTION",
    "STEP_NUM")
    AS
    SELECT
    T1.transaction_id,
    T1.parent_transaction_id,
    T1.ca_dn_id,
    V2.auth_group_id,
    V2.policy_id,
    T1.request_type,
    T1.request_status,
    T2.ee_dn_hash,
    T2.ee_dn,
    T2.ee_email_hash,
    T2.ee_email,
    T2.key_usage,
    T2.smart_card_serial,
    T2.cert_type,
    T2.cert_serial_num,
    T2.cert_index,
    T2.renewal_flag,
    T2.archive_flag,
    T1.time_received,
    T1.downloaded,
    T1.request_data,
    V2.action,
    V2.step_num
    FROM TAB1
    <ANOTHER VIEW> V2,
    TAB2 T1,
    TAB2 T2
    WHERE
    T1.transaction_id = T2.transaction_id
    AND
    V2.policy_id = T1.policy_id
    order by transaction_id;
    The query at the top runs within milliseconds if the VIEW is created as :-
    order by t2.transaction_id
    But without the alias "t2" in the order by, the query takes about 1 1/2 minutes
    Can you tell me why? I thought if you ordering by primary key (lesser number of values compared to foreign key values), the query should be faster..no?
    Thanks in advance

    Thanks for keeping up with this issue Hemant.
    Here are the plans for each case.
    I would be very interested in how you'd recognize which plan is the best and what are the derivatives.
    I don't much (or rather anything!) what is 'card' values, 'cost' values etc which I believe are used to decide the best plan of the lot.
    Thanks again
    Note TAB1 and TAB2 are from view definition posted initially
    1) Execution Plan for VIEW1 <<-- With ORDER BY" clause but no table ailas (order by transaction_id)
    SQL> EXPLAIN PLAN FOR SELECT TO_CHAR(QT.TRANSACTION_ID), QT.POLICY_ID, QT.REQUEST_TYPE
    2 FROM <VIEW1> QT WHERE QT.CERT_SERIAL_NUM=24293 AND
    3 (QT.AUTH_GROUP_ID=0 OR QT.AUTH_GROUP_ID=1) AND ROWNUM <= 3 ORDER
    4 BY TRANSACTION_ID ASC
    5 /
    Explained.
    Elapsed: 00:00:01.00
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 3 | 195 | 17 |
    |* 1 | COUNT STOPKEY | | | | |
    | 2 | VIEW | VIEW1 | 17 | 1105 | 17 |
    |* 3 | SORT ORDER BY STOPKEY | | 17 | 38573 | 17 |
    | 4 | NESTED LOOPS | | 17 | 38573 | 10 |
    | 5 | MERGE JOIN CARTESIAN | | 1 | 167 | 9 |
    | 6 | VIEW | VIEW2 | 1 | 52 | 8 |
    | 7 | SORT UNIQUE | | 1 | 156 | 8 |
    | 8 | NESTED LOOPS | | 1 | 156 | 6 |
    | 9 | NESTED LOOPS | | 1 | 143 | 6 |
    | 10 | NESTED LOOPS OUTER | | 1 | 117 | 5 |
    |* 11 | HASH JOIN | | 1 | 104 | 5 |
    | 12 | NESTED LOOPS | | 1 | 52 | 2 |
    |* 13 | TABLE ACCESS FULL | TAB3 | 1 | 39 | 2 |
    |* 14 | INDEX UNIQUE SCAN | (PK_TAB4) | 1 | 13 | |
    | 15 | TABLE ACCESS FULL | TAB5 | 82 | 4264 | 2 |
    | 16 | VIEW PUSHED PREDICATE | View3 | 1 | 13 | |
    | 17 | NESTED LOOPS | | 1 | 52 | 2 |
    | 18 | NESTED LOOPS | | 1 | 39 | 2 |
    |* 19 | INDEX UNIQUE SCAN | (PK_TAB6) | 1 | 13 | 1 |
    |* 20 | INDEX RANGE SCAN | (PK_TAB7) | 1 | 26 | 1 |
    |* 21 | INDEX UNIQUE SCAN | (PK_TAB8) | 1 | 13 | |
    | 22 | TABLE ACCESS BY INDEX ROWID| TAB9 | 3 | 78 | 1 |
    |* 23 | INDEX UNIQUE SCAN | (PK_TAB9) | 1 | | |
    |* 24 | INDEX UNIQUE SCAN | (PK_TAB10)| 1 | 13 | |
    | 25 | BUFFER SORT | | 1 | 115 | 9 |
    | 26 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 115 | 1 |
    |* 27 | INDEX RANGE SCAN | (TAB2_IDX2)| 1 | | |
    |* 28 | TABLE ACCESS BY INDEX ROWID | TAB1 | 12 | 25224 | 1 |
    |* 29 | INDEX UNIQUE SCAN | (PK_TAB1) | 1 | | |
    Predicate Information (identified by operation id):
    1 - filter(ROWNUM<=3)
    3 - filter(ROWNUM<=3)
    11 - access("TAB5"."PATH_ID"="TAB4"."PATH_ID")
    13 - filter("TAB3"."AUTH_GROUP_ID"<>(-1) AND ("TAB3"."AUTH_GROUP_ID"=0 OR "TAB3"."AUTH_GROUP_ID"=1))
    14 - access("TAB3"."PATH_ID"="TAB4"."PATH_ID")
    19 - access("TAB5"."DOMAIN_ID"="TAB6"."DOMAIN_ID")
    20 - access("TAB6"."DOMAIN_ID"="TAB7"."DOMAIN_ID")
    21 - access("TAB7"."RULE_ID"="TAB8"."RULE_ID")
    23 - access("TAB9"."POLICY_ID"="TAB5"."POLICY_ID")
    24 - access("TAB9"."ASSOCIATED_FORM_ID"="TAB10"."FORM_ID")
    27 - access("TAB2"."CERT_SERIAL_NUM"=24293)
    28 - filter("View2"."POLICY_ID"="TAB1"."POLICY_ID")
    29 - access("TAB1"."TRANSACTION_ID"="TAB2"."TRANSACTION_ID")
    Note: cpu costing is off
    54 rows selected.
    Elapsed: 00:00:01.81
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
    Statistics
    39 recursive calls
    0 db block gets
    629 consistent gets
    0 physical reads
    104 redo size
    5169 bytes sent via SQL*Net to client
    405 bytes received via SQL*Net from client
    5 SQL*Net roundtrips to/from client
    31 sorts (memory)
    0 sorts (disk)
    54 rows processed
    2) Execution Plan for VIEW1 <<-- With ORDER BY" clause and table alias (order by TAB2.transaction_id)
    SQL> explain plan for SELECT TO_CHAR(QT.TRANSACTION_ID), QT.POLICY_ID, QT.REQUEST_TYPE
    2 FROM <VIEW1> QT WHERE QT.CERT_SERIAL_NUM=30003 AND
    3 (QT.AUTH_GROUP_ID=0 OR QT.AUTH_GROUP_ID=1) AND ROWNUM <= 3 ORDER
    4 BY TRANSACTION_ID ASC
    5 /
    Explained.
    Elapsed: 00:00:10.20
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 3 | 195 | 14 |
    | 1 | SORT ORDER BY | | 3 | 195 | 14 |
    |* 2 | COUNT STOPKEY | | | | |
    | 3 | VIEW | VIEW1 | 17 | 1105 | 13 |
    | 4 | NESTED LOOPS | | 17 | 38573 | 13 |
    | 5 | MERGE JOIN CARTESIAN | | 1 | 167 | 12 |
    |* 6 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 115 | 4 |
    | 7 | INDEX FULL SCAN | (TAB2_IDX) | 94 | | 1 |
    | 8 | BUFFER SORT | | 1 | 52 | 8 |
    | 9 | VIEW | VIEW2 | 1 | 52 | 8 |
    | 10 | SORT UNIQUE | | 1 | 156 | 8 |
    | 11 | NESTED LOOPS | | 1 | 156 | 6 |
    | 12 | NESTED LOOPS | | 1 | 143 | 6 |
    | 13 | NESTED LOOPS OUTER | | 1 | 117 | 5 |
    |* 14 | HASH JOIN | | 1 | 104 | 5 |
    | 15 | NESTED LOOPS | | 1 | 52 | 2 |
    |* 16 | TABLE ACCESS FULL | TAB3 | 1 | 39 | 2 |
    |* 17 | INDEX UNIQUE SCAN | (PK_TAB4) | 1 | 13 | |
    | 18 | TABLE ACCESS FULL | TAB5 | 82 | 4264 | 2 |
    | 19 | VIEW PUSHED PREDICATE | View3 | 1 | 13 | |
    | 20 | NESTED LOOPS | | 1 | 52 | 2 |
    | 21 | NESTED LOOPS | | 1 | 39 | 2 |
    |* 22 | INDEX UNIQUE SCAN | (PK_TAB6) | 1 | 13 | 1 |
    |* 23 | INDEX RANGE SCAN | (PK_TAB7) | 1 | 26 | 1 |
    |* 24 | INDEX UNIQUE SCAN | (PK_TAB8) | 1 | 13 | |
    | 25 | TABLE ACCESS BY INDEX ROWID| TAB9 | 3 | 78 | 1 |
    |* 26 | INDEX UNIQUE SCAN | (PK_TAB9) | 1 | | |
    |* 27 | INDEX UNIQUE SCAN | (PK_TAB10) | 1 | 13 | |
    |* 28 | TABLE ACCESS BY INDEX ROWID | TAB1 | 12 | 25224 | 1 |
    |* 29 | INDEX UNIQUE SCAN | (PK_TAB1) | 1 | | |
    Predicate Information (identified by operation id):
    2 - filter(ROWNUM<=3)
    6 - filter("TAB2"."CERT_SERIAL_NUM"=30003)
    14 - access("TAB5"."PATH_ID"="TAB4"."PATH_ID")
    16 - filter("TAB3"."AUTH_GROUP_ID"<>(-1) AND ("TAB3"."AUTH_GROUP_ID"=0 OR "TAB3"."AUTH_GROUP_ID"=1))
    17 - access("TAB3"."PATH_ID"="TAB4"."PATH_ID")
    22 - access("TAB5"."DOMAIN_ID"="TAB6"."DOMAIN_ID")
    23 - access("TAB6"."DOMAIN_ID"="TAB7"."DOMAIN_ID")
    24 - access("TAB7"."RULE_ID"="TAB8"."RULE_ID")
    26 - access("TAB9"."POLICY_ID"="TAB5"."POLICY_ID")
    27 - access("TAB9"."ASSOCIATED_FORM_ID"="TAB10"."FORM_ID")
    28 - filter("VIEW2"."POLICY_ID"="TAB1"."POLICY_ID")
    29 - access("TAB1"."TRANSACTION_ID"="TAB2"."TRANSACTION_ID")
    Note: cpu costing is off
    53 rows selected.
    Elapsed: 00:00:08.29
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
    Statistics
    1079 recursive calls
    0 db block gets
    597 consistent gets
    21 physical reads
    0 redo size
    5177 bytes sent via SQL*Net to client
    405 bytes received via SQL*Net from client
    5 SQL*Net roundtrips to/from client
    63 sorts (memory)
    0 sorts (disk)
    53 rows processed
    3) Execution Plan for VIEW1 <<-- Without any "ORDER BY" clause
    SQL> explain plan for SELECT TO_CHAR(QT.TRANSACTION_ID), QT.POLICY_ID, QT.REQUEST_TYPE
    2 FROM <VIEW1> QT WHERE QT.CERT_SERIAL_NUM=30003 AND
    3 (QT.AUTH_GROUP_ID=0 OR QT.AUTH_GROUP_ID=1) AND ROWNUM <= 3 ORDER
    4 BY TRANSACTION_ID ASC
    5 /
    Explained.
    Elapsed: 00:00:10.20
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 3 | 213 | 11 |
    | 1 | SORT ORDER BY | | 3 | 213 | 11 |
    |* 2 | COUNT STOPKEY | | | | |
    | 3 | NESTED LOOPS | | 17 | 1207 | 10 |
    | 4 | MERGE JOIN CARTESIAN | | 1 | 32 | 9 |
    | 5 | VIEW | VIEW2 | 1 | 26 | 8 |
    | 6 | SORT UNIQUE | | 1 | 156 | 8 |
    | 7 | NESTED LOOPS | | 1 | 156 | 6 |
    | 8 | NESTED LOOPS | | 1 | 143 | 6 |
    | 9 | NESTED LOOPS OUTER | | 1 | 117 | 5 |
    |* 10 | HASH JOIN | | 1 | 104 | 5 |
    | 11 | NESTED LOOPS | | 1 | 52 | 2 |
    |* 12 | TABLE ACCESS FULL | TAB3 | 1 | 39 | 2 |
    |* 13 | INDEX UNIQUE SCAN | PK_TAB4 | 1 | 13 | |
    | 14 | TABLE ACCESS FULL | TAB5 | 82 | 4264 | 2 |
    | 15 | VIEW PUSHED PREDICATE | VIEW3 | 1 | 13 | |
    | 16 | NESTED LOOPS | | 1 | 52 | 2 |
    | 17 | NESTED LOOPS | | 1 | 39 | 2 |
    |* 18 | INDEX UNIQUE SCAN | PK_TAB6 | 1 | 13 | 1 |
    |* 19 | INDEX RANGE SCAN | PK_TAB7 | 1 | 26 | 1 |
    |* 20 | INDEX UNIQUE SCAN | PK_TAB8 | 1 | 13 | |
    | 21 | TABLE ACCESS BY INDEX ROWID| TAB9 | 3 | 78 | 1 |
    |* 22 | INDEX UNIQUE SCAN | PK_TAB9 | 1 | | |
    |* 23 | INDEX UNIQUE SCAN | PK_TAB10 | 1 | 13 | |
    | 24 | BUFFER SORT | | 1 | 6 | 9 |
    | 25 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 6 | 1 |
    |* 26 | INDEX RANGE SCAN | TAB2_IDX2 | 1 | | |
    |* 27 | TABLE ACCESS BY INDEX ROWID | TAB1 | 12 | 468 | 1 |
    |* 28 | INDEX UNIQUE SCAN | PK_TAB1 | 1 | | |
    Predicate Information (identified by operation id):
    2 - filter(ROWNUM<=3)
    10 - access("TAB5"."PATH_ID"="TAB4"."PATH_ID")
    12 - filter("TAB3"."AUTH_GROUP_ID"<>(-1) AND ("TAB3"."AUTH_GROUP_ID"=0 OR "TAB3"."AUTH_GROUP_ID"=1))
    13 - access("TAB3"."PATH_ID"="TAB4"."PATH_ID")
    18 - access("TAB5"."DOMAIN_ID"="TAB6"."DOMAIN_ID")
    19 - access("TAB6"."DOMAIN_ID"="TAB7"."DOMAIN_ID")
    20 - access("TAB7"."RULE_ID"="TAB8"."RULE_ID")
    22 - access("TAB9"."POLICY_ID"="TAB5"."POLICY_ID")
    23 - access("TAB9"."ASSOCIATED_FORM_ID"="TAB10"."FORM_ID")
    26 - access("TAB2"."CERT_SERIAL_NUM"=1022)
    27 - filter("VIEW2"."POLICY_ID"="TAB1"."POLICY_ID")
    28 - access("TAB1"."TRANSACTION_ID"="TAB2"."TRANSACTION_ID")
    Note: cpu costing is off
    52 rows selected.
    Elapsed: 00:00:03.37
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
    Statistics
    38 recursive calls
    0 db block gets
    287 consistent gets
    0 physical reads
    0 redo size
    5006 bytes sent via SQL*Net to client
    405 bytes received via SQL*Net from client
    5 SQL*Net roundtrips to/from client
    29 sorts (memory)
    0 sorts (disk)
    52 rows processed

  • CBO not picking the right execution plan

    Database: Oracle 9.2.0.6 EE
    OS:Solaris 9
    I am trying to tune a query that is generated via Siebel Analytics. I am seeing a behaviour which is puzzling me but hopefully would be 'elementary' for someone like JPL.
    The query is based on a total of 7 tables. If I comment out any 2 dimension tables, the query picks up the right index on the fact table. However, the moment I add another table to the query, the plan goes awry.
    The query with 5 tables is as below:
    select count(distinct decode( T30256.HEADER_FLG , 'N' , T30256.ROW_WID ) ) as c1,
    T352305.DAY_DT as c2,
    case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  as c3,
    T352305.ROW_WID as c5
    from
                   W_PRODUCT_D T30955,
                   W_PRDATTRNM_D T44643,                         
                   W_DAY_D T352305,                 
                   W_ORDERITEM_F T30256,              
                   W_PRDATTR_D T40081                         
    where  ( T30955.ROW_WID = T44643.ROW_WID
    and T30256.LAST_UPD_DT_WID = T352305.ROW_WID
    and T30256.PROD_ATTRIB_WID = T40081.ROW_WID 
    and T30256.PROD_WID = T30955.ROW_WID
    and T30955.PROD_NAME = 'Mobile Subscription'
    and (case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  in ('BT150BB-18M', 'BT250BB-18M', 'BT50BB-18M', 'BT600BB-18M'))
    and T352305.DAY_DT between TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 7 and TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 1
    group by
    T352305.ROW_WID, T352305.DAY_DT,
    case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end
    ;And the execution plan is as below:
    | Id  | Operation                        |  Name                | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                 |                      |   269 | 25824 | 18660   (3)|
    |   1 |  SORT GROUP BY                   |                      |   269 | 25824 | 18660   (3)|
    |   2 |   NESTED LOOPS                   |                      |   269 | 25824 | 18658   (3)|
    |   3 |    NESTED LOOPS                  |                      |  6826 |   579K|  4734   (3)|
    |   4 |     MERGE JOIN CARTESIAN         |                      |     8 |   544 |     6  (17)|
    |   5 |      NESTED LOOPS                |                      |     1 |    54 |     4  (25)|
    |   6 |       TABLE ACCESS BY INDEX ROWID| W_PRODUCT_D          |     1 |    37 |     3  (34)|
    |*  7 |        INDEX RANGE SCAN          | W_PRODUCT_D_M2       |     1 |       |     2  (50)|
    |   8 |       TABLE ACCESS BY INDEX ROWID| W_PRDATTRNM_D        |     1 |    17 |     2  (50)|
    |*  9 |        INDEX UNIQUE SCAN         | W_PRDATTRNM_D_P1     |     1 |       |            |
    |  10 |      BUFFER SORT                 |                      |     8 |   112 |     4   (0)|
    |  11 |       TABLE ACCESS BY INDEX ROWID| W_DAY_D              |     8 |   112 |     3  (34)|
    |* 12 |        INDEX RANGE SCAN          | W_DAY_D_M39          |     8 |       |     2  (50)|
    |  13 |     TABLE ACCESS BY INDEX ROWID  | W_ORDERITEM_F        |   849 | 16131 |   592   (3)|
    |* 14 |      INDEX RANGE SCAN            | W_ORDERITEM_F_INDX9  |   852 |       |     4  (25)|
    |* 15 |    INDEX RANGE SCAN              | W_PRDATTR_D_M29_T1   |     1 |     9 |     3  (34)|
    ----------------------------------------------------------------------------------------------Note how the dimension tables W_PRODUCT_D & W_DAY_D are joined using cartesian join before joining to the fact table W_ORDERITEM_F using the composite index 'W_ORDERITEM_F_INDX9'. This index consists of LAST_UPD_DT_WID, PROD_WID and ACTION_TYPE_WID, which are foreign keys to the dimension tables.
    Now if I add one more table to the query:
    select count(distinct decode( T30256.HEADER_FLG , 'N' , T30256.ROW_WID ) ) as c1,
                  T352305.DAY_DT as c2,
                   case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  as c3,
                   T30371.X_BT_DLR_GROUP as c4,
                   T352305.ROW_WID as c5
              from                W_PRODUCT_D T30955,
                   W_PRDATTRNM_D T44643,                         
                   W_DAY_D T352305,                 
                   W_ORDERITEM_F T30256,              
                   W_ORDER_D T30371,                                            
                   W_PRDATTR_D T40081                         
              where  ( T30955.ROW_WID = T44643.ROW_WID
              and T30256.LAST_UPD_DT_WID = T352305.ROW_WID
              and T30256.PROD_ATTRIB_WID = T40081.ROW_WID
              and T30256.PROD_WID = T30955.ROW_WID
              and T30256.ORDER_WID = T30371.ROW_WID
              and T30955.PROD_NAME = 'Mobile Subscription'
              and T30371.STATUS_CD = 'Complete'
              and T30371.ORDER_TYPE = 'Sales Order' 
              and (case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  in ('BT150BB-18M', 'BT250BB-18M', 'BT50BB-18M', 'BT600BB-18M'))
              and T352305.DAY_DT between TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 7 and TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 1
              group by T30371.X_BT_DLR_GROUP, T352305.ROW_WID, T352305.DAY_DT,
              case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end;I have added a single table W_ORDER_D to the query, and the execution plan is:
    | Id  | Operation                          |  Name               | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                   |                     |    44 |  6336 | 78695   (3)|
    |   1 |  SORT GROUP BY                     |                     |    44 |  6336 | 78695   (3)|
    |   2 |   NESTED LOOPS                     |                     |    44 |  6336 | 78694   (3)|
    |   3 |    NESTED LOOPS                    |                     |   269 | 27707 | 78145   (3)|
    |*  4 |     HASH JOIN                      |                     |  6826 |   626K| 64221   (3)|
    |   5 |      TABLE ACCESS BY INDEX ROWID   | W_DAY_D             |     8 |   112 |     4  (25)|
    |*  6 |       INDEX RANGE SCAN             | W_DAY_D_M39         |     1 |       |     3  (34)|
    |   7 |      TABLE ACCESS BY INDEX ROWID   | W_ORDERITEM_F       | 86886 |  2206K| 64197   (3)|
    |   8 |       NESTED LOOPS                 |                     | 87004 |  6797K| 64200   (3)|
    |   9 |        NESTED LOOPS                |                     |     1 |    54 |     4  (25)|
    |  10 |         TABLE ACCESS BY INDEX ROWID| W_PRODUCT_D         |     1 |    37 |     3  (34)|
    |* 11 |          INDEX RANGE SCAN          | W_PRODUCT_D_M2      |     1 |       |     2  (50)|
    |  12 |         TABLE ACCESS BY INDEX ROWID| W_PRDATTRNM_D       |     1 |    17 |     2  (50)|
    |* 13 |          INDEX UNIQUE SCAN         | W_PRDATTRNM_D_P1    |     1 |       |            |
    |* 14 |        INDEX RANGE SCAN            | W_ORDERITEM_F_N6    | 86886 |       |   212  (18)|
    |* 15 |     INDEX RANGE SCAN               | W_PRDATTR_D_M29_T1  |     1 |     9 |     3  (34)|
    |* 16 |    INDEX RANGE SCAN                | W_ORDER_D_N6        |     1 |    41 |     3  (34)|
    -----------------------------------------------------------------------------------------------Now CBO doesn't choose the composite index and the cost also has increased to 78695. But if I simply add an /*+ORDERED*/ hint to the above query, so that it should join the dimension tables before joining to fact table, then the cost drops to 20913. This means that CBO is not choosing the plan with the lowest cost. I tried increasing the optimizer_max_permutations to 80000, setting session level optimizer_dynamic_sampling to 8 (just to see if it works), but no success.
    Could you please advise how to overcome this problem?
    Many thanks.

    joshic wrote:
    Database: Oracle 9.2.0.6 EE
    OS:Solaris 9
    I am trying to tune a query that is generated via Siebel Analytics. I am seeing a behaviour which is puzzling me but hopefully would be 'elementary' for someone like JPL.
    The query is based on a total of 7 tables. If I comment out any 2 dimension tables, the query picks up the right index on the fact table. However, the moment I add another table to the query, the plan goes awry.
    I have added a single table W_ORDER_D to the query, and the execution plan is:
    Now CBO doesn't choose the composite index and the cost also has increased to 78695. But if I simply add an /*+ORDERED*/ hint to the above query, so that it should join the dimension tables before joining to fact table, then the cost drops to 20913. This means that CBO is not choosing the plan with the lowest cost. I tried increasing the optimizer_max_permutations to 80000, setting session level optimizer_dynamic_sampling to 8 (just to see if it works), but no success.Back to the original question:
    * Can you force the index usage of the composite index on W_ORDERITEM_F in the second query using an INDEX hint (instead of the ORDERED hint)? If yes, what does the plan look like, particularly what cost is reported?
    * Could you post the plans including the "Predicate Information" section below the plan output?
    * What is the definition of the index W_ORDERITEM_F_N6 on W_ORDERITEM_F?
    * Are the cardinalities reported in the execution plans close to reality or way off? The best way to verify this would be to run your query with SQL tracing enabled and generate a tkprof output. If you do so please post the tkprof output here as well.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Cartesian of data from two tables with no matching columns

    Hello,
    I was wondering – what’s the best way to create a Cartesian of data from two tables with no matching columns in such a way, so that there will be only a single SQL query generated?
    I am thinking about something like:
    for $COUNTRY in ns0: COUNTRY ()
    for $PROD in ns1:PROD()
    return <Results>
         <COUNTRY> {fn:data($COUNTRY/COUNTRY_NAME)} </COUNTRY>
         <PROD> {fn:data($PROD/PROD_NAME)} </PROD>
    </Results>
    And the expected result is combination of all COUNTRY_NAMEs with all PROD_NAMEs.
    What I’ve noticed when checking query plan is that DSP will execute two queries to have the results – one for COUNTRY_NAME and another one for PROD_NAME. Which in general results in not the best performance ;-)
    What I’ve noticed also is that when I add something like:
    where COUNTRY_NAME != PROD_NAME
    everything is ok and there is only one query created (it's red in the Query plan, but still it's ok from my pov). Still it looks to me more like a workaround, not a real best approach. I may be wrong though...
    So the question is – what’s the suggested approach for such queries?
    Thanks,
    Leszek
    Edited by xnts at 11/19/2007 10:54 AM

    Which in general results in not the best performanceI disagree. Only for two tables with very few rows, would a single sql statement give better performance.
    Suppose there are 10,000 rows in each table - the cross-product will result in 100 million rows. Sounds like a bad idea. For this reason, DSP will not push a cross-product to a database. It will get the rows from each table in separate sql statements (retrieving only 20,000 rows) and then produce the cross-product itself.
    If you want to execute sql with cross-products, you can create a sql-statement based dataservice. I recommend against doing so.

  • Drawing quadratic equations on a 2D cartesian co-ordinate system

    Hi,
    I need to design a 2D cartesian co-ordinate system to plot quadratic equations on the graph using pure action script. Quadratic equations are of the form y = ax^2 + bx + c where a,b and c are the variables for which the values need to accepted from the user as input. Accordingly, the curve needs to be plotted on the graph.
    Could anybody kindly help me to write an action script 3.0 code to suffice the above requirement?
    Thanks in advance.
    Cheers,
    Pratik.

    that will take more work than doable in a forum.  to start, you need to find the roots of your equation (use the quadratic formula) and make sure the real roots are towards the center of your x-axis.  the two parts where y tends towards (+infinity or -infinity) do not require much display.
    if there is only 1 or 0 roots, put that equation in vertex form and use an x-axis centered around the vertex.
    for a sample of how this can be done:  http://www.kglad.com > snippets > function graphs.

  • Cartesian selects after Update from 10.0.2.0.3 to 10.0.2.0.5

    Hello,
    we just installed the patch 10.0.2.0.5 on a 10.0.2.0.3 database and some selects didn't work as before. While changing the select clause, there are diffent counts.
    There are 3 tables:
    Detail_1 => MASTER_1 <= Detail_2
    MASTER_1 has a primary and an unique Key. The 2 detail tables have FK. Now when selecting only columns from the detail tables (joined with master) we get cartesian selects. If i use one column of the master table in the select clause everything is fine.
    Here is an example:
    CREATE TABLE MASTER_1
    ( "KUNID" NUMBER NOT NULL ENABLE,
    "CUSTOMER_NO" VARCHAR2(20 BYTE),
    CONSTRAINT "PK_MASTER1" PRIMARY KEY ("KUNID"),
    CONSTRAINT "UK_MASTER1" UNIQUE ("CUSTOMER_NO"));
    CREATE TABLE DETAIL_1
    ( "CUSTOMER_NO" VARCHAR2(20 BYTE),
    CONSTRAINT "FK_DETAIL1" FOREIGN KEY ("CUSTOMER_NO") REFERENCES "MASTER_1" ("CUSTOMER_NO"));
    CREATE TABLE DETAIL_2
    ( "KUNID" NUMBER,
    CONSTRAINT "FK_DETAIL2" FOREIGN KEY ("KUNID") REFERENCES "MASTER_1" ("KUNID")) ;
    INSERT INTO MASTER_1 VALUES(1,'A');
    INSERT INTO MASTER_1 VALUES(2,'B');
    INSERT INTO DETAIL_1 VALUES ('A');
    INSERT INTO DETAIL_1 VALUES ('B');
    INSERT INTO DETAIL_2 VALUES ('1');
    INSERT INTO DETAIL_2 VALUES ('2');
    INSERT INTO DETAIL_2 VALUES ('1');
    INSERT INTO DETAIL_2 VALUES ('2');
    INSERT INTO DETAIL_2 VALUES ('1');
    INSERT INTO DETAIL_2 VALUES ('2');
    COMMIT;
    SELECT a.*
    FROM MASTER_1 b,
    DETAIL_1 a,
    DETAIL_2 c
    WHERE a.CUSTOMER_NO = b.CUSTOMER_NO
    AND b.KUNID = c.KUNID
    AND a.CUSTOMER_NO = 'A';
    The Result on a 10.0.2.0.3.0 Database for different select clauses
    SELECT a.* => 3 Row Selected
    SELECT b.* => 3 Row Selected
    SELECT c.* => 3 Row Selected
    The Result on a 10.0.2.0.5.0 Database for different select clauses
    SELECT a.* => 6 Row Selected
    SELECT b.* => 3 Row Selected
    SELECT c.* => 6 Row Selected
    So you see, we get different rows only by changing the select clause.
    Note: It seemed to be important to have both FK. When deleting one of them - or both - we get the same correct results: 3 rows with any select clause.
    IS this a bug or have we to change our sql?
    Regards
    Rudi Zugreif

    Hi,
    thanks for your reply.
    The alter session works, but even so I will contact ORacle Suppoer
    The explain plan (before alter session):
    Explain Plan for 10.2.0.5
    SELECT a.* (6 Rows)
      MERGE JOIN CARTESIAN
        TABLE ACCESS FULL DETAIL_1
        BUFFER SORT
          TABLE ACCESS FULL DETAIL_2
        TABLE ACCESS FULL DETAIL_1
        BUFFER SORT
          TABLE ACCESS FULL DETAIL_2
    SELECT b.* (3 Rows)
        NESTED LOOPS 
          TABLE ACCESS BY INDEX ROWID MASTER_1
            INDEX UNIQUE SCAN UK_MASTER1
          TABLE ACCESS FULL DETAIL_1
        TABLE ACCESS FULL DETAIL_2
      HASH JOIN 
        NESTED LOOPS 
          TABLE ACCESS BY INDEX ROWID MASTER_1
            INDEX UNIQUE SCAN UK_MASTER1
          TABLE ACCESS FULL DETAIL_1
        TABLE ACCESS FULL DETAIL_2
    Explain Plan for 10.2.0.3
    SELECT a.* (3 Rows)
    NESTED LOOPS 
          TABLE ACCESS BY INDEX ROWID MASTER_1
            INDEX UNIQUE SCAN UK_MASTER1
          TABLE ACCESS FULL DETAIL_1
        TABLE ACCESS FULL DETAIL_2
      HASH JOIN 
        NESTED LOOPS 
          TABLE ACCESS BY INDEX ROWID MASTER_1
            INDEX UNIQUE SCAN UK_MASTER1
          TABLE ACCESS FULL DETAIL_1
    SELECT b.* (3 Rows)
      HASH JOIN 
        NESTED LOOPS 
          TABLE ACCESS BY INDEX ROWID MASTER_1
            INDEX UNIQUE SCAN UK_MASTER1
          TABLE ACCESS FULL DETAIL_1
        TABLE ACCESS FULL DETAIL_2regards
    Rudi
    Edited by: gogetter on Jul 27, 2010 1:19 AM

  • Query not working fine

    Hi
    db version is 9.2.0.8.0
    in dev the query is working fine.But in qa the query is not working fine(hanging).I had checked the explain plans.
    Both are different.This is due to difference in volume of data.
    I am pasting the explain plans of both the queries in qa and dev
    qa explain plan
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 606M| 118G| | 107M (1)|
    | 1 | SORT GROUP BY | | 606M| 118G| 524G| 107M (1)|
    | 2 | HASH JOIN | | 1869M| 363G| | 50748 (1)|
    | 3 | TABLE ACCESS FULL | DIM_GEOGRAPHY_HIER | 9066 | 318K| | 331 (1)|
    | 4 | HASH JOIN | | 2474K| 408M| 2232K| 50400 (1)|
    | 5 | TABLE ACCESS FULL | DIM_GEOGRAPHY_HIER | 54396 | 1593K| | 330 (1)|
    | 6 | HASH JOIN | | 2474K| 337M| | 31791 (1)|
    | 7 | TABLE ACCESS FULL | DIM_PRODUCT_HIER | 206 | 3296 | | 25 (4)|
    | 8 | HASH JOIN | | 3162K| 382M| | 31745 (1)|
    | 9 | TABLE ACCESS FULL | DIM_PRODUCT_HIER | 3087 | 27783 | | 25 (4)|
    | 10 | HASH JOIN | | 3162K| 355M| 2952K| 31699 (1)|
    | 11 | MERGE JOIN CARTESIAN | | 62930 | 2212K| | 14627 (1)|
    | 12 | INDEX FAST FULL SCAN | SYS_C0013071 | 2923 | | | 4 (25)|
    | 13 | BUFFER SORT | | 22 | 792 | | 14623 (1)|
    | 14 | TABLE ACCESS BY INDEX ROWID| CURCY_CONVERT_RATE | 22 | 792 | | 6 (17)|
    | 15 | INDEX RANGE SCAN | XPKCURRATE | 22 | | | 5 (20)|
    | 16 | TABLE ACCESS FULL | SHIPPABLE_BACKLOG_FACT | 321K| 25M| | 15494 (1)|
    dev explain plan
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 17M| 2978M| | 927K (1)|
    | 1 | SORT GROUP BY | | 17M| 2978M| 6504M| 927K (1)|
    |* 2 | HASH JOIN | | 17M| 2978M| | 2726 (1)|
    |* 3 | TABLE ACCESS FULL | DIM_GEOGRAPHY_HIER | 4992 | 180K| | 416 (1)|
    |* 4 | HASH JOIN | | 41051 | 5852K| 2872K| 2309 (1)|
    | 5 | TABLE ACCESS FULL | DIM_GEOGRAPHY_HIER | 69888 | 2047K| | 415 (1)|
    |* 6 | HASH JOIN | | 41051 | 4650K| | 1504 (1)|
    |* 7 | TABLE ACCESS FULL | DIM_PRODUCT_HIER | 206 | 3296 | | 37 (3)|
    |* 8 | HASH JOIN | | 52460 | 5123K| | 1467 (1)|
    | 9 | TABLE ACCESS FULL | DIM_PRODUCT_HIER | 3087 | 27783 | | 37 (3)|
    |* 10 | HASH JOIN | | 52460 | 4661K| | 1430 (1)|
    |* 11 | TABLE ACCESS FULL | SHIPPABLE_BACKLOG_FACT | 7718 | 414K| | 513 (1)|
    | 12 | MERGE JOIN CARTESIAN | | 48941 | 1720K| | 915 (0)|
    | 13 | INDEX FULL SCAN | SYS_C0060330 | 1827 | | | 7 (15)|
    | 14 | BUFFER SORT | | 27 | 972 | | 913 (0)|
    | 15 | TABLE ACCESS BY INDEX ROWID| CURCY_CONVERT_RATE | 27 | 972 | | 2 (50)|
    |* 16 | INDEX RANGE SCAN | XPKCURRATE | 27 | | | 4 (25)|
    Here is the query
    SELECT 'BACKLOG' AS SUBJECT_AREA, 'CURRENT' AS TIME_RANGE
    ,GEO_ROLLUP.GEOGRAPHY_HIER_KEY
    ,PRODUCT_ROLLUP.PRODUCT_HIER_KEY
    , backlog_FACT.DISTRIBUTION_CH_ID
    , backlog_FACT.SALES_DISTRICT_ID
    , SUM(NVL(backlog_FACT.GC_SCHEDULED_AMT,0) - NVL(backlog_FACT.GC_biilled_AMT,0)) AS billing_backlog_AMT
    , SUM(NVL(backlog_FACT.GC_SCHEDULED_AMT,0)- NVL(backlog_FACT.GC_DELIVERED_AMT,0)) AS delivery_backlog_AMT
    , SUM(NVL(backlog_FACT.GC_SCHEDULED_AMT,0) - NVL(backlog_FACT.GC_REV_REC_AMT,0)) AS rev_rec_backlog_AMT
    , CURCY.VALID_FROM
    FROM fact.shippable_backlog_FACT backlog_FACT
    , DIM.DIM_PRODUCT_HIER PRODUCT
    , DIM.DIM_GEOGRAPHY_HIER GEO
    , DIM.DIM_DATE DT
    , DIM.DIM_PRODUCT_HIER PRODUCT_ROLLUP
    , DIM.DIM_GEOGRAPHY_HIER GEO_ROLLUP
    , DIM.CURCY_CONVERT_RATE CURCY
    WHERE
    PRODUCT.PRODUCT_HIER_KEY = backlog_FACT.GEF_PRODUCT_HIER_KEY
    AND GEO.GEOGRAPHY_HIER_KEY = backlog_FACT.GEF_SHIP_TO_GEO_HIER_KEY
    AND ( backlog_FACT.DELIVERY_COMPLETE_DATE IS NULL
         OR backlog_FACT.BILLING_COMPLETE_DATE IS NULL
         OR backlog_FACT.REV_REC_COMPLETE_DATE IS NULL
    AND PRODUCT.PRODUCT_TYPE = PRODUCT_ROLLUP.PRODUCT_TYPE
    AND PRODUCT_ROLLUP.HIER_LEVEL_NUM = 4
    AND PRODUCT_ROLLUP.CURRENT_RECORD_IND = 'Y'
    AND GEO_ROLLUP.SUB_POLE = GEO.SUB_POLE
    AND GEO_ROLLUP.HIER_LEVEL_NUM = 3
    AND GEO_ROLLUP.CURRENT_RECORD_IND = 'Y'
    AND CURCY.VALID_FROM <= BACKLOG_FACT.ORDER_LINE_CREATE_DATE
    AND CURCY.VALID_TO > BACKLOG_FACT.ORDER_LINE_CREATE_DATE
    AND CURCY.EXCHANGE_TYPE_ID = 'M'
    AND CURCY.TO_CURRENCY_ID = 'USD'
    AND CURCY.FROM_CURRENCY_ID = BACKLOG_FACT.DOCUMENT_CURRENCY_ID
    GROUP BY
    PRODUCT_ROLLUP.PRODUCT_HIER_KEY,
    GEO_ROLLUP.GEOGRAPHY_HIER_KEY,
    backlog_FACT.DISTRIBUTION_CH_ID,
    backlog_FACT.SALES_DISTRICT_ID,
    CURCY.VALID_FROM;
    I analyzed all the tables involved in it.
    can anybody give me suggestion in crating indexes or anything else?
    Thanks
    Veer

    Veer,
    Modify your post and enclose your code and output between \ tags for formatting
    \Your code or output goes here
    \Now, are table stats are upto date on all the table on QA machine? If not, analyze your table and indexes and re-run your query
    Regards
    Edited by: OrionNet on May 7, 2009 3:35 PM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • General algorithm for cartesian product

    i am looking for an algorithm to get the cartesian product from a set of sets like {{1,2,3,4},{a,b,c},{x,y,z,7,15}...} - this means in most general form.
    google yields no results :-(. i think implementing it by myself is not a good idea.

    dermoritz wrote:
    prometheuzz is your algorithm better than n*mi n: number of sets mi: cardinality of the set i ?
    can you short explain the algorithm?You can't do any better than that because for n sets: S(0), S(1), S(2) ... S(n-1) there are prod(i in [0, n), |S(i)|) elements of the caresian product. Prometeuzz algorithm generates
    one at ever pass of the loop executing n steps per element. If you're afraid that the product number will be too large you can also fiddle with the indexes themselves:
    // scard[i] == |S(i)|
    // prod[i] == element of S(i) in product
    int[] next(int[] scard, int[] prod) {
       for (int i= prod.lerngth; i-- > 0; prod= 0)
    if (++prod[i] < scard[i]) return prod; // return indexes of next product
    return null; // no next product anymore
    }kind regards,
    Jos                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

Maybe you are looking for

  • Calculation in BindingUtils

    Hi I'm having a few troubles with actionscript and using binding utils. In a bind in MXML I can do something like: <mx:Panel      id="myPanel"      height = "{parentApplication.height - 200}" /> i.e I can add a fixed offset to the attribute. Is there

  • External hard drive has caused library to lose content

    after a number of low disk space notices, i got an external hard drive and thought i had solved a problem.  shortly after, a large number of songs disappeared from itunes (as well as my playlists) and i haven't synced since, fearing purchased and loa

  • Why cant i view anything on the page?

    Im trying to view a web page but all i see is a loading bar that when finish loading, nothing comes up. My flash player is up to date and my company help desk says it works on their mac computers. Why cant my computer view the same thing?

  • Pwd change option in Hyperion 9.3.1

    Hi All, i created a user in Shared services and exported to WebAnalysis till now this is fine.... is there any option for user to change Password Vijay.....

  • ClassNotFoundException DefaultRealmImpl

    I receive a ClassNotFoundException for DefaultRealmImpl when I try to execute the statement Realm.getRealm("RDBMSRealm"); The class is located under \classes and I have \classes in the CLASSPATH. Any ideas?