Why isn't my query using the index?
I have a query that inserts values for engines in a grid; it uses a static date table to determine the day in week, or
week in year (depending on different standards, the DBA can configure this table to their business's likings). I have
two indexes on this table:
create table d_date (
date_key number(5) not null,
sql_calendar_date timestamp(3) null,
year_id number(5) null,
month_id number(3) null,
day_id number(3) null,
year_end_biz_date timestamp(3) null,
qtr_end_biz_date timestamp(3) null,
month_end_biz_date timestamp(3) null,
week_end_biz_date timestamp(3) null,
quarter_id number(3) null,
week_id number(3) null,
day_in_year number(5) null,
day_in_month number(3) null,
day_in_week number(3) null,
month_name char(3) null,
day_in_week_name char(3) null,
month_type_code char(1) null,
week_type_code char(1) null,
date_type_code char(1) null,
weekend_flag char(1) null,
holiday_flag char(1) null,
from_datetime timestamp(3) null,
to_datetime timestamp(3) null,
current_flag char(1) null,
constraint d_date_pkey primary key (date_key)
) tablespace dim;
create index d_date_dy on d_date(year_id, day_in_year) tablespace_dim_idx;
create index d_date_ww on d_date(year_id, week_id) tablespace_dim_idx;Now, when I run a query to insert the week id into a table based on two values, the year_key and day_in_year_key,
it should use the d_date_dy index correct?
Here is what the query looks like:
INSERT INTO F_ENGINE (YEAR_KEY,MONTH_KEY,WEEK_IN_YEAR_KEY,DAY_IN_YEAR_KEY,DAY_IN_MONTH_KEY,HOUR_IN_DAY_KEY, Q_HOUR_IN_DAY_KEY,
GRID_KEY,ENGINE_KEY,TIME_STAMP,ENGINE_CPU_UTIL,ENGINE_CPU_GRID_UTIL,MEMORY_TOTAL_BYTE, MEMORY_FREE_BYTE,DISK_FREE_MEGABYTE,
PROCESS_COUNT,ENGINE_ID,GRID_ID,GRID_NAME,BATCH_ID,RECORD_VIEWABLE_F)
SELECT EXTRACT(YEAR FROM START_DATETIME),EXTRACT(MONTH FROM START_DATETIME), DD.WEEK_ID,
TO_NUMBER(TO_CHAR(START_DATETIME, 'DDD')), EXTRACT(DAY FROM START_DATETIME),EXTRACT(HOUR FROM START_DATETIME),
FLOOR(EXTRACT(MINUTE FROM START_DATETIME)/15)*15,DG.GRID_KEY,DE.ENGINE_KEY, START_DATETIME,CPU_UTIL,DS_CPU,MEMORY,
FREE_MEMORY,FREE_DISK,PROCESSES,ID,PE.GRID,DG.GRID_NAME,:B1 ,1
FROM P_ENGINE PE, D_GRID DG, D_ENGINE DE, D_DATE DD
WHERE PE.GRID = DG.GRID_ID AND DG.CURRENT_FLAG = 'Y' AND PE.ID = DE.ENGINE_ID AND DE.GRID_KEY = DG.GRID_KEY AND
DE.CURRENT_FLAG = 'Y' AND PE.BATCH_ID = :B1 AND DD.YEAR_ID = EXTRACT(YEAR FROM START_DATETIME) AND
DD.DAY_IN_YEAR = TO_NUMBER(TO_CHAR(START_DATETIME,'DDD'))
ORDER BY EXTRACT(YEAR FROM START_DATETIME),EXTRACT(MONTH FROM START_DATETIME),
EXTRACT(DAY FROM START_DATETIME),EXTRACT(HOUR FROM START_DATETIME),FLOOR(EXTRACT(MINUTE FROM START_DATETIME)/15)*15,
DG.GRID_KEY,DE.ENGINE_KEY
Here is the explain plan:
Operation Object Object Type Order Rows Size (KB) Cost Time (sec) CPU Cost I/O Cost
INSERT STATEMENT
SORT ORDER BY
HASH JOIN
HASH JOIN
HASH JOIN
TABLE ACCESS FULL D_GRID TABLE 1 2 0.316 3 1 36887 3
TABLE ACCESS FULL D_ENGINE TABLE 2 10 0.410 3 1 42607 3
PARTITION LIST SINGLE 5 1434 344.496 9 1 2176890 9
TABLE ACCESS FULL P_ENGINE TABLE 4 1434 344.496 9 1 2176890 9
TABLE ACCESS FULL D_DATE TABLE 7 7445 283.550 19 1 3274515 18Now it is obviously not using the index for the d_date table since it is doing a full table access.
Does this have something to do with the fact that I am using extract(), to_number(), to_char() functions in my WHERE clause that it is not allowing the use of the index?
Any help would be greatly appreciated. Thanks.
-Tim
It's difficult to tell just from this. For one thing, you didn't post your query using the forum format tags, so it's hard to read and you didn't post your Oracle version.
In the query, you don't always prefix columns with the table alias. That makes it impossible for us (and maintainers of this code) to know at a glance which table a column is in.
It's possible that performing functions on a column will disable the index. Do your other tables have indexes? Do you have updated statistics on all the tables?
The main reason the optimizer will not use an index is because it thinks it cheaper not to.
Similar Messages
-
Why my select is not using the index
This is my index
CREATE INDEX CONFIG_STATE_IDX ON IDENTIFIER
(CONFIGURATION_ID, STATE)
LOGGING
TABLESPACE NII_INDEX
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
NOPARALLEL;
This is my select statement:
SELECT *
FROM identifier i
WHERE
i.configuration_id = '89afead40a0c0b8d00628c59aa405ea4'
AND i.state = 'QT'
AND ROWNUM <6
This is my exmplain plan result
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Hint=CHOOSE 5 2128
COUNT STOPKEY
TABLE ACCESS FULL IDENTIFIER 133 K 19 M 2128
Why it is not using the index on configuration_id and state.Possibility one: you didn't do an analyze statistics on the table and/or the index after index creation.
Possibility two: The optimizer has determined that it can return the query result set with fewer I/Os if it does a FTS vs using the index (the optimizer is very keen on I/Os). -
How to find out if your query uses the indexes?
How can one tell if the query being issued is using your indexes or doing full table scans?
Thank you.Thank you.
Ok, let me see if I understand it. So, having an
index may not speed things up.True
Full table scans are not bad at all -- as I have it
in my head. The query I ran before was: select *
from table1;In that case an index would only slow things down; you are asking it to get all the information from the table - it has to read all of the table ( a full scan).
>
So full table scans and index have to do with the db
block size and the size of the row correct?
Block size and row size don't have a huge amount to do with it, but they do play a role.
Let me ask: How does one know the size of a row and
then the best option for the db blocks? Block size is a global setting (at the tablespace level I think). You would not likely change the block size based on the average row length in any one table. It would be about the last thing you might look at in terms of tuning (though you might consider it up-front if you had a huge amount of very predictable data).
>
And if, I create indexes and queries have the where
clause and the database uses full table scans then
does it means that either:
The database believes that the best execution plan is
to either do FULL SCANS OR USE INDEXES -- ALL UPTO
THE DATABASE?
No. There is another piece of information that the database needs to make good decisions. If for example you have a WHERE clause "WHERE not_paid = 1" and you have an index on not_paid. To make a good decision the database needs to know about how many of the rows are likely to be not_paid =1. If it's 90% then a full table scan will be cheaper than looking up the addresses of 90% of the rows and then getting the data. If it's 10% using the index will be cheaper. You need to use Analyze Tables to get the database to store this information. Looks like you need to use a bit of time with the manuals.
Jon
-J -
How to avoid the query using the index?
select *from cstb_cut ;
cust_id cust_name
10001 xxxx
10002 yyyy
10003 zzzz
Please find the above table and 10000 records are there in that table and also one index was there on cust_id.
but my query don't want to use the index?how it will be done?Hi,
DEVI suvarna wrote:
select *from cstb_cut ;
cust_id cust_name
10001 xxxx
10002 yyyy
10003 zzzz
Please find the above table and 10000 records are there in that table and also one index was there on cust_id.
but my query don't want to use the index?how it will be done?
The index doesn't help for this query, so it's not used.
The main purpose of indexes is the help find a small number (like 1) of rows quickly. You're asking for all rows; getting each one through the index would be slower than just getting all of them directly.
Sometimes (but not here) the index can be used instead of the table, when the index contains all the data you need from the table. An index on cust_id doesn't tell you anything about any other column, such as cust_name. Since you asked to have all columns displayed, it has to fetch data from the table, not the index. -
Why does not my query use an index?
I have a table with some processed rows (state: 9) and some unprocessed rows (states: 0,1,2,3,4).
This table has over 120000 rows, but this number will grow.
Most of the rows are processed and most of them also contain a group id. Number of groups is relatively small (let's assume 20).
I would like to obtain the oldest some_date for every group. This values has to be outer joined to a on-line report (contains one row for each group).
Here is my set-up:
Tested on: 10.2.0.4 (Solaris), 10.2.0.1 (WinXp)
drop table t purge;
create table t(
id number not null primary key,
grp_id number,
state number,
some_date date,
pad char(200)
insert into t(id, grp_id, state, some_date, pad)
select level,
trunc(dbms_random.value(0,20)),
9,
sysdate+dbms_random.value(1,100),
'x'
from dual
connect by level <= 120000;
insert into t(id, grp_id, state, some_date, pad)
select level + 120000,
trunc(dbms_random.value(0,20)),
trunc(dbms_random.value(0,5)),
sysdate+dbms_random.value(1,100),
'x'
from dual
connect by level <= 2000;
commit;
exec dbms_stats.gather_table_stats(user, 'T', estimate_percent=>100, method_opt=>'FOR ALL COLUMNS SIZE 1');
Tom Kyte's printtab
==============================
TABLE_NAME : T
NUM_ROWS : 122000
BLOCKS : 3834I know, this could be easily solved by fast refresh on commit materialized view like this:
select
grp_id,
min(some_date),
from
t
where
state in (0,1,2,3,4)
grpup by
grp_id;+ I have to create log on (grp_id, some_date, state)
Number of rows with active state will be always relatively small. Let's assume 1000-2000.
So my another idea was to create a selective index. An index which would contain only data for rows with an active state.
Something like this:
create index fidx_active on t (
case state
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end,
case state
when 0 then some_date
when 1 then some_date
when 2 then some_date
when 3 then some_date
when 4 then some_date
end) compress 1; so a tuple (group_id, some_date) is projected to tuple (null, null) when the state is not an active state and therefore it is not indexed.
We can save even more space by compressing 1st expression.
analyze index idx_grp_state_date validate structure;
select * from index_stats
@pr
Tom Kyte's printtab
==============================
HEIGHT : 2
BLOCKS : 16
NAME : FIDX_ACTIV
LF_ROWS : 2000 <-- we're indexing only active rows
LF_BLKS : 6 <-- small index: 1 root block with 6 leaf blocks
BR_ROWS : 5
BR_BLKS : 1
DISTINCT_KEYS : 2000
PCT_USED : 69
PRE_ROWS : 25
PRE_ROWS_LEN : 224
OPT_CMPR_COUNT : 1
OPT_CMPR_PCTSAVE : 0Note: @pr is a Tom Kyte's print table script adopted by Tanel Poder (I'm using Tanel's library) .
Then I created a query to be outer joined to the report (report contains a row for every group).
I want to achieve a full scan of the index.
select
case state -- 1st expression
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end grp_id,
min(case state --second expression
when 0 then some_date
when 1 then some_date
when 2 then some_date
when 3 then some_date
when 4 then some_date
end) as mintime
from t
where
case state --1st expression: at least one index column has to be not null
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end is not null
group by
case state --1st expression
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end;-------------
Doc's snippet:
13.5.3.6 Full Scans
A full scan is available if a predicate references one of the columns in the index. The predicate does not need to be an index driver. A full scan is also available when there is no predicate, if both the following conditions are met:
All of the columns in the table referenced in the query are included in the index.
At least one of the index columns is not null.
A full scan can be used to eliminate a sort operation, because the data is ordered by the index key. It reads the blocks singly.
13.5.3.7 Fast Full Index Scans
Fast full index scans are an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULL constraint. A fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation, because the data is not ordered by the index key. It reads the entire index using multiblock reads, unlike a full index scan, and can be parallelized.
You can specify fast full index scans with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. Fast full index scans cannot be performed against bitmap indexes.
A fast full scan is faster than a normal full index scan in that it can use multiblock I/O and can be parallelized just like a table scan.
So the question is: Why does oracle do a full table scan?
Everything needed is in the index and one expression is not null, but index (fast) full scan is not even considered by CBO (I did a 10053 trace)
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 1 | 85 | 20 |00:00:00.11 | 3841 |
|* 2 | TABLE ACCESS FULL| T | 1 | 6100 | 2000 |00:00:00.10 | 3841 |
Predicate Information (identified by operation id):
2 - filter(CASE "STATE" WHEN 0 THEN "GRP_ID" WHEN 1 THEN "GRP_ID" WHEN 2
THEN "GRP_ID" WHEN 3 THEN "GRP_ID" WHEN 4 THEN "GRP_ID" END IS NOT NULL)Let's try some minimalistic examples. Firstly with no FBI.
create index idx_grp_id on t(grp_id);
select grp_id,
min(grp_id) min
from t
where grp_id is not null
group by grp_id;
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | HASH GROUP BY | | 1 | 20 | 20 |00:00:01.00 | 244 | 237 |
|* 2 | INDEX FAST FULL SCAN| IDX_GRP_ID | 1 | 122K| 122K|00:00:00.54 | 244 | 237 |
Predicate Information (identified by operation id):
2 - filter("GRP_ID" IS NOT NULL)This kind of output I was expected to see with FBI. Index FFS was used although grp_id has no NOT NULL constraint.
Let's try a simple FBI.
create index fidx_grp_id on t(trunc(grp_id));
select trunc(grp_id),
min(trunc(grp_id)) min
from t
where trunc(grp_id) is not null
group by trunc(grp_id);
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 1 | 20 | 20 |00:00:00.94 | 3841 |
|* 2 | TABLE ACCESS FULL| T | 1 | 6100 | 122K|00:00:00.49 | 3841 |
Predicate Information (identified by operation id):
2 - filter(TRUNC("GRP_ID") IS NOT NULL)Again, index (fast) full scan not even considered by CBO.
I tried:
alter table t modify grp_id not null;
alter table t add constraint trunc_not_null check (trunc(grp_id) is not null);I even tried to set table hidden column (SYS_NC00008$) to NOT NULL
It has no effect, FTS is still used..
Let's try another query:
select distinct trunc(grp_id)
from t
where trunc(grp_id) is not null
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH UNIQUE | | 1 | 20 | 20 |00:00:00.85 | 244 |
|* 2 | INDEX FAST FULL SCAN| FIDX_GRP_ID | 1 | 122K| 122K|00:00:00.49 | 244 |
Predicate Information (identified by operation id):
2 - filter("T"."SYS_NC00008$" IS NOT NULL)Here the index FFS is used..
Let's try one more query, very similar to the above query:
select trunc(grp_id)
from t
where trunc(grp_id) is not null
group by trunc(grp_id)
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 1 | 20 | 20 |00:00:00.86 | 3841 |
|* 2 | TABLE ACCESS FULL| T | 1 | 122K| 122K|00:00:00.49 | 3841 |
Predicate Information (identified by operation id):
2 - filter(TRUNC("GRP_ID") IS NOT NULL)And again no index full scan..
So my next question is:
What are the restrictions which prevent index (fast) fullscan to be used in these scenarios?
Thank you very much for your answers.
Edited by: user1175494 on 16.11.2010 15:23
Edited by: user1175494 on 16.11.2010 15:25I'll start off with the caveat that i'm no Johnathan Lewis so hopefully someone will be able to come along and give you a more coherent explanation than i'm going to attempt here.
It looks like the application of the MIN function against the case statement is confusing the optimizer and disallowing the usage of your FBI. I tested this against my 11.2.0.1 instance and your query chooses the fast full scan without being nudged in the right direction.
That being said, i was able to get this to use a fast full scan on my 10 instance, but i had to jiggle the wires a bit. I modified your original query slightly, just to make it easier to do my fiddling.
original (in the sense that it still takes the full table scan) query
with data as
select
case state -- 1st expression
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end as grp_id,
case state --second expression
when 0 then some_date
when 1 then some_date
when 2 then some_date
when 3 then some_date
when 4 then some_date
end as mintime
from t
where
case state --1st expression: at least one index column has to be not null
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end is not null
and
case state --second expression
when 0 then some_date
when 1 then some_date
when 2 then some_date
when 3 then some_date
when 4 then some_date
end is not null
select--+ GATHER_PLAN_STATISTICS
grp_id,
min(mintime)
from data
group by grp_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats +peeked_binds'));
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 2 | 33 | 40 |00:00:00.07 | 7646 |
|* 2 | TABLE ACCESS FULL| T | 2 | 33 | 4000 |00:00:00.08 | 7646 |
Predicate Information (identified by operation id):
2 - filter((CASE "STATE" WHEN 0 THEN "GRP_ID" WHEN 1 THEN "GRP_ID" WHEN 2
THEN "GRP_ID" WHEN 3 THEN "GRP_ID" WHEN 4 THEN "GRP_ID" END IS NOT NULL AND
CASE "STATE" WHEN 0 THEN "SOME_DATE" WHEN 1 THEN "SOME_DATE" WHEN 2 THEN
"SOME_DATE" WHEN 3 THEN "SOME_DATE" WHEN 4 THEN "SOME_DATE" END IS NOT
NULL))
modified version where we prevent the MIN function from being applied too early, by using ROWNUM
with data as
select
case state -- 1st expression
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end as grp_id,
case state --second expression
when 0 then some_date
when 1 then some_date
when 2 then some_date
when 3 then some_date
when 4 then some_date
end as mintime
from t
where
case state --1st expression: at least one index column has to be not null
when 0 then grp_id
when 1 then grp_id
when 2 then grp_id
when 3 then grp_id
when 4 then grp_id
end is not null
and
case state --second expression
when 0 then some_date
when 1 then some_date
when 2 then some_date
when 3 then some_date
when 4 then some_date
end is not null
and rownum > 0
select--+ GATHER_PLAN_STATISTICS
grp_id,
min(mintime)
from data
group by grp_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats +peeked_binds'));
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 2 | 20 | 40 |00:00:00.01 | 18 |
| 2 | VIEW | | 2 | 33 | 4000 |00:00:00.07 | 18 |
| 3 | COUNT | | 2 | | 4000 |00:00:00.05 | 18 |
|* 4 | FILTER | | 2 | | 4000 |00:00:00.03 | 18 |
|* 5 | INDEX FAST FULL SCAN| FIDX_ACTIVE | 2 | 33 | 4000 |00:00:00.01 | 18 |
Predicate Information (identified by operation id):
4 - filter(ROWNUM>0)
5 - filter(("T"."SYS_NC00006$" IS NOT NULL AND "T"."SYS_NC00007$" IS NOT NULL)) -
Why does it not use the index?
L.S.,
We are using a table called IT_RFC_REGISTRATION. It is a relatively big table for our application.
Its primary key is RFCNR, each new RFCNR getting the next value.
Now for my intranet report I am interested in the last 40 records. But when I execute:
SELECT *
FROM IT_RFC_REGISTRATION
ORDER BY RFCNR DESC
the query takes ages to execute.
When I do this:
SELECT RFCNR
FROM IT_RFC_REGISTRATION
ORDER BY RFCNR DESC
the result comes instantaneous because this query uses the index on RFCNR.
Why does the former query not use the index to execute? It should be much faster to fetch ROWIDs from the index end to start and use those to get the records, than to load all the records and then sort them.
Is there a trick with which I can use a join of the latter query and the former query to speed up the result?
Greetings,
Philbert de Zwart,
Utrecht, The Netherlands.The difference you see in query run time is based on the amount data being sorted, then returned. In the first query, a full table scan is faster since if the index was used, Oracle would have to do a lookup in the index, get the rowid's and go look up the data in the table (TWO disk i/o's). It's faster to just scan the entire table.
Indexes will generally not be used unless you have a where clause. If you only need a few fields from the table, you could include them all in an index. For instance, if you only need RFCNR & DESC create a concatenated index on those two columns and then only a scan of the index is required (very fast). -
Does an 'in' clause use the index?
In the following query:
Select * from myTable where field_1 in ('thisfield', 'thatfield');
Assuming there is an index on field_1, will this query use the index?
Thanks,
SaraIn the following query:
Select * from myTable where field_1 in ('thisfield', 'thatfield');
Assuming there is an index on field_1, will this query use the index?It should use the index to find where the row you want is in the table and then access the table to return all colunms for that row.
This can be easily verified by doing an explain plan on your SQL statement. The Oracle manuals should have information on how to
run an explain plan if you're not familiar with it. -
Why is this query not using the index?
check out this query:-
SELECT CUST_PO_NUMBER, HEADER_ID, ORDER_TYPE, PO_DATE
FROM TABLE1
WHERE STATUS = 'N'
and here's the explain plan:-
1
2 -------------------------------------------------------------------------------------
3 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
4 -------------------------------------------------------------------------------------
5 | 0 | SELECT STATEMENT | | 2735K| 140M| 81036 (2)|
6 |* 1 | TABLE ACCESS FULL| TABLE1 | 2735K| 140M| 81036 (2)|
7 -------------------------------------------------------------------------------------
8
9 Predicate Information (identified by operation id):
10 ---------------------------------------------------
11
12 1 - filter("STATUS"='N')
There is already an index on this column, as is shown below:-
INDEX_NAME INDEX_TYPE UNIQUENESS TABLE_NAME COLUMN_NAME COLUMN_POSITION
1 TABLE1_IDX2 NORMAL NONUNIQUE TABLE1 STATUS 1
2 TABLE1_IDX NORMAL NONUNIQUE TABLE1 HEADER_ID 1
So why is this query not using the index on the 'STATUS' Column?
I've already tried using optimizer hints and regathering the stats on the table, but the execution plan still remains the same, i.e. it still uses a FTS.
I have tried this command also:-
exec dbms_stats.gather_table_stats('GECS','GEPS_CS_SALES_ORDER_HEADER',method_opt=>'for all indexed columns size auto',cascade=>true,degree=>4);
inspite of this, the query is still using a full table scan.
The table has around 55 Lakh records, across 60 columns. And because of the FTS, the query is taking a long time to execute. How do i make it use the index?
Please help.
Edited by: user10047779 on Mar 16, 2010 6:55 AMIf the cardinality is really as skewed as that, you may want to look at putting a histogram on the column (sounds like it would be in order, and that you don't have one).
create table skewed_a_lot
as
select
case when mod(level, 1000) = 0 then 'N' else 'Y' end as Flag,
level as col1
from dual connect by level <= 1000000;
create index skewed_a_lot_i01 on skewed_a_lot (flag);
exec dbms_stats.gather_table_stats(user, 'SKEWED_A_LOT', cascade => true, method_opt => 'for all indexed columns size auto');Is an example. -
Query
SELECT case.case_objid FROM [email protected] case, table_x_cwp_tickect_details_vw t WHERE CASE.case_condition_cd IN ('OPEN', 'OPEN-DISPATCH', 'OPEN-REJECT', 'OPEN-RETURNED') AND case.case_type_cd in ('CUSTOMER FAULT', 'CHRONIC','SCHEDULED ACTIVITY','PROBLEM') AND ROWNUM <= 500 AND case.case_objid = t.ticket_objid AND ( ( case.account_id = '672286' ) ) ORDER BY case.case_id DESC
From PROD
Plan
SELECT STATEMENT HINT: FIRST_ROWS Cost: 2,629 Bytes: 221,500 Cardinality: 500
37 SORT ORDER BY Cost: 2,629 Bytes: 221,500 Cardinality: 500
36 COUNT STOPKEY
35 NESTED LOOPS OUTER Cost: 2,628 Bytes: 279,533 Cardinality: 631
33 HASH JOIN OUTER Cost: 2,627 Bytes: 275,116 Cardinality: 631
31 NESTED LOOPS OUTER Cost: 2,249 Bytes: 266,282 Cardinality: 631
28 NESTED LOOPS Cost: 1,766 Bytes: 257,448 Cardinality: 631
26 NESTED LOOPS Cost: 1,765 Bytes: 253,031 Cardinality: 631
24 NESTED LOOPS Cost: 1,764 Bytes: 248,614 Cardinality: 631
22 NESTED LOOPS Cost: 1,763 Bytes: 244,197 Cardinality: 631
19 NESTED LOOPS Cost: 1,258 Bytes: 235,363 Cardinality: 631
17 NESTED LOOPS Cost: 1,257 Bytes: 230,946 Cardinality: 631
14 NESTED LOOPS OUTER Cost: 752 Bytes: 217,695 Cardinality: 631
12 HASH JOIN Cost: 751 Bytes: 213,278 Cardinality: 631
1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
11 HASH JOIN Cost: 748 Bytes: 208,861 Cardinality: 631
2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
10 HASH JOIN Cost: 746 Bytes: 204,444 Cardinality: 631
3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
9 HASH JOIN Cost: 743 Bytes: 200,027 Cardinality: 631
4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
8 NESTED LOOPS Cost: 741 Bytes: 195,610 Cardinality: 631
5 REMOTE REMOTE CASE Cost: 235 Bytes: 156,488 Cardinality: 631
7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
13 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
15 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
18 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
21 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
20 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
27 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
30 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
29 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
bold 32 TABLE ACCESS FULL TABLE SA.TABLE_MOD_LEVEL Cost: 376 Bytes: 1,442,084 Cardinality: 103,006 bold
34 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
From DEV platform
Plan
SELECT STATEMENT HINT: FIRST_ROWS Cost: 591 Bytes: 61,134 Cardinality: 138
37 SORT ORDER BY Cost: 591 Bytes: 61,134 Cardinality: 138
36 COUNT STOPKEY
35 HASH JOIN Cost: 590 Bytes: 61,134 Cardinality: 138
1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
34 HASH JOIN Cost: 588 Bytes: 60,168 Cardinality: 138
2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
33 HASH JOIN Cost: 585 Bytes: 59,202 Cardinality: 138
3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
32 HASH JOIN Cost: 583 Bytes: 58,236 Cardinality: 138
4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
31 NESTED LOOPS OUTER Cost: 580 Bytes: 57,270 Cardinality: 138
29 NESTED LOOPS OUTER Cost: 579 Bytes: 56,304 Cardinality: 138
27 NESTED LOOPS OUTER Cost: 469 Bytes: 54,372 Cardinality: 138
24 NESTED LOOPS Cost: 363 Bytes: 52,440 Cardinality: 138
22 NESTED LOOPS Cost: 362 Bytes: 51,474 Cardinality: 138
20 NESTED LOOPS Cost: 361 Bytes: 50,508 Cardinality: 138
18 NESTED LOOPS Cost: 360 Bytes: 49,542 Cardinality: 138
15 NESTED LOOPS Cost: 249 Bytes: 47,610 Cardinality: 138
13 NESTED LOOPS Cost: 248 Bytes: 46,644 Cardinality: 138
10 NESTED LOOPS OUTER Cost: 138 Bytes: 43,746 Cardinality: 138
8 NESTED LOOPS Cost: 137 Bytes: 42,780 Cardinality: 138
5 REMOTE REMOTE CASE Cost: 26 Bytes: 34,224 Cardinality: 138
7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
14 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
17 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
16 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
19 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
21 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
26 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
bold 28 INDEX RANGE SCAN INDEX SA.IND_PART_INFO2PART_NUM Cost: 1 Bytes: 14 Cardinality: 1 bold
30 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
Conclusion:
IND_PART_INFO2PART_NUM is not in use in Production environment
PROD
1. SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
INDEX_NAME NUM_ROWS CLUSTERING_FACTOR
IND_PART_INFO2PART_NUM 103023 46488
DEV environment
SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR,table_name from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
INDEX_NAME NUM_ROWS CLUSTERING_FACTOR TABLE_NAME
IND_PART_INFO2PART_NUM 101982 45722 TABLE_MOD_LEVEL
1. Index is rebuild
2. stats are up to date
3. Redef on table is done.
Still no change in the plan .Osama-mustafa wrote:
Aman.... wrote:
Osama-mustafa wrote:
alter index <index-name> rebuild ;Why?
Aman....I faced this issue with query and indexes was need rebuildWhat issue Osama-that query wasn't using index and after rebuild it did start using it? Not just that this reply is wrong , this is OP has mentioned that he has done already. Please note that index rebuild is not the answer when the query is not using the index. There can be many reasons behind it. Have a look at Richard Foote's blog where he explains all of this in a very detailed way and in many posts.
Aman.... -
Why is Oracle not using the index??
Hi,
I have a table called 'arc_errors' which has an index on 'member_number' as follows:- Create/Recreate indexes
create index DWO.DW_ARC_CERRORS_MNO on DWO.DW_ARC_CERRORS (MEMBER_NUMBER);
But surpisingly, when I execute the following query, it does not use the index.
SELECT member_number,
COUNT(*) error_count
FROM arc_errors a
WHERE member_number = 68534152 AND
( tx_type = 'SDIC' AND
error_number IN (4, 7, 12, 13, 15, 17, 18, 705) )
OR
( tx_type = 'AUTH' AND
error_number IN (100, 104, 107, 111, 116) )
OR
( tx_type = 'BHO' AND
error_number IN (708,710) )
OR
( tx_type = 'XLGN' AND
( error_number BETWEEN 102 AND 105 OR
error_number BETWEEN 107 AND 120 OR
error_number BETWEEN 300 AND 304 ) )
OR
( tx_type = 'None' AND
( error_number IN (20, 112) OR
error_number BETWEEN 402 AND 421 ) )
OR
( tx_type = 'HYBR' AND
error_number IN (303, 304) )
GROUP BY member_number;
This is what 'explain plan' tell me
SELECT STATEMENT, GOAL = RULE 237907 502923 15087690
SORT GROUP BY 237907 502923 15087690
PARTITION RANGE ALL
TABLE ACCESS FULL DWO DW_ARC_CERRORS 237209 502923 15087690
Can someone tell me why a 'table acess full' is required here?
Thanks in advance,
RajeshSorry, I just found the solution myself. I need to put an extra pair of braces around the set of conditions seperated by OR.
-
How can i know if my query is using the index ?
Hello...
How can i know if my query is using the index of the table or not?
im using set autotrace on...but is there another way to do it?
thanks!
Alessandro Falanque.Hi,
You can use Explain Plan for checking that your query is using proper index or not. First you need to check that Plan_table is installed in your database or not. If it is not there THEN THE SCRIPT WILL BE LIKE THIS:
CREATE TABLE PLAN_TABLE (
STATEMENT_ID VARCHAR2 (30),
TIMESTAMP DATE,
REMARKS VARCHAR2 (80),
OPERATION VARCHAR2 (30),
OPTIONS VARCHAR2 (30),
OBJECT_NODE VARCHAR2 (128),
OBJECT_OWNER VARCHAR2 (30),
OBJECT_NAME VARCHAR2 (30),
OBJECT_INSTANCE NUMBER,
OBJECT_TYPE VARCHAR2 (30),
OPTIMIZER VARCHAR2 (255),
SEARCH_COLUMNS NUMBER,
ID NUMBER,
PARENT_ID NUMBER,
POSITION NUMBER,
COST NUMBER,
CARDINALITY NUMBER,
BYTES NUMBER,
OTHER_TAG VARCHAR2 (255),
PARTITION_START VARCHAR2 (255),
PARTITION_STOP VARCHAR2 (255),
PARTITION_ID NUMBER,
OTHER LONG,
DISTRIBUTION VARCHAR2 (30))
TABLESPACE SYSTEM NOLOGGING
PCTFREE 10
PCTUSED 40
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 10240
NEXT 10240
PCTINCREASE 50
MINEXTENTS 1
MAXEXTENTS 121
FREELISTS 1 FREELIST GROUPS 1 )
NOCACHE;
After that write the following command in the SQL prompt.
Explain plan for (Select statement);
Select level, SubStr( lpad(' ',2*(Level-1)) || operation || ' ' ||
object_name || ' ' || options || ' ' ||
decode(id, null , ' ', decode(position, null,' ', 'Cost = ' || position) ),1,100)
|| ' ' || nvl(other_tag, ' ') Operation
from PLAN_TABLE
start with id = 0
connect by
prior id = parent_id;
This will show how the query is getting executed . What are all the indexes it is using etc.
Cheers.
Samujjwal Basu -
Rule-Based Optimizer doesn4t use the index
Does anybody know why the rule-based optimizer doesn4t use the index of all columns in the where clause?
I have a select that use the hint RULE to force the optimizer to work in rule mode and also one index to all columns used in the where clause. Analyzing the execution plan (EXPLAIN PLAN) I observed the optimizer accesses all tables, but one, using the index. There4s one table (the first of the execution plan) that is accessed using a Full Table Scan (FTS).
I've rebuilt the index for this table, but the execution plan doesn4t change.
Any suggestions?
Thanks in advance.
Eliane.Hi. Oracle may not use an index if it finds that a full table scan is quicker/more efficient. Try the hint /*+ INDEX (table index) */ and compare the query performance with that of the one without this hint. (As you know, if you force Rule-based approach, the COST column in EXPLAIN PLAN output will not be populated. You may have to use trace/tkprof.)
-
Peformance tuning of query using bitmap indexes
Hello guys
I just have a quick question about tuning the performance of sql query using bitmap indexes..
Currently, there are 2 tables, date and fact. Fact table has about 1 billion row and date dim has about 1 million. These 2 tables are joined by 2 columns:
Date.Dateid = Fact.snapshot.dates and Date.companyid = fact.companynumber
I have query that needs to be run as the following:
Select dates.dayofweek, dates,dates, fact.opened_amount from dates, facts
where Date.Dateid = Fact.snapshot.dates and Date.companyid = fact.companynumber and dates.dayofweek = 'monday'.
Currently this query is running forever. I think it is joining that takes a lot of time. I have created bitmap index on dayofweek column because it's low on distinctive rows. But it didn't seem to speed up with the performance..
I'd like to know what other indexes will be helpful for me.. I am thinking of creating another one for companynumber since it also have low distinctive records.
Currently the query is being generated by frontend tools like OBIEE so I can't change the sql nor can't I purge data or create smaller table, I have to what with what I have..
So please let me know your thoughts in terms of performance tunings.
ThanksThe explain plan is:
Row cost Bytes
Select statement optimizer 1 1
nested loops 1 1 299
partition list all 1 0 266
index full scan RD_T.PK_FACTS_SNPSH 1 0 266
TABLE ACCESS BY INDEX ROWID DATES_DIM 1 1 33
INDEX UNIQUE SCAN DATES_DIM_DATE 1 1
There is no changes nor wait states, but query is taking 18 mins to return results. When it does, it returns 1 billion rows, which is the same number of rows of the fact table....(strange?)That's not a bitmap plan. Plans using bitmaps should have steps indicating bitmap conversions; this plan is listing ordinary btree index access. The rows and bytes on the plan for the volume of data you suggested have to be incorrect. (1 row instead of 1B?????)
What version of the data base are you using?
What is your partition key?
Are the partioned table indexes global or local? Is the partition key part of the join columns, and is it indexed?
Analyze the tables and all indexes (use dbms_stats) and see if the statistics get better. If that doesn't work try the dynamic sampling hint (there is some overhead for this) to get statistics at runtime.
I have seen stats like the ones you listed appear in 10g myself.
Edited by: riedelme on Oct 30, 2009 10:37 AM -
How to monitor perticuler sql statement using the INDEX or not?
I am running on a long running quary, and the output is comming very late. So i want to know the sql quary is using the index or not? How to know that?
If you want to check the real execution plan of a running query without waiting for query completion, you can try following steps that you should adapt to your query and your environment:
1. start the query
select
count(*)
from all_objects, all_objects;2. Retrieve in another session the SQL_ID and the CHILD_NUMBER of the running query:
select sql_id, child_number, sql_text
from v$sql
where sql_text like '%all_objects%';3. use DBMS_XPLAN.DISPLAY_CURSOR to get the real execution plan from shared pool using SQL_ID and CHILD_NUMBER from step 2:
select * from table(dbms_xplan.display_cursor(<sql_id>,<child_number>));Actually you don't need to restart the query if it is already running because the hint GATHER_PLAN_STATISTICS is only needed if you want to have current execution statistics.
Edited by: P. Forstmann on 2 mars 2011 10:23 -
Hi,
I have a Z-Table. The Primary key is:
EQUNR and LFDNR
I created now a new index with the field: EQUNR BSTNK .
Now I entered 3 equnrs and bstnk like 07* in SE16n
Normally what I thought should happen is that it uses the index to read the three equipments and than checks the field bstnk.
Instead it does a sequentiel read of the hole table that contains 12mio entries!
When I enter the bstnk more qualified like 0712354* the search is fast (1sec). Why is SAP bypassing the index and does a sequentiel read instead?!Hi I checked,
ST05 the fast run was using an Index, the second didn't!
Thanks to John. After I started a runstat on this table it worked.
But the weird thing is when I use a inner join between my Z-Table and the EQUI table it doesn't use the index.
When I first select all equnrs in EQUI and then select the data from my z-Table with for all entries it uses my new index!
Example:
EQUNR has Index on field SERNR
Z-Table has Index on EQUNR + BSTNK
in sernrs I have ~5 full qualified sernos
in bstnk I have something like 07*
3 of these serialnumbers are in a bstnk that begins with 07.
select *
into corresponding fields of table search_result
from equi as a
inner join z-table as b on b~equnr = a~equnr
where a~sernr in sernrs
and b~bstnk in bstnks
After 5 min I have to kill the process. in SM50 I can see sequential read...
When I do this:
select equnr
from equi
into corresponding fields of table lt_search_result
where sernr in sernrs.
select *
from z_table
into corresponding fields of table lt_search_result
for all entries in lt_search_result
where equnr = lt_search_result-equnr
and bstnk in bstnks.
It takes 2sec and I got the result.
Edited by: Daniel Winter on Apr 21, 2010 8:51 AM
Edited by: Daniel Winter on Apr 21, 2010 8:51 AM
Maybe you are looking for
-
Urgent Deadline to Fix PC Mess Displaying iWeb Created Site -- Please Help!
IWeb 08 and web-design-savvy Mac users, I really need your help... and I'm on a tight deadline. I've designed the website promoting our group's big event by using iWeb 08; I was very troubled when I discovered tonight that there are major display pro
-
Website will not open correctly
I haev a website that that I use with no issues on my Desktop computer, but when I open webite on the ipad some things don't work, and the owner of the site says it's Safari. Anybody have a solution?
-
I want to get rid of an old email address but forget the password?
I have changed my email address and password, but to change icloud I need my old email addresses' apple ID password, which I no longer have. Help!
-
Hi, I've tried several floppy disks (all of which work in other computers), and also flashed the bios to the latest version, and cleared the cmos. What I'm still getting is this: I put a floppy disk into the diskdrive (in Windows, in DOS it seems to
-
Slow SDO_RELATE when using group by.. please help!!
Hi All, I'm fairly new to the spatial side of Oracle so please go easy on me. I have 2 tables (a and b), each containing line geometries. There is a one(a) to many(b) relationship between the two. I want to write a query which selects information fro