Bitmap index column goes for full table scan

Hi all,
Database : 10g R2
OS : Windows xp
my select query is :
SELECT tran_id, city_id, valid_records
FROM transaction_details
WHERE type_id=101;
And the Explain Plan is :
Plan
SELECT STATEMENT ALL_ROWSCost: 29 Bytes: 8,876 Cardinality: 634
1 TABLE ACCESS FULL TABLE TRANSACTION_DETAILS** Cost: 29 Bytes: 8,876 Cardinality: 634
total number of rows in the table = 1800 ;
distinct value of type_ids are 101,102,103
so i created a bit map index on it.
CREATE BITMAP INDEX btmp_typeid ON transaction_details
(type_id)
LOGGING
NOPARALLEL;
after creating the index, the explain plan shows the same. why it goes for full table scan?.
Kindly share ur idea on this.
Edited by: 887268 on Apr 3, 2013 11:01 PM
Edited by: 887268 on Apr 3, 2013 11:02 PM

>
I am sorry for being ignorant, can you please cite any scenario of locking due to bitmap indices? A link can be useful as well.
>
See my full reply in this thread
Bitmap index for FKs on Fact tables
>
ETL is affected because DML operations (INSERT/UPDATE/DELETE) on tables with bitmapped indexes can have serious performance issues due to the serialization involved. Updating a single bit-mapped column value (e.g. from 'M' to 'F' for gender) requires both bitmapped index blocks to be locked until the update is complete. A bitmap index stored ROWID ranges (min rowid - max rowid) than can span many, many records. The entire 'range' of rowids is locked in order to change just one value.
To change from 'M' the 'M' rowid range for that one row is locked and the ROWID must be removed from the range byt clearing the bit. To change to 'F' the 'F' rowid id range needs to be found, locked and the bit set that corresponds to that rowid. No other rows with rowids in the range can be changed since this is a serial operation. If the range includes 1000 rows and they all need changed it takes 1000 serial operations.

Similar Messages

"db file scattered read" too high and Query going for full table scan-Why ?

Hi,
I had a big table of around 200mb and had a index on it.
In my query I am using the where clause which has to use the
index. I am neither using any not null condition
nor using any function on the index fields.
Still my query is not using the index.
It is going for full table scan.
Also the statspack report is showing the
"db file scattered read" too high.
Can any body help and suggest me why this is happenning.
Also tell me the possible solution for it.
Thanks
Arun Tayal

"db file scattered read" are physical reads/multi block reads. This wait occurs when the session reading data blocks from disk and writing into the memory.
Take the execution plan of the query and see what is wrong and why the index is not being used.
However, FTS are not always bad. By the way, what is your db_block_size and db_file_multiblock_read_count values?
If those values are set to high, Optimizer always favour FTS thinking that reading multiblock is always faster than single reads (index scans).
Dont see oracle not using index, just find out why oracle is not using index. Use the INDEX hint to force optimizer to use index. Take the execution with/witout index and compare the cardinality,cost and of course, logical reads.
Jaffar
Message was edited by:
The Human Fly

Order by column has index which results in full table scan

I have a query on table A which has index for column B.In the query i am using order by column B .In explain plan it shows that the full table scan is performed for table A without picking up the index for B .How can i ensure that index is picked up in the explain plan.Please help its urgent.
Pandu

Please help its urgent.Contact Oracle Support in that case.
By making that remark you have just made Blushadow go out to lunch (again) now.... ;)
Depending on your query a full scan could be 100% appropriate here.
But since you didn't post your DB_version, optimizer settings, execution plan etc. there's not much more to say, really, besides:
"Full scans aren't always evil".
See:
[When your query takes too long...|http://forums.oracle.com/forums/thread.jspa?messageID=3299435]
[How to post a SQLstatement Tuning Request|http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0]

Different Cost values for full table scans

I have a very simple query that I run in two environments (Prod (20 CPU) and Dev (12 CPU)). Both environemtns are HPUX, oracle 9i.
The query looks like this:
SELECT prd70.jde_item_n
FROM gdw.vjda_gdwprd68_bom_cmpnt prd68
,gdw.vjda_gdwprd70_gallo_item prd70
WHERE prd70.jde_item_n = prd68.parnt_jde_item_n
AND prd68.last_eff_t+nvl(to_number(prd70.auto_hld_dy_n),0)>= trunc(sysdate)
GROUP BY prd70.jde_item_n
When I look at the explain plans, there is a significant difference in cost and I can't figure out why they would be different. Both queries do full table scans, both instances have about the same number of rows, statistics on both are fresh.
Production Plan:
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=18398 Card=14657 B
ytes=249169)
1 0 SORT (GROUP BY) (Cost=18398 Card=14657 Bytes=249169)
2 1 HASH JOIN (Cost=18304 Card=14657 Bytes=249169)
3 2 TABLE ACCESS (FULL) OF 'GDWPRD70_GALLO_ITEM' (Cost=949
4 Card=194733 Bytes=1168398)
4 2 TABLE ACCESS (FULL) OF 'GDWPRD68_BOM_CMPNT' (Cost=5887
Card=293149 Bytes=3224639)
Development plan:
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3566 Card=14754 B
ytes=259214)
1 0 HASH GROUP BY (GROUP BY) (Cost=3566 Card=14754 Bytes=259214)
2 1 HASH JOIN (Cost=3558 Card=14754 Bytes=259214)
3 2 TABLE ACCESS (FULL) OF 'GDWPRD70_GALLO_ITEM' (Cost=1914
4 Card=193655 Bytes=1323598)
4 2 TABLE ACCESS (FULL) OF 'GDWPRD68_BOM_CMPNT' (Cost=1076
Card=295075 Bytes=3169542)
There seems to be no reason for the costs to be so different, but I'm hoping that someone will be able to lead me in the right direction.
Thanks,
Jdelao

This link may help:
http://jaffardba.blogspot.com/2007/07/change-behavior-of-group-by-clause-in.html
But looking at the explain plans one of them uses a SORT (GROUP BY) (higher cost query) and the other uses a HASH GROUP BY (GROUP BY) (lower cost query). From my searches on the `Net the HASH GROUP BY is a more efficient algorithm than the SORT (GROUP BY) which would lead me to believe that this is one of the reasons why the cost values are so different. I can't find which version HASH GROUP BY came in but quick searches indicate 10g for some reason.
Are your optimizer features parameter set to the same value? In general you could compare relevant parameters to see if there is a difference.
Hope this helps!

SIDs for Full table scan wait events in db

Guys,
10.2.0.5/ 2 node RAC / RHEL-3
CanAnyone provide me an sql to find all SID doing full table scans in a db?
Thanks!
Hari

You ought to be able to query v$sql_plan for those sql plans with a full scan in them and if you want all the recent plans that contain a full table scan in them. You can join this back to v$session for those session currently executing a full table scan but if the sql in question was a previous statement executed by the session the join will not show the session because that statement is no longer the current statement.
1 select p.sql_id, s.sid, p.object_name, p.operation, p.options
2 from v$sql_plan p, v$session s
3 where p.options like '%FULL%'
4* and s.sql_id = p.sql_id
You will probably want to filter out internal operations (operation = "FIXED TABLE")
HTH -- Mark D Powell --

Slow Query Using index. Fast with full table Scan.

Hi;
(Thanks for the links)
Here's my question correctly formated.
The query:
SELECT count(1)
from ehgeoconstru ec
where ec.TYPE='BAR'
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'Runs on 32 seconds!
Same query, but with one extra where clause:
SELECT count(1)
from ehgeoconstru ec
where ec.TYPE='BAR'
and ( (ec.contextVersion = 'REALWORLD')     --- ADDED HERE
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'This runs in 400 seconds.
It should return data from one table, given the conditions.
The version of the database is Oracle9i Release 9.2.0.7.0
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME                                 TYPE        VALUE
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     99
optimizer_index_cost_adj             integer     10
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSE
SQL> Here is the output of EXPLAIN PLAN for the first fast query:
PLAN_TABLE_OUTPUT
| Id | Operation                     | Name               | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT     |                         |           |       |       |
|   1 | SORT AGGREGATE       |                         |           |       |       |
|* 2 |   TABLE ACCESS FULL   | EHCONS            |       |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE"
              IS NULL AND "EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy
-mm-dd
              hh24:mi:ss') AND "EC"."TYPE"='BAR')
Note: rule based optimizationHere is the output of EXPLAIN PLAN for the slow query:
PLAN_TABLE_OUTPUT
   |       |
|   1 | SORT AGGREGATE              |                             |       |
   |       |
|* 2 |   TABLE ACCESS BY INDEX ROWID| ehgeoconstru      |       |
   |       |
|* 3 |    INDEX RANGE SCAN          | ehgeoconstru_VSN |       |
   |       |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE" IS
NULL AND "EC"."TYPE"='BAR')
PLAN_TABLE_OUTPUT
   3 - access("EC"."CONTEXTVERSION"='REALWORLD' AND "EC"."BIRTHDATE"<=TO_DATE('2
009-10-06
              11:52:12', 'yyyy-mm-dd hh24:mi:ss'))
       filter("EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy-mm-dd hh24:
mi:ss'))
Note: rule based optimizationThe TKPROF output for this slow statement is:
TKPROF: Release 9.2.0.7.0 - Production on Tue Nov 17 14:46:32 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: gen_ora_3120.trc
Sort options: prsela exeela fchela
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT count(1)
from ehgeoconstru ec
where ec.TYPE='BAR'
and ( (ec.contextVersion = 'REALWORLD')
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00     538.12     162221    1355323          0           1
total        4      0.00     538.12     162221    1355323          0           1
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 153
Rows     Row Source Operation
      1 SORT AGGREGATE
27747   TABLE ACCESS BY INDEX ROWID OBJ#(73959)
2134955    INDEX RANGE SCAN OBJ#(73962) (object id 73962)
alter session set sql_trace=true
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.02          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        1      0.00       0.02          0          0          0           0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 153
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      2      0.00       0.02          0          0          0           0
Fetch        2      0.00     538.12     162221    1355323          0           1
total        5      0.00     538.15     162221    1355323          0           1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        0      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
    2 user SQL statements in session.
    0 internal SQL statements in session.
    2 SQL statements in session.
Trace file: gen_ora_3120.trc
Trace file compatibility: 9.02.00
Sort options: prsela exeela fchela
       2 sessions in tracefile.
       2 user SQL statements in trace file.
       0 internal SQL statements in trace file.
       2 SQL statements in trace file.
       2 unique SQL statements in trace file.
      94 lines in trace file.Edited by: PauloSMO on 17/Nov/2009 4:21
Edited by: PauloSMO on 17/Nov/2009 7:07
Edited by: PauloSMO on 17/Nov/2009 7:38 - Changed title to be more correct.

Although your optimizer_mode is choose, it appears that there are no statistics gathered on ehgeoconstru. The lack of cost estimate and estimated row counts from each step of the plan, and the "Note: rule based optimization" at the end of both plans would tend to confirm this.
Optimizer_mode choose means that if statistics are gathered then it will use the CBO, but if no statistics are present in any of the tables in the query, then the Rule Based Optimizer will be used. The RBO tends to be index happy at the best of times. I'm guessing that the index ehgeoconstru_VSN has contextversion as the leading column and also includes birthdate.
You can either gather statistics on the table (if all of the other tables have statistics) using dbms_stats.gather_table_stats, or hint the query to use a full scan instead of the index. Another alternative would be to apply a function or operation against the contextversion to preclude the use of the index. something like this:
SELECT COUNT(*)
FROM ehgeoconstru ec
WHERE ec.type='BAR' and
      ec.contextVersion||'' = 'REALWORLD'
      ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') and
      deathdate is null and
      SUBSTR(ec.strgfd, 1, LENGTH('[CIMText')) <> '[CIMText'or perhaps UPPER(ec.contextVersion) if that would not change the rows returned.
John

Why my query not using any index but doing a FULL TABLE SCAN

Hi,
My EXPLAIN PLAN output is
Plan hash value: 1163866984
| Id | Operation               | Name              | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT        |                   |   774 |   159K|       | 40847   (2)| 00:08:11 |
|* 1 | FILTER                 |                   |       |       |       |            |          |
|   2 |   SORT GROUP BY         |                   |   774 |   159K|       | 40847   (2)| 00:08:11 |
|* 3 |    HASH JOIN            |                   | 77337 |    15M| 9744K| 40843   (2)| 00:08:11 |
|* 4 |     HASH JOIN           |                   | 77337 | 8836K| 5896K| 20987   (2)| 00:04:12 |
|* 5 |      HASH JOIN          |                   | 77337 | 4984K|       | 9292   (3)| 00:01:52 |
|* 6 |       HASH JOIN         |                   | 24991 |   951K|       | 3349   (3)| 00:00:41 |
|* 7 |        TABLE ACCESS FULL| IDS_TXNIDNUMBERS | 24991 |   683K|       | 2328   (3)| 00:00:28 |
|   8 |        TABLE ACCESS FULL| IDS_TXNDEMDATAMAP | 2419K|    25M|       | 1006   (3)| 00:00:13 |
|   9 |       TABLE ACCESS FULL | IDS_IDNUMBERS     | 7435K|   191M|       | 5903   (2)| 00:01:11 |
| 10 |      TABLE ACCESS FULL | IDS_DEMDATA       | 2583K|   125M|       | 3683   (5)| 00:00:45 |
| 11 |     TABLE ACCESS FULL   | IDS_TXN           | 2583K|   231M|       | 6403   (1)| 00:01:17 |
----------------------------------------------------------------------------------------------------- All my 5 tables IDS_TXNIDNUMBERS, IDS_TXNDEMDATAMAP, IDS_IDNUMBERS,IDS_DEMDATA, IDS_TXN has indexes in relevant columns. Is it cause less time so CBO is not using the indexes.
Thanks
Amitava.

amitavachatterjee1975 wrote:
Please be polite when responding to my queries. If you find these questions not to your standard, stay away from them. This is an open forum and I have got my full rights to ask questions.Unsure, what wrong did you find in SB's reply. I find those links perfectly knowledgeable. The question of having so many unanswered questions probably pricked you a little too much. But that, IMO, is a legitimate question, to be asked to a User who even after being associated with OTN for over an year has 100% record of not getting an answer.
For your original question, you will have to provide more details to allow people to answer you.
You must read {message:id=3292438} and post the mentioned details. People do not carry a Crystal Ball to identify the problem merely by reading few lines of Problem description and Explain plans. Do not make people guess, provide appropriate details, to help them Help "You".

Avod full table scan help...

HI ,
I have sql with some filter and all the have index. the table size is huge index is there in explain plan though index it's going for full table scan it's not recognizing index. i used index hint/*+ INDEX (SYM.SYM_DEPL,SYM.SYDB_DE_N18) */ though it's not recoginizing index in explian plan going for full table scan. and qury take more time.
please help to resolve the issue and it should recognize index rather than full table scan..

user13301356 wrote:
HI ,
I have sql with some filter and all the have index. the table size is huge index is there in explain plan though index it's going for full table scan it's not recognizing index. i used index hint/*+ INDEX (SYM.SYM_DEPL,SYM.SYDB_DE_N18) */ though it's not recoginizing index in explian plan going for full table scan. and qury take more time.
please help to resolve the issue and it should recognize index rather than full table scan..What is database version? Are all columns in the table indexed? Copy and paste the query that you are executing.

Selecting a column goes for a full table scan

Hi,
Oracle version 10.2
I have the below query:
SELECT   c.companyid,
         c.contactid,
         c.contactlname
    FROM contact c,company ic
   WHERE UPPER((c.contactlname)) LIKE CASE
           WHEN 'test' IS NULL THEN
            UPPER((c.contactlname))
           ELSE DECODE(1,
                   1,
                   '%' || 'TEST' || '%',
                   2,
                   'TEST' || '%',
                   3,
                   '%' || 'TEST',
                   4,
                   'TEST')
         END
     AND c.activeflag = DECODE('Y', 'N', 'Y', c.activeflag)
     AND ic.companyid=c.companyidthis is using the index on table company.
Explain plan:
SELECT STATEMENT, GOAL = ALL_ROWS               68     3523     176150
NESTED LOOPS               68     3523     176150
TABLE ACCESS FULL          CONTACT     65     3523     155012
INDEX UNIQUE SCAN          COMPANY_PK     0     1     6          Now if i include two more columns from the company table in the select statement the plan changes and it goes for a full table scan...
Query:
SELECT   ic.companyname,
         ic.companystatustypeid,
         c.companyid,
         c.contactid,
         c.contactlname
    FROM contact c,company ic
   WHERE UPPER((c.contactlname)) LIKE CASE
           WHEN 'test' IS NULL THEN
            UPPER((c.contactlname))
           ELSE DECODE(1,
                   1,
                   '%' || 'TEST' || '%',
                   2,
                   'TEST' || '%',
                   3,
                   '%' || 'TEST',
                   4,
                   'TEST')
         END
     AND c.activeflag = DECODE('Y', 'N', 'Y', c.activeflag)
     AND ic.companyid=c.companyidExplain Plan:
SELECT STATEMENT, GOAL = ALL_ROWS               2126     4121     403858
HASH JOIN               2126     4121     403858
TABLE ACCESS FULL          CONTACT     108     4121     185445
PARTITION LIST ALL               1959     1031340     54661020
   TABLE ACCESS FULL          COMPANY     1959     1031340     54661020     Any ideas why?

dont think so.
i tried removing the filters also:
Query:
SELECT -- ic.companyname,
       -- ic.companystatustypeid,
c.companyid,
         c.contactid,
         c.contactlname,
         c.contactfname,
         c.contactpositionid,
         c.contactroledesc,
         c.updateddate
    FROM contact c,company ic
   WHERE ic.companyid=c.companyidplan:
SELECT STATEMENT, GOAL = ALL_ROWS               109     73346     3520608
NESTED LOOPS               109     73346     3520608
TABLE ACCESS FULL          CONTACT     51     73346     3080532
INDEX UNIQUE SCAN          COMPANY_PK     0     1     6     Query:
SELECT   ic.companyname,
         ic.companystatustypeid,
c.companyid,
         c.contactid,
         c.contactlname,
         c.contactfname,
         c.contactpositionid,
         c.contactroledesc,
         c.updateddate
    FROM contact c,company ic
   WHERE ic.companyid=c.companyid
     Plan:
SELECT STATEMENT, GOAL = ALL_ROWS               2462     73346     6894524
HASH JOIN               2462     73346     6894524
TABLE ACCESS FULL          CONTACT     51     73346     3080532
PARTITION LIST ALL               1348     973674     50631048
   TABLE ACCESS FULL          COMPANY     1348     973674     50631048     Does the columns selected have an impact on the plan?? I thought the plan is derived on basis of the join conditions...

How to find the count of tables going for fts(full table scan in oracle 10g

HI
how to find the count of tables going for fts(full table scan) in oracle 10g
regards

Hi,
Why do you want to 'find' those tables?
Do you want to 'avoid FTS' on those tables?
You provide little information here. (Perhaps you just migrated from 9i and having problems with certain queries now?)
FTS is sometimes the fastest way to retrieve data, and sometimes an index scan is.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9422487749968
There's no 'FTS view' available, if you want to know what happens on your DB you need, like Anand already said, to trace sessions that 'worry you'.

Why does not a query go by index but FULL TABLE SCAN

I have two tables;
table 1 has 1400 rwos and more than 30 columns , one of them is named as 'site_code' , a index was created on this column;
table 2 has more 150 rows than 20 column , this primary key is 'site_code' also.
the two tables were analysed by dbms_stats.gather_table()...
when I run the explain for the 2 sqls below:
select * from table1 where site_code='XXXXXXXXXX';
select * from table1 where site_code='XXXXXXXXXX';
certainly the oracle explain report show that 'Index scan'
but the problem raised that
I try to explain the sql
select *
from table1,table2
where 1.'site_code'=2.'site_code'
the explain report that :
select .....
FULL Table1 Scan
FULL Table2 Scan
why......

Nikolay Ivankin wrote:
BluShadow wrote:
Nikolay Ivankin wrote:
Try to use hint, but I really doubt it will be faster.No, using hints should only be advised when investigating an issue, not recommended for production code, as it assumes that, as a developer, you know better than the Oracle Optimizer how the data is distributed in the data files, and how the data is going to grow and change over time, and how best to access that data for performance etc.Yes, you are absolutly right. But aren't we performing such an investigation, are we? ;-)The way you wrote it, made it sound that a hint would be the solution, not just something for investigation.
select * from .. always performs full scan, so limit your query.No, select * will not always perform a full scan, that's just selecting all the columns.
A select without a where clause or that has a where clause that has low selectivity will result in full table scans.But this is what I have ment.But not what you said.

Function based indexes doing full table scan

Guys,
I am testing function based indexes and whatever I do
it is doing a full table scan.
1)I have set the following init parameters as
QUERY_REWRITE_ENABLED=TRUE
QUERY_REWRITE_INTEGRITY=TRUSTED
2)CREATE INDEX i3 ON emp(UPPER(ename));
3) ANALYZE TABLE emp COMPUTE STATISTICS
ANALYZE INDEX I3 COMPUTE STATISTICS
4) DELETE plan_table;
5) EXPLAIN PLAN SET statement_id='Test1' FOR
SELECT ename FROM emp WHERE UPPER(ename) = 'KING';
6) SELECT LPAD(' ',2*level-2)||operation||' '||options||' '||object_name
query_plan
FROM plan_table
WHERE statement_id='Test1'
CONNECT BY prior id = parent_id
START WITH id = 0 order by id
7) And the query plan shows as
SELECT STATEMENT
TABLE ACCESS FULL EMP
I am using 9.0.1.4 !!!
Any help is appreciated !!!
Regards,
A.Kishore

One of the many new features in Oracle 8i is the Function-Based Index (we will refrain from using FBI, but only just). This allows the DBA to create indexes on functions or expressions; these functions can be user generated pl/sql functions, standard SQL functions (non-aggregate only) or even a C callout.
A classic problem the DBA faces in SQL Tuning is how to tune those queries that use function calls in the where clause, and result in indexes created on these columns not to be used.
Example
Standard B-Tree index on SURNAME with cost based optimizer
create index non_fbi on sale_contacts (surname);
analyze index non_fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'SALES_CONTACTS' (Cost=3 Card=16 Bytes=272)
Now we use a function based index
create index fbi on sale_contacts (UPPER(surname));
analyze index fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'FBI' (NON-UNIQUE) (Cost=2 Card=381 Bytes=6477)
The function-based index has forced the optimizer to use index range scans (retuning zero or more rowids) on the surname column rather than doing a full table scan (non-index lookup). Optimal performance does vary depending on table size, uniqueness and selectivity of columns, use of fast full table scans etc. Therefore try both methods to gain optimal performance in your database.
It is important to remember that the function-based B*Tree index does not store the expression results in the index but uses an "expression tree". The optimizer performs expression matching by parsing the expression used in the SQL statement and comparing the results against the expression-tree values in the function-based index. This comparison IS case sensitive (ignores spaces) and therefore your function-based index expressions should match expressions used in the SQL statement where clauses.
Init.ora Parameters
The following parameter must be set in your parameter file: QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
Grants
Grants To create function-based indexes the user must be granted CREATE INDEX and QUERY REWRITE, or alternatively be granted CREATE ANY INDEX and GLOBAL QUERY REWRITE. The index owner must have EXECUTE access on the function used for the index. If execute access is revoked then the function-based index will be "disabled" (see dba_indexes).
Disabled Indexes
If your function-based index has a status of "disabled" the DBA can do one of the following:
a) drop and create the index (take note of its current settings)
b) alter index enable, function-based indexes only, also use disable keyword as required
c) alter index unusable.
Queries on a DISABLED index fail if the optimizer chooses to use the index.Here is an example ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
All DML operations on a DISABLED index also fail unless the index is also marked UNUSABLE and the initialization parameter SKIP_UNUSABLE_INDEXES is set to true.
Some more Examples
CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
..or a composite index..
CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = 'JONES';
Restriction & Rule Summary
The following restrictions apply to function based indexes. You may not index:
a) LOB columns
b) REF
c) Nested table column
d) Objects types with any of the above data types.
Function-based indexes must always follow these rules:
a) Cost Based optimizer only, must generate statistics after the index is created
b) Can not store NULL values (function can not return NULL under any circumstance)
c) If a user defined pl/sql routine is used for the function-based index, and is invalidated, the index will become "disabled"
d) Functions must be deterministic (always return the same value for a known input)
e) The index owner must have "execute" access on function used in the function-based index. Revocation of the privilege will render the index "disabled"
f) May have a B-Tree and Bitmap index type only
g) Can not use expressions that are based on aggregate functions, ie. SUM, AVG etc.
h) To alter a function-based index as enabled, the function used must be valid, deterministic and the signature of the function matches the signature of the function when it was created.
Joel P�rez

URGENT HELP Required: Solution to avoid Full table scan for a PL/SQL query

Hi Everyone,
When I checked the EXPLAIN PLAN for the below SQL query, I saw that Full table scans is going on both the tables TABLE_A and TABLE_B
UPDATE TABLE_A a
SET a.current_commit_date =
(SELECT MAX (b.loading_date)
FROM TABLE_B b
WHERE a.sales_order_id = b.sales_order_id
AND a.sales_order_line_id = b.sales_order_line_id
AND b.confirmed_qty > 0
AND b.data_flag IS NULL
OR b.schedule_line_delivery_date >= '23 NOV 2008')
Though the TABLE_A is a small table having nearly 1 lakh records, the TABLE_B is a huge table, having nearly 2 and a half crore records.
I created an Index on the TABLE_B having all its fields used in the WHERE clause. But, still the explain plan is showing FULL TABLE SCAN only.
When I run the query, it is taking long long time to execute (more than 1 day) and each time I have to kill the session.
Please please help me in optimizing this.
Thanks,
Sudhindra

Check the instruction again, you're leaving out information we need in order to help you, like optimizer information.
- Post your exact database version, that is: the result of select * from v$version;
- Don't use TOAD's execution plan, but use
SQL> explain plan for <your_query>;
SQL> select * from table(dbms_xplan.display);(You can execute that in TOAD as well).
Don't forget you need to use the {noformat}{noformat} tag in order to post formatted code/output/execution plans etc.
It's also explained in the instruction.
When was the last time statistics were gathered for table_a and table_b?
You can find out by issuing the following query:select table_name
, last_analyzed
, num_rows
from user_tables
where table_name in ('TABLE_A', 'TABLE_B');
Can you also post the results of these counts;select count(*)
from table_b
where confirmed_qty > 0;
select count(*)
from table_b
where data_flag is null;
select count(*)
from table_b
where schedule_line_delivery_date >= /* assuming you're using a date, and not a string*/ to_date('23 NOV 2008', 'dd mon yyyy');

Why it is taking full table scan when index is available

Hi all,
I am facing a strange problem with index.
I created index on a column like
1. CREATE INDEX ASSETS_ARTIST_IDX2 ON ASSETS(artist).
SELECT asset.artist AS NAME FROM ASSETS asset WHERE asset.artist LIKE 'J%'
Explain Plan : INDEX RANGE SCAN
2. CREATE INDEX ASSETS_ARTIST_IDX2 ON ASSETS(UPPER (TRANSLATE (artist, ',;:"', ' ')));
SELECT asset.artist AS NAME FROM ASSETS asset WHERE UPPER (TRANSLATE (artist, ',;:"', ' ')) LIKE 'J%'
          Explain Plan : TABLE ACCESS FULL
first time it is taking index range scan,but in second situation scaning full table.Please let me know how to avoid the full table scan.
Regards,
Rajasekhar

Actually, I misseunderstood damorgan' s statement about NULL and OP did not provide table definition. So based on FTS I would say it is more likely column is NULLable, otherwise I would expect INDEX FAST SCAN:
SQL> create table emp1 as select * from emp
2 /
Table created.
SQL> create index emp1_idx1 on emp1(empno)
2 /
Index created.
SQL> exec dbms_stats.gather_table_stats('SCOTT','EMP1');
PL/SQL procedure successfully completed.
SQL> desc emp1
Name                                                                     Null?    Type
EMPNO                                                                             NUMBER(4)
ENAME                                                                             VARCHAR2(10)
JOB                                                                               VARCHAR2(9)
MGR                                                                               NUMBER(4)
HIREDATE                                                                          DATE
SAL                                                                               NUMBER(7,2)
COMM                                                                              NUMBER(7,2)
DEPTNO                                                                            NUMBER(2)
SQL> explain plan for
2 select empno
3 from emp1 where UPPER(TRANSLATE(empno, ',;:"', ' ')) LIKE '7%'
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2226897347
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     4 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP1 |     1 |     4 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER(TRANSLATE(TO_CHAR("EMPNO"),',;:"',' ')) LIKE '7%')
13 rows selected.
SQL> alter table emp1 modify empno not null
2 /
Table altered.
SQL> explain plan for
2 select empno
3 from emp1 where UPPER(TRANSLATE(empno, ',;:"', ' ')) LIKE '7%'
4 /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 2850860361
| Id | Operation        | Name      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |           |     1 |     4 |     1   (0)| 00:00:01 |
|* 1 | INDEX FULL SCAN | EMP1_IDX1 |     1 |     4 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER(TRANSLATE(TO_CHAR("EMPNO"),',;:"',' ')) LIKE '7%')
13 rows selected.
SQL> SY.

How to check small table scan full table scan if we will use index in where clause.

How to check small table scan full table scan if i will use index column in where clause.
Is there example link there i can test small table scan full table if index is used in where clause.

Use explain plan on your statement or set autotrace traceonly in your SQL*Plus session followed by the SQL you are testing.
For example
SQL> set autotrace traceonly
SQL> select *
2 from XXX
3 where id='fga';
no rows selected
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=13 Card=1 Bytes=16
          5)
   1    0   PARTITION RANGE (ALL) (Cost=13 Card=1 Bytes=165)
   2    1     TABLE ACCESS (FULL) OF 'XXX' (TABLE) (Cost=13 Card
          =1 Bytes=165)
Statistics
          1 recursive calls
          0 db block gets
       1561 consistent gets
        540 physical reads
          0 redo size
       1864 bytes sent via SQL*Net to client
        333 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processed

Bitmap index column goes for full table scan

Similar Messages

Maybe you are looking for