Simple SQL Query is not using Bitmap index

Hello to All,
We are having Oracle9i Database and using it for the datawarehouse purpose.
I have created the bitmap index on calledinfo column and I am running the following simple query which takes serveral hours to complete:
select * from ssp.ssp_2006_q4 where calledinfo='799992515f'
OR
select calledinfo from ssp.ssp_2006_q4 where calledinfo='799992515f'
I don't know why it is not using the bitmap index: Can anybody help me here?
Thanks in Advance
Hashim

I know why and everyone that has read Jonathan Lewis' book on the CBO knows why.
Why? Because the CBO thinks the cost of using your index will be higher than the cost of ignoring it.
To see what Oracle is thinking run an explain plan using DBMS_XPLAN for create the output and then rerun it with a hint forcing index usage.
It is a mistake to believe that an index will always make things better. Issues of cardinality, clustering factor, etc. are very important.
Post the explain plans if you have any questions about what they show:
http://www.psoug.org/reference/explain_plan.html

Similar Messages

Query is not using the INDEX

I have issue with a query as follows. It is not using index when i keep a function on the left hand side of comparison in where condition.
But when I remove the function it is using index.
With BLC AS
Name                                      Null?    Type
ID                                        NOT NULL NUMBER
MASTER_VALUE               NOT NULL NUMBER(8)
DESC_TEXT_ID                                    NUMBER
GVM                                                     VARCHAR2(50)
MASTER_LOOKUP_ID    NOT NULL NUMBER
WORK_SECTION_ID                          NUMBER
AUDIT_TRAIL_NO                              NUMBER
SQL> SELECT COUNT(*) FROM BLC;
COUNT(*)
      7769
SQL> SELECT COUNT(DISTINCT(GVM)) "distinct" FROM BLC;
distinct
      1350
SQL> SELECT COUNT(*) "nulls" FROM BLC WHERE GVM IS NULL;
     nulls
      6419
SQL> SELECT COLUMN_NAME,INDEX_NAME FROM DBA_IND_COLUMNS WHERE TABLE_NAME='BLC';
COLUMN_NAME                              INDEX_NAME
MASTER_LOOKUP_ID      LKPCDE_MSTLKP_FK_I
WORK_SECTION_ID        LKPCDE_WRKSEC_FK_I
GVM                                   LKPCDE_UK
MASTER_VALUE              LKPCDE_MASTERID_VALUE_UK
MASTER_LOOKUP_ID     LKPCDE_MASTERID_VALUE_UK
ID                                       LKPCDE_PK
SQL> EXPLAIN PLAN FOR SELECT ID FROM BLC WHERE UPPER ( GVM) = 'MAIN_ORG';
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3196655606
| Id | Operation         | Name             | Rows | Bytes | Cost (%CPU)| Time|
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT |                  |    78 |   624 |    18   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| BLC |    78 |   624 |    18   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER("GVM")='MAIN_ORG')
13 rows selected.
SQL> EXPLAIN PLAN FOR SELECT ID FROM BLC WHERE GVM
= 'MAIN_ORG';
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 1620245961
| Id | Operation                   | Name             | Rows | Bytes | Cost (%
CPU)| Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT            |                  |     1 |     8 |     2
(0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| BLC |     1 |     8 |     2
(0)| 00:00:01 |
|* 2 |   INDEX UNIQUE SCAN         | LKPCDE_UK        |     1 |       |     1
(0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   2 - access("GVM"='MAIN_ORG')
14 rows selected.
SQL> EXPLAIN PLAN FOR SELECT /* INDEX(LKPCDE_UK) */ ID FROM BLC WHE
RE UPPER ( GVM ) = 'MAIN_ORG';
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3196655606
| Id | Operation         | Name             | Rows | Bytes | Cost (%CPU)| Time
     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT |                  |    78 |   624 |    18   (0)| 00:0
0:01 |
|* 1 | TABLE ACCESS FULL| BLC |    78 |   624 |    18   (0)| 00:0
0:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER("GVM")='MAIN_ORG')
13 rows selected.
Please let me know how i can force to use an index as it is causing CPU usage.
I can not change the query in application as it is used at many places.
Thanks

Hi,
Version is
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for 64-bit Windows: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
Sorry, in my last post i forgot to mention that i already created a function based index but still it is not using because, there is a UNIQUE constraint on that column.
Thanks

Simple query but not using index..please help??

I do have this column indexed. Why my query is not using this index?
Any help .
select count(*) from v_dis_sub_har;
SQL>
COUNT(*)
   4543289
1 row selected.
SQL>
select vzw_vendor_id , count(*)
from v_dis_sub_har
group by vzw_vendor_id
SQL>   2    3    4
VZW_VENDOR_ID   COUNT(*)
       200091     908653
       200013     908659
       200012     908659
       200057     908659
       200031     908659
5 rows selected.
SQL> SQL>
explain plan for
select
event_seq
from v_dis_sub_har b
where b.VZW_VENDOR_ID='200013'
-- and b.status='P' and b.extract_date is null
SQL>   2    3    4    5    6    7
Explained.
SQL> SQL>
select plan_table_output from table(dbms_xplan.display)
SQL> SQL>   2
PLAN_TABLE_OUTPUT
Plan hash value: 2852398983
| Id | Operation         | Name          | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |               |   908K| 7986K| 3132 (16)| 00:00:38 |
|* 1 | TABLE ACCESS FULL| V_DIS_SUB_HAR |   908K| 7986K| 3132 (16)| 00:00:38 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter("B"."VZW_VENDOR_ID"=200013)
13 rows selected.
SQL> SQL>

You are right Justin. Oracle is not stupid as you may want to say some times when things do not happen according to you. I just created a bitmap index on status field and look what appened. Som times it uses bitmap index and some times it does not. And the reason is clear. Row count by status. 'S' status uses bitmap index where 'P' does not.
Thanks for your help.
select   status, count(*)
from v_dis_sub_har
group by status
;SQL>   2    3    4
S   COUNT(*)
A    5844982
P    2312759
S      20178
3 rows selected.
SQL>
explain plan for
select
event_seq
from v_dis_sub_har b
where
--b.VZW_VENDOR_ID=200013
-- and
b.status='S'
--and b.extract_date is null
select plan_table_output from table(dbms_xplan.display)
SQL>   2    3    4    5    6    7    8    9   10
Explained.
SQL> SQL> SQL> SQL>   2
PLAN_TABLE_OUTPUT
Plan hash value: 829738689
| Id | Operation                    | Name                         | Rows | Bytes | Cost (%CPU)| T
ime     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT             |                              | 20290 |   118K| 2772   (1)| 0
0:00:34 |
|   1 | TABLE ACCESS BY INDEX ROWID | V_DIS_SUB_HAR                | 20290 |   118K| 2772   (1)| 0
0:00:34 |
|   2 |   BITMAP CONVERSION TO ROWIDS|                              |       |       |            |
        |
|* 3 |    BITMAP INDEX SINGLE VALUE | V_DISPATCH_SUBSCRIPTION_NDX2 |       |       |            |
        |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   3 - access("B"."STATUS"='S')
15 rows selected.
SQL> SQL> set line 120
SQL> /
PLAN_TABLE_OUTPUT
Plan hash value: 829738689
| Id | Operation                    | Name                         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                              | 20290 |   118K| 2772   (1)| 00:00:34 |
|   1 | TABLE ACCESS BY INDEX ROWID | V_DIS_SUB_HAR                | 20290 |   118K| 2772   (1)| 00:00:34 |
|   2 |   BITMAP CONVERSION TO ROWIDS|                              |       |       |            |          |
|* 3 |    BITMAP INDEX SINGLE VALUE | V_DISPATCH_SUBSCRIPTION_NDX2 |       |       |            |          |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   3 - access("B"."STATUS"='S')
15 rows selected.
SQL>
explain plan for
select
event_seq
from v_dis_sub_har b
where
--b.VZW_VENDOR_ID=200013
-- and
b.status='P'
--and b.extract_date is null
select plan_table_output from table(dbms_xplan.display)
      SQL>   2    3    4    5    6    7    8    9   10
Explained.
SQL> SQL> SQL> SQL>   2
PLAN_TABLE_OUTPUT
Plan hash value: 2852398983
| Id | Operation         | Name          | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |               | 2325K|    13M| 5784 (18)| 00:01:10 |
|* 1 | TABLE ACCESS FULL| V_DIS_SUB_HAR | 2325K|    13M| 5784 (18)| 00:01:10 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter("B"."STATUS"='P')
13 rows selected.
SQL>

SQL Query not using Composite Index

Hi,
Please look at the below query:
SELECT pde.participant_uid
,pde.award_code
,pde.award_type
,SUM(decode(pde.distribution_type
,'FORFEITURE'
,pde.forfeited_quantity *
pde.sold_price * cc.rate
,pde.distributed_quantity *
pde.sold_price * cc.rate)) AS gross_Amt_pref_Curr
FROM part_distribution_exec pde
,currency_conversion cc
,currency off_curr
WHERE pde.participant_uid = 4105
AND off_curr.currency_iso_code =
pde.offering_currency_iso_code
AND cc.from_currency_uid = off_curr.currency_uid
AND cc.to_currency_uid = 1
AND cc.latest_flag = 'Y'
GROUP BY pde.participant_uid
,pde.award_code
,pde.award_type
In oracle 9i, i"ve executed this above query, it takes 6 seconds and the cost is 616, this is due to non usage of the composite index, Currency_conversion_idx(From_currency_uid, To_currency_uid, Latest_flag). I wonder why this index is not used while executing the above query. So, I've dropped the index and recreated it. Now, the query is using this index. After inserting many rows or say in 1 days time, if the same query is executed, again the query is not using the index. So everyday, the index should be dropped and recreated.
I don't want this drop and recreation of index daily, I need a permanent solution for this.
Can anyone tell me, Why this index goes stale after a period of time???? Please take some time and Solve this issue.
-Sankar

Hi David,
This is Sankar here. Thankyou for your reply.
I've got the plan table output for this problematic query, please go thro' it and help me out why the index CURRENCY_CONVERSION_IDX is used now and why it's not using while executing the query after a day or inserting some records...
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 26 | 15678 | 147 |
| 1 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 89 | 2 |
|* 2 | INDEX UNIQUE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 61097 | | 1 |
| 3 | SORT AGGREGATE | | 1 | 67 | |
|* 4 | FILTER | | | | |
|* 5 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | 67 | 2 |
| 6 | SORT AGGREGATE | | 1 | 94 | |
|* 7 | FILTER | | | | |
|* 8 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 94 | 3 |
|* 9 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | | 2 |
|* 10 | FILTER | | | | |
|* 11 | HASH JOIN | | 26 | 15678 | 95 |
|* 12 | HASH JOIN OUTER | | 26 | 11596 | 91 |
|* 13 | HASH JOIN | | 26 | 10218 | 86 |
| 14 | VIEW | | 1 | 82 | 4 |
| 15 | SORT GROUP BY | | 1 | 116 | 4 |
|* 16 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_LEDGER | 1 | 116 | 2 |
|* 17 | INDEX RANGE SCAN | PARTICIPANT_UID_IDX | 1 | | 1 |
|* 18 | HASH JOIN OUTER | | 26 | 8086 | 82 |
|* 19 | HASH JOIN | | 26 | 6006 | 71 |
| 20 | NESTED LOOPS | | 36 | 5904 | 66 |
| 21 | NESTED LOOPS | | 1 | 115 | 65 |
| 22 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 18 | 756 | 2 |
|* 23 | INDEX RANGE SCAN | KLS_IDX_CURRENCY_CONV | 3 | | 1 |
| 24 | VIEW | | 1 | 73 | 4 |
| 25 | SORT GROUP BY | | 1 | 71 | 4 |
| 26 | TABLE ACCESS BY INDEX ROWID| PART_AWARD_VALUE | 1 | 71 | 2 |
|* 27 | INDEX RANGE SCAN | PAV_PARTICIPANT_UID_IDX | 1 | | 1 |
| 28 | TABLE ACCESS BY INDEX ROWID | PARTICIPANT_AWARD | 199 | 9751 | 1 |
|* 29 | INDEX UNIQUE SCAN | PARTICIPANT_AWARD_PK1 | 100 | | |
|* 30 | INDEX FAST FULL SCAN | PARTICIPANT_AWARD_TYPE_PK1 | 147 | 9849 | 4 |
| 31 | VIEW | | 1 | 80 | 10 |
| 32 | SORT GROUP BY | | 1 | 198 | 10 |
|* 33 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 1 | 42 | 2 |
| 34 | NESTED LOOPS | | 1 | 198 | 8 |
| 35 | NESTED LOOPS | | 2 | 312 | 4 |
| 36 | TABLE ACCESS BY INDEX ROWID| PART_DISTRIBUTION_EXEC | 2 | 276 | 2 |
|* 37 | INDEX RANGE SCAN | IND_PARTICIPANT_UID | 1 | | 1 |
| 38 | TABLE ACCESS BY INDEX ROWID| CURRENCY | 1 | 18 | 1 |
|* 39 | INDEX UNIQUE SCAN | CURRENCY_AK | 1 | | |
|* 40 | INDEX RANGE SCAN | CURRENCY_CONVERSION_AK | 2 | | 1 |
| 41 | VIEW | | 1 | 53 | 4 |
| 42 | SORT GROUP BY | | 1 | 62 | 4 |
|* 43 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_VESTING | 1 | 62 | 2 |
|* 44 | INDEX RANGE SCAN | PAVES_PARTICIPANT_UID_IDX | 1 | | 1 |
| 45 | TABLE ACCESS FULL | AWARD | 1062 | 162K| 3 |
| 46 | TABLE ACCESS BY INDEX ROWID | CURRENCY | 1 | 18 | 2 |
|* 47 | INDEX UNIQUE SCAN | CURRENCY_AK | 102 | | 1 |
Predicate Information (identified by operation id):
2 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2
"PAPS"."INSTALLMENT_NUM"=1)
4 - filter(4105=:B1)
5 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
7 - filter(4105=:B1)
8 - filter("PAPS"."STATUS"='OPEN')
9 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
10 - filter("CC_A_P_CURR"."FROM_CURRENCY_UID"= (SELECT /*+ */ "CURRENCY"."CURRENCY_UID" FROM
"EWAPDBO"."CURRENCY" "CURRENCY" WHERE "CURRENCY"."CURRENCY_ISO_CODE"=:B1))
11 - access("SYS_ALIAS_7"."AWARD_CODE"="A"."AWARD_CODE")
12 - access("SYS_ALIAS_7"."AWARD_CODE"="PVS"."AWARD_CODE"(+))
13 - access("SYS_ALIAS_8"."AWARD_CODE"="PALS"."AWARD_CODE" AND
"SYS_ALIAS_8"."AWARD_TYPE"="PALS"."AWARD_TYPE")
16 - filter(TRUNC("PAL1"."LEDGER_ENTRY_DATE")<=TRUNC(SYSDATE@!) AND "PAL1"."ALLOC_TYPE"='IPU')
17 - access("PAL1"."PARTICIPANT_UID"=4105)
filter("PAL1"."PARTICIPANT_UID"=4105)
18 - access("SYS_ALIAS_8"."AWARD_CODE"="PDES"."AWARD_CODE"(+) AND
"SYS_ALIAS_8"."AWARD_TYPE"="PDES"."AWARD_TYPE"(+))
19 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_8"."AWARD_CODE")
23 - access("CC_A_P_CURR"."TO_CURRENCY_UID"=1 AND "CC_A_P_CURR"."LATEST_FLAG"='Y')
27 - access("PAV"."PARTICIPANT_UID"=4105)
filter("PAV"."PARTICIPANT_UID"=4105)
29 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_9"."AWARD_CODE" AND
"SYS_ALIAS_7"."PARTICIPANT_UID"=4105)
30 - filter("SYS_ALIAS_8"."PARTICIPANT_UID"=4105)
33 - filter("CC"."LATEST_FLAG"='Y')
37 - access("PDE"."PARTICIPANT_UID"=4105)
filter("PDE"."PARTICIPANT_UID"=4105)
39 - access("OFF_CURR"."CURRENCY_ISO_CODE"="PDE"."OFFERING_CURRENCY_ISO_CODE")
40 - access("CC"."FROM_CURRENCY_UID"="OFF_CURR"."CURRENCY_UID" AND "CC"."TO_CURRENCY_UID"=1)
43 - filter("PV"."VESTING_DATE"<=SYSDATE@!)
44 - access("PV"."PARTICIPANT_UID"=4105)
filter("PV"."PARTICIPANT_UID"=4105)
47 - access("CURRENCY"."CURRENCY_ISO_CODE"=:B1)
Note: cpu costing is off
93 rows selected.
Please help me out...
-Sankar

Query not using the index

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

Can downloaded oracle9i Enterprise Edition use Bitmap index?

Hello there,
I have a downloaded Oracle9i Enterprise Edition. After I create some bitmap index on a partitioned table, I use the following sql statement to check the bitmap index:
select index_name, index_type, status from user_index;
It tells me that all the statuses of the bitmap indexes are "N/A" (Not availabe). Does that mean I can NOT use bitmap index in this downloaded Enterprise version?
If I must use bitmap indexes, what should I do?
Many thanks in advance!
-wendy

are you creating a local index on the partitioned table?

Why is my SQL not using an index?

I have a small SQL query (10g) where I join to basic table together on a customer_id column.
select *
from customer c
inner join work_item sp1 ON sp1.customer_id = c.customer_id
and I am using TOAD, which tells me (in the Explain Plan area), that I'm doing a "TABLE ACCESS FULL" scan on the customer table.
But when I look at the details of BOTH tables, I can clearly see that they both have an index on the customer field, and they are both the same data types...
The interesting thing, is that if I change the query to only select data from the work_item table,
select sp1.*
from customer c
inner join work_item sp1 ON sp1.customer_id = c.customer_id
I can see that the indexes are being used...
Why is this? I must be able to select certain columns from the customer table, but why would it not use an index when I do?
Thanks!

If I understand correctly, below is a simple test case.
I created a small table and indexed "object_id" column.
When I issue "Select * from t" optimizer goes with FULL TABLE SCAN, whereas wehn "select OBJECT_ID from t" is issued, optimizer chooses to read from the index instead of accessing the table. This is because FAST FULL SCAN is far cheaper than a FTS in this case.
SQL> create table t as select object_id, object_name from all_objects;
Table created.
SQL> exec dbms_stats.gather_table_stats(user, 't');
PL/SQL procedure successfully completed.
SQL> create index t_idx1 on t(object_id);
Index created.
SQL> set autotrace traceonly exp
SQL> select * from t;
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 37932 | 1074K|    55   (2)| 00:00:01 |
| 1 | TABLE ACCESS FULL| T | 37932 | 1074K| 55 (2)| 00:00:01 |
SQL> select object_id from t;
Execution Plan
Plan hash value: 3958994525
| Id | Operation            | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |        | 37932 |   185K|    25   (0)| 00:00:01 |
| 1 | INDEX FAST FULL SCAN| T_IDX1 | 37932 | 185K| 25 (0)| 00:00:01 |
SQL>

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

The 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

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 AM

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

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

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,
Rajesh

Sorry, I just found the solution myself. I need to put an extra pair of braces around the set of conditions seperated by OR.

Class oracle.xml.sql.query.OracleXMLQuery not found in import

I tried to perform load java using a non-sys user :
loadjava -user user1/passwd -v -o -r Archive.java
but encountered the following error:
Errors in Archive:
ORA-29535: source requires recompilation
Archive:11: Class oracle.xml.sql.query.OracleXMLQuery not found in import.
Info: 1 errors
loadjava: 3 errors
But if I use sys user I don't have any error:
loadjava -user sys/manager -v -o -r Arachive.java
initialization complete
loading : Archive
creating : Archive
resolver :
resolving: Archive
Why is this so?
ANy security setup that I missed?
Thanks in advance.
Note:
my Archive.java file contains:
// Core Java Classes
import java.io.*;
import java.sql.*;
// Oracle Java classes
import oracle.jdbc.*;
import oracle.jdbc.driver.*;
import oracle.xml.sql.query.OracleXMLQuery;
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Azman Diron ([email protected]):
I tried to perform load java using a non-sys user :
loadjava -user user1/passwd -v -o -r Archive.java
but encountered the following error:
Errors in Archive:
ORA-29535: source requires recompilation
Archive:11: Class oracle.xml.sql.query.OracleXMLQuery not found in import.
Info: 1 errors
loadjava: 3 errors
But if I use sys user I don't have any error:
loadjava -user sys/manager -v -o -r Arachive.java
initialization complete
loading : Archive
creating : Archive
resolver :
resolving: Archive
Why is this so?
ANy security setup that I missed?
Thanks in advance.
Note:
my Archive.java file contains:
// Core Java Classes
import java.io.*;
import java.sql.*;
// Oracle Java classes
import oracle.jdbc.*;
import oracle.jdbc.driver.*;
import oracle.xml.sql.query.OracleXMLQuery;
<HR></BLOCKQUOTE>
Managed to solve this problem.
Drop all xml objects owned by sys and user1.
Reload xml objcets for user1 with -force option.
null

Not using my index !!!

i have 3 tables:
customer (has over 120,000 rows)
business
workplace
I'm doing a query which is blowing out (time wise) due to the fact that it's not using the index which i have specified on the customer table. The index which is specified on the customer table has 3 columns in it and in my joins i've used two of them and it's doing a full table scan.
However, the other two tables are not as big as customer but not very small either and the joins that i've used on them are using the indexes that i've specified and is behaving.

1.In a query change the order of a table ,keep the tables with less data first
i.e select a.x,b.y,c.z
from custormer a,business b,workplace c
2.As far as u r using 2 columns in the same manner in order which index been created
it doesn't matter
check on explain plan and see which of the table been fully scan.
Jitesh

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

Simple SQL Query and Parameters and LOV

Newbie and trying to work thru building a simple sql query with a single table query and use a parameter and lov.
Can anyone point me to an example.
simple query:
select cust_id, name_desc, name_add1, name_add2, name_city
from customer_table
where cust_id = :cust_parm
This works in straight sql and in the query builder by prompting for the customer ID. When building a parameter using LOV or search, it doesn't seem to detect the variable.
Thanks..
DD

If you are using version 11g, then as soon as you save the query in the data model, it should notice the parameter and ask if you want to add the parameter to the data model. What version of BIP are you using?
What happens if you exclude the parameter from the query and simply hard-code the criteria? Can you generate XML data?
From your wording, it sounds like you're trying to create a parameter from the LOV dialog. LOVs and parameters are totally distinct. After each are created separately, then you configure the parameter to use the LOV.

Simple SQL Query is not using Bitmap index

Similar Messages

Maybe you are looking for