Index not usable in my simple query
Hi,
I have created index for INC_ID coloumn but when I use it in queries, it is not working. Verified the index it is on valid stat only, eventhough its not using in queries.
can you please suggest why it is not using. what I have to do for this. I am going to use this query in procedures. My DBA will not allow to use hints in queries.
Thanks in advance
select * from TAB_FLNDAT t where t.INC_ID = 2055Explain plan
SELECT STATEMENT, GOAL = ALL_ROWS 339682 19174 7631252
TABLE ACCESS FULL AIMS_OWNR ONT_T_FLNDATASTATUS_AGNT 339682 19174 7631252Total no of records in TAB_FLNDAT table -- 21427155
Table DDL
-- Create table
create table TAB_FLNDAT
INC_ID VARCHAR2(25),
INC_PERIOD NUMBER,
AREA_DEF_ID NUMBER,
DEAL_CODE VARCHAR2(50),
FLNMTH DATE,
DOCNUM NUMBER(10),
CPNNUM NUMBER(3),
CTRY_ISO_CODE VARCHAR2(2),
FLNLOCCOD VARCHAR2(7),
FLNCTYCOD VARCHAR2(3),
FLNDATAKEY NUMBER,
MAIN_CLASS VARCHAR2(17),
BOKCLSCOD VARCHAR2(1),
ORIGIN VARCHAR2(6),
DESTINATION VARCHAR2(3),
FINAL_ST NUMBER(1),
SALE_ST NUMBER(1),
AGENT_ST NUMBER(1),
EKOAL_ST NUMBER(1),
FARE_ST NUMBER(1),
PAPERTKT_ST NUMBER(1),
OND_ST NUMBER(1),
RBD_ST NUMBER(1),
FLIGHT_ST NUMBER(1),
FBC_ST NUMBER(1),
DEAL_ST NUMBER(1),
DEAL_ST_CODE VARCHAR2(50),
ONDRBD_ST NUMBER(1),
DATE_ST NUMBER(1),
CODESHARE_ST NUMBER(1),
HPMCO_ST NUMBER(1),
CTRY_ST NUMBER(1),
LC_REVENUE NUMBER(18,3),
CURCOD VARCHAR2(3),
LC_NET_NET NUMBER(21,3),
REPORTING_CURRENCY VARCHAR2(3),
CARDSGCOD VARCHAR2(2),
CARNUMCOD VARCHAR2(3),
DOCTYP VARCHAR2(3),
FLNDAT DATE,
FLTNUM VARCHAR2(4),
FLNSEC VARCHAR2(6),
FLNITN VARCHAR2(200),
SALMTH DATE,
SALCTYCOD VARCHAR2(3),
SALLOCCOD VARCHAR2(10),
FABCOD VARCHAR2(50),
IATA_FABCOD VARCHAR2(50),
TOTPAX NUMBER(9),
CPNCNT NUMBER(6),
PAXCNT NUMBER(6),
CBKGRSAMT NUMBER(15,3),
CBKNETAMT NUMBER(15,3),
CBKCOMAMT NUMBER(15,3),
CBKORCAMT NUMBER(15,3),
COSGRSAMT NUMBER(15,3),
COSNETAMT NUMBER(15,3),
COSCOMAMT NUMBER(15,3),
COSORCAMT NUMBER(15,3),
COUCOD VARCHAR2(7),
TOUCOD VARCHAR2(20),
OLD_DOCNUM NUMBER(10),
ON_OFFLINE CHAR(1),
ENTFABCOD VARCHAR2(50),
EKOALIND CHAR(1),
ONL_INTL_INDICATOR VARCHAR2(1),
FULL_ITINERARY VARCHAR2(500),
RPD_COSGRSAMT NUMBER(15,3),
RPD_COSNETAMT NUMBER(15,3),
RPD_COSCOMAMT NUMBER(15,3),
RPD_COSORCAMT NUMBER(15,3),
SALDAT DATE,
REPENDDAT DATE,
ETKIND VARCHAR2(1),
MKTFLTNUM VARCHAR2(8),
CODSHRIND VARCHAR2(1),
FARE_TYPE VARCHAR2(50),
CMM_CUSTOMER_ID VARCHAR2(25),
OPERATING_COST NUMBER(18,3),
ACM_AMOUNT NUMBER(18,3),
GDS_COST NUMBER(18,3),
OCCURRENCE NUMBER(3),
PROCESS_MONTH DATE,
ONTRACK_FBC VARCHAR2(100),
EKHMCOIND CHAR(1),
RPT_FLNITN VARCHAR2(200),
CORPORATE_ID VARCHAR2(25),
CORP_DEAL_CODE VARCHAR2(50),
OSI_DATA VARCHAR2(100),
PAX_NAME VARCHAR2(1000),
PAX_TYPE VARCHAR2(1),
BOOKING_DATE DATE,
SKYWARDS_NO VARCHAR2(11),
PROCESSED CHAR(1),
FLTFULROU VARCHAR2(30),
FLTROUFLNLEG VARCHAR2(30),
FLNACFTYP VARCHAR2(10),
SEQNO NUMBER(3),
FORM_OF_PAYMENT VARCHAR2(9),
TRPTYP VARCHAR2(1),
FOPDTL VARCHAR2(300),
PNR_ID NUMBER(15),
VALUE_ADDED_COST NUMBER(18,3),
LINK_OD VARCHAR2(45),
TEMP VARCHAR2(50),
ONT_FBC_TEMP VARCHAR2(100),
ONT_FBC_TYPE_TEMP VARCHAR2(20),
ONT_FBC_ST_TEMP NUMBER(1),
INC_FINAL_ST_TEMP NUMBER(1),
TEMP_FLAG VARCHAR2(1),
MODIFIED CHAR(1),
MATCH_FLAG CHAR(2)
tablespace A_DAT
pctfree 10
initrans 1
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
-- Create/Recreate indexes
create index IND_FLNST_AGNT_DOC on TAB_FLNDAT (DOCNUM)
tablespace A_IDX
pctfree 10
initrans 2
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
create index IND_FLNST_AGNT_FLNMTH on TAB_FLNDAT (FLNMTH)
tablespace A_IDX
pctfree 10
initrans 2
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
create bitmap index IND_FLNST_AREDEF on TAB_FLNDAT (AREA_DEF_ID)
tablespace A_IDX
pctfree 10
initrans 2
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
create index IND_FLNST_FLNDATAKEY on TAB_FLNDAT (FLNDATAKEY)
tablespace A_IDX
pctfree 10
initrans 2
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
create bitmap index IND_FLNST_INCPERIOD on TAB_FLNDAT (INC_PERIOD)
tablespace A_IDX
pctfree 10
initrans 2
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
create index IND_FLNST_INC_ID on TAB_FLNDAT (INC_ID)
tablespace A_IDX
pctfree 10
initrans 2
maxtrans 255
storage
initial 64K
next 1M
minextents 1
maxextents unlimited
);Edited by: venkatraman.L on Mar 18, 2012 12:51 PM
Edited by: venkatraman.L on Mar 18, 2012 12:52 PM
venkatraman.L wrote:
yes if I use Quotes it is using index. It should be a numeric field.
Thanks Etbin. I was a little surprised by that. i thought oracle will always implicitly convert to the type of the column. But that happens only for insert/updates.
From the docs (http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements002.htm):
The following rules govern the direction in which Oracle Database makes implicit datatype conversions:
<li>During INSERT and UPDATE operations, Oracle converts the value to the datatype of the affected column.
<li>During SELECT FROM operations, Oracle converts the data from the column to the type of the target variable.
<li>When manipulating numeric values, Oracle usually adjusts precision and scale to allow for maximum capacity. In such cases, the numeric datatype resulting from such operations can differ from the numeric datatype found in the underlying tables.
<li>When comparing a character value with a numeric value, Oracle converts the character data to a numeric value.
<li>Conversions between character values or NUMBER values and floating-point number values can be inexact, because the character types and NUMBER use decimal precision to represent the numeric value, and the floating-point numbers use binary precision.
Rule 4 is what happened in your case.
Similar Messages
-
Index not used in a simple query
Hi all,
I have a query which is using only 2 tables linked with an indexed column, i'm surprised that the 2 tables are not using index and they are full scanned. here is some details:
Table a: T1 (col11 number, col12 varchar2) indexed on col11 (primary key): rows number=4 millions indexe: idx1 on col11
Table b: T2 (col21 number, col22 varchar2) indexed on col21 (primary key): rows number=3 millions indexe: idx2 on col21
select a.col12, b.col22 from T1 a, T2 b where a.col11=b.col21
The execution plan is:
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=ALL_ROWS 3 M 32356
PX COORDINATOR
PX SEND QC (RANDOM) SYS.:TQ10002 3 M 67 M 32356 :Q1002 P->S QC (RANDOM)
HASH JOIN 3 M 67 M 32356 :Q1002 PCWP
PX RECEIVE 3 M 20 M 7376 :Q1002 PCWP
PX SEND HASH SYS.:TQ10001 3 M 20 M 7376 :Q1001 P->P HASH
PX BLOCK ITERATOR 3 M 20 M 7376 :Q1001 PCWC
TABLE ACCESS FULL T2 3 M 20 M 7376 :Q1001 PCWP
BUFFER SORT :Q1002 PCWC
PX RECEIVE 3 M 44 M 24708 :Q1002 PCWP
PX SEND HASH SYS.:TQ10000 3 M 44 M 24708 S->P HASH
TABLE ACCESS FULL T1 3 M 44 M 24708 ThanksHi Herald,
Thanks for your reply
when selecting only the columns which are indexed, it is using the index
select a.account_link_code_n, b.account_link_code_n from gsm_sims_master a, gsm_service_mast b
where a.account_link_code_n=b.account_link_code_n
See the execution below:
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=ALL_ROWS 3 M 11051
PX COORDINATOR
PX SEND QC (RANDOM) SYS.:TQ10002 3 M 44 M 11051 :Q1002 P->S QC (RANDOM)
HASH JOIN 3 M 44 M 11051 :Q1002 PCWP
PX RECEIVE 3 M 20 M 7376 :Q1002 PCWP
PX SEND HASH SYS.:TQ10001 3 M 20 M 7376 :Q1001 P->P HASH
PX BLOCK ITERATOR 3 M 20 M 7376 :Q1001 PCWC
TABLE ACCESS FULL GSM_SERVICE_MAST 3 M 20 M 7376 :Q1001 PCWP
BUFFER SORT :Q1002 PCWC
PX RECEIVE 3 M 22 M 3403 :Q1002 PCWP
PX SEND HASH SYS.:TQ10000 3 M 22 M 3403 S->P HASH
INDEX FAST FULL SCAN ABILLITY.SIM_ACC_LNK_CD_IDX 3 M 22 M 3403 But using hints has a very bad execution plan and a very high cost:
select /*+ index(a) index(b) */ a.account_link_code_n, b.account_link_code_n from gsm_sims_master a, gsm_service_mast b
where a.account_link_code_n=b.account_link_code_n
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=ALL_ROWS 3 M 31899
HASH JOIN 3 M 44 M 31899
INDEX FULL SCAN ABILLITY.GSM_SERV_MAST#ACLINK_CODE$PK 3 M 20 M 8158
INDEX FULL SCAN ABILLITY.SIM_ACC_LNK_CD_IDX 3 M 22 M 15709 Thank you
Luc -
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. -
Index not picked up by the query
I am doing complex joining with multiple tables ..
table A has got 104M records other tables are having circa 100K records ...
Now I have created index on table A on a field which is being used in filter condition ... but when I analysing the explain plan of the query - I can see table A has been fully accessed - index is not being used.
Can anyone put some llight why it is happening ... Is it somthing to do with what I am selecting in the query ...You can search the forum for the same question and get other threads on this topic.
The short answer is that the index isn't being used because the optimizer decides that doing the full table scan (FTS) is more efficient - it may or may not be right. There are lots of factors that could make the cost-based optimizer (CBO) not use an index, but the more common ones are
* modifying a WHERE clause column value with ||, arithmetic, or a function (index supression)
* You're going to read all or most of the rows in the table anyway, so the index would not help (at least, the CBO might think so) -
Simple Query working on 10G and not working on 11gR2 after upgrade
Hi Folks,
This is the first time i am posting the query in this Blog.
I have a small issue which preventing the UAT Sigoff.
Simple query working fine on 10.2.0.1 and after upgrade to 11.2.0.1 its error out
10.2.0.4:
=====
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=1;
COUNT(*)
1
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=00001;
COUNT(*)
1
SQL> select ATTRIBUTE1 FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=1;
ATTRIBUTE1
00001
11.2.0.1:
=====
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=1
ERROR at line 1:
ORA-01722: invalid number
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=00001
ERROR at line 1:
ORA-01722: invalid number
SQL> select ATTRIBUTE1 FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1='1';
no rows selected
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1='00001';
COUNT(*)
1
SQL> select ATTRIBUTE1 FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1='00001';
ATTRIBUTE1
00001
++++++++++++++++++++++++++++++++++++++++++++++
SQL > desc APPS.HZ_PARTIES
Name Type
======== ======
ATTRIBUTE1 VARCHAR2(150)
++++++++++++++++++++++++++++++++++++++++++++++
Changes:
Recently i upgraded the DB from 10.2.0.4 to 11.2.0.1
Query:
1.If the type of that row is VARCHAR,why it is working in 10.2.0.4 and why not working in 11.2.0.1
2.after upgrade i analyzed the table with "analyze table " query for all AP,AR,GL,HR,BEN,APPS Schemas--Is it got impact if we run analyze table.
Please provide me the answer for above two questions or refer the document is also well enough to understand.Based on the Answer client will sigoff to-day.
Thanks,
P KumarWhiteHat wrote:
the issue has already been identified: in oracle versions prior to 11, there was an implicit conversion of numbers to characters. your database has a character field which you are attempting to compare to a number.
i.e. the string '000001' is not in any way equivalent to the number 1. but Oracle 10 converts '000001' to a number because you are asking it to compare to the number you have provided.
version 11 doesn't do this anymore (and rightly so).
the issue is with the bad code design. you can either: use characters in the predicate (where field = 'parameter') or you can do a conversion of the field prior to comparing (where to_num(field) = parameter).
I would suggest that you should fix your code and don't assume that '000001' = 1I don't think that the above is completely correct, and a simple demonstration will show why. First, a simple table on Oracle Database 10.2.0.4:
CREATE TABLE T1(C1 VARCHAR2(20));
INSERT INTO T1 VALUES ('1');
INSERT INTO T1 VALUES ('0001');
COMMIT;A select from the above table, relying on implicit data type conversion:
SELECT
FROM
T1
WHERE
C1=1;
C1
1
0001Technically, the second row should not have been returned as an exact match. Why was it returned, let's take a look at the actual execution plan:
SELECT
FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
SQL_ID g6gvbpsgj1dvf, child number 0
SELECT * FROM T1 WHERE C1=1
Plan hash value: 3617692013
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 2 (100)| |
|* 1 | TABLE ACCESS FULL| T1 | 2 | 24 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(TO_NUMBER("C1")=1)
Note
- dynamic sampling used for this statementNotice that the VARCHAR2 column was converted to a NUMBER, so if there was any data in that column that could not be converted to a number (or NULL), we should receive an error (unless the bad rows are already removed due to another predicate in the WHERE clause). For example:
INSERT INTO T1 VALUES ('.0001.');
SELECT
FROM
T1
WHERE
C1=1;
SQL> SELECT
2 *
3 FROM
4 T1
5 WHERE
6 C1=1;
ERROR:
ORA-01722: invalid numberNow the same test on Oracle Database 11.1.0.7:
CREATE TABLE T1(C1 VARCHAR2(20));
INSERT INTO T1 VALUES ('1');
INSERT INTO T1 VALUES ('0001');
COMMIT;
SELECT
FROM
T1
WHERE
C1=1;
C1
1
0001
SELECT
FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
SQL_ID g6gvbpsgj1dvf, child number 0
SELECT * FROM T1 WHERE C1=1
Plan hash value: 3617692013
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 2 (100)| |
|* 1 | TABLE ACCESS FULL| T1 | 2 | 24 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(TO_NUMBER("C1")=1)
Note
- dynamic sampling used for this statement
INSERT INTO T1 VALUES ('.0001.');
SELECT
FROM
T1
WHERE
C1=1;
SQL> SELECT
2 *
3 FROM
4 T1
5 WHERE
6 C1=1;
ERROR:
ORA-01722: invalid numberAs you can see, exactly the same actual execution plan, and the same end result.
The OP needs to determine if non-numeric data now exists in the column. Was the database characterset possibly changed during/after the upgrade?
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Simple Query in Oracle Linked Table in MS Access causes full table scan.
I am running a very simple query in MS ACCESS to a linked Oracle table as follows:
Select *
From EXPRESS_SERVICE_EVENTS --(the linked table name refers to EXPRESS.SERVICE_EVENTS)
Where performed > MyDate()
or
Select *
From EXPRESS_SERVICE_EVENTS --(the linked table name refers to EXPRESS.SERVICE_EVENTS)
Where performed > [Forms]![MyForm]![Date1]
We have over 50 machines and this query runs fine on over half of these, using an Oracle Index on the "performed" field. Running exactly the same thing on the other machines causes a full table scan, therefore ignoring the Index (all machines access the same Access DB).
Strangely, if we write the query as follows:
Select *
From EXPRESS_SERVICE_EVENTS
Where performed > #09/04/2009 08:00#
it works fast everywhere!
Any help on this 'phenominon' would be appreciated.
Things we've done:
Checked regional settings, ODBC driver settings, MS Access settings (as in Tools->Options), we have the latest XP and Office service packs, and re-linked all Access Tables on both the slow and fast machines independantly).Primarily, thanks gdarling for your reply. This solved our problem.
Just a small note to those who may be using this thread.
Although this might not be the reason, my PC had Oracle 9iR2 installed with Administratiev Tools, where user machines had the same thing installed but using Runtime Installation. For some reason, my PC did not have 'bind date' etc. as an option in the workarounds, but user machines did have this workaround option. Strangely, although I did not have the option, my (ODBC) query was running as expected, but user queries were not.
When we set the workaround checkbox accordingly, the queries then run as expected (fast).
Once again,
Thanks -
Simple query takes 18 minutes to retrieve data....
Hi,
I am facing this problem at the customer site where a simple query on a table takes 18 minutes or more. Please find below the details.
Table Structure
CREATE TABLE dsp_data
quantum_id NUMBER(11) NOT NULL,
src NUMBER(11) NOT NULL,
call_status NUMBER(11) NOT NULL,
dst NUMBER(11) NOT NULL,
measurement_id NUMBER(11) NOT NULL,
is_originating NUMBER(1) NOT NULL,
measurement_value NUMBER(15,4) NOT NULL,
data_type_id NUMBER(3) NOT NULL,
data VARCHAR2(200) NOT NULL
TABLESPACE dsp_data_tspace
STORAGE (PCTINCREASE 0 INITIAL 100K NEXT 1024K)
PARTITION BY RANGE (quantum_id)
(PARTITION dsp_data_default VALUES LESS THAN (100));
CREATE INDEX dsp_data_idx ON dsp_data
quantum_id,
src,
call_status,
dst,
measurement_id,
is_originating,
measurement_value,
data_type_id
TABLESPACE dsp_data_idx_tspace
LOCAL;
CREATE INDEX dsp_data_src_idx ON dsp_data
src
TABLESPACE dsp_data_idx_tspace
LOCAL;
CREATE INDEX dsp_data_dst_idx ON dsp_data
dst
TABLESPACE dsp_data_idx_tspace
LOCAL;
ALTER TABLE dsp_data
ADD CONSTRAINT fk_dsp_data_1
FOREIGN KEY
quantum_id
REFERENCES mds_measurement_intervals
quantum_id
ALTER TABLE dsp_data
ADD CONSTRAINT fk_dsp_data_2
FOREIGN KEY
data_type_id
REFERENCES mds_drilldown_types
type_id
ALTER TABLE dsp_data
ADD CONSTRAINT pk_dsp_data
PRIMARY KEY
quantum_id,
src,
call_status,
dst,
measurement_id,
is_originating,
measurement_value,
data_type_id,
data
USING INDEX
TABLESPACE dsp_data_idx_tspace
LOCAL;
Table Space Creation
All table space creation is done using following command
CREATE TABLESPACE [tablespaceName]
DATAFILE [tablespaceDatafile] SIZE 500M REUSE
AUTOEXTEND ON NEXT 10240K
DEFAULT STORAGE ( INITIAL 1024K
NEXT 1024K
MINEXTENTS 10
MAXEXTENTS UNLIMITED
PCTINCREASE 0
Server Configuration on CUtsomer Site
(1) 2 x Dual PA8900 Proc = 4GHz
(2) RAM = 16GB
(3) 3 x Internal HDDs
(4) 1 x External MSA-30 storage array (oracle db)
Record Information On Customer Site
select count(*) from dsp_data;
COUNT(*)
181931197
select min (quantum_id) from dsp_data where dst=2;
This takes 18 minutes or more....
SQL> SQL> SQL> explain plan for select min (quantum_id) from dsp_data where dst=2;
Explained.
SQL> @?/rdbms/admin/utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 999040277
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 14 | 1 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 14 | | | | |
| 2 | FIRST ROW | | 92 | 1288 | 1 (0)| 00:00:01 | | |
| 3 | PARTITION RANGE ALL | | 92 | 1288 | 1 (0)| 00:00:01 | 1 | 29 |
|* 4 | INDEX FULL SCAN (MIN/MAX)| DSP_DATA_IDX | 92 | 1288 | 1 (0)| 00:00:01 | 1 | 29 |
As mentioned above the query takes 18 minutes or more. This is a critical issue at customer. Can you please give your suggestions how to improve and reduce the query time. Thanks in advance.Hi,
I did the following changes in the indexes of table.
drop index DSP_DATA_IDX;
create index DSP_DATA_MEASUREMENT_ID_IDX on DSP_DATA (MEASUREMENT_ID) TABLESPACE dsp_data_idx_tspace LOCAL;
After that I did explain plan,
explain plan for select min(QUANTUM_ID) from mds.DSP_DATA where SRC=11;
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU
| 0 | SELECT STATEMENT | | 1 | 11 | 3 (0
| 1 | SORT AGGREGATE | | 1 | 11 |
| 2 | FIRST ROW | | 430K| 4626K| 3 (0
| 3 | PARTITION RANGE ALL | | 430K| 4626K| 3 (0
| 4 | INDEX FULL SCAN (MIN/MAX)| PK_DSP_DATA | 430K| 4626K| 3 (0
Note
- 'PLAN_TABLE' is old version
14 rows selected
SELECT table_name, index_name, monitoring, used FROM v$object_usage;
TABLE_NAME INDEX_NAME MONITORING USED
DSP_DATA DSP_DATA_SRC_IDX YES NO
It seems that DSP_DATA_SRC_IDX is not getting used in query. What changes do i need to make so that DSP_DATA_SRC_IDX index gets used.
Also, you have stated that to create global index on src and dst. How do i create them.
Thanks in Advance.
Edited by: 780707 on Jul 8, 2010 11:58 PM -
Hi,
I'm using Oracle 10g r2.
I have this simple query that seems to take too much time to execute :
DECLARE
nb_mesures INTEGER;
min_day DATE;
max_day DATE;
BEGIN
SELECT
COUNT(meas_id),
MIN(meas_day),
MAX(meas_day)
INTO
nb_mesures,
min_day,
max_day
FROM
geodetic_measurements gm
INNER JOIN
operation_measurements om
ON gm.meas_id = om.ogm_meas_id
WHERE ogm_op_id = 0;
htp.p(nb_mesures||' measurements from '||min_day||' to '||max_day);
END;- Tables (about 11.000 records for the "Operations" table, and 800.000 for the 2 others) :
"Operation_measurements" is the table who makes the link between the 2 others (get the 2 keys).
SQL> DESCRIBE OPERATIONS
Nom NULL Type
OP_ID NOT NULL NUMBER(7)
OP_PARENT_OP_ID NUMBER(7)
OP_RESPONSIBLE NOT NULL VARCHAR2(10)
OP_DESCRIPT VARCHAR2(80)
OP_VEDA_NAME NOT NULL VARCHAR2(10)
OP_BEGIN NOT NULL DATE
OP_END DATE
OP_INSERT_DATE DATE
OP_LAST_UPDATE DATE
OP_INSERT_BY VARCHAR2(50)
OP_UPDATE_BY VARCHAR2(50)
SQL> DESCRIBE OPERATION_MEASUREMENTS
Nom NULL Type
OGM_MEAS_ID NOT NULL NUMBER(7)
OGM_OP_ID NOT NULL NUMBER(6)
OGM_INSERT_DATE DATE
OGM_LAST_UPDATE DATE
OGM_INSERT_BY VARCHAR2(50)
OGM_UPDATE_BY VARCHAR2(50)
SQL> DESCRIBE GEODETIC_MEASUREMENTS
Nom NULL Type
MEAS_ID NOT NULL NUMBER(7)
MEAS_TYPE NOT NULL VARCHAR2(2)
MEAS_TEAM NOT NULL VARCHAR2(10)
MEAS_DAY NOT NULL DATE
MEAS_OBJ_ID NOT NULL NUMBER(6)
MEAS_STATUS VARCHAR2(1)
MEAS_COMMENT VARCHAR2(150)
MEAS_DIRECTION VARCHAR2(1)
MEAS_DIST_MODE VARCHAR2(2)
MEAS_SPAT_ID NOT NULL NUMBER(7)
MEAS_INST_ID NUMBER(7)
MEAS_DECALAGE NUMBER(8,5)
MEAS_INST_HEIGHT NUMBER(8,5)
MEAS_READING NOT NULL NUMBER(11,5)
MEAS_CORRECT_READING NUMBER(11,5)
MEAS_HUMID_TEMP NUMBER(4,1)
MEAS_DRY_TEMP NUMBER(4,1)
MEAS_PRESSURE NUMBER(4)
MEAS_HUMIDITY NUMBER(2)
MEAS_CONSTANT NUMBER(8,5)
MEAS_ROLE VARCHAR2(1)
MEAS_INSERT_DATE DATE
MEAS_LAST_UPDATE DATE
MEAS_INSERT_BY VARCHAR2(50)
MEAS_UPDATE_BY VARCHAR2(50)
MEAS_TILT_MODE VARCHAR2(4000) - Explain plan (I'm not familiar with explain plans...) :
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 | 19 | 256 (10)| 00:00:02 |
| 1 | SORT AGGREGATE | | 1 | 19 | | |
| 2 | NESTED LOOPS | | 75 | 1425 | 256 (10)| 00:00:02 |
|* 3 | TABLE ACCESS FULL | OPERATION_MEASUREMENTS | 75 | 600 | 90 (27)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| GEODETIC_MEASUREMENTS | 1 | 11 | 3 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | MEAS_PK_2 | 1 | | 2 (50)| 00:00:01 |
--------------------------------------------------------------------------------------------------------How can I optimize this query ?
Thanks.
Yann.Looks like you are missing an FK-index on the middle table, for the FK going to OPERATIONS.
Currently this:
WHERE ogm_op_id = 0;Is computed via a full table scan followed by a filter operation. Assuming OP_ID is rather selective, an index on OGM_OP_ID could do the trick here. -
Simple query takes time to run
Hi,
I have a simple query whcih takes about 20 mins to run.. here is the TKPROF forit:
SELECT
SY2.QBAC0,
sum(decode(SALES_ORDER.SDCRCD,'USD', SALES_ORDER.SDAEXP,'CAD', SALES_ORDER.SDAEXP /1.0452))
FROM
JDE.F5542SY2 SY2,
JDE.F42119 SALES_ORDER,
JDE.F0116 SHIP_TO,
JDE.F5542SY1 SY1,
JDE.F4101 PRODUCT_INFO
WHERE
( SHIP_TO.ALAN8=SALES_ORDER.SDSHAN )
AND ( SY1.QANRAC=SY2.QBNRAC and SY1.QAOTCD=SY2.QBOTCD )
AND ( PRODUCT_INFO.IMITM=SALES_ORDER.SDITM )
AND ( SY2.QBSHAN=SALES_ORDER.SDSHAN )
AND ( SALES_ORDER.SDLNTY NOT IN ('H ','HC','I ') )
AND ( PRODUCT_INFO.IMSRP1 Not In (' ','000','689') )
AND ( SALES_ORDER.SDDCTO IN ('CO','CR','SA','SF','SG','SP','SM','SO','SL','SR') )
AND (
( SY1.QACTR=SHIP_TO.ALCTR )
AND ( PRODUCT_INFO.IMSRP1=SY1.QASRP1 )
GROUP BY
SY2.QBAC0
call count cpu elapsed disk query current rows
Parse 1 0.07 0.07 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 10 92.40 929.16 798689 838484 0 131
total 12 92.48 929.24 798689 838484 0 131
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 62
Rows Row Source Operation
131 SORT GROUP BY
3535506 HASH JOIN
4026100 HASH JOIN
922 TABLE ACCESS FULL OBJ#(187309)
3454198 HASH JOIN
80065 INDEX FAST FULL SCAN OBJ#(30492) (object id 30492)
3489670 HASH JOIN
65192 INDEX FAST FULL SCAN OBJ#(30457) (object id 30457)
3489936 PARTITION RANGE ALL PARTITION: 1 9
3489936 TABLE ACCESS FULL OBJ#(30530) PARTITION: 1 9
97152 TABLE ACCESS FULL OBJ#(187308)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.07 0.07 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 10 92.40 929.16 798689 838484 0 131
total 13 92.48 929.24 798689 838484 0 131
Misses in library cache during parse: 1kindly suggest how to resolve this...
OS is windows and its 9i DB...
Thanks> ... you want to get rid of the IN statements.
They prevent Oracle from usering the index.
SQL> create table mytable (id,num,description)
2 as
3 select level
4 , case level
5 when 0 then 0
6 when 1 then 1
7 else 2
8 end
9 , 'description ' || to_char(level)
10 from dual
11 connect by level <= 10000
12 /
Table created.
SQL> create index i1 on mytable(num)
2 /
Index created.
SQL> exec dbms_stats.gather_table_stats(user,'mytable')
PL/SQL procedure successfully completed.
SQL> set autotrace on explain
SQL> select id
2 , num
3 , description
4 from mytable
5 where num in (0,1)
6 /
ID NUM DESCRIPTION
1 1 description 1
1 row selected.
Execution Plan
Plan hash value: 2172953059
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 5001 | 112K| 2 (0)| 00:00:01 |
| 1 | INLIST ITERATOR | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| MYTABLE | 5001 | 112K| 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | I1 | 5001 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("NUM"=0 OR "NUM"=1)Regards,
Rob. -
Simple Query returns no result
We have a problem with a simple query on a "old" Table in our Database. The Table has following Structure:
CREATE TABLE <table_name>
ROLE_ID INTEGER NOT NULL,
ROLE_NAME VARCHAR (99) ascii NOT NULL,
OBJECTDATA LONG BYTE,
UNIQUE (ROLE_NAME)
The table containts two rows and following querys get these results:
select role_id, role_name from <schema>.<table_name>
--> 2 rows
select role_id, role_name from <schema>.<table_name>
order by role_id
--> 2 rows
select role_id, role_name from <schema>.<table_name>
order by role_name
--> 0 rows ?? confusion
When we create a "new" table with the same structure, and insert the same content to this new table, the queries are working correctly.
What happened with our "old" table, so that these simple queries don't function anymore?
(Database Kernel 7.6.05 Build 009-123-191-997)
thx
gerri
Edited by: Gerfried on Jul 17, 2009 11:42 AMOk, Gerfried send me the dump file and this is what was in it:
INV ROOT/LEAF 15857 perm entries : 0 [block 0]
bottom : 81 filevers: dummy convvers: 9
writecnt: 1
00001 nodepage.pno: 15857 nodepage.pt : data
00006 nodepage.pt2: inv nodepage.chk: checksumData
00008 nodepage.mde: empty
08181 nd_checksum : 61937 nodepge2.pno: 15857
08189 nodepge2.pt : data nodepge2.pt2: inv
08191 nodepge2.chk: checksumData
08192 nodepge2.mde: empty
00009 nd_bottom : 81 nd_rec_cnt : 0
00017 nd_level : 0
00019 nd_filestate: empty
00020 nd_sorted : false nd_root : 15857/F13D0000
00025 nd_right : nil_pno nd_left : nil_pno
00033 nd_last : nil_pno nd_conv_vers: 9
00045 nd_str_vers : nil_pno nd_file_vers: dummy
00052 ndPageVersio: 0 nd_inv_usage: 0
00057 nd_leaf_cnt : 1 nd_treeleavs: nil
00065 nd_trans_id : nil ndInvRoot : nil_pno
00077 nd_write_cnt: 1
END OF FILE
Obviously the reason for not delivering any data for the query is: this index is empty.
See "nd_filestate: empty" !
For some reasons (that I really don't know - sorry about that) this index had not been maintained anymore, since a very long time.
"nd_conv_vers: 9" tells us that it was the 9th savepoint that wrote down this page to the disks and that it had not been touched since then.
To view the current converter version you may just use the db_restartinfo command in dbmcli.
If you were a SAP customer the next thing I'd check would be with which database version these indexes had been created, what the internal file state is etc. - just to figure out the root cause.
As such an analysis is basically not possible via this forum all I can propose is to look for those indexes (containing 0 entries although the table has more rows) and rebuild them.
This statement should do the trick:
select i.owner, i.indexname, i.tablename, if.*
from files if join files tf on if.primaryfileid=tf.fileid
join indexes i on if.fileid=i.fileid
where if.entrycount =0
and if.type ='INDEX'
and tf.entrycount >0
best regards,
Lars -
This simple query takes 2 hrs. How to improve it??
This is a simple query. It takes 2 hours to run this query. Tables have over 100,000 rows.
SELECT
TO_CHAR(BC_T_ARRIVALS.ARR_FLIGHT_DATE,'DD/MM/YYYY') ARR_FLIGHT_DATE
FROM
BC_T_ARRIVALS a, BC_M_FLIGHTS f
WHERE
a.ARR_FLT_SEQ_NO = f.FLT_SEQ_NO AND
f.FLT_LOC_CODE = PK_BC_R_LOCATIONS.FN_SEL_LOC_CODE('BANDARANAYAKE INTERNATIONAL AIRPORT') AND TO_CHAR(a.ARR_FLIGHT_DATE,'YYYY/MM/DD') >= TO_CHAR(:P_FROM_DATE,'YYYY/MM/DD')
AND TO_CHAR(a.ARR_FLIGHT_DATE,'YYYY/MM/DD') <= TO_CHAR(:P_TO_DATE,'YYYY/MM/DD')
UNION
SELECT
TO_CHAR(BC_T_DEPARTURES.DEP_FLIGHT_DATE,'DD/MM/YYYY') DEP_FLIGHT_DATE
FROM
BC_T_DEPARTURES d, BC_M_FLIGHTS f
WHERE
d.DEP_FLT_SEQ_NO = BC_M_FLIGHTS.FLT_SEQ_NO AND
f.FLT_LOC_CODE = PK_BC_R_LOCATIONS.FN_SEL_LOC_CODE('BANDARANAYAKE INTERNATIONAL AIRPORT') AND TO_CHAR(d.DEP_FLIGHT_DATE,'YYYY/MM/DD') >= TO_CHAR(:P_FROM_DATE,'YYYY/MM/DD')
AND TO_CHAR(d.DEP_FLIGHT_DATE,'YYYY/MM/DD') <= TO_CHAR(:P_TO_DATE,'YYYY/MM/DD')As I see it, this query will not make the DB engine use any indexes since expressions are used in the 'WHERE' clause. Am I correct?
How can we improve the performance of this query???Maybe (do you really need to convert dates to chars ? That might prevent index use ...)
select f.BC_M_FLIGHTS,
TO_CHAR(BC_T_DEPARTURES.DEP_FLIGHT_DATE,'DD/MM/YYYY') DEP_FLIGHT_DATE,
TO_CHAR(BC_T_ARRIVALS.ARR_FLIGHT_DATE,'DD/MM/YYYY') ARR_FLIGHT_DATE
from (select BC_M_FLIGHTS,
FLT_LOC_CODE
from BC_M_FLIGHTS
where FLT_LOC_CODE = PK_BC_R_LOCATIONS.FN_SEL_LOC_CODE('BANDARANAYAKE INTERNATIONAL AIRPORT')
) f,
BC_T_ARRIVALS a,
BC_T_DEPARTURES d
where f.BC_M_FLIGHTS = a.ARR_FLT_SEQ_NO
and f.BC_M_FLIGHTS = d.DEP_FLT_SEQ_NO
and (TO_CHAR(a.ARR_FLIGHT_DATE,'YYYY/MM/DD') between TO_CHAR(:P_FROM_DATE,'YYYY/MM/DD') and TO_CHAR(:P_TO_DATE,'YYYY/MM/DD')
or TO_CHAR(d.DEP_FLIGHT_DATE,'YYYY/MM/DD') between TO_CHAR(:P_FROM_DATE,'YYYY/MM/DD') and TO_CHAR(:P_TO_DATE,'YYYY/MM/DD')
)Regards
Etbin
Edited by: Etbin on 2.3.2012 18:44
select column list altered -
Simple query help in plsql - help
oracle version : 10gR2
indexes are created on each column, is there anyway to make them used while searching for the records rewriting the following query to test given data in any case (lower ,upper)...
SELECT * FROM TX_USERS
WHERE userid like decode( UPPER('Md'),null,userid, UPPER( 'MD')||'%' ) and
first_name like decode(UPPER('Na'),null, first_name, UPPER( 'NA')||'%' ) AND
LAST_name like decode(('Ra'),null, LAST_name, UPPER('RA')||'%' )
-- list goes on..
UPPER('Md') -- is the input values comes from form.. for example i_userid.. this query works fine .. is there anyway of getting indices used without using functional based indexing when we rewrite query like shown below??? input parameter valeus can be anything and table column values can be anything i.e. anycase (upper or lower or mix of both)..
actual code would be
upper(userid) like decode( UPPER(i_userid),null,userid, UPPER( i_userid)||'%' ) and
upper(first_name) like decode(UPPER(i_first_name),null, first_name, UPPER( i_firstname)||'%' )
if we put upper(userid) then index not used ..........anyway of rewriting using it or any other technique... or any other new wayNo, its not working... see the below..
create table test5 as select owner, object_name, subobject_name, object_type from all_objects;
create unique index test5_i5 on test5 (owner, object_name, subobject_name, object_type);
select * from test5 where owner like 'SCOTT' AND OBJECT_NAME LIKE 'EMP';
INDEX RANGE SCAN| TEST5_I5 | 4 | 248 | 1 (0)| 00:00:01 |
but when i use
select * from test5 where UPPER(OWNER) LIKE 'SCOTT%' AND UPPER(OBJECT_NAME) LIKE 'EMP%';
TABLE ACCESS FULL| TEST5 | 3 | 186 | 65 (5)| 00:00:01 |
i know it goes to full scan, i want to know is there any other way to make index used .. without using functional based indx...
the reason is user can search any one of the column data and data is mixed case in table columns and/or conditions specified in query..
.. any help...
not sure how to use 'NLS_SORT=BINARY_CI' on multicolumn index and enable index used in search operation.. ANY OTHER WAY OF DOING THIS...
requirements is
mixed (lower,upper) data stored in db columns and mixed case data searched, 5 columns specified in where condition, data may be provided in search conditon to one or two or to all 5 columns in mixed case... matching records need to be returned.. suggest a good way of doing this... thnx -
Filters not getting passed in MDX query while using SAP BW with OBIEE
Hello,
I've been working on OBIEE with SAP BW as back-end. I've created some reports & those are working fine when there is less amount of data. But when I try to run a report with 3 dimensions & 1 fact it throws an error saying "No more storage space available for extending an internal table". When I checked MDX query, I found that the filters that I had applied to request & also selected from prompts are not getting passed in that query. So, I tried running a simple request using a simple filter in Answers. Although this request returns results but I can't see filter conditions in query. MDX query always show crossjoin but I can't see filter conditions anywhere.
Is it the normal OBIEE behaviour OR am I doing something wrong in there? Can you please help me out with this?
Thanks,
RockyHello Sainath,
We tried those things. But it is still giving same error.
State: HY00. Code: 10058. [NQODBC][SQL_STATE:HY000][nQSError: 10058] A general error has occurred. XML/A error returned from the server: Fault code: "XMLAnalysisError.0X80000005". Fault string: "The XML for Analysis provider encountered an error: MDX result contains too many cells (more than 1 million)". (HY000)
The problem here, I think, is the filter parameters are not getting passed in the MDX query. Any idea why would that happen? Is there any setting to do so?
Thanks in advance for help.
Regards,
Rocky -
Hi Everybody,
Does anybody know how can i know which indexes are not used in our Oracle 8iR3 Database.
We need to purge as soon as possible all indexes not used
in our Datawarehousing system because they're growing and growing.
I know there's some mechanism in Oracle 9i to query which are unused is it possible to simulate something similar?
Kind regards and thank you in advance.
José Luis Pérez
[email protected]Are you asking about index monitoring in 8i? One way (and there aren't very many at all) of doing this is to collect (query them out of the DD) execution plans and scan those for index usage.
-
Dear Experts,
Not able to Execute this simple query :
Select T1.JobID , T1.BudgetValue,T1.ActualValue FROM [dbo].[Enprise_JobCost_ActualBudgetView] T1 WHERE T1.TransType = '[%0]'
RegardsHello,
View - A View in simple terms is a subset of a 'virtual table. It can be used to retrieve data from the tables, Insert, Update or Delete from the tables. The Results of using View are not permanently stored in the database.
Stored Procedure - A stored procedure is a group of SQL statements which can be stored into the database and can be shared over the netwrok with different users.
http://www.geekinterview.com/question_details/65914
Better make a UDT for your requirement.
Thanks
Manvendra Singh Niranjan
Maybe you are looking for
-
I just burned a DVD-R and usually I can see the disc show up on my desktop and in Finder after it's done burning. This time I don't see it anywhere. I can pop the disc into my MacBookPro and it reads fine. Is there a way to test the drive in my MacPr
-
Quicktime functions disabled because a compatibile version of QT could not be found...
Suddenly I am getting this error on start-up...Quicktime functions disabled because a compatibile version of QT could not be found...what give ? AECS3...I have Quicktime Pro 7.65, I works fine, quicktime works in Premiere and in the Bridge. AE can't
-
PLEASE FIX IT APPLE EMAIL ME IF MY IPAD IS UNFREEZED
-
Windows performed an update yesterday and now I have a shield in the corner of my Foxfire icon and I have a blackout over the red X and minimize window in the upper right corner when I sign on to Foxfire. How do I get rid of it?
-
Hi, In my actual cubes, i have data for the 12 months ie from 01.2006 to 12.2006, I created copy planning function and in characteristcs usuage "Create Row" From change----T0 Change 1. Calyear--2006-- 2007 2. Calmonth--01.2006 to 03.2006-- 01.2007 to