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
-
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 PierceSteven,
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_OUTPUTPlease 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
DerrickIt'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=80Hello, 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.... -
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,
MiniI 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 advanceThanks 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 AMWhich 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. -
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 ZugreifHi,
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 -
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
VeerVeer,
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
-
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?