Nested subquery?

hello,
I'm trying to write a subquery (1st time) in my WHERE clause.
the way i wanted to work is. If gl_tr_type = 'SO' then execute the rest. But then i need g.cust_name to be in the group by between d. ACCT_ACC_LNG , f.FISCAL_MONTH,?
I tried to write case in WHERE but that just took very long time!
Thank-you for your Help!!!
SELECT
b.en_ent,
e.sa_sub,
c.cc_cstctr,
d.acct_acc,
b. EN_ENTITY_LNG,
e. SA_SUB_LNG,
c. COST_CTR_LNG,
d. ACCT_ACC_LNG ,
f. FISCAL_MONTH,
f. FISCAL_YEAR_LNG,
d. ACCT_TYPE,
SUM(a.gl_amt)
FROM
F_ACCT_TRX_HIST_STG1 a,
D_ENTITY_STG2 b,
D_COSTCTR_STG2 c,
D_ACCTS_STG2 d,
D_SUBACCTS_STG2 e,
D_PERIOD_STG1 f
WHERE a.gl_eff_dt BETWEEN '02-april-2007' AND '02-april-2007' AND
a.GL_ENT = b.EN_ENT AND
c.CC_CSTCTR = UPPER (a.GL_CC) AND
d.acct_acc = a.gl_acc AND
e.sa_sub = a.gl_sa AND
a.gl_eff_dt = f.calendar_date AND
(SELECT g. cust_name
FROM FINMART.D_CUSTOMER g,
DSSMART.F_SALES_INVOICE h
WHERE a.gl_tr_type = 'SO'AND
a.gl_doc =h.inv_nbr AND
h.inv_cust_bill_to_nbr = g.cust_nbr)
GROUP BY b.EN_ENT, e.sa_sub, c.cc_cstctr, d.acct_acc,
b. EN_ENTITY_LNG,
e. SA_SUB_LNG,
c. COST_CTR_LNG,
d. ACCT_ACC_LNG ,
f. FISCAL_MONTH,
f. FISCAL_YEAR_LNG,
d. ACCT_TYPE

It's not reading CASE in GROUP BY, ORA-22818 subquery expression not allowed here! Can anyone explain what is wrong?
This script works only if I delete SUM and GROUP BY or if i delete CASE statment from GROUP BY than it works too (but it freezes after 100 records, i think because it hits SO transactions)
Thank-you for you help!!!!
SELECT b.en_ent
,e.sa_sub
,c.cc_cstctr
,d.acct_acc
,b. en_entity_lng
,e. sa_sub_lng
,c. cost_ctr_lng
,d. acct_acc_lng
,f. fiscal_month
,f. fiscal_year_lng
,d. acct_type
     ,a. gl_tr_type
,CASE
WHEN a.gl_tr_type = 'SO' THEN
(SELECT g. cust_name
FROM F_ACCT_TRX_HIST_STG2 a
          ,finmart.D_CUSTOMER g
,dssmart.f_sales_invoice h
WHERE a.gl_doc = h.inv_nbr
AND h.inv_cust_bill_to_nbr = g.cust_nbr)
ELSE
NULL
END cust_name
,SUM(a.gl_amt)
FROM F_ACCT_TRX_HIST_STG2 a
,D_ENTITY_STG2 b
,D_COSTCTR_STG2 c
,D_ACCTS_STG2 d
,D_SUBACCTS_STG2 e
,D_PERIOD_STG1 f
WHERE a.gl_ent = b.en_ent
AND c.cc_cstctr = UPPER(a.gl_cc)
AND d.acct_acc = a.gl_acc
AND e.sa_sub = a.gl_sa
AND a.gl_eff_dt = f.calendar_date
GROUP BY b.en_ent
,e.sa_sub
,c.cc_cstctr
,d.acct_acc
,b. en_entity_lng
,e. sa_sub_lng
,c. cost_ctr_lng
,d. acct_acc_lng
     , CASE
WHEN a.gl_tr_type = 'SO' THEN
(SELECT g. cust_name
FROM F_ACCT_TRX_HIST_STG2 a
               ,finmart.D_CUSTOMER g
,dssmart.f_sales_invoice h
WHERE a.gl_doc = h.inv_nbr
AND h.inv_cust_bill_to_nbr = g.cust_nbr)
ELSE
NULL
END
,f. fiscal_month
,f. fiscal_year_lng
,d. acct_type
     ,a. gl_tr_type
Message was edited by:
user568493
Message was edited by:
user568493

Similar Messages

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....

Nested subquery, using items from other part of query

Hi All,
I have a tricky problem and I will try explain as best I can:
DB version is 11.2.0.3.0
create table product_list (product_id number,
                project_name varchar2(30))
create table products (product_id number,
                project_desc varchar2(30))
create table total_counts (product_id number,
                total_count number,
                project_name varchar2(30))
create table fixed_counts (product_id number,
                fixed_count number,
                project_name varchar2(30).
                    fixed_date date)
create table product_rating (product_id number,
                rating number,
                quarter_last_updated number)
create table quarters (quarter_id number,
                quarter_end_date date)
insert into product_list values (1, 'Prod 1');
insert into product_list values (2, 'Prod 2');
insert into product_list values (3, 'Prod 3');
insert into products values (1, 'Prod 1');
insert into products values (2, 'Prod 2');
insert into products values (3, 'Prod 3');
insert into total_counts values (1, 2000, 'Prod 1');
insert into total_counts values (2, 1000, 'Prod 2');
insert into total_counts values (3, 500, 'Prod 3');
insert into fixed_counts values (1, 1, 'Prod 1', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (1, 3, 'Prod 1', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (2, 50, 'Prod 2', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (2, 2, 'Prod 2', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (2, 3, 'Prod 2', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (2, 3, 'Prod 2', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (3, 8, 'Prod 3', to_date('01/01/2013','DD/MM/YYYY'));
insert into fixed_counts values (3, 3, 'Prod 3', to_date('01/03/2013','DD/MM/YYYY'));
insert into product_rating values (1, 1, 1);
insert into product_rating values (3, 2, 2);
insert into quarters values (1, to_date('01/10/2012','DD/MM/YYYY'));
insert into quarters values (2, to_date('01/02/2013','DD/MM/YYYY'));My current query effectively joins 2 tables 'TOTAL_COUNTS' and 'FIXED_COUNTS'. The FIXED_COUNTS table is updated daily when one of the products has a fix made against it and the query outputs a list of all Products and their percentage "fixed" rate (used in an APEX Interactive report).
select A.PRODUCT, A.TOTAL, B.FIXED, a.PROD_ID, round((FIXED/TOTAL) * 100, 2) percent
from (
select sum(a.total_count) TOTAL, a.product_id PROD_ID, d.Product_desc PRODUCT
from total_counts a, product_list c, products d
where a.product_id = c.product_id
and lower(a.project_name) = lower(c.project_name)
and c.product_id = d.product_id
group by a.product_id, d.product_desc
) A
JOIN
select sum(b.fixed_count) FIXED, b.product_id PROD_ID, d.Product_desc PRODUCT
from fixed_counts b, product_list c, products d
where b.product_id = c.product_id
and lower(b.project_name) = lower(c.project_name)
and c.product_id = d.product_id
group by b.product_id, d.product_desc
) B
on A.PROD_ID = B.PROD_ID and A.PRODUCT = B.PRODUCT This gives me an output like:
PRODUCT     TOTAL     FIXED     PROD_ID     percent
Prod 1     2000     4     1     0.2
Prod 2     1000     58     2     5.8
Prod 2      500     11     3     2.2The query works fine and does exactly the job I require. However, I now have a requirement that when a product gets a "fixed" percentage rate over 1% the product gets a point added against it in a "product_rating" table and i have to recalculate the fixed percentage from the date the point was added (if no point added we take all "fixed").
I have added 2 new tables for this: "product_rating" and "quarters". The "product_rating" table contains the Product_id and the points it has accumulated so far. It is updated once a quarter. The "quarters" table just holds the dates for us to use for the new calculations.
So effectively I need to replace this:
sum(b.fixed_count) FIXEDwith something like this:
if a product has a point against it in the "product_rating" table then we just show fixes from the date the point was added i.e.
select sum(b.fixed_count) from fixed_counts b, product_rating c, quarters d
where b.product_id = c.product_id and c.quarter_last_updated = d.quarter_id
and b.product_id = PROD_ID
and b.fixed_date > (select quarter_end_date from quarters where quarter_id = the_last_quarter_updated)Based on the values in the tables above the percentages for 'Prod 3' should now be 0.6. This is because it received a product_rating on quarter 2 so the new calculation is based on all "fixes" after this date (only the last one on 01-MAR-13').
I have tried numerous ways of embedding this in the current query but I cannot get it to work. Sorry for not adding the complete table info but the total_counts and fixed_counts tables have much more columns that I removed from the query so it would be easier to view. Thanks in advance for your help. If I can add anymore info please ask.
Tom
Edited by: TomH on May 14, 2013 8:54 AM
Edited by: TomH on May 14, 2013 8:58 AM

TomH wrote:
of course youre right, thanks.
I have added some table info and data that will hopefully make it a bit easier to understand.Okay, thanks ... in the future though please try and run the commands yourself to ensure they work. What you provided is close, but it didn't run straight away without some modifications.
I'll start with expressing my concerns for your data model, it seems .... wrong, for lack of a better word. Even given that you said you stripped out a bunch of stuff to make the example. Do you have anyone you work with that can review the model for you?
As for the query, this isn't pretty (I'm in a bit of a rush here) so you can probably clean it up considerably. I just tried to demonstrate the basics of what you're going to have to do.
ME_XE? with base_data as
2 (
3     select
4        b.fixed_date,
5        b.fixed_count,
6        b.product_id ,
7        d.project_desc
8     from fixed_counts b, product_list c, products d
9     where b.product_id = c.product_id
10     and lower(b.project_name) = lower(c.project_name)
11     and c.product_id = d.product_id
12 ),
13     final_base_data as
14 (
15     select
16        b.product_id      PROD_ID,
17        b.project_desc    PRODUCT,
18        sum
19        (
20           case
21              when b.fixed_date >= stuff.quarter_end_date or stuff.quarter_end_date is null
22              then
23                 b.fixed_count
24              else
25                 0
26           end
27        ) as FIXED
28     from base_data b
29     left outer join
30     (
31        select
32           pr.product_id,
33           qr.quarter_end_date
34        from product_rating pr , quarters qr
35        where pr.quarter_last_updated = qr.quarter_id
36     ) stuff
37     on (stuff.product_id = b.product_id)
38     group by b.product_id, b.project_desc
39 )
40 select A.PRODUCT, A.TOTAL, B.FIXED, a.PROD_ID, round((b.FIXED/a.TOTAL) * 100, 2) percent
41 from
42 (
43     select sum(a.total_count) TOTAL, a.product_id PROD_ID, d.project_desc PRODUCT
44     from total_counts a, product_list c, products d
45     where a.product_id = c.product_id
46     and lower(a.project_name) = lower(c.project_name)
47     and c.product_id = d.product_id
48     group by a.product_id, d.project_desc
49 ) A
50 JOIN final_base_data B
51 on A.PROD_ID = B.PROD_ID and A.PRODUCT = B.PRODUCT
52 ;
PRODUCT                                     TOTAL              FIXED            PROD_ID            PERCENT
Prod 1                                       2000                  4                  1                 .2
Prod 2                                       1000                 58                  2                5.8
Prod 3                                        500                  3                  3                 .6
3 rows selected.Cheers,

Corelated subquery Vs Nested Sub Query

hi all,
i am having a small doubt regarding the usage of corelated subqueries. what is the difference between corelated subquery & nested subquery in terms of performance. Which is more advisable to use?
pls. help me.

"The one that gives you the best performance when benchmarked with your data"
I would ammend that to:
The one that gives you the best performance and the right answer when benchmarked with your data
John

Nested Subselect in UPDATE statement

Hi everybody,
I have the following problem: There are two tables FOO and BAR that both have columns X and Y and a primary key. I want to fill the values X and Y of FOO with the values X and Y from BAR where FOO.key = BAR.key . There may be multiple rows from BAR with the same key so I simply select the first one. The query would look like
UPDATE foo f
   SET ( x, y ) = ( SELECT *
                      FROM ( SELECT b.x, b.y
                               FROM bar b
                              WHERE f.key = b.key )
                     WHERE ROWNUM = 1 );However, this doesn't work because the alias F is not known inside the nested subquery. If I remove the outer subquery ( the one with ROWNUM=1 ) it works fine. But I need to limit the result to a single row ( in the real application I sort the innermost query by date ). Why does Oracle forget the meaning of alias F within the nested subquery?
Pat

Hi, Pat,
A subquery can be correlated only to its immediate parent query, not its grandparent.
You can get the results you want using MERGE instead of UPDATE.
You can also get the same results with only one sub-query, something like this:
UPDATE foo f
   SET ( x, y ) = ( SELECT MAX (x) KEEP (DENSE_RANK LAST ORDER BY a_date)
                           ,        MAX (y) KEEP (DENSE_RANK LAST ORDER BY a_date)
              FROM   bar
              WHERE key     = f.key
            );I suspect MERGE will be more efficient.
Edited by: Frank Kulash on Mar 9, 2010 11:02 AM

Discoverer Subquery Help needed

Hi everyone,
I have a problem creating a nested subquery in Discoverer 4.
I want to create three sheets: A, B and C. Sheet A is a query on the database, retrieving all Id's that meet a certain condition. Sheet B needs to referr to sheet A and query the database for those Id's from A that meet another set of conditions. Its not possible to create a condition that combines the two, because it would require two loops over the database.
Now, here is the problem: sheet C needs to referr to the results of both sheets A and B to find a certain result in the database.
The problem is that Discoverer doesn't allow me to referr to two different subqueries in the same condition.
For example:
C_Id = A_Id (Subquery sheet A)
AND
C=Id <> B_Id (Subquery sheet B)
Does anyone know how to create those three sheets and make sheet C able to referr to both sheets A and B as a subquery?

Hi Rod,
Thanks for the reply.
I could find out that it was a view that was created when i had scheduled a workbook and it became invalid because we had changed the schema of the views being used the report and dropped the views from the earlier schema.
I again have one question, when the report is scheduled there are two objects formed in the backend :
EUL5_B090912142833Q1V1
EUL5_B090912142833Q1R1
The only difference between the two is that one is a view(with V1 suffixed) and the other is a table (with R1 suffixed).
What is the significance of these two objects and does the view becoming invalid impact anything as the scheduled report fetches data from the table EUL5_B090912142833Q1R1.
Regards,
Shruti

Ref Cursors / throwing data into a Ref Cursor as data is fetched

I was wondering if anyone has executed an SQL statement and as each row is being fetched back from an SQL, doing some data checks and processing to see if the row is valid to return or not, based on the values being fetched in an SQL.
For example, I'm taking an SQL statement and trying to do some tuning. I have an Exists clause in the Where statement that has a nested sub-query with some parameters passed in. I am attempting to move that statement to a function call in a package (which is called in the SELECT statement). As I fetch each row back, I want to check some values that are Selected and if the values are met, then, I want to execute the function to see if the data exists. If it does exist, then, I want the fetched row returned in the Ref Cursor. If the criteria is met and the row doesn't exist in the function call, then, I don't want the fetched row to return.
Right now, the data has to be thrown to REF Cursor because it's being outputted to the Java application as a Result Set.
I've found many statements where you can take a SELECT statement and throw the Results in the Ref Cursor. But, I want to go a step further and before I throw each row in the Ref Cursor, I want to some processing to see if I put the Fetched Row in the Ref Cursor.
If someone has a better idea to accomplish this, I'm all ears. Like I say, I'm doing this method only for the sake of doing some database tuning and I think this will speed things up. Having the EXISTS clause works and it runs fast from an End-user standpoint but, when it processes on the database with the nested subquery, it is slow.
Here's an example of something that might be a problem (Notice the nested subquery). I moved the nested subquery to a function call written on the database package and make the call to the procedure/package in the SELECT statement. As I process each row, I want to check some values prior having the function call execute. If it meet some criteria, then the record is Ok to fetch and display in the Ref Cursor. If it does not meet the criteria and goes through the function and doesn't return data, then, I don't want the Fetched row from the main query to return the data.:
SELECT EMPNO,
FIRST_NAME,
LAST_NAME
FROM EMP E,
DEPT D
WHERE E.DEPTNO = D.DEPTNO
AND EXISTS (SELECT 'X'
FROM MANAGER M
WHERE M.MANAGER_ID = E.MANAGER_ID
AND MANAGER_TYPE IN (SELECT MANAGER_TYPE
FROM MANAGER_LOOKUP ML WHERE ML.MANAGER_TYPE = M.MANAGER_TYPE))
Any help or ideas of other things to try is appreciated. Keep in mind that I am returning this data to the Java application so, throwing the data to a Ref Cursor in the PL/SQL is the ideal method.
Chris

Ref cursors are not required nor desirable when writing java database application. Cursors are mentioned only once in the JDBC documentation reference guide, in the section "Memory Leaks and Running Out of Cursors".
In a word cursors are just plain ridiculous, and in fact I never used them in my 15+ years of application development practice:
http://vadimtropashko.wordpress.com/cursors/

Query Question - Linking in Time Span Data to Point-in-Time References

I am trying to pull historical data from a time-span table of records, using another point-in-time reference. I have been unsuccessful.
I've thrown some sample tables and data together to illustrate what I am seeking:
Create Table EmployeeInfo (
       id Number(10,0),               -- Employee ID Number
       Name VarChar2(32 Byte),        -- Employee Name
       CurrentShift VarChar2(2 Byte) -- Current Employee Shift
Create Table ShiftChanges (
       id Number(10,0),               -- Employee ID that this shift change record is for
       ChangeDate Date,               -- Date that this Change Took Place
       OldShift VarChar2(2 Byte),
       NewShift VarChar2(2 Byte)
Create Table TimeCard(
       id Number(10,0),               -- Employee ID Number for this Timecard
       WorkDay Date,                  -- What Day is this Timecard for?
       Hours Float(63)                -- Number of Hours worked.
COMMIT;
INSERT INTO EmployeeInfo VALUES (100,'John Doe','Days')
INSERT INTO EmployeeInfo VALUES (101,'Jane Doe','Days');
INSERT INTO TimeCard VALUES (100, to_date('01012010','ddmmyyyy'), 10.5);
INSERT INTO TimeCard VALUES (101, to_date('01012010','ddmmyyyy'), 10);
INSERT INTO TimeCard VALUES (100, to_date('02012010','ddmmyyyy'), 9);
INSERT INTO TimeCard VALUES (101, to_date('02012010','ddmmyyyy'), 10.5);
INSERT INTO TimeCard VALUES (100, to_date('03012010','ddmmyyyy'), 8);
INSERT INTO TimeCard VALUES (101, to_date('03012010','ddmmyyyy'), 7);
INSERT INTO ShiftChanges VALUES (100, to_date('02012010','ddmmyyyy'), 'Nights', 'Days');
COMMIT;I could do a query such as:
SELECT TC.id,
       EM.Name,
       TC.Workday,
       EM.CurrentShift AS Shift
FROM   TimeCard TC,
       EmployeeInfo EM
WHERE (TC.ID=EM.ID(+));But it will not give me the historical shift, only the current. Since John Doe changed shifts on Jan 2 from Nights to Days, the above query would not reflect it.
I have attempted to join the historical table using a less-than operator. This doesn't work since more than one row can be returned.
SELECT TC.id,
       EM.Name,
       TC.Workday,
       SC.NewShift AS Shift
FROM   TimeCard TC,
       EmployeeInfo EM,
       ShiftChanges SC
WHERE (TC.ID=EM.ID(+)) AND
       (TC.ID=SC.ID(+) AND TC.WORKDAY<=SC.WORKDAY(+));The problem stems from the fact that you need to examine multiple records in one table in order to obtain the correct historical data for the other.
The following SQL script {color:green}does work{color} - if the values are defined ahead of time.
DEFINE EMPID=101;
DEFINE CHGDATE=to_date('01/01/2010','dd/mm/yyyy');
SELECT SQ.Shift
FROM   (SELECT ShiftChanges.NewShift AS Shift,
                RANK() OVER (ORDER BY ShiftChanges.ChangeDate DESC) R
        FROM    ShiftChanges
        WHERE   ShiftChanges.id = &EMPID AND
                ShiftChanges.ChangeDate <= &CHGDATE
        ) SQ
WHERE R = 1However, I have been unsuccessful in adapting it to the example tables I provided. If I insert the query as an inline subquery* in the select statement, it won't work, since the criteria is nested two levels down, and I can only get parent values within the first level.
I haven't thought of a way I can do this using a nested subquery - I keep running into that problem - how do you link in Time-Span data with a point-in-time reference.
Any ideas / enlightening thoughts?
Thank You
{size:8}_SELECT * FROM V$VERSION information:_
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
PL/SQL Release 9.2.0.8.0 - Production
"CORE     9.2.0.8.0     Production"
TNS for 32-bit Windows: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
{size}
user10879184 re-wrote the original post on 29-Mar-2010 1:21 PM to reflect suggestions made by poster.

I changed the tables to hold VARCHAR2(6) shift information and your query to reference the ChangeDate column.
I also assume you meant to link a TimeCard entry with the most previous ShiftChange entry rather than one that occurs after the time worked (TC.WORKDAY>=SC.CHANGEDATE(+) rather than TC.WORKDAY<=SC.CHANGEDATE(+)):
Another issue you don't take into account the case where there has been no shift change. In that event you need the current shift from the EmployeeInfo table which is taken care of with the NVL function.
You correctly note that multiple shift change records will result in duplicate TimeCard records though your test data fails to check for that condition. I added this row:
SQL> INSERT INTO ShiftChanges VALUES (100, to_date('03012010','ddmmyyyy'), 'Days', 'Nights'); Now it is apparent
SQL> SELECT TC.id,
2         EM.Name,
3         TC.Workday,
4         NVL(SC.NewShift,EM.CurrentShift) AS Shift
5 FROM   TimeCard TC,
6         EmployeeInfo EM,
7         ShiftChanges SC
8 WHERE TC.ID=EM.ID(+) AND
9         TC.ID=SC.ID(+) AND TC.WORKDAY>=SC.CHANGEDATE(+);
        ID NAME                             WORKDAY   SHIFT
       100 John Doe                         01-JAN-10 Days
       100 John Doe                         02-JAN-10 Days
       100 John Doe                         03-JAN-10 Days
       100 John Doe                         03-JAN-10 Nights
       101 Jane Doe                         01-JAN-10 Days
       101 Jane Doe                         02-JAN-10 Days
       101 Jane Doe                         03-JAN-10 Days
7 rows selected.The reason for the duplicate Jan3 time is the two shift change records. We are matching both ShiftChange records that occured before the 3rd.
We also see that your test data has John starting out on Days and then shifting from Nights to Days on the 2nd for no real change. Fixing that:
SQL> DELETE from ShiftChanges where ID = 100;
2 rows deleted.
SQL> INSERT INTO ShiftChanges VALUES (100, to_date('02012010','ddmmyyyy'), 'Days', 'Nights');
1 row created.
SQL> INSERT INTO ShiftChanges VALUES (100, to_date('03012010','ddmmyyyy'), 'Nights', 'Days');
1 row created.Then:
SQL> SELECT TC.id,
2         EM.Name,
3         TC.Workday,
4         NVL(SC.NewShift,EM.CurrentShift) AS Shift
5 FROM   TimeCard TC,
6         EmployeeInfo EM,
7         (SELECT ID, Workday, ChangeDate, NewShift
8          FROM
9                 (SELECT TC2.ID, TC2.Workday, SC2.ChangeDate, SC2.Newshift,
10                         MAX (SC2.ChangeDate) KEEP (DENSE_RANK LAST ORDER BY SC2.ChangeDate)
11                                              OVER (PARTITION BY SC2.ID, TC2.Workday) AS Max_ChangeDate
12                  FROM   ShiftChanges SC2,
13                         TimeCard TC2
14                  WHERE TC2.Workday >= SC2.ChangeDate
15                  AND    TC2.ID = SC2.ID
16                  )
17          WHERE   ChangeDate = Max_ChangeDate
18          ) SC
19 WHERE TC.ID=EM.ID(+) AND
20         TC.ID=SC.ID(+) AND
21         TC.Workday=SC.ChangeDate(+) AND
22         TC.Workday = SC.Workday(+);
        ID NAME                             WORKDAY   SHIFT
       100 John Doe                         01-JAN-10 Days
       100 John Doe                         02-JAN-10 Nights
       100 John Doe                         03-JAN-10 Days
       101 Jane Doe                         01-JAN-10 Days
       101 Jane Doe                         02-JAN-10 Days
       101 Jane Doe                         03-JAN-10 Days
6 rows selected.The inline view finds the greatest ChangeDate less than the TimeCard Workday for each Workday.

Illegal use of sequence operator

Hi All,
In my map I am using a sequence in the expression operator and then I am putting the output to a joiner and after that data is moved to target table but while validating this map I am getting error:sequence operator r used in complex mapping which requires generation using nested subquery.sequences r not allowed to be used in nested subqueries. Can anyone tell me how can this issue be resolved.
Thanks n Regards,
Amrit

Hi,
You can try moving the Sequence operator after join, ie as a final step close to target.
Mahesh

Queries with custom functions

Hi, Oracle gurus,
I experienced recently an issue with SQL performance when playing with queries using PL/SQL functions.
Let’s look at the following query:
SELECT my_package.my_function(x)
FROM Xvalues
This query returns values calculated by a PL/SQL function “my_function” in “my_package” package. The function performs some CPU intensive computations so that it takes it approx. 1 second to return a value. If the “Xvalues” table contains 100 rows then it takes Oracle 100 seconds to complete the query. OK.
Now I want to filter only non null results so that my query may look as:
SELECT y
FROM (
SELECT my_package.my_function(x) y
FROM Xvalues
WHERE y IS NOT NULL
It was surprising for me that it took Oracle ca. 200 seconds to complete this query, twice as long as the original one. I believe that the optimizer resolves this query to something like this:
SELECT my_package.my_function(x) y
FROM Xvalues
WHERE my_package.my_function(x) IS NOT NULL
When processing such a query Oracle first evaluates the WHERE clause to decide to return output values specified in the SELECT clause or not. That’s logical in most situations, but in this particular case it leads to longer execution time.
What I do to workaround this problem is splitting the query. First I put all values into a temporary table using
INSERT INTO TempTable
(SELECT my_package.my_function(x)
FROM Xvalues)
and then select non null results with another query
SELECT y
FROM TempTable
WHERE y IS NOT NULL
The whole execution time shrinks to original ca. 100 seconds what I wanted to achieve. Nevertheless I am not satisfied with this solution because it introduces some intermediate steps. This is only a simplified example but in fact my query is much more complex, consists of many nested subqueries, etc. and this approach – although effective – would require dozens of temporary tables and make the whole query unclear.
I wonder if there is a simpler solution possible, for example to have one single hierarchical query like above one and force Oracle first to fully process the nested subquery and then the embracing one? The goal is to decrease waiting for filtered results down to original 100 seconds (or a bit longer) …
Any suggestions will be greatly appreciated!
Greg

Maybe Tom Kyte's "trick" of the "select pl_sql_function () from dual" to invoke scalar subquery caching can help you:
select ename
from emp, dept
where (select dname_lookup(emp.deptno) from dual) = 'SALES'
and dept.deptno = 30
and emp.deptno = dept.deptno;http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1547006324238
As Tom says, in 11g you'll be able to cache that function (new 11g feature) which removes the need for the "trick":
Oracle® Database PL/SQL Language Reference 11g Release 1 (11.1)
- 8 Using PL/SQL Subprograms
-- Using the Cross-Session PL/SQL Function Result Cache
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/subprograms.htm#BABFHACJ
"On the PL/SQL Function Result Cache" by Steven Feuerstein
http://www.oracle.com/technology/oramag/oracle/07-sep/o57plsql.html
Regards,
Zlatko

At which column i will create index ????

my query is as follows and please tell me at which column of the table i would create an index
select code, detail, nvl(sum(dr)-sum(cr),0) from spda
where sdate < '01-feb-09'
order by codebecause the query result very slow as there is above 3 million record in a table
Regards
M. Laeeque A.
Edited by: MLA on Feb 27, 2009 12:02 PM

MLA wrote:
my query is as follows and please tell me at which column of the table i would create an index
select code, detail, nvl(sum(dr)-sum(cr),0) from spda
where and sdate < '01-feb-09'because the query result very slow as there is above 3 million record in a tableYou've posted this request three times (with three different versions of above statement).
Which one would you like to get replied to?
If this is the nested subquery that is part of the query posted here: Query Response Very Slow
you should consider that the nested subquery is correlated to the outer query by this additional predicate:
WHERE SUBSTR(spda.mcode,1,2) || '-' || SUBSTR(spda.mcode,3,4) =
SUBSTR(ac.code,1,2) || '-' || SUBSTR(ac.code,3,4)So in order to optimize the nested subquery access path this should be taken into account.
As I've already pointed out in the other thread, getting rid of the nested subquery and instead using regular joins probably offers the best performance.
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/

Need help with calc from tables

I have a table that contains query #1 and have another table
that contains a field that needs to use the result of the cfset in
another calc.
The new calc in query #2 needs to divide the Num_Checks_Trans
from query #1 by the by the Weekly_Hours_Recorded in query #2.
Can anyone help me figure this out?
<b>1.</b>
<cfquery name="QryEmployeeDetail"
datasource="NBProdReports">
SELECT TblContractInfo_SubMenuTable.User_ID,
TblContractInfo_SubMenuTable.Contract_Number,
TblContractInfo_SubMenuTable.Transaction_Type,
TblContractInfo_SubMenuTable.Num_Checks_Trans, TblTransType.Value,
TblContractInfo_SubMenuTable.Notes, TblMasterTrans.Date_Opened
from TblContractInfo_SubMenuTable, TblMasterTrans,
TblTransType
WHERE TblContractInfo_SubMenuTable.Task_Number =
TblMasterTrans.Task_Number
and TblTransType.Transaction_Type =
TblContractInfo_SubMenuTable.Transaction_Type
And TblMasterTrans.Date_Opened BETWEEN
#createODBCDate(DED_startDate)# AND #createODBCDate(DED_endDate)#
order BY TblMasterTrans.Date_Opened ASC,
TblContractInfo_SubMenuTable.User_id ASC
</cfquery>
<cfset totalTrans = 0 />
<cfloop query="QryEmployeeDetail">
<cfset totalTrans = totalTrans +
(QryEmployeeDetail.Num_Checks_Trans * QryEmployeeDetail.Value)
/></cfloop>
Text
2.
<cfquery name="QryEmployeeDetail"
datasource="NBProdReports">
SELECT TblContractInfo_SubMenuTable.User_ID,
TblContractInfo_SubMenuTable.Contract_Number,
TblContractInfo_SubMenuTable.Transaction_Type,
TblContractInfo_SubMenuTable.Num_Checks_Trans, TblTransType.Value,
TblContractInfo_SubMenuTable.Notes, TblMasterTrans.Date_Opened
from TblContractInfo_SubMenuTable, TblMasterTrans,
TblTransType
WHERE TblContractInfo_SubMenuTable.Task_Number =
TblMasterTrans.Task_Number
and TblTransType.Transaction_Type =
TblContractInfo_SubMenuTable.Transaction_Type
And TblMasterTrans.Date_Opened BETWEEN
#createODBCDate(DED_startDate)# AND #createODBCDate(DED_endDate)#
order BY TblMasterTrans.Date_Opened ASC,
TblContractInfo_SubMenuTable.User_id ASC
</cfquery>

This can be rewritten as a single query which is good for a
number of reasons, including we only make one trip to the database
and we do our calculations on the SQL backend, which is faster than
doing them in CFML.
What you're going to want to do is SUM() the total
transaction values by having a column like SUM(Num_Checks_Trans *
Value) AS totalTrans. To get the value for your other column you
can calculate that like Num_Checks_Trans / Weekly_Hours_Recorded. I
didn't see the latter in either of your queries so I'm not sure
where it comes from, but you can definitely use it in your SELECT
clause when calculating.
Since SUM() is an aggregate function, you'll have to use a
GROUP BY clause to make it work. You'll have to GROUP BY each
column in the SELECT statement. If some of the columns have
differing data that you won't want to use in the GROUP, you can
always use a nested subquery as part of your FROM clause and then
join that to the original queries with the totals.
I hope that helps.
- William

XmlAgg first n ordered elements only problem

I cannot find a way on Oracle to limit the number of rows aggregated by XmlAgg to only the first n in a specified order. I have produced a simple example demonstrating my problem which should be easy to replicate, as follows:
I have two tables, INCIDENT and INCIDENT_LOG_ENTRY (there may be many entries for a given incident).
I wish to extract details (as XML) of an incident and its most recent two log entries only.
-- Create INCIDENT table and two incidents:
create table INCIDENT (ID NUMBER(10,0) PRIMARY KEY, INCIDENT_SUMMARY VARCHAR2(200));
insert into INCIDENT values (1, 'Hold up');
insert into INCIDENT values (2, 'Car Crash');
-- Create INCIDENT_LOG_ENTRY table and log entries for both incidents:
CREATE table INCIDENT_LOG_ENTRY (ID NUMBER(10,0) PRIMARY KEY, INCIDENT_ID NUMBER(10,0), ENTRY_DATE_TIME DATE, ENTRY_TEXT VARCHAR2(500));
insert into INCIDENT_LOG_ENTRY values (1, 1, TO_DATE('2009-01-01 08:15:11', 'YYYY-MM-DD HH24:MI:SS'), 'Hold up on Main Street');
insert into INCIDENT_LOG_ENTRY values (2, 1, TO_DATE('2009-01-01 08:17:40', 'YYYY-MM-DD HH24:MI:SS'), 'Suspect pursued in high speed chase');
insert into INCIDENT_LOG_ENTRY values (3, 1, TO_DATE('2009-01-01 08:20:29', 'YYYY-MM-DD HH24:MI:SS'), 'Suspect lost in traffic');
insert into INCIDENT_LOG_ENTRY values (4, 1, TO_DATE('2009-01-03 11:55:31', 'YYYY-MM-DD HH24:MI:SS'), 'Suspect apprehended in hospital');
insert into INCIDENT_LOG_ENTRY values (21, 2, TO_DATE('2009-01-01 08:29:15', 'YYYY-MM-DD HH24:MI:SS'), 'Collision between car jumping red light and lorry');
insert into INCIDENT_LOG_ENTRY values (22, 2, TO_DATE('2009-01-01 08:45:53', 'YYYY-MM-DD HH24:MI:SS'), 'Driver taken to hospital');
Here is the query (note order by is within xmlAgg as per Oracle documentation):
SELECT xmlAgg(xmlElement("INCIDENT", xmlForest(i.ID, i.INCIDENT_SUMMARY),
xmlElement("INCIDENT_LOG_ENTRIES",
(SELECT xmlAgg(xmlElement("INCIDENT_LOG_ENTRY", xmlForest(ile.ID, ile.ENTRY_DATE_TIME, ile.ENTRY_TEXT)) order by ile.ENTRY_DATE_TIME desc)
FROM INCIDENT_LOG_ENTRY ile
WHERE ile.INCIDENT_ID = i.ID
AND rownum <= 2
FROM INCIDENT i where i.ID = 1
And here is its output:
<INCIDENT>
<ID>1</ID>
<INCIDENT_SUMMARY>Hold up</INCIDENT_SUMMARY>
<INCIDENT_LOG_ENTRIES>
<INCIDENT_LOG_ENTRY>
<ID>2</ID>
<ENTRY_DATE_TIME>01-JAN-09</ENTRY_DATE_TIME>
<ENTRY_TEXT>Suspect pursued in high speed chase</ENTRY_TEXT>
</INCIDENT_LOG_ENTRY>
<INCIDENT_LOG_ENTRY>
<ID>1</ID>
<ENTRY_DATE_TIME>01-JAN-09</ENTRY_DATE_TIME>
<ENTRY_TEXT>Hold up on Main Street</ENTRY_TEXT>
</INCIDENT_LOG_ENTRY>
</INCIDENT_LOG_ENTRIES>
</INCIDENT>
This is not the desired result - I want the two most recent log entries (4 and 3). Clearly the rownum has taken effect before the ordering is applied by XmlAgg. However, if I try to force the ordering first by using a nested subquery, Oracle complains that the incident (table alias 'i') is not visible within the subquery:
SELECT xmlAgg(xmlElement("INCIDENT", xmlForest(i.ID, i.INCIDENT_SUMMARY),
xmlElement("INCIDENT_LOG_ENTRIES",
(SELECT xmlAgg(xmlElement("INCIDENT_LOG_ENTRY", xmlForest(ile.ID, ile.ENTRY_DATE_TIME, ile.ENTRY_TEXT)) order by ile.ENTRY_DATE_TIME desc)
FROM (select * from (select * from INCIDENT_LOG_ENTRY WHERE INCIDENT_ID = i.ID order by ENTRY_DATE_TIME) where rownum <= 2) ile
FROM INCIDENT i where i.ID = 1
Which results in:
SQL Error: ORA-00904: "I"."ID": invalid identifier
If anyone knows how to resolve this problem I would be extremely grateful.
(BTW, it works without any trouble on SQL Server:
select i.ID, i.INCIDENT_SUMMARY,
(select top 2 ile.ID, ile.ENTRY_TEXT, ile.ENTRY_DATE_TIME
from INCIDENT_LOG_ENTRY ile
where ile.INCIDENT_ID = i.ID
order by ile.ENTRY_DATE_TIME desc for xml path('INCIDENT_LOG_ENTRY'), type) as "INCIDENT_LOG_ENTRIES"
from INCIDENT i
where i.ID = 1
for xml path('INCIDENT'), type
Which yields the desired result:
<INCIDENT>
<ID>1</ID>
<INCIDENT_SUMMARY>Hold up</INCIDENT_SUMMARY>
<INCIDENT_LOG_ENTRIES>
<INCIDENT_LOG_ENTRY>
<ID>4</ID>
<ENTRY_TEXT>Suspect apprehended in hospital</ENTRY_TEXT>
<ENTRY_DATE_TIME>2009-01-03T11:55:31</ENTRY_DATE_TIME>
</INCIDENT_LOG_ENTRY>
<INCIDENT_LOG_ENTRY>
<ID>3</ID>
<ENTRY_TEXT>Suspect lost in traffic</ENTRY_TEXT>
<ENTRY_DATE_TIME>2009-01-01T08:20:29</ENTRY_DATE_TIME>
</INCIDENT_LOG_ENTRY>
</INCIDENT_LOG_ENTRIES>
</INCIDENT>
)

Hi,
Sorry, I don't know how to get the first 2 rows in the XML functions, which, no doubt, is the best way to do it.
At the table level, you can assign numbers to every log entry in a sub-query, and use that number (instead of ROWNUM) to get the top 2:
WITH   numbered_log_entry
AS
     SELECT     id, incident_id, entry_date_time, entry_text
     ,     RANK () OVER ( PARTITION BY incident_id
                           ORDER BY          entry_date_time     DESC
                    ) AS rnk
     FROM     incident_log_entry
SELECT xmlAgg ( xmlElement ( "INCIDENT"
                           , xmlForest (i.ID, i.INCIDENT_SUMMARY)
                   , xmlElement ( "INCIDENT_LOG_ENTRIES"
                                , ( SELECT xmlAgg ( xmlElement ( "INCIDENT_LOG_ENTRY"
                                                              , xmlForest ( ile.ID
                                                          , ile.ENTRY_DATE_TIME
                                                       , ile.ENTRY_TEXT
                                              ) order by ile.ENTRY_DATE_TIME desc
                              FROM    numbered_LOG_ENTRY ile     -- Changed
                              WHERE   ile.INCIDENT_ID      = i.ID
                              AND     rnk          <= 2     -- Changed
FROM    INCIDENT   i
where      i.ID        = 1;Notice that the main query is exatcly what you posted, except for the 2 line marked "Changed".
Thanks for posting the CREATE TABLE and INSERT statments! That made it really easy to test.
You may have noticed that this site compresses whitespace.
When you have to post formated code or output on this site, type these 6 characters:
{code}
(small letters only, inside curly brackets) before and after sections of formatted text, to preserve spacing.

Generating mixed case columns for XML using Object views

I am trying to model a query involving joins to generate hierarchical levels for XML document. I model it with an object view with a multicast subquery and the generated XML works fine except the following :
The generated XML creates a tag <view_column_name>_ITEM for the nested multicase subquery columns in the view and all the nested subquery view columns in upper case because the underlying table columns are in upper case. To better illustrate, please see the following example :
CREATE TYPE Tillinstance_t as object (
"Tillinstanceid" number
,"Stationid" number
,"Comment" varchar2(2000)
,"DepositID" number(38)
,"TimestampCreate" date
,"UseridCreate" number
,"TimestampChange" date
,"UseridChange" number
,"TimestampClosed" date
,"UseridClosed" number
,"TimestampBalance" date
,"UserIDBalance" number )
create type insts as table of Tillinstance_t ;
CREATE OR REPLACE VIEW till_view AS
SELECT t.tillid as "TillID"
, t.description as "Descr"
, t.word as "Word"
, t.Scopetypeid as "ScopeTypeId"
, t.displayOrder as "DisplayOrder"
, t.useridcreate as "UserIDCreate"
, t.newid as "NewID"
, t.flagactive as "FlagActive"
, t.timestampcreate as "TSCR"
, t.useridcreate as "UIDCR"
, t.timestampchange as "TSCH"
, t.useridchange as "UIDCH"
, CAST( MULTISET ( SELECT i.Tillinstanceid as "TillinstanceID"
, i.stationid as "StationID"
, i.ocomment as "Comment"
, i.depositid as "DepositID"
, i.Timestampcreate as "TSCR"
, i.useridcreate as "UIDCR"
, i.Timestampchange as "TSCH"
, i.useridchange as "UIDCH"
, i.timestampclosed as "TSCL"
, i.useridclosed as "UIDCL"
, i.timestampbalance as "TSBAL"
, i.useridbalance as "UIDBAL"
FROM TillInstance i
WHERE t.tillid = i.tillid)
AS Insts)
AS "Insts"
FROM ucTill t
The generated XML shows up in the form of :
<?xml version = '1.0'?>
<Tills>
<Till TillID="1002" Descr="Till #3" Word="Till3" ScopeTypeId="8"
DisplayOrder="0" UserIDCreate="296" TSCR="3/26/2001 0:0:0" UIDCR="296"
TSCH="5/4/2001 14:12:32" UIDCH="298">
<Insts>
<Insts_ITEM TILLINSTANCEID="1278" STATIONID="1057" OCOMMENT="Morning Till3"
TIMESTAMPCREATE="3/26/2001 0:0:0" USERIDCREATE="296" TIMESTAMPCHANGE="6/7/2001
8:26:49" USERIDCHANGE="99" TIMESTAMPCLOSED="6/7/2001 8:26:49"
USERIDCLOSED="99"/>
<Insts_ITEM TILLINSTANCEID="1362" STATIONID="1057" TIMESTAMPCREATE="6/7/2001
8:27:13" USERIDCREATE="99" TIMESTAMPCHANGE="6/11/2001 11:32:58"
USERIDCHANGE="320"/>
</Insts>
</Till>
</Tills>
Now How do I stripe out the _ITEM from the generated XML and change the columns TIMESTAMPCREATE, USERIDCLOSED etc to mixed case?
Any idea

I could generate the mixed case columns with no problem. It was my mistake and sorry for the inconvinience.
However I am running into problems modelling a nested hierarchical set of queries with levels more than 2.
Please advise of any sample code available anywhere.
For example I could do :
create table x1 ( id number , f1 varchar2(10));
creat table x2 ( id number , id_x1 number references x1(id) , f1 varchar2(10)) ;
create table x3 ( id number , id_x2 number references x2(id), f1 varchar2(10)) ;
To model this, I did
create type x3_typ as object ( id number, id_x2 number , f1 varchar2(10)) ;
create type x3_typ_t is table of x3_typ ;
create type x2_typ as object ( id number, id_x1 number , f1 varchar2(10), x3_list x3_typ_t ) ;
create type x2_typ_t is table of ref x2_typ ;
create type x1_typ as object ( id number
, f1 varchar2(10) , x2_list x2_typ_t ) ;
create or replace view x3_x2 as
select id , f1 , cast(multiset(select * from x3 ) as x3_typ_t ) as x3_list
If I try to use a view again like as given below, I get the Oracle inconsistent datatypes error.
create or replace view x2_x1 as
select id , f1 , cast(multiset(select * from x3_x2 ) as x2_typ_t ) as x2_list
I there a better way? Am I missing something? Please help.

Can a subquery be nested more than 2 levels in oracle 10g

hi
can a subquery be nested more than 2 levels in oracle..10g
thank u
rajiv
Message was edited by:
user500763

You will never learn anything about Oracle if you just keep posting your 1z0-001 exam questions here.
Look it up, try it, test it. Otherwise all you're learning how to do is cut and paste.

Nested subquery?

Similar Messages

Maybe you are looking for