Indexes not getting used in schema having chinese data
I have a database with chinese data in it. When i execute few queries in that schema it does not use the available indexes of that table. Query takes long time to execute and the temp tablespace gets full. But when i execute the same query in another schema having english data the query executes quickly and uses all the indexes.
I tried gathering database statistics and rebuilding the indexes but that did not work out as well.
Can any body tell me whether the index creation differs for foreign languages? Do i need to create the indexes differently then normally we create?
why the indexes are not being used in the schema having chinese data?
Edited by: user621442 on Dec 17, 2009 10:03 AM
user621442 wrote:
I have a database with chinese data in it. When i execute few queries in that schema it does not use the available indexes of that table. Query takes long time to execute and the temp tablespace gets full. But when i execute the same query in another schema having english data the query executes quickly and uses all the indexes.
I tried gathering database statistics and rebuilding the indexes but that did not work out as well.
Can any body tell me whether the index creation differs for foreign languages? Do i need to create the indexes differently then normally we create?
why the indexes are not being used in the schema having chinese data?
Edited by: user621442 on Dec 17, 2009 10:03 AMHi,
I do not think so index would behave differently for different languages, yes sorting may behave in a diffierent way.
Can you post the explain plan from both the database.
And also nls_sort parameter from both the database.
I believe that you have order by clause which is not able to sort using index.
Regards
Anurag
Similar Messages
-
Index not getting used in spite of hints
Its Oracle 10g Release 10.2.0.4.0 Hi All,
I have this query in which there is are indexes on Intrument table like this:
Instrument:
idx 1 : (INSTRUMENT_ID, END_COB_DATE, CLOSE_ACTION_ID, PRODUCT_SUB_TYPE_ID, BEGIN_COB_DATE)
idx 2 : ( INSTRUMENT_ID, INSTRUMENT_VN, END_COB_DATE, CLOSE_ACTION_ID)
idx 3 : (CLOSE_ACTION_ID, END_COB_DATE)I tried all the possible ways but none of the indexes are getting used causing full table scans of this table. I need some guidance on how can I avoid this FTS so the query can run fast and use the index on Instrument table:
query:
select distinct i.instrument_id,
i.name,
case
when (mn2.display_name != 'DEBT PRIORITY CLASS' and
mn2.display_name is not null) then
mn2.display_name
else
mn1.display_name
end "DEBT_PRIORITY_CLASS"
from instrument i, inst_debt id
left join marsnode mn1 on (id.debt_priority_class_id = mn1.node_id and
mn1.close_date is null and
mn1.type_id = 58412926883279)
left join marsnodelink mnl1 on (mn1.node_id = mnl1.node_id and
mnl1.close_date is null and
mnl1.begin_cob_date <=
TO_DATE('27-Oct-2010', 'DD-Mon-YYYY') and
mnl1.end_cob_date >
TO_DATE('27-Oct-2010', 'DD-Mon-YYYY'))
left join marsnode mn2 on (mnl1.parent_id = mn2.node_id and
mn2.close_date is null and
mn2.type_id = 58412926883279)
where i.instrument_id = id.instrument_id
and i.instrument_vn = id.instrument_vn
AND i.end_cob_date > TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
AND i.close_action_id is null
AND i.product_sub_type_id = 3
AND i.begin_cob_date <= TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')This is the execution plan
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 2026K| 407M| | 509K (20)|
| 1 | HASH UNIQUE | | 2026K| 407M| 879M| 509K (20)|
|* 2 | HASH JOIN RIGHT OUTER | | 2026K| 407M| | 426K (23)|
|* 3 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 501 | 23046 | | 239 (3)|
|* 4 | INDEX RANGE SCAN | FKI_38576_TYPE_ID | 10159 | | | 34 (6)|
|* 5 | HASH JOIN RIGHT OUTER | | 2026K| 318M| | 425K (23)|
|* 6 | TABLE ACCESS FULL | MARSNODELINK | 330 | 15510 | | 6560 (16)|
|* 7 | HASH JOIN RIGHT OUTER | | 2026K| 228M| | 419K (23)|
|* 8 | TABLE ACCESS BY INDEX ROWID| MARSNODE | 501 | 23046 | | 239 (3)|
|* 9 | INDEX RANGE SCAN | FKI_38576_TYPE_ID | 10159 | | | 34 (6)|
|* 10 | HASH JOIN | | 2026K| 139M| 34M| 418K (23)|
| 11 | TABLE ACCESS FULL | INST_DEBT | 1031K| 22M| | 1665 (30)|
*|* 12 | TABLE ACCESS FULL | INSTRUMENT | 2062K| 96M| | 413K (23)|*
--------------------------------------------------------------------------------------------------predicate info
2 - access("MNL1"."PARENT_ID"="MN2"."NODE_ID"(+))
3 - filter("MN2"."CLOSE_DATE"(+) IS NULL)
4 - access("MN2"."TYPE_ID"(+)=58412926883279)
5 - access("MN1"."NODE_ID"="MNL1"."NODE_ID"(+))
6 - filter("MNL1"."CLOSE_DATE"(+) IS NULL AND "MNL1"."END_COB_DATE"(+)>TO_DATE('
2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "MNL1"."BEGIN_COB_DATE"(+)<=TO_DATE('
2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
7 - access("ID"."DEBT_PRIORITY_CLASS_ID"="MN1"."NODE_ID"(+))
8 - filter("MN1"."CLOSE_DATE"(+) IS NULL)
9 - access("MN1"."TYPE_ID"(+)=58412926883279)
10 - access("I"."INSTRUMENT_ID"="ID"."INSTRUMENT_ID" AND
"I"."INSTRUMENT_VN"="ID"."INSTRUMENT_VN")
12 - filter("I"."PRODUCT_SUB_TYPE_ID"=3 AND "I"."CLOSE_ACTION_ID" IS NULL AND
"I"."END_COB_DATE">TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"I"."BEGIN_COB_DATE"<=TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))Regards,
AashishAashish S. wrote:
I tried all the possible ways but none of the indexes are getting used causing full table scans of this table. I need some guidance on how can I avoid this FTS so the query can run fast and use the index on Instrument table:I assume the last part of the above statement is what you actually need to achieve (i.e. improve execution time of the query) and the query not using index is what you think the "cause" for the actual "problem". I will try to answer the actual "problem". Based on what you have posted, some observations/suggestions
1) Your plan shows the query is expected to retrieve 2026K rows. Are you sure you need to retrieve that many records? You may want to revisit the "requirement" here.
2) Continuing above point, you may want to post details of how much time the query is taking to execute at present and how much time do you expect it to take. Another most important details will be how are you measuring the query execution time. With that huge number of records, it is quite possible that more time is being spent in just transferring the query results to the "client" than actual time taken by server to execute the query.
3) If what you have posted is the order of columns in the indexes on INSTRUMENT table, then which index do you think will help the query execution and how? The order of columns suggest that none of the indexes will be good enough and that seems to be the right choice.
4) Your predicate section states that filter predicate on INSTRUMENT table generates 2062K rows. How many records exist in INSTRUMENT table? You will need to have many times more records (besides other factors like ordering of table data etc.) in the table to justify the indexed access to fetch these huge number of rows.
5) Finally, you may want to verify whether the statistics on tables and indexes used by the query are up-to-date.
Hope this helps. -
Index not getting used in the query(Query performance improvement)
Hi,
I am using oracle 10g version and have this query:
select distinct bk.name "Book Name",
fs.feed_description "Feed Name",
fbs.cob_date "Cob",
at.description "Data Type",
ah.user_name " User",
ah.comments "Comments",
ah.time_draft
from Action_type at,
action_history ah,
sensitivity_audit sa,
logical_entity le,
feed_static fs,
feed_book_status fbs,
feed_instance fi,
marsnode bk
where at.description = 'Regress Positions'
and fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011'
and fi.most_recent = 'Y'
and bk.close_date is null
and ah.time_draft = 'after'
and sa.close_action_id is null
and le.close_action_id is null
and at.action_type_id = ah.action_type_id
and ah.action_id = sa.create_action_id
and le.logical_entity_id = sa.type_id
and sa.feed_id = fs.feed_id
and sa.book_id = bk.node_id
and sa.feed_instance_id = fi.feed_instance_id
and fbs.feed_instance_id = fi.feed_instance_id
and fi.feed_id = fs.feed_id
union
select distinct bk.name "Book Name",
fs.feed_description "Feed Name",
fbs.cob_date "Cob",
at.description "Data Type",
ah.user_name " User",
ah.comments "Comments",
ah.time_draft
from feed_book_status fbs,
marsnode bk,
feed_instance fi,
feed_static fs,
feed_book_status_history fbsh,
Action_type at,
Action_history ah
where fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011'
and ah.action_type_id = 103
and bk.close_date is null
and ah.time_draft = 'after'
-- and ah.action_id = fbs.action_id
and fbs.book_id = bk.node_id
and fbs.book_id = fbsh.book_id
and fbs.feed_instance_id = fi.feed_instance_id
and fi.feed_id = fs.feed_id
and fbsh.create_action_id = ah.action_id
and at.action_type_id = ah.action_type_id
union
select distinct bk.name "Book Name",
fs.feed_description "Feed Name",
fbs.cob_date "Cob",
at.description "Data Type",
ah.user_name " User",
ah.comments "Comments",
ah.time_draft
from feed_book_status fbs,
marsnode bk,
feed_instance fi,
feed_static fs,
feed_book_status_history fbsh,
Action_type at,
Action_history ah
where fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011'
and ah.action_type_id = 101
and bk.close_date is null
and ah.time_draft = 'after'
and fbs.book_id = bk.node_id
and fbs.book_id = fbsh.book_id
and fbs.feed_instance_id = fi.feed_instance_id
and fi.feed_id = fs.feed_id
and fbsh.create_action_id = ah.action_id
and at.action_type_id = ah.action_type_id;This is the execution plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 231 | 43267 | 104K (85)|
| 1 | SORT UNIQUE | | 231 | 43267 | 104K (85)|
| 2 | UNION-ALL | | | | |
| 3 | NESTED LOOPS | | 1 | 257 | 19540 (17)|
| 4 | NESTED LOOPS | | 1 | 230 | 19539 (17)|
| 5 | NESTED LOOPS | | 1 | 193 | 19537 (17)|
| 6 | NESTED LOOPS | | 1 | 152 | 19534 (17)|
|* 7 | HASH JOIN | | 213 | 26625 | 19530 (17)|
|* 8 | TABLE ACCESS FULL | LOGICAL_ENTITY | 12 | 264 | 2 (0)|
|* 9 | HASH JOIN | | 4267 | 429K| 19527 (17)|
|* 10 | HASH JOIN | | 3602 | 90050 | 1268 (28)|
|* 11 | INDEX RANGE SCAN | IDX_FBS_CD_FII_BI | 3602 | 46826 | 22 (5)|
|* 12 | TABLE ACCESS FULL | FEED_INSTANCE | 335K| 3927K| 1217 (27)|
|* 13 | TABLE ACCESS FULL | SENSITIVITY_AUDIT | 263K| 19M| 18236 (17)|
| 14 | TABLE ACCESS BY INDEX ROWID | FEED_STATIC | 1 | 27 | 1 (0)|
|* 15 | INDEX UNIQUE SCAN | IDX_FEED_STATIC_FI | 1 | | 0 (0)|
|* 16 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 1 | 41 | 3 (0)|
|* 17 | INDEX RANGE SCAN | PK_MARSNODE | 3 | | 2 (0)|
|* 18 | TABLE ACCESS BY INDEX ROWID | ACTION_HISTORY | 1 | 37 | 2 (0)|
|* 19 | INDEX UNIQUE SCAN | PK_ACTION_HISTORY | 1 | | 1 (0)|
|* 20 | TABLE ACCESS BY INDEX ROWID | ACTION_TYPE | 1 | 27 | 1 (0)|
|* 21 | INDEX UNIQUE SCAN | PK_ACTION_TYPE | 1 | | 0 (0)|
|* 22 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 1 | 41 | 3 (0)|
| 23 | NESTED LOOPS | | 115 | 21505 | 42367 (28)|
|* 24 | HASH JOIN | | 114 | 16644 | 42023 (28)|
| 25 | NESTED LOOPS | | 114 | 13566 | 42007 (28)|
|* 26 | HASH JOIN | | 114 | 12426 | 41777 (28)|
|* 27 | HASH JOIN | | 957 | 83259 | 41754 (28)|
|* 28 | TABLE ACCESS FULL | ACTION_HISTORY | 2480 | 91760 | 30731 (28)|
| 29 | NESTED LOOPS | | 9570K| 456M| 10234 (21)|
| 30 | TABLE ACCESS BY INDEX ROWID| ACTION_TYPE | 1 | 27 | 1 (0)|
|* 31 | INDEX UNIQUE SCAN | PK_ACTION_TYPE | 1 | | 0 (0)|
| 32 | TABLE ACCESS FULL | FEED_BOOK_STATUS_HISTORY | 9570K| 209M| 10233 (21)|
|* 33 | INDEX RANGE SCAN | IDX_FBS_CD_FII_BI | 3602 | 79244 | 22 (5)|
| 34 | TABLE ACCESS BY INDEX ROWID | FEED_INSTANCE | 1 | 10 | 2 (0)|
|* 35 | INDEX UNIQUE SCAN | PK_FEED_INSTANCE | 1 | | 1 (0)|
| 36 | TABLE ACCESS FULL | FEED_STATIC | 2899 | 78273 | 16 (7)|
|* 37 | INDEX RANGE SCAN | PK_MARSNODE | 1 | | 2 (0)|
|* 38 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 1 | 41 | 3 (0)|
| 39 | NESTED LOOPS | | 115 | 21505 | 42367 (28)|
|* 40 | HASH JOIN | | 114 | 16644 | 42023 (28)|
| 41 | NESTED LOOPS | | 114 | 13566 | 42007 (28)|
|* 42 | HASH JOIN | | 114 | 12426 | 41777 (28)|
|* 43 | HASH JOIN | | 957 | 83259 | 41754 (28)|
|* 44 | TABLE ACCESS FULL | ACTION_HISTORY | 2480 | 91760 | 30731 (28)|
| 45 | NESTED LOOPS | | 9570K| 456M| 10234 (21)|
| 46 | TABLE ACCESS BY INDEX ROWID| ACTION_TYPE | 1 | 27 | 1 (0)|
|* 47 | INDEX UNIQUE SCAN | PK_ACTION_TYPE | 1 | | 0 (0)|
| 48 | TABLE ACCESS FULL | FEED_BOOK_STATUS_HISTORY | 9570K| 209M| 10233 (21)|
|* 49 | INDEX RANGE SCAN | IDX_FBS_CD_FII_BI | 3602 | 79244 | 22 (5)|
| 50 | TABLE ACCESS BY INDEX ROWID | FEED_INSTANCE | 1 | 10 | 2 (0)|
|* 51 | INDEX UNIQUE SCAN | PK_FEED_INSTANCE | 1 | | 1 (0)|
| 52 | TABLE ACCESS FULL | FEED_STATIC | 2899 | 78273 | 16 (7)|
|* 53 | INDEX RANGE SCAN | PK_MARSNODE | 1 | | 2 (0)|
------------------------------------------------------------------------------------------------------and the predicate info
Predicate Information (identified by operation id):
7 - access("LE"."LOGICAL_ENTITY_ID"="SA"."TYPE_ID")
8 - filter("LE"."CLOSE_ACTION_ID" IS NULL)
9 - access("SA"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
10 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
11 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
12 - filter("FI"."MOST_RECENT"='Y')
13 - filter("SA"."CLOSE_ACTION_ID" IS NULL)
15 - access("FI"."FEED_ID"="FS"."FEED_ID")
filter("SA"."FEED_ID"="FS"."FEED_ID")
16 - filter("BK"."CLOSE_DATE" IS NULL)
17 - access("SA"."BOOK_ID"="BK"."NODE_ID")
18 - filter("AH"."TIME_DRAFT"='after')
19 - access("AH"."ACTION_ID"="SA"."CREATE_ACTION_ID")
20 - filter("AT"."DESCRIPTION"='Regress Positions')
21 - access("AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
22 - filter("BK"."CLOSE_DATE" IS NULL)
24 - access("FI"."FEED_ID"="FS"."FEED_ID")
26 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
27 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
"AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
28 - filter("AH"."ACTION_TYPE_ID"=103 AND "AH"."TIME_DRAFT"='after')
31 - access("AT"."ACTION_TYPE_ID"=103)
33 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
35 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
37 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
38 - filter("BK"."CLOSE_DATE" IS NULL)
40 - access("FI"."FEED_ID"="FS"."FEED_ID")
42 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
43 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
"AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
44 - filter("AH"."ACTION_TYPE_ID"=101 AND "AH"."TIME_DRAFT"='after')
47 - access("AT"."ACTION_TYPE_ID"=101)
49 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
51 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
53 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
Note
- 'PLAN_TABLE' is old versionIn this query, mainly the ACTION_HISTORY and FEED_BOOK_STATUS_HISTORY tables are getting accessed fullly though there are indexes createdon them like this
ACTION_HISTORY
ACTION_ID column Unique index
FEED_BOOK_STATUS_HISTORY
(FEED_INSTANCE_ID, BOOK_ID, COB_DATE, VERSION) composite indexI tried all the best combinations however the indexes are not getting used anywhere.
Could you please suggest some way so the query will perform better way.
Thanks,
AashishHi Mohammed,
This is what I got after your method of execution plan
SQL_ID 4vmc8rzgaqgka, child number 0
select distinct bk.name "Book Name" , fs.feed_description "Feed Name" , fbs.cob_date
"Cob" , at.description "Data Type" , ah.user_name " User" , ah.comments "Comments"
, ah.time_draft from Action_type at, action_history ah, sensitivity_audit sa, logical_entity
le, feed_static fs, feed_book_status fbs, feed_instance fi, marsnode bk where at.description =
'Regress Positions' and fbs.cob_date BETWEEN '01 Feb 2011' AND '08 Feb 2011' and
fi.most_recent = 'Y' and bk.close_date is null and ah.time_draft='after' and
sa.close_action_id is null and le.close_action_id is null and at.action_type_id =
ah.action_type_id and ah.action_id=sa.create_action_id and le.logical_entity_id = sa.type_id
and sa.feed_id = fs.feed_id and sa.book_id = bk.node_id and sa.feed_instance_id =
fi.feed_instance_id and fbs.feed_instance_id = fi.feed_instance_id and fi.feed_id = fs.feed_id
union select distinct bk.name "Book Name" , fs.
Plan hash value: 1006571916
| Id | Operation | Name | E-Rows | OMem | 1Mem | Used-Mem |
| 1 | SORT UNIQUE | | 231 | 6144 | 6144 | 6144 (0)|
| 2 | UNION-ALL | | | | | |
| 3 | NESTED LOOPS | | 1 | | | |
| 4 | NESTED LOOPS | | 1 | | | |
| 5 | NESTED LOOPS | | 1 | | | |
| 6 | NESTED LOOPS | | 1 | | | |
|* 7 | HASH JOIN | | 213 | 1236K| 1236K| 1201K (0)|
|* 8 | TABLE ACCESS FULL | LOGICAL_ENTITY | 12 | | | |
|* 9 | HASH JOIN | | 4267 | 1023K| 1023K| 1274K (0)|
|* 10 | HASH JOIN | | 3602 | 1095K| 1095K| 1296K (0)|
|* 11 | INDEX RANGE SCAN | IDX_FBS_CD_FII_BI | 3602 | | | |
|* 12 | TABLE ACCESS FULL | FEED_INSTANCE | 335K| | | |
|* 13 | TABLE ACCESS FULL | SENSITIVITY_AUDIT | 263K| | | |
| 14 | TABLE ACCESS BY INDEX ROWID | FEED_STATIC | 1 | | | |
|* 15 | INDEX UNIQUE SCAN | IDX_FEED_STATIC_FI | 1 | | | |
|* 16 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 1 | | | |
|* 17 | INDEX RANGE SCAN | PK_MARSNODE | 3 | | | |
|* 18 | TABLE ACCESS BY INDEX ROWID | ACTION_HISTORY | 1 | | | |
|* 19 | INDEX UNIQUE SCAN | PK_ACTION_HISTORY | 1 | | | |
|* 20 | TABLE ACCESS BY INDEX ROWID | ACTION_TYPE | 1 | | | |
|* 21 | INDEX UNIQUE SCAN | PK_ACTION_TYPE | 1 | | | |
|* 22 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 1 | | | |
| 23 | NESTED LOOPS | | 115 | | | |
|* 24 | HASH JOIN | | 114 | 809K| 809K| 817K (0)|
| 25 | NESTED LOOPS | | 114 | | | |
|* 26 | HASH JOIN | | 114 | 868K| 868K| 1234K (0)|
|* 27 | HASH JOIN | | 957 | 933K| 933K| 1232K (0)|
|* 28 | TABLE ACCESS FULL | ACTION_HISTORY | 2480 | | | |
| 29 | NESTED LOOPS | | 9570K| | | |
| 30 | TABLE ACCESS BY INDEX ROWID| ACTION_TYPE | 1 | | | |
|* 31 | INDEX UNIQUE SCAN | PK_ACTION_TYPE | 1 | | | |
| 32 | TABLE ACCESS FULL | FEED_BOOK_STATUS_HISTORY | 9570K| | | |
|* 33 | INDEX RANGE SCAN | IDX_FBS_CD_FII_BI | 3602 | | | |
| 34 | TABLE ACCESS BY INDEX ROWID | FEED_INSTANCE | 1 | | | |
|* 35 | INDEX UNIQUE SCAN | PK_FEED_INSTANCE | 1 | | | |
| 36 | TABLE ACCESS FULL | FEED_STATIC | 2899 | | | |
|* 37 | INDEX RANGE SCAN | PK_MARSNODE | 1 | | | |
|* 38 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 1 | | | |
| 39 | NESTED LOOPS | | 115 | | | |
|* 40 | HASH JOIN | | 114 | 743K| 743K| 149K (0)|
| 41 | NESTED LOOPS | | 114 | | | |
|* 42 | HASH JOIN | | 114 | 766K| 766K| 208K (0)|
|* 43 | HASH JOIN | | 957 | 842K| 842K| 204K (0)|
|* 44 | TABLE ACCESS FULL | ACTION_HISTORY | 2480 | | | |
| 45 | NESTED LOOPS | | 9570K| | | |
| 46 | TABLE ACCESS BY INDEX ROWID| ACTION_TYPE | 1 | | | |
|* 47 | INDEX UNIQUE SCAN | PK_ACTION_TYPE | 1 | | | |
| 48 | TABLE ACCESS FULL | FEED_BOOK_STATUS_HISTORY | 9570K| | | |
|* 49 | INDEX RANGE SCAN | IDX_FBS_CD_FII_BI | 3602 | | | |
| 50 | TABLE ACCESS BY INDEX ROWID | FEED_INSTANCE | 1 | | | |
|* 51 | INDEX UNIQUE SCAN | PK_FEED_INSTANCE | 1 | | | |
| 52 | TABLE ACCESS FULL | FEED_STATIC | 2899 | | | |
|* 53 | INDEX RANGE SCAN | PK_MARSNODE | 1 | | | |
Predicate Information (identified by operation id):
7 - access("LE"."LOGICAL_ENTITY_ID"="SA"."TYPE_ID")
8 - filter("LE"."CLOSE_ACTION_ID" IS NULL)
9 - access("SA"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
10 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
11 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
12 - filter("FI"."MOST_RECENT"='Y')
13 - filter("SA"."CLOSE_ACTION_ID" IS NULL)
15 - access("FI"."FEED_ID"="FS"."FEED_ID")
filter("SA"."FEED_ID"="FS"."FEED_ID")
16 - filter("BK"."CLOSE_DATE" IS NULL)
17 - access("SA"."BOOK_ID"="BK"."NODE_ID")
18 - filter("AH"."TIME_DRAFT"='after')
19 - access("AH"."ACTION_ID"="SA"."CREATE_ACTION_ID")
20 - filter("AT"."DESCRIPTION"='Regress Positions')
21 - access("AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
22 - filter("BK"."CLOSE_DATE" IS NULL)
24 - access("FI"."FEED_ID"="FS"."FEED_ID")
26 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
27 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
"AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
28 - filter(("AH"."ACTION_TYPE_ID"=103 AND "AH"."TIME_DRAFT"='after'))
31 - access("AT"."ACTION_TYPE_ID"=103)
33 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
35 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
37 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
38 - filter("BK"."CLOSE_DATE" IS NULL)
40 - access("FI"."FEED_ID"="FS"."FEED_ID")
42 - access("FBS"."BOOK_ID"="FBSH"."BOOK_ID")
43 - access("FBSH"."CREATE_ACTION_ID"="AH"."ACTION_ID" AND
"AT"."ACTION_TYPE_ID"="AH"."ACTION_TYPE_ID")
44 - filter(("AH"."ACTION_TYPE_ID"=101 AND "AH"."TIME_DRAFT"='after'))
47 - access("AT"."ACTION_TYPE_ID"=101)
49 - access("FBS"."COB_DATE">=TO_DATE(' 2011-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"FBS"."COB_DATE"<=TO_DATE(' 2011-02-08 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
51 - access("FBS"."FEED_INSTANCE_ID"="FI"."FEED_INSTANCE_ID")
53 - access("FBS"."BOOK_ID"="BK"."NODE_ID")
Note
- Warning: basic plan statistics not available. These are only collected when:
* hint 'gather_plan_statistics' is used for the statement or
* parameter 'statistics_level' is set to 'ALL', at session or system level
122 rows selected.
Elapsed: 00:00:02.18The action_type_id column is of NUMBER type. -
Hi,
Oracle version 10g
I have created a partitioned table and it has the below columns:
The table is partitioned on the created_date.
How data gets inserted into this table:
we have a staging table which will get first populated and then using Exchange partitionis populated.
statement which populates rel_table
' ALTER TABLE ' || table1 ||
' EXCHANGE PARTITION ' ||partitionname ||
' WITH TABLE ' || table2 ||
' WITH VALIDATION UPDATE GLOBAL INDEXES';
after exchange partition the indexs gets rebuild
The table would have millions of records.
Now if i issue a query
plz help...But the indexed column is used in the join, so the index should get used right?Not necessarily. How many rows are in the table? How many rows have that column > 0?
Please read these:
When your query takes too long
When your query takes too long ...
How to Post a SQL statement tuning request
HOW TO: Post a SQL statement tuning request - template posting -
Can't i use xml schema and oledb data connection at the same time?
Hello to all and thanks in advance.I use xml schema and oledb data connection at the same time and the problem is that when I try to export the xml, the outcome is not what i expect.Without the oledb connection everything is ok (just the schema) and the xml complies with the schema.
Can't i have both schema and oledb and the exported xml be as i want it?You can use both at the same time, but not gor Internet access if that's what you're asking.
Now there is a thing called Link Aggregation, which combines a number of interfaces for speed/redundancy, but it really only works locally, and then only with ALL special equipment in the route, and most likely OSX Server involved.
Sorry. -
Could not get F4 help assigne to Formula date on web
Hi All,
When i run my query in web , i could not get F4 help assigne to Formula date variable which is processing by customer exit and ready for input.
can u lease help me in this .
Thanks
ManSee these Norton support threads for information about Firefox 8.0 compatibility.
360 <br />
http://community.norton.com/t5/Norton-360/Firefox-8-Support-for-Norton-Toolbar/td-p/581640
NIS <br />
http://community.norton.com/t5/Norton-Internet-Security-Norton/Firefox-8-Support-for-Norton-Toolbar/td-p/581516 -
Custom color scheme xml not getting used
I have a custom color scheme. I used the advanced settings.
Some of the color scheme settings are getting picked up but I don't think any of the advanced ones are.
The advanced settings ARE getting written to the color scheme's xml document (XcelsiuscustomThemes/mySchemeName.xml
)... so that's good. Here's an example:
<ListView>
<headerStyleName.color>0xE1EFF7</headerStyleName.color>
<textSelectedColor>0x333333</textSelectedColor>
<headerStyleName.textSelectedColor>0x333333</headerStyleName.textSelectedColor>
</ListView>
Is there someplace I need to point to the XcelsiuscustomThemes/mySchemeName.xml ? So that those styles get used ?
Incidentally, If I edit the programfiles(x86)/.../themes/DefaultMapping.xml document -- then any changes are reflected... so it seems like I just need to be able to tell xcelsius to use the XcelsiuscustomThemes/mySchemeName.xml instead of the DefaultMapping.xmlHi Hema
They should be located here:
C:\Program Files\Business Objects\Xcelsius\assets\themes\custom
OR:
C:\Documents and Settings\<User Name>\Application Data\XcelsiuscustomThemes
Regards
Charles
Edited by: Charles Davies on Oct 5, 2009 5:11 PM -
Linguistic index not being used
I am using 10G database and am having an issue that my linguistic index is not being used during sorting.
Any help will be appreciated.
Table structure.
create table TEST
ID CHAR(256) not null,
NAME VARCHAR2(100) not null,
DESIGNATION VARCHAR2(200)
alter table TEST add constraint ID primary key (ID)
create index TEST_IDX on TEST (NLSSORT(NAME,'nls_sort=''GENERIC_M'''))
Number of rows - 1 million
Query being run.
alter session set nls_sort='Generic_M';
select * from test order by name;
Explain plan
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1001K| 270M| | 70194 (1)| 00:14:0
3 |
| 1 | SORT ORDER BY | | 1001K| 270M| 579M| 70194 (1)| 00:14:0
3 |
| 2 | TABLE ACCESS FULL| TEST | 1001K| 270M| | 9163 (1)| 00:01:5
0 |
--------------------------------------------------------------------------------I don't think that's true, at least with the nls_sort function. I'm running into the same problem now, and I've traced with and without the use of the index, and it's definitely better with the index.
Here it is, not using the index:
SQL> select * from test where col2='sfs';
no rows selected
Execution Plan
Plan hash value: 1357081020
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST | 1 | 366 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('7366730
0') )
Note
- dynamic sampling used for this statement
Statistics
87 recursive calls
0 db block gets
21 consistent gets
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
327 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
And here it is WITH the index:
SQL> select /*+ index_asc(test index1) */ * from test where col2='adsfas';
no rows selected
Execution Plan
Plan hash value: 2960817241
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
| 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:0
0:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 366 | 2 (0)| 00:0
0:01 |
|* 2 | INDEX FULL SCAN | INDEX1 | 1 | | 1 (0)| 00:0
0:01 |
Predicate Information (identified by operation id):
2 - access(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
0') )
filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
0') )
Note
- dynamic sampling used for this statement
Statistics
11 recursive calls
0 db block gets
7 consistent gets
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
327 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
Oddly enough, the optimizer chooses not to use the index on this example table I created. -
SALV - ALV selected row Index - Not getting in second time
I am having a ALV grid using CL_SALV_TABLE class. and its have PF-status button "Display" and user select a line and press "Display" button system will display a PDF document from content server.
The following is the code i am using for getting index of selected row.
My problem is user select a line for the first time i am getting the index, but user select second time i am not getting the index
module user_command_0300 input.
call method cl_gui_cfw=>dispatch.
case ok_code.
when c_hist.
perform f_show_history.
when others.
endcase.
clear ok_code.
endmodule.
then
form f_show_history.
data : p_wa_rows type int4.
data : p_i_rows type salv_t_row.
gr_table->get_metadata( ).
p_i_rows = gr_selections->get_selected_rows( )." Here Its failing in second time. P_I_ROWS showing blank second time
clear: wa_output.
read table p_i_rows into p_wa_rows index 1.
if sy-subrc eq 0.
read table i_output into wa_output index p_wa_rows.
if sy-subrc eq 0.
perform f_display_document.
endif..
endif.
refresh : p_i_rows. clear : p_i_rows.
gr_selections = gr_table->get_selections( ).
gr_selections->set_selected_rows( p_i_rows ).
gr_table->refresh( ).
call method cl_gui_cfw=>set_new_ok_code( new_code = 'REFR' ).
endform. " F_show_history
PS : I don't want to place the button in the ALV application toolbar
a®Hi Dear,
I have some clue regarding your problem but that is in simple Alv not in oops.
declare a first field of your internal table i.e. you are passing to alv as cell type c.
then in layout
add
gs_layout-box_fieldname = 'SEL'.
pass this layout to alv.
then you are able to get exact row number.
LOOP AT gt_gi INTO gs_gi WHERE sel = 'X'.
gs_gi-sel = ' '.
APPEND gs_gi TO gt_gi.
CLEAR gs_gi.
ENDLOOP.
Hope this clue will help you.
Regards,
Vijay -
Index not being used in Select statement
Friends
I have the following SQL statement:
SELECT
a.acct,
a.date_field,
UPPER(b.feegroup) feegrp,
SUM (a.fee1) fee1,
SUM (a.fee2) fee2,
SUM (a.fee3) fee3
FROM table1 a, table2 b
WHERE 1 = 1
AND a.fee_id = b.fee_id
GROUP BY a.acct, a.date_field, b.feegroup;
Both the tables have index on fee_id column. When I run the explain plan for this statement, I am getting the following output:
Operation | Option | Object Name | Position
SELECT STATEMENT | | | 560299
HASH | GROUP BY| |1
TABLE ACCESS | FULL| table2 | 1
TABLE ACCESS | FULL| table1 | 2
Why Oracle is not using the index?
Edited by: darshilm on Dec 10, 2009 3:56 PMThe proposed plan is the optimal according to your current conditions in the "where clause" where you have only the equality join condition and therefore the CBO can use HASH JOIN. Using any kind of index access would just increase the amount of required work unless you would add some very restrictive conditions which will select rows from relatively small amount of blocks. Here I have to mention that what really counts in the CBO cost calculation is the amount of blocks accessed and not the number of rows. The "currency" for I/O in Oracle is a block and not a row. CBO always uses an assumption that there is nothing in the buffer cache and it will have to perform a physical read for every block.
How many blocks will actually be accessed depends on the data distribution. It can happen that every single row that you have to retrieve resides in a different block and although you access only 1000 rows out of a million row table you would have to visit almost every block of that table. For such a situation a FULL TABLE SCAN is the best access path and Oracle will use multiblock I/O for that. On the other side you can have those 1000 rows only in a few blocks and then the index access would be the most appropriate one. For index access Oracle uses single block I/O. Usually the actual situation is somewhere between this two extreme situations. But you can run some tests by yourself and see when an index access will be replaced by a full table scan while you will make your predicates less selective.
HTH, Joze
Co-author of the forthcoming book "Expert Oracle Practices"
http://www.apress.com/book/view/9781430226680
Oracle related blog: http://joze-senegacnik.blogspot.com/
Blog about flying: http://jsenegacnik.blogspot.com/
Blog about Building Ovens, Baking and Cooking: http://senegacnik.blogspot.com -
Dear All,
Having real trouble these days with the indexes.
I have a query below:
SELECT MAX(A.ID) PRID,TIMEPERIODID,RESOURCEID
FROM TIMESHEET A, TIMEPERIOD B
WHERE A.STATUS IN (1,3,4) AND A.ISADJUSTMENT = 0
AND A.timeperiodid = B.id
AND TRUNC(B.PSTART)>=TRUNC(NEXT_DAY(SYSDATE-28,'MONDAY'))
GROUP BY TIMEPERIODID,RESOURCEID
The explain plan for this query is as below:
Plan COST
SELECT STATEMENT 2720
SORT GROUP BY 2720
HASH JOIN 2520
TABLE ACCESS FULL TIMEPERIOD 2
TABLE ACCESS FULL TIMESHEET 2516As you can see, table access full on timesheet table. However, I have an index on timeperiodid column of the table. Despite using it as hint, the index is not being used. Is it that indexes are not used with GROUP BY?
Please help.
Thanks,and the explain plan:
Plan
SELECT STATEMENT ALL_ROWSCost: 18,747 Bytes: 105 Cardinality: 1
34 SORT GROUP BY Cost: 18,742 Bytes: 105 Cardinality: 1
33 FILTER
21 NESTED LOOPS Cost: 18,727 Bytes: 105 Cardinality: 1
18 HASH JOIN Cost: 18,722 Bytes: 415 Cardinality: 5
11 TABLE ACCESS BY INDEX ROWID TIMEENTRY Cost: 14 Bytes: 144 Cardinality: 9
10 NESTED LOOPS Cost: 15,980 Bytes: 15,552 Cardinality: 243
8 HASH JOIN Cost: 15,588 Bytes: 1,344 Cardinality: 28
3 HASH JOIN Cost: 4,050 Bytes: 24,876,930 Cardinality: 829,231
1 TABLE ACCESS FULL TEAM Cost: 3,394 Bytes: 879,444 Cardinality: 48,858
2 INDEX FAST FULL SCAN NON-UNIQUE TASK2 Cost: 396 Bytes: 11,656,104 Cardinality: 971,342
7 VIEW index$_join$_003 Cost: 10,376 Bytes: 24,981,984 Cardinality: 1,387,888
6 HASH JOIN Cost: 15,588 Bytes: 1,344 Cardinality: 28
4 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT1 Cost: 3,835 Bytes: 24,981,984 Cardinality: 1,387,888
5 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT4 Cost: 3,835 Bytes: 24,981,984 Cardinality: 1,387,888
9 INDEX RANGE SCAN NON-UNIQUE TIMEENTRY5 Cost: 2 Cardinality: 12
17 VIEW USER25. Cost: 2,741 Bytes: 553,812 Cardinality: 29,148
16 SORT GROUP BY Cost: 2,741 Bytes: 1,107,624 Cardinality: 29,148
15 HASH JOIN Cost: 2,540 Bytes: 1,107,624 Cardinality: 29,148
13 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1 Bytes: 140 Cardinality: 10
12 INDEX RANGE SCAN NON-UNIQUE TIMEPERIOD2 Cost: 1 Cardinality: 2
14 TABLE ACCESS FULL TIMESHEET Cost: 2,537 Bytes: 12,040,224 Cardinality: 501,676
20 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1 Bytes: 22 Cardinality: 1
19 INDEX UNIQUE SCAN UNIQUE TIMEPERIOD1 Cardinality: 1
32 NESTED LOOPS Cost: 5 Bytes: 75 Cardinality: 1
29 NESTED LOOPS Cost: 4 Bytes: 63 Cardinality: 1
27 NESTED LOOPS Cost: 2 Bytes: 37 Cardinality: 1
25 NESTED LOOPS Cost: 2 Bytes: 31 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID OBS_TYPES Cost: 1 Bytes: 18 Cardinality: 1
22 INDEX UNIQUE SCAN UNIQUE OBS_TYPES_U2 Cardinality: 1
24 INDEX RANGE SCAN NON-UNIQUE PROJECT_INDX1 Cost: 1 Bytes: 13 Cardinality: 1
26 INDEX UNIQUE SCAN UNIQUE PROJECTS_PK Bytes: 6 Cardinality: 1
28 INDEX RANGE SCAN NON-UNIQUE OBS_ASSOCIATIONS_N3 Cost: 2 Bytes: 26 Cardinality: 1
31 TABLE ACCESS BY INDEX ROWID OBS_UNITS Cost: 1 Bytes: 12 Cardinality: 1
30 INDEX UNIQUE SCAN UNIQUE OBS_UNITS_U1 Cardinality: 1 -
Newly created index not being used
Hello friends,
I am observing that a newly created index on a z table with mandt & a new field is not being used. I have already rebuild index & updated stats for table.
when we query on this table with where clause having same 2 fields mandt & other.. we expected this index to be used. This table is very large. What more i can do now ?
In trace/SQL session, we can see it is going full table scan.. and takes very long time.
this new field contain no data as of now for all existing rows. Is this the reason ? or sometihng else ?
SQL Statement
SELECT
FROM
"ABSA"
WHERE
"MANDT" = :A0 AND "ZABCD" = :A1
Execution Plan
Explain from v$sql_plan not possible -> Explain from PLAN_TABLE is displayed !
No values in v$sql_plan for Address: 0000000166710240 Hash_value: 3891403872 Child_number: 0 Sql_id:
SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
1 TABLE ACCESS FULL ZABSA
( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
Filter Predicates
NONUNIQUE Index ZABSA~Z01
Column Name #Distinct
MANDT 1
ZABCD 1
thanks & regards
ashish
Edited by: ashish vikas on Mar 3, 2012 9:05 PMashish vikas wrote:
> Execution Plan
> Explain from v$sql_plan not possible -> Explain from PLAN_TABLE is displayed !
> No values in v$sql_plan for Address: 0000000166710240 Hash_value: 3891403872 Child_number: 0 Sql_id:
>
> SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
>
> 1 TABLE ACCESS FULL ZABSA
> ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
> Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
> Filter Predicates
>
> NONUNIQUE Index ZABSA~Z01
> Column Name #Distinct
> MANDT 1
> ZABCD 1
Hi,
with this WHERE clause, both columns just one distinct value, the Full Table Scan is indded the best approach, beside
the point you only need a check to evaluate a value is NOT in the result.
In this case you should HINT the statement to the new index, because the DB will always assume that this index is non-selective.
Volker -
Force index not getting picked up while running the SQL Quer
Hi All,
We are facing an issue with one SQL Query. We have created a custom Index and we are using that index in our query by using the following syntax:
/*+INDEX(ol XXEXH_ORDER_LINES_N2)*/
Where
ol – Table Alias Name
XXEXH_ORDER_LINES_N2 – Index Name
But still the index is not getting picked up in the Explain Plan.
If any one of you have faced a similar issue then please let us know how you had resolved it.
Appreciate your help.
DB version:10.2.0.4
Apps version: 11.5.10.2.0
Regards,
Manpreet
Edited by: 876912 on Aug 3, 2011 2:49 AMHi;
For your issue i suggest close your thread here as changing thread status to answered and move it to Forum Home » Database or Forum Home » Database » SQL and PL/SQL which you can get more quick response
Regard
Helios -
Force index not getting picked up while running the SQL Query
Hi All,
We are facing an issue with one SQL Query. We have created a custom Index and we are using that index in our query by using the following syntax:
/*+INDEX(ol XXEXH_ORDER_LINES_N2)*/
Where
ol – Table Alias Name
XXEXH_ORDER_LINES_N2 – Index Name
But still the index is not getting picked up in the Explain Plan.
If any one of you have faced a similar issue then please let us know how you had resolved it.
Appreciate your help.
DB version:10.2.0.4
Apps version: 11.5.10.2.0
Thanks.The query and plan are given as:
SELECT
/*+INDEX(ol XXEXH_ORDER_LINES_N2)*/
ol.header_id,
ol.line_id,
ol.line_type_id,
ol.flow_status_code,
ol.last_update_date,
ol.inventory_item_id,
ol.ship_from_org_id,
oh.order_number,
ttv.NAME,
msib.segment1,
msib.item_type,
fl.segment1 || '-' || fl.segment2 || '-' || fl.segment3 || '-' || fl.segment4 current_loc,
ship_to.country
|| '-'
|| NVL (ship_to.state, ship_to.province)
|| '-'
|| DECODE (ship_to.county,
NULL, ship_to.city,
ship_to.county
|| DECODE (ship_to.country,
NULL, NULL,
'-' || ship_to.city
) new_loc,
mmt.transaction_type_id,
mtt.transaction_type_name,
DECODE (mil.segment1,
UPPER ('Field%'), 'PLEASE VALIDATE FIELD LOCATION',
hou.country
|| '-'
|| DECODE (mil.segment1,
UPPER ('Field%'), NULL,
hou.region_2
|| '-'
|| DECODE (mil.segment1,
UPPER ('Field%'), NULL,
hou.region_1
|| '-'
|| DECODE (mil.segment1,
UPPER ('Field%'), NULL,
hou.town_or_city
) rma_loc,
ship_su.attribute1 oper_loc,
msib.organization_id --SC#5878
,fa.asset_number --SC#5878
,fdh.code_combination_id --SC#5878
,fa.asset_id parent_asset_id
FROM fnd_flex_values_vl ffvv,
fnd_flex_value_sets ffvs,
mtl_item_locations mil,
--hr_organization_units_v hou,
hr_organization_units o,
-- hr_lookups l,
-- hr_lookups l2,
hr_locations hou,
hr_locations_all_tl lot,
mtl_transaction_types mtt,
mtl_material_transactions mmt,
hz_locations ship_to,
hz_cust_acct_sites ship_cas,
hz_cust_site_uses ship_su,
hz_party_sites ship_ps,
fa_distribution_history fdh,
fa_locations fl,
fa_additions fa,
mtl_system_items_b msib,
oe_transaction_types_tl ttv,
oe_order_headers oh,
oe_order_lines ol
WHERE ol.org_id = TO_NUMBER (fnd_profile.VALUE ('ORG_ID')) --SC#5878
AND ol.flow_status_code = 'CLOSED'
AND TRUNC(ol.last_update_date) BETWEEN '01-SEP-2010' AND '31-OCT-2010'
AND ol.header_id = oh.header_id
AND ol.line_type_id = ttv.transaction_type_id
AND ol.inventory_item_id = msib.inventory_item_id
AND ol.ship_from_org_id = msib.organization_id
AND msib.item_type = 'REN'
AND SUBSTR(fa.asset_number,1,DECODE(INSTR(fa.asset_number,'-'),0,LENGTH(fa.asset_number),INSTR(fa.asset_number,'-')-1)) = msib.segment1 -- SC#11824 / added for fetching all assets with any suffix/ on 20-JUL-2011 by MPRAKAS
AND fdh.asset_id(+) = fa.asset_id
AND fdh.location_id = fl.location_id(+)
AND fdh.date_ineffective IS NULL
AND ol.ship_to_org_id = ship_su.site_use_id
AND ship_su.cust_acct_site_id = ship_cas.cust_acct_site_id
AND ship_cas.party_site_id = ship_ps.party_site_id
AND ship_ps.location_id = ship_to.location_id
AND mmt.inventory_item_id = ol.inventory_item_id --added new condition
AND mmt.organization_id = ol.ship_from_org_id --added new condition
AND mmt.trx_source_line_id = ol.line_id
AND mmt.transaction_quantity > 0
AND mmt.transaction_type_id = mtt.transaction_type_id(+)
AND mtt.transaction_type_name(+) = 'RMA Receipt'
AND o.organization_id(+) = mmt.organization_id
AND mil.inventory_location_id(+) = mmt.locator_id
AND ffvs.flex_value_set_name = 'HCCA_AFF_LOCATION' --added new condition
AND ffvv.flex_value_set_id = ffvs.flex_value_set_id(+)
AND ffvv.flex_value(+) = ship_su.attribute1
AND ttv.LANGUAGE = 'US'
AND (ol.ordered_item_id IS NULL OR ol.ordered_item_id > 0)
AND NVL (ol.ship_to_org_id, 1) > 0
AND NVL (hou.location_id, 1) > 0
AND o.location_id = hou.location_id(+)
AND NVL (hou.business_group_id, NVL (hr_general.get_business_group_id, -99)) = NVL (hr_general.get_business_group_id, -99)
AND hou.location_id = lot.location_id
AND lot.LANGUAGE = USERENV ('LANG')
AND (fa.asset_id = fa.parent_asset_id OR fa.parent_asset_id IS NULL)
Plan
SELECT STATEMENT ALL_ROWSCost: 4,065 Bytes: 958 Cardinality: 2
125 CONCATENATION
62 NESTED LOOPS OUTER Cost: 3,140 Bytes: 479 Cardinality: 1
59 FILTER
58 NESTED LOOPS OUTER Cost: 3,139 Bytes: 441 Cardinality: 1
55 NESTED LOOPS Cost: 3,131 Bytes: 420 Cardinality: 1
52 NESTED LOOPS OUTER Cost: 3,130 Bytes: 390 Cardinality: 1
49 NESTED LOOPS OUTER Cost: 3,128 Bytes: 377 Cardinality: 1
46 NESTED LOOPS Cost: 3,127 Bytes: 351 Cardinality: 1
44 HASH JOIN Cost: 3,126 Bytes: 342 Cardinality: 1
42 NESTED LOOPS Cost: 2,443 Bytes: 324 Cardinality: 1
40 NESTED LOOPS Cost: 2,443 Bytes: 315 Cardinality: 1
38 NESTED LOOPS Cost: 2,443 Bytes: 306 Cardinality: 1
36 NESTED LOOPS Cost: 2,443 Bytes: 298 Cardinality: 1
33 NESTED LOOPS Cost: 2,442 Bytes: 268 Cardinality: 1
31 NESTED LOOPS Cost: 2,441 Bytes: 259 Cardinality: 1
28 NESTED LOOPS Cost: 2,438 Bytes: 238 Cardinality: 1
25 NESTED LOOPS Cost: 2,437 Bytes: 207 Cardinality: 1
22 NESTED LOOPS Cost: 2,436 Bytes: 194 Cardinality: 1
19 NESTED LOOPS Cost: 2,435 Bytes: 184 Cardinality: 1
16 NESTED LOOPS Cost: 2,433 Bytes: 168 Cardinality: 1
13 NESTED LOOPS Cost: 2,432 Bytes: 154 Cardinality: 1
10 NESTED LOOPS Cost: 2,430 Bytes: 126 Cardinality: 1
7 NESTED LOOPS Cost: 2,427 Bytes: 102 Cardinality: 1
4 NESTED LOOPS Cost: 779 Bytes: 34,028 Cardinality: 724
2 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUE_SETS Cost: 2 Bytes: 28 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_FLEX_VALUE_SETS_U2 Cost: 1 Cardinality: 1
3 TABLE ACCESS FULL TABLE AR.HZ_CUST_SITE_USES_ALL Cost: 777 Bytes: 13,756 Cardinality: 724
6 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_LINES_ALL Cost: 3 Bytes: 55 Cardinality: 1
5 INDEX RANGE SCAN INDEX ONT.OE_ORDER_LINES_N2 Cost: 2 Cardinality: 1
9 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_MATERIAL_TRANSACTIONS Cost: 3 Bytes: 24 Cardinality: 1
8 INDEX RANGE SCAN INDEX INV.MTL_MATERIAL_TRANSACTIONS_N1 Cost: 2 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_SYSTEM_ITEMS_B Cost: 2 Bytes: 28 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) INV.MTL_SYSTEM_ITEMS_B_U1 Cost: 1 Cardinality: 1
15 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCT_SITES_ALL Cost: 1 Bytes: 14 Cardinality: 1
14 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCT_SITES_U1 Cost: 0 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 2 Bytes: 16 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U1 Cost: 1 Cardinality: 1
21 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTY_SITES Cost: 1 Bytes: 10 Cardinality: 1
20 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTY_SITES_U1 Cost: 0 Cardinality: 1
24 TABLE ACCESS BY INDEX ROWID TABLE HR.HR_ALL_ORGANIZATION_UNITS Cost: 1 Bytes: 13 Cardinality: 1
23 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_ORGANIZATION_UNITS_PK Cost: 0 Cardinality: 1
27 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 1 Bytes: 31 Cardinality: 1
26 INDEX UNIQUE SCAN INDEX (UNIQUE) ONT.OE_TRANSACTION_TYPES_TL_U1 Cost: 0 Cardinality: 1
30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 3 Bytes: 21 Cardinality: 1
29 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N1 Cost: 2 Cardinality: 1
32 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_FLEX_VALUES_TL_U1 Cost: 1 Bytes: 9 Cardinality: 1
35 TABLE ACCESS BY INDEX ROWID TABLE HR.HR_LOCATIONS_ALL Cost: 1 Bytes: 30 Cardinality: 1
34 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_LOCATIONS_PK Cost: 0 Cardinality: 1
37 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_ALL_ORGANIZATION_UNTS_TL_PK Cost: 0 Bytes: 8 Cardinality: 1
39 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_LOCATIONS_ALL_TL_PK Cost: 0 Bytes: 9 Cardinality: 1
41 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_LOCATIONS_ALL_TL_PK Cost: 0 Bytes: 9 Cardinality: 1
43 TABLE ACCESS FULL TABLE FA.FA_ADDITIONS_B Cost: 683 Bytes: 670,734 Cardinality: 37,263
45 INDEX UNIQUE SCAN INDEX (UNIQUE) FA.FA_ADDITIONS_TL_U1 Cost: 1 Bytes: 9 Cardinality: 1
48 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_TRANSACTION_TYPES Cost: 1 Bytes: 26 Cardinality: 1
47 INDEX UNIQUE SCAN INDEX (UNIQUE) INV.MTL_TRANSACTION_TYPES_U1 Cost: 0 Cardinality: 1
51 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_ITEM_LOCATIONS Cost: 2 Bytes: 13 Cardinality: 1
50 INDEX RANGE SCAN INDEX (UNIQUE) INV.MTL_ITEM_LOCATIONS_U1 Cost: 1 Cardinality: 1
54 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_LOCATIONS Cost: 1 Bytes: 30 Cardinality: 1
53 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_LOCATIONS_U1 Cost: 0 Cardinality: 1
57 TABLE ACCESS BY INDEX ROWID TABLE FA.FA_DISTRIBUTION_HISTORY Cost: 8 Bytes: 126 Cardinality: 6
56 INDEX RANGE SCAN INDEX FA.FA_DISTRIBUTION_HISTORY_N2 Cost: 2 Cardinality: 6
61 TABLE ACCESS BY INDEX ROWID TABLE FA.FA_LOCATIONS Cost: 1 Bytes: 38 Cardinality: 1
60 INDEX UNIQUE SCAN INDEX (UNIQUE) FA.FA_LOCATIONS_U1 Cost: 0 Cardinality: 1
124 NESTED LOOPS OUTER Cost: 925 Bytes: 479 Cardinality: 1
121 FILTER
120 NESTED LOOPS OUTER Cost: 924 Bytes: 441 Cardinality: 1
117 NESTED LOOPS Cost: 916 Bytes: 420 Cardinality: 1
115 HASH JOIN Cost: 915 Bytes: 411 Cardinality: 1
113 NESTED LOOPS OUTER Cost: 231 Bytes: 393 Cardinality: 1
110 NESTED LOOPS OUTER Cost: 229 Bytes: 380 Cardinality: 1
107 NESTED LOOPS Cost: 228 Bytes: 354 Cardinality: 1
104 NESTED LOOPS Cost: 225 Bytes: 330 Cardinality: 1
102 NESTED LOOPS Cost: 224 Bytes: 321 Cardinality: 1
99 NESTED LOOPS Cost: 222 Bytes: 293 Cardinality: 1
96 NESTED LOOPS Cost: 221 Bytes: 263 Cardinality: 1
93 NESTED LOOPS Cost: 220 Bytes: 253 Cardinality: 1
90 NESTED LOOPS Cost: 218 Bytes: 237 Cardinality: 1
87 NESTED LOOPS Cost: 217 Bytes: 223 Cardinality: 1
84 NESTED LOOPS Cost: 216 Bytes: 192 Cardinality: 1
81 NESTED LOOPS Cost: 210 Bytes: 137 Cardinality: 1
78 NESTED LOOPS Cost: 28 Bytes: 118 Cardinality: 1
75 NESTED LOOPS Cost: 22 Bytes: 97 Cardinality: 1
73 NESTED LOOPS Cost: 22 Bytes: 88 Cardinality: 1
71 NESTED LOOPS Cost: 22 Bytes: 79 Cardinality: 1
69 NESTED LOOPS Cost: 22 Bytes: 71 Cardinality: 1
66 NESTED LOOPS Cost: 19 Bytes: 58 Cardinality: 1
64 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUE_SETS Cost: 2 Bytes: 28 Cardinality: 1
63 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_FLEX_VALUE_SETS_U2 Cost: 1 Cardinality: 1
65 TABLE ACCESS FULL TABLE HR.HR_LOCATIONS_ALL Cost: 17 Bytes: 30 Cardinality: 1
68 TABLE ACCESS BY INDEX ROWID TABLE HR.HR_ALL_ORGANIZATION_UNITS Cost: 3 Bytes: 13 Cardinality: 1
67 INDEX RANGE SCAN INDEX HR.HR_ORGANIZATION_UNITS_FK3 Cost: 1 Cardinality: 5
70 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_ALL_ORGANIZATION_UNTS_TL_PK Cost: 0 Bytes: 8 Cardinality: 1
72 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_LOCATIONS_ALL_TL_PK Cost: 0 Bytes: 9 Cardinality: 1
74 INDEX UNIQUE SCAN INDEX (UNIQUE) HR.HR_LOCATIONS_ALL_TL_PK Cost: 0 Bytes: 9 Cardinality: 1
77 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_FLEX_VALUES Cost: 6 Bytes: 2,667 Cardinality: 127
76 INDEX RANGE SCAN INDEX APPLSYS.FND_FLEX_VALUES_N2 Cost: 2 Cardinality: 127
80 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_SITE_USES_ALL Cost: 182 Bytes: 19 Cardinality: 1
79 INDEX RANGE SCAN INDEX APPS.HCCA_HZ_CUST_SITE_USES_ALL_N1 Cost: 1 Cardinality: 489
83 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_LINES_ALL Cost: 6 Bytes: 55 Cardinality: 1
82 INDEX RANGE SCAN INDEX ONT.OE_ORDER_LINES_N2 Cost: 2 Cardinality: 4
86 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 1 Bytes: 31 Cardinality: 1
85 INDEX UNIQUE SCAN INDEX (UNIQUE) ONT.OE_TRANSACTION_TYPES_TL_U1 Cost: 0 Cardinality: 1
89 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCT_SITES_ALL Cost: 1 Bytes: 14 Cardinality: 1
88 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCT_SITES_U1 Cost: 0 Cardinality: 1
92 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 2 Bytes: 16 Cardinality: 1
91 INDEX UNIQUE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U1 Cost: 1 Cardinality: 1
95 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTY_SITES Cost: 1 Bytes: 10 Cardinality: 1
94 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTY_SITES_U1 Cost: 0 Cardinality: 1
98 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_LOCATIONS Cost: 1 Bytes: 30 Cardinality: 1
97 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_LOCATIONS_U1 Cost: 0 Cardinality: 1
101 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_SYSTEM_ITEMS_B Cost: 2 Bytes: 28 Cardinality: 1
100 INDEX UNIQUE SCAN INDEX (UNIQUE) INV.MTL_SYSTEM_ITEMS_B_U1 Cost: 1 Cardinality: 1
103 INDEX UNIQUE SCAN INDEX (UNIQUE) APPLSYS.FND_FLEX_VALUES_TL_U1 Cost: 1 Bytes: 9 Cardinality: 1
106 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_MATERIAL_TRANSACTIONS Cost: 3 Bytes: 24 Cardinality: 1
105 INDEX RANGE SCAN INDEX INV.MTL_MATERIAL_TRANSACTIONS_N1 Cost: 2 Cardinality: 1
109 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_TRANSACTION_TYPES Cost: 1 Bytes: 26 Cardinality: 1
108 INDEX UNIQUE SCAN INDEX (UNIQUE) INV.MTL_TRANSACTION_TYPES_U1 Cost: 0 Cardinality: 1
112 TABLE ACCESS BY INDEX ROWID TABLE INV.MTL_ITEM_LOCATIONS Cost: 2 Bytes: 13 Cardinality: 1
111 INDEX RANGE SCAN INDEX (UNIQUE) INV.MTL_ITEM_LOCATIONS_U1 Cost: 1 Cardinality: 1
114 TABLE ACCESS FULL TABLE FA.FA_ADDITIONS_B Cost: 683 Bytes: 670,734 Cardinality: 37,263
116 INDEX UNIQUE SCAN INDEX (UNIQUE) FA.FA_ADDITIONS_TL_U1 Cost: 1 Bytes: 9 Cardinality: 1
119 TABLE ACCESS BY INDEX ROWID TABLE FA.FA_DISTRIBUTION_HISTORY Cost: 8 Bytes: 126 Cardinality: 6
118 INDEX RANGE SCAN INDEX FA.FA_DISTRIBUTION_HISTORY_N2 Cost: 2 Cardinality: 6
123 TABLE ACCESS BY INDEX ROWID TABLE FA.FA_LOCATIONS Cost: 1 Bytes: 38 Cardinality: 1
122 INDEX UNIQUE SCAN INDEX (UNIQUE) FA.FA_LOCATIONS_U1 Cost: 0 Cardinality: 1 -
Index not being used in access path
Hi,
I have been trying to rewrite a query which currently is taking almost 1min and 25 secs to execute. The database version is 11.1.0.7.
The query is -
SELECT COUNT(1)
FROM TAB1 p
WHERE p.ACODE = 24377
AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
AND p.rflag = 'Y';
The table originally didn't have an index on p.ACODE. So, I created this index and set it to visible and set the optimizer_use_invisible_indexes parameter also to TRUE. I set the monitoring on this index too. Even though I have created the index on the ACODE column, the access path doesn't use it. Can someone please tell me why this is not being used.
Below is the explain plan for the sql stmt and the usage of the index -
I have changed the actual table and column names -
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.ACODE = 24377
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.ACODE = 24377
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3942424611
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 214K (2)| 00:42:57 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 214K (2)| 00:42:57 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 209K (2)| 00:41:56 |
|* 4 | TABLE ACCESS FULL | TAB1 | 1 | 32 | 209K (2)| 00:41:55 |
| 5 | INDEX FAST FULL SCAN| PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AKey")
3 - access("PHS"."PKey"="P"."AKey")
4 - filter(TO_NUMBER("P"."ACODE")=24377 AND "P"."rflag"='Y')
20 rows selected.
Elapsed: 00:00:00.03
SQL> select index_name,VISIBILITY from user_indexes where index_name='IDX_TAB1_ACODE';
INDEX_NAME VISIBILIT
IDX_TAB1_ACODE VISIBLE
Elapsed: 00:00:00.01
SQL> show parameter visible
NAME TYPE VALUE
optimizer_use_invisible_indexes boolean TRUE
SQL>
SQL> SELECT v.index_name, v.table_name,
v.monitoring, v.used,
start_monitoring, end_monitoring
FROM v$object_usage v, dba_indexes u
WHERE v.index_name = u.index_name
AND v.index_name = 'IDX_TAB1_ACODE';
INDEX_NAME TABLE_NAME MON USE START_MONITORING END_MONITORING
IDX_TAB1_ACODE TAB1 YES NO 05/26/2010 14:13:41
Elapsed: 00:00:00.10
Edited by: user12158503 on May 26, 2010 1:24 PMThanks Centinul.
I apologize for posting in both sections. I put it in the Database General too because I thought I originally posted it in the wrong section.
The index was not being used because it was doing the implicit type conversion. When I enclosed it in quotes, it returns the result within a second and it uses the index.(whereas without the index it takes around 1min 25 sec)
Here is the explain plan and execution time after enclosing it in quotes -
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.AKey = '24377'
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2008452282
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 5134 (1)| 00:01:02 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 5134 (1)| 00:01:02 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 60 (2)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 32 | 6 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | IDX_TAB1_AKey | 4 | | 1 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 7 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AGILITYKEY")
3 - access("PHS"."PKey"="P"."AGILITYKEY")
4 - filter("P"."rflag"='Y')
5 - access("P"."AKey"='24377')
22 rows selected.
Elapsed: 00:00:00.02
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.AKey = '24377'
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
Elapsed: 00:00:00.52
Can you give me some tips on where I could read about learning to understand the explain plan. I did read a few articles which did help me, but not much. I am looking for something in detail.
Maybe you are looking for
-
Hi, A flow instance blocks and gives an error in the logfiles (copied below). It only happened once and we already executed some hundreds of instances, so the implementation looks fine to me. Has someone an idea what it could be? Is it possible to ve
-
WebLogic 7.0.1 and apache ssl plug-in
I am not seeing any forwarding of SSL requests from Apache to WebLogic once I upgraded from 7.0.0.1 to 7.0.1 and used the new plug-in. I actually found the plug-in size for solaris to be smaller then the 7.0.0.1 which I found to be a little strange.
-
How can I create a table to create new objects in database using ADF, I try to drag the execute operation but has no effect . Thank you. I think the button commit is missing, please correct me if I´m wrong. Message was edited by: Luis Henrique Correa
-
Can I do a "Fit Image" ala Photoshop in Illustrator
I have need to be able to make different size and orientation images fit into a 1.25" x 2.15" area. I can do this easily in Photoshop with the "Fit Image" command. However, I haven't been able to figure out how to do this in Illy. I have created an a
-
Compressor Won't Add Files to Source
For some reason my Compressor won't add any files to the source. For example I'm trying to add a ~30GB .mp4 to the source so that I convert it. Not sure what other details I can give other than this.