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

Similar Messages

With new Free Characeristics Aggregates are not being used

Hi....i have a query from a multicube with two infocubes where i have two aggregates one for each cube...in my query both aggregates are being used with no problems....when i add a new free characteristic that appers on aggregates something happens and the aggregates are not being used anymore...i dont understand why this happens because i know that ......free characteristics ....doesnt affects the aggregates usage....is this correct??? or not?
Regards

Since this is an open forum, not Adobe support... you need to contact Adobe staff to help
Adobe contact information - http://helpx.adobe.com/contact.html
-Select your product and what you need help with
-Click on the blue box "Still need help? Contact us"
-or by telephone http://helpx.adobe.com/x-productkb/global/phone-support-orders.html

How to tell which Indexes are not being used?

We are a large development shop and have many customers. Our database design is very generic so that it works for all of our customers. Each night we use an SSIS ETL process to bring down large amounts of data from the iSeries into SQL. One
particularily large customer takes a very long time and we are looking for ways to speed up thier data import and transformation. I would like to see which indexes he does not use and possibly remove them. Each night we fully repopulate hundreds of staging
and ods tables and incrementally delete and repopulate the days work for a handful of history type tables. Removing some indexes off of the large tables could make a big impact.
How can i tell which indexes the customer does not use?

> IDENTIFYING UNUSED INDEXES IN A SQL SERVER DATABASE
Just because an index is not being used does not necessarily mean it should be removed.
> Index This: All About SQL Server Indexes
sp_BlitzIndex
José Diz Belo Horizonte, MG - Brasil

Spooling out profile that are not being used

hi guys,
is there anyway to spool out those profile that are not in used or assigned to any username or roles?

flaskvacuum wrote:
hi guys,
is there anyway to spool out those profile that are not in used or assigned to any username or roles?
SQL> CREATE PROFILE test LIMIT
2     FAILED_LOGIN_ATTEMPTS 5
3     PASSWORD_LIFE_TIME 60
4     PASSWORD_REUSE_TIME 60
5     PASSWORD_REUSE_MAX 5
6     PASSWORD_VERIFY_FUNCTION null
7     PASSWORD_LOCK_TIME 1/24
8     PASSWORD_GRACE_TIME 10;
Profile created.
-- Created but not assigned --
SQL> select distinct profile from dba_profiles where profile not in (select profile from dba_users);
PROFILE
TEST
SQL>

Photo Geo tags are not being used by Places

I have been importing photos into iPhoto with valid geo tags and none of the photos are being shown on the Places map.
When I initially starting using iPhoto I imported some pictures from my iPhone and realised that the pictures were identified on the Places maps automatically, since I have added photos and manually edited the location information directly in Places.
If I import pictures from my iPhone they are not entered into Places and if you check all the location information is blank, if you look at the extended information you can see all the correct GPS information...
I'm confused..

in your iPhoto preferences is look up places set to "Automatically"? The default is "never" and it must be changed to "automatically" to work.
LN

How do I delete places in the organizer that are not being used?

In Elements Organizer 12, I think I accidentally created a "place" on the map that I do not want to apply to any photos. When I try to do conduct an advanced search, the place is appearing as a checkbox. I do not want this place to show up in the search field, as we have never been there. How do I remove places that are not associated with any photos?

If you are accessing emails from multiple devices, you are better off using the IMAP protocol. Then the devices sync with the server and they are all looking at the same information. With POP, you are going to get your emails spread about, some on Outlook, some on the iPad. It could get very confusing.
By default, the iPad will not delete from a POP server. Instructions for changing this are here: http://support.apple.com/kb/HT3228

How to remove the bufgs that are not being used

Hi,
I have a IP block that has BUFGs that may or may not be used depending on which design the IP block is used. If they are not used I would like them to be removed but the tools are not consistent, sometimes they remove them and sometimes they do not.
How do I specifically tell Vivado to remove a BUFG in the .XDC file?
I've seen someone suggest to use the following attribute in the VHDL file but I need something in the XDC file
attribute buffer_type of drck_i : signal is "none";
Thank you,
Luis

Hi
If the BUFG instance is instantiated in the IP or your design then the buffer_type attribute will not work.
The opt_design trims the unconnected instances during implementation. Ensure that the BUFG does not have DONT_TOUCH property set on it which might affect trimming.
Thanks,
Deepika.

How to identify SQL_PROFILES that are not being used?

In dba_hist_sqlstat table were found 26 Sql_Profiles, some of them are not used.
Questions:
- Is there any way to identify which one are not used?
I tried verifying DBA_SQL_PROFILES but this does not help to much.
- Analyzing one by one, Is the only way to find why they are not used?
Thanks,
Deyanira

Hello;
You should be able to Join the views DBA_USERS and DBA_PROFILES to see whats in use. ( or not in use )
select distinct
profile
from
dba_profiles
where
profile not in ( select profile from dba_users ) On the second question I would ask the DBA.
Best Regards
mseberg
Dan is correct. I have misread the question. Sorry about that.
Edited by: mseberg on Jun 28, 2012 3:06 PM

Is there a way of telling if tables in a schema are not being used?

I've thought about using the AUDIT_TRAIL.
Is there any query that you can run to tell this, without setting this up?

v$segment_statistics is one of the accumulator views that gets reset when the database is bounced. You'll probably want to take snapshots of the view regularly into a separate history table because of that.
Remember that you need to monitor for an appropriate period of time (you may have objects that are used only at month-end, only at year-end, or only for some process that happens on an irregular basis) to ensure that the objects are really and truly unused. Make sure that the business unit agrees as well-- there are plenty of tables that are kept around solely to comply with data retention policies. Dropping one of those tables caan quickly become a career limiting move should there ever be a records request from the legal department.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Index not being used in Oracle 11g

Hi,
I executed an SQL in Oracle 9i based on a Materialized View with an index. Execution plan shows it used Index and did Range scan. But the same query if I executed in Oracle 11g, it did full table scan and ignored the index. Finally, I used /*+Index*/ hint to tell compiler to use the index. Can anyone tell why it happended like this.
below is the query.
SELECT TYPE,NAME,PARENT_ID,CHILD_ID,UNIT_OF_MEASURE,QUANTITY,POSITION_NUMBER
FROM MVIEW_BOM_CHILD_ATTRIBUTES
WHERE BREAKDOWN_LIMIT = 'FALSE'
CONNECT BY PRIOR CHILD_ID = PARENT_ID START WITH PARENT_ID IN ('7325','34676','10121','35154','34370','4909','5494','28714','2273','22551','36465','35416','7148','34774',' 23290','18225','24415','35774','34772','20108','19072','8134','14688','31751','12669','26450','34716','768 4','26004','8770','34001','32614','3816','19801','30329','13822','15784','9296','17147','35423','6181','3477 3','18683','20780','35191','17990','7788','1559','7691','35449','34640','35432','35829','14161','9412','2039 2','593','23744','15741','35850','4177','36420','34695','33027','34655','31315','13552','23089','14025','901 2','22930','36182','13413','13839','32502','2392','19666','35183','32174','35170','20545','14344','29190','1 8163','19124','35448','32171','23498','2694','31101','4357','30421','35826','17976','13218','34770','35778' ,'16112','36408','34797','3294','9600','23524','3663','36412','34674','26715','2886','3204','15928','4510','8 112','27232','14966','35217','6281','1610','16359','25906','10262','3291','35777','11789','34675','24208','1 0093','28479','2928','23396','19702','32716','29813','2536','2349','34639','18610','35175','9796','26915','6 041','4745','34718','17946','3285','34308','9451','29689','17903','34642','35166','4630','35760','35761','34 696','27958','5912','35549','17695','31595','8028','24020','16025','8004','6430','36391','3580','32433','354 94','27368','15801','35583','35488','18807','34180','26626','20629','34767','14771','28746','34728','4948',' 34355','14000','34734','35820','36449','4904','11136','35177','27740','8016','13883','36402','35233','2614 7','21089','33152','35162','11320','32843','7336','34654','35602','32026','35582','24500','10573','33778','1 651','22781','25784','30124','10798','15930','28652','1513','745','35415','30404','21990','20872','2272','16 273','4234','35601','35581','22088','15543','3362','7713','35431','34719','27710','33104','20482','16801','1 686','35658','16545','32681','8722','20046','8950','34799','31605','21299','19572','445','35489','35656','35 546','7414','13369','35455','35434','35438','19383','10591','24698','14607','25715','27913','1046','15511',' 36386','6801','25134','2717','2083','35288','15851','14538','35398','11575','35156','35435','4232','36380',' 18406','32862','20879','5695','4229','24132','7081','35420','34694','22474','30047','29352','34735','2305',' 36409','18040','13472','31481','29246').
Thanks

SBH wrote:
My doubt is only that is it possible that a SQL query with same index proprties uses different access path to execute. Is it dependent on oracle version also.
Yes, it is possible.
It is even possible on the same Oracle version - look at simple examples:
case 1
create table test as
select level l, 'test' test from dual
connect by level < 1000;
create index test_ix on test(l);
explain plan for
select * from test where l < 50;
select * from table(dbms_xplan.display);
Plan hash value: 1408842701
| Id | Operation                   | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |         |    49 |   931 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST    |    49 |   931 |     3   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | TEST_IX |    49 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("L"<50)
Note
   - dynamic sampling used for this statement (level=2)case 2
drop table test;
create table test as
select * from (
select level l, 'test' test from dual
connect by level < 1000
) order by dbms_random.value(0,100);
create index test_ix on test(l);
explain plan for
select * from test where l < 50;
select * from table(dbms_xplan.display);
Plan hash value: 1357081020
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |    49 |   931 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST |    49 |   931 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("L"<50)
Note
   - dynamic sampling used for this statement (level=2)The same query on the same table containing the same data in it. And the same index.
The only difference is records order in the table.
In the first case CBO decided that index range scan would be reasonable.
In the second case CBO preferred FTS as less costly.

Check what oracle installed components are actually being used in database

I have been allotted a new database which I have to optimize. So I am thinking about removing some installed components which I think are not being used in any way in database (i.e procedures calls etc). I can see a whole lot of components like "SDO","ORDIM" which I think are not being used but previous DBAs have installed them. So, is there any way to ensure that no part of database are actually using these components so that I can remove these components. Also ,what are your expert comments about this?

Is this a production or a development environment? If an object isn't being used then it's not necessarily a problem (performance wise) unless it's cluttering up either your dictionary or raising concerns in regards consuming unnecessary space. Personally I'd recommend that it's better to tune what is being used / taking resources. It may be a once a year report or some old utility pulled out once a year, best check why these things are there.
If you go down the dropping route, rather than drop anything immediately lock accounts for an agreed period of time to make sure that the schema isn't used & check any references from other schemas to objects within the schema that you're planning to drop, potentially audit these to check whether they're being called by other schemas / checking dba_dependencies between schemas & objects using a hierarchical query to check sublevels.
There are also quite a few Oracle standard components that are installed by default that have interdependencies and won't necessarily be used in the dictionary (checking dba_features_usage_statistics)

Recently, my passwords on many websites are not being saved, forcing me to log in every 15 minutes or so. Is anyone else experiencing this? I am wondering if it is a result of a "bad" update?

For the past few weeks, I have noticed that passwords on many different websites are not being saved. I literally have to log back into each page every 15 minutes or so. Is this the result of a bad software update? Have an appointment at the Genius Bar tomorrow but if this can be resolved without going in, it would be preferred.

For what it's worth, you posted this in 2011, and here in 2014 I am still having this same issue. Over the last two days, I have had to unlock my apple account 8 times. I didn't get any new devices. I haven't initiated a password reset. I didn't forget my password. I set up two factor authentication and have been able to do the unlocking with the key and using a code sent to one of my devices.
That all works.
It's this having to unlock my account every time I go to use any of my devices. And I have many: iMac, iPad, iPad2, iPad mini, iPhone 5s, iPod touch (daughter), and my old iPhone 4 being used as an ipod touch now. They are all synced, and all was working just fine.
I have initiated an incident with Apple (again) but I know they are just going to suggest I change my Apple ID. It's a simple one, and one that I am sure others think is theirs. I don't want to change it. I shouldn't have to. Apple should be able to tell me who is trying to use it, or at least from where.
Thanks for listening,
Melissa

HT4623 I update my iPad mini retina with iOS 7.1 resulting in not being to down load NOR OPEN PPT, WORD files using iWork, page, can anyone pls help?

I update my iPad mini retina with iOS 7.1 resulting in not being to down load NOR OPEN PPT, WORD files using iWork, page, can anyone pls help?

You want to just use Dropbox until the dust settles. To use it from iWork for iOS (assuming you have the Dropbox app installed on your device), open the document in Keynote (for example), tap the share icon (box with upward pointing arrow), choose Open in Another App, choose Keynote as your format, then choose Open in Dropbox and you will get an option to save it to your Dropbox account. To open it from Dropbox in iWork for iOS, open the document in the Dropbox app, tap the share icon, tap Open in Keynote (for example). It's a bit clunky, but works.

I use imap and emails deleted on my computer are not being deleted on my iPhone?

i use imap and emails deleted on my computer are not being deleted on my iphone?

Didn't work. I also tried it by deleting the account and that hasn't worked. I still have all of the deleted messages on my iphone.

I rec'd an alert that my "Apple ID and phone no. are now being used for iCloud on a new iPhone." I am not using iCloud and I don't have a new iPhone. Is this something to worry about?

I rec'd an alert that my "Apple ID and phone no. are now being used for iCloud on a new iPhone." I am not using iCloud and I don't have a new iPhone. Is this something to worry about?

Howdy Libbidydooda,
There are a couple of possibilities that may apply to the email you have received regarding your Apple ID. The first is that the email may be a legitimate warning that your Apple ID has been compromised. For this reason I would suggest that you change the password to your Apple ID as soon as possible. Use the instructions on this page -
Apple ID: Changing your password - Apple Support
In order to increase security for your Apple ID you may want to set up and use two-step verification. See this article for information about it -
Frequently asked questions about two-step verification for Apple ID - Apple Support
The second possibilty is that the email is an attempt at "phishing" in order to get you to reveal personal information. Typically this is done with an email that looks like it comes from an official source but has links to web pages that, while they may look like they are real, may actually be gathering your information for use by others. This article has more information about phishing -
Identifying fraudulent "phishing" email - Apple Support
For this reason it is important that you do not follow any links in the email, as they may compromise your security.
Thanks for using Apple Support Communities.
Best,
Brett L

Nested subQuery results are not being used by Oracle 10g

Similar Messages

Maybe you are looking for