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

Similar Messages

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 is this query not using my index ?

hey
i have the following situation
(i'm sorry but i can't add the acctual script or output)
create table x as
select      level high_card ,
     mod(level,1000) medium_card ,
     mod(level,10) low_card ,
     '***' padding
from     dual
connect by level < 100001;
create index x_med_low_ix on x(low_card,medium_card);
create index x_high_ix on x(high_card);
exec dbms_stats.gather_table_stats(user,'x',cascade=>true,method_opt=>'for all indexed columns size auto');
i'm running the following query
select      *
from      x
where      low_card = 70
and     medium_card = 70
and     high_card = 70;
i'm expecting a range scan on the x_high_ix index. the optimizer expects only one row. the stats on the high_card columns shows that (num_rows * density = 1).
when i run the query the optimizer uses the x_med_low_ix and does 14 cr.
when i force the use of x_high_ix the cr goes down to 4.
i don't want to declare x_high_ix as unique.
so, why isn't he using my index ?

It's using that index for me:
SQL> create table x as
2 select level high_card ,
3 mod(level,1000) medium_card ,
4 mod(level,10) low_card ,
5 '***' padding
6 from dual
7 connect by level < 100001;
Table created.
SQL>
SQL> create index x_med_low_ix on x(low_card,medium_card);
Index created.
SQL>
SQL> create index x_high_ix on x(high_card);
Index created.
SQL>
SQL> exec dbms_stats.gather_table_stats(user,'x',cascade=>true,method_opt=>'for all indexed columns
size auto');
PL/SQL procedure successfully completed.
SQL> ed
Wrote file afiedt.buf
1   select *
2   from x
3   where low_card = 70
4   and medium_card = 70
5* and high_card = 70
SQL>
SQL> /
no rows selected
Execution Plan
Plan hash value: 775193209
| Id | Operation                   | Name      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |           |     1 |    15 |     2   (0)| 00:00:01 |
|* 1 | TABLE ACCESS BY INDEX ROWID| X         |     1 |    15 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | X_HIGH_IX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("LOW_CARD"=70 AND "MEDIUM_CARD"=70)
   2 - access("HIGH_CARD"=70)
Statistics
          0 recursive calls
          0 db block gets
          3 consistent gets
          0 physical reads
          0 redo size
        454 bytes sent via SQL*Net to client
        370 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processed
SQL> set autot off
SQL> select * from v$version;
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Productionwhat is your version?
By the way, when i force optimizer to use index X_MED_LOW_IX, it does 2 CR for me.

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.

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

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.

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]

Spatial Query not using Spatial Index

Hi All,
I have a query which uses the SDO_WITHIN_DISTANCE operator, but is taking far too long to complete.
SELECT
               RT.*,RD.RPD_NODE_ID, RD.RPD_XCOORD,RD.RPD_YCOORD
          FROM
               railplan_data RD
               LEFT JOIN Walk_data_sets WDS ON RD.RPD_RPS_ID = WDS.WDS_RPS_ID
               LEFT JOIN RWNet_Temp RT ON WDS.WDS_ID = RT.RW_WDS_ID
          WHERE
               WDS.wds_id = 441
          AND
               MDSYS.SDO_WITHIN_DISTANCE(RT.RW_GEOM,RD.RPD_GEOLOC,'DISTANCE=' || TO_CHAR(RT.RW_BUFFER) || ' UNIT=METER') = 'TRUE';
Upon generation of the explain plan I have realised that the spatial index is not being used in the query, but I can't for the life of me get the thing working
3     | Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
4     ------------------------------------------------------------------------------------------
5     | 0 | SELECT STATEMENT | | 25841 | 99M| | 201 |
6     |* 1 | FILTER | | | | | |
7     | 2 | MERGE JOIN OUTER | | | | | |
8     |* 3 | HASH JOIN | | 12652 | 420K| 2968K| 185 |
9     | 4 | TABLE ACCESS FULL | RAILPLAN_DATA | 75910 | 2075K| | 60 |
10     | 5 | TABLE ACCESS BY INDEX ROWID| WALK_DATA_SETS | 1 | 6 | | 1 |
11     |* 6 | INDEX UNIQUE SCAN | WDS_PK | 1 | | | |
12     |* 7 | SORT JOIN | | 16 | 63760 | | 16 |
13     |* 8 | TABLE ACCESS FULL | RWNET_TEMP | 16 | 63760 | | 4 |
If anyone could help me out in figuring out why the spatial index is not being used, I would be most appreciative.
TIA
Dan

Hi all again,
Well I finally got an upgrade to Oracle 10 (yay!), so I am now trying to implement the SDO_JOIN method as per my earlier posts. In fact it is actually working, but I have a question. When I run an explain plan it does not show the use of any domain indexes which I would expect to see, but performs fine (1.07s) with just a few records (10 in 1 table, 15000 in the other), please see code and explain plan below:
SELECT
Distinct
    RT.RW_ID, RD.RPD_NODE_ID,
    RD.RPD_XCOORD,RD.RPD_YCOORD
FROM
    RPD_TEMP_762 RD,
    WALK_DATA_SETS WDS,
    RWNET_TEMP RT,
    TABLE
    (SDO_JOIN
        ( 'RWNET_TEMP',
            'RW_GEOM',
            'RPD_TEMP_762',
            'RPD_GEOLOC',
            'distance= ' || TO_CHAR(RT.RW_BUFFER) || ' unit=meter')) SPATIAL_JOIN_RESULT
WHERE WDS.WDS_ID = RT.RW_WDS_ID
AND WDS.WDS_ID = 762
AND SPATIAL_JOIN_RESULT.ROWID1 = RT.ROWID
AND SPATIAL_JOIN_RESULT.ROWID2 = RD.ROWID
PLAN_TABLE_OUTPUT
| Id | Operation                            | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT                     |              |    74 | 5994 | 21753   (1)|
|   1 | SORT UNIQUE                         |              |    74 | 5994 | 21691   (1)|
|* 2 |   HASH JOIN                          |              | 1046K|    80M| 1859   (1)|
|   3 |    NESTED LOOPS                      |              | 6076 |   213K| 1824   (1)|
|   4 |     NESTED LOOPS                     |              |    74 | 2516 |   194   (1)|
|* 5 |      INDEX UNIQUE SCAN               | WDS_PK       |     1 |     4 |     0   (0)|
|* 6 |      TABLE ACCESS FULL               | RWNET_TEMP   |    74 | 2220 |   194   (1)|
|* 7 |     COLLECTION ITERATOR PICKLER FETCH| SDO_JOIN     |       |       |            |
|   8 |    TABLE ACCESS FULL                 | RPD_TEMP_762 | 17221 |   756K|    28   (0)|
------------------------------------------------------------------------------------------ When i try to add hints to force the use of spatial indexes the performance of this query drops through the floor (it takes minutes / hours), index hint shown below:
/*+ ORDERED INDEX(RW rw_geom) INDEX(RD rpd_geoloc) */My question is is the first query using domain indexes, and if not, how do I get it to?
TIA
Dan

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 is captcha not reloading in firefox but does in chrome, safari and opera?

Captcha reload/refresh is not working in firefox but it does in chrome, opera and safari.
I have already tried adding a query string in the url so that firefox will be forced to reload the page i am calling but still, the image is still the same.
I have also tried testing my page in firefox on a safe mode. But it still producing the same image.
Please help...

Hello,
Many site issues can be caused by corrupt cookies or cache. In order to try to fix these problems, the first step is to clear both cookies and the cache.
Note: ''This will temporarily log you out of all sites you're logged in to.''
To clear cache and cookies do the following:
#Go to Firefox > History > Clear recent history or (if no Firefox button is shown) go to Tools > Clear recent history.
#Under "Time range to clear", select "Everything".
#Now, click the arrow next to Details to toggle the Details list active.
#From the details list, check ''Cache'' and ''Cookies'' and uncheck everything else.
#Now click the ''Clear now'' button.
Further information can be found in the [[Clear your cache, history and other personal information in Firefox]] article.
Did this fix your problems? Please report back to us!
Thank you.

Why Is Query Against XMLTYPE Table ACME_CUST Doing A Full Table Scan?

On our Oracle Database 11g Enterprise Edition Release 11.2.0.1.0, we have a query against against a 25,214 record XMLTYPE ACME_CUST table.
SELECT rownum   AS seq,
      EID AS eid,
      SUBSTR(CUST_ID, 1, INSTR(CUST_ID, '|')-1) AS tgt_acme_customer_id,
      SUBSTR(CUST_ID, INSTR(CUST_ID, '|')   +1) AS src_acme_customer_id_list
    FROM
      (SELECT ac.eid EID,
        listagg(ac.acme_cust_id, '|') WITHIN GROUP (
      ORDER BY ac.acme_cust_id, ac.acme_cust_id) CUST_ID
      FROM ACME_CUST ac
      GROUP BY ac.eid
      HAVING COUNT(ac.acme_cust_id)>1)Explain plan shows:
Select Statement
Count
VIEW
FILTER
Filter Predicates
COUNT(*) > 1
SORT GROUP BY
TABLE ACCESS ACME_CUST FULL
The ACME_CUST Table has a virtual column defined on acme_cust_id along with a corresponding index. This filed is also defined as a primary key.
Here is the table definitiion and associated statements:
CREATE
TABLE "N98991"."ACME_CUST" OF XMLTYPE
    CONSTRAINT "ACME_CUST_ID_PK" PRIMARY KEY ("ACME_CUST_ID") USING INDEX
    PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536
    NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1
    FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE
    DEFAULT) TABLESPACE "ACME_DEV" ENABLE
XMLTYPE STORE AS SECUREFILE BINARY XML
    TABLESPACE "ACME_DEV" ENABLE STORAGE IN ROW CHUNK 8192 CACHE READS LOGGING
    NOCOMPRESS KEEP_DUPLICATES STORAGE(INITIAL 106496 NEXT 1048576 MINEXTENTS 1
    MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
    CELL_FLASH_CACHE DEFAULT)
ALLOW NONSCHEMA ALLOW ANYSCHEMA VIRTUAL COLUMNS
    "EID" AS (CAST(SYS_XQ_UPKXML2SQL(SYS_XQEXVAL(XMLQUERY(
    'declare default element namespace "http://www.cigna.com/acme/domains/customer/customerprofile/2011/11"; (::)
/customerProfile/@eid'
    PASSING BY VALUE SYS_MAKEXML(128,"XMLDATA") RETURNING CONTENT ),0,0,
    16777216,0),50,1,2) AS VARCHAR2(15))),
*bold* "ACME_CUST_ID" AS (CAST(SYS_XQ_UPKXML2SQL(SYS_XQEXVAL(XMLQUERY(
    'declare default element namespace "http://www.cigna.com/acme/domains/customer/customerprofile/2011/11"; (::)
/customerProfile/@id' *bold*
    PASSING BY VALUE SYS_MAKEXML(128,"XMLDATA") RETURNING CONTENT ),0,0,
    16777216,0),50,1,2) AS VARCHAR2(50))),
    "CRET_DT" AS (SYS_EXTRACT_UTC(CAST(TO_TIMESTAMP_TZ(SYS_XQ_UPKXML2SQL(
    SYS_XQEXVAL(XMLQUERY(
    'declare default element namespace "http://www.cigna.com/acme/domains/customer/customerprofile/2011/11"; (::)
/customerProfile/@create_dt'
    PASSING BY VALUE SYS_MAKEXML(128,"XMLDATA") RETURNING CONTENT ),0,0,
    16777216,0),50,1,2),'SYYYY-MM-DD"T"HH24:MI:SS.FFTZH:TZM') AS TIMESTAMP
WITH
TIME ZONE)))
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0
    FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
    CELL_FLASH_CACHE DEFAULT
TABLESPACE "ACME_DEV" ;
CREATE
INDEX "N98991"."ACME_CST_CRET_DT_IDX" ON "N98991"."ACME_CUST"
    "CRET_DT"
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0
    FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
    CELL_FLASH_CACHE DEFAULT
TABLESPACE "ACME_DEV" ;
CREATE
INDEX "N98991"."ACME_CST_EID_IDX" ON "N98991"."ACME_CUST"
    "EID"
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0
    FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
    CELL_FLASH_CACHE DEFAULT
TABLESPACE "ACME_DEV" ;
*bold*CREATE UNIQUE INDEX "N98991"."ACME_CUST_ID_PK" ON "N98991"."ACME_CUST"
    "ACME_CUST_ID"
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE *bold*
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0
    FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
    CELL_FLASH_CACHE DEFAULT
TABLESPACE "ACME_DEV" ;
CREATE
    INDEX "N98991"."ACME_CUST_XMLINDEX_IX" ON "N98991"."ACME_CUST"
      OBJECT_VALUE
    INDEXTYPE IS "XDB"."XMLINDEX" PARAMETERS
      'XMLTABLE ACME_CUST_IDX_TAB XMLNamespaces (''http://www.cigna.com/acme/domains/commoncontact/2011/11'' as "cm", default ''http://www.cigna.com/acme/domains/customer/customerprofile/2011/11''),
''/customerProfile''
columns
DOB date PATH ''personInformation/cm:birthDate'',
FIRSTNAME varchar2(40)    PATH ''name/cm:givenName'',
LASTNAME varchar2(40)    PATH ''name/cm:surName'',
SSN varchar2(30)    PATH ''identifiers/ssn'',
MEMBERINFOS XMLType path ''memberInfos/memberInfo'' VIRTUAL
XMLTable acme_cust_lev2_idx_tab XMLNAMESPACES(default ''http://www.cigna.com/acme/domains/customer/customerprofile/2011/11''),
''/memberInfo'' passing MEMBERINFOS
columns
ami varchar2(40) PATH ''ami'',
subscId varchar2(50) PATH ''clientRelationship/subscriberInformation/subscriberId'',
employeeId varchar2(50) PATH ''systemKeys/employeeId'',
clientId varchar2(50) PATH ''clientRelationship/clientId''
CREATE UNIQUE INDEX "N98991"."SYS_C00384339" ON "N98991"."ACME_CUST"
    "SYS_NC_OID$"
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE
    INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0
    FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
    CELL_FLASH_CACHE DEFAULT
TABLESPACE "ACME_DEV" ;
CREATE UNIQUE INDEX "N98991"."SYS_IL0000649948C00003$$" ON "N98991"."ACME_CUST"
    PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 65536 NEXT 1048576
    MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST
    GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "ACME_DEV" PARALLEL (DEGREE 0 INSTANCES 0) ;Why isn't the unique index ACME_CUST_ID_PK on the virtual column ACME_CUST_ID being used in the explain plan?
Any input would be much appreciated, as really stumped here.
Regards,
Rick

Hi Richard,
The 10053 event appears overkill for this situation. What's the big deal?
Set the event, run the query, unset the event, check the trace file, that's all.
It's not overkill if it helps you understanding what happens and why an index is of no use in this situation.
Tried the /*+ INDEX_FFS(ACME_CUST_ID_PK) */ hint in the 'nested' query.Not sure what nested query you're referring to, so if I misunderstood what you mean, just ignore the following comment.
From what you posted earlier, it looks like you're talking about this part :
listagg(ac.acme_cust_id,'|') WITHIN GROUP (
ORDER BY ac.acme_cust_id,ac.acme_cust_id) CUST_IDThat's not a nested query, it's a projection. All the main work (retrieving rows) has already been done when it comes to this part.
May just have to accept the query performance as it is...Maybe you can try something else.
See the document : Oracle XML DB : Best Practices, page 15 ex. 8 :
When there are multiple scalar values that need to be grouped or ordered, it is better to write it
with XMLTable construct that projects out all columns to be ordered or grouped as shown
below.Here's an example close to your actual requirement :
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
SQL> create table xtab_cols of xmltype
2 xmltype store as securefile binary xml;
Table created.
SQL> insert /*+ append */ into xtab_cols
2 select xmlelement("ROW",
3           xmlforest(
4            TABLE_NAME, COLUMN_NAME, DATA_TYPE, DATA_TYPE_MOD, DATA_TYPE_OWNER,
5            DATA_LENGTH, DATA_PRECISION, DATA_SCALE, NULLABLE, COLUMN_ID,
6            DEFAULT_LENGTH, NUM_DISTINCT, LOW_VALUE, HIGH_VALUE,
7            DENSITY, NUM_NULLS, NUM_BUCKETS, LAST_ANALYZED, SAMPLE_SIZE,
8            CHARACTER_SET_NAME, CHAR_COL_DECL_LENGTH,
9            GLOBAL_STATS, USER_STATS, AVG_COL_LEN, CHAR_LENGTH, CHAR_USED,
10            V80_FMT_IMAGE, DATA_UPGRADED, HISTOGRAM
11           )
12         )
13 from dba_tab_cols
14 where owner = 'SYS'
15 ;
57079 rows created.
SQL> commit;
Commit complete.
SQL> set long 1000
SQL> set pages 100
SQL> select xmlserialize(document object_value) from xtab_cols where rownum = 1;
XMLSERIALIZE(DOCUMENTOBJECT_VALUE)
<ROW>
<TABLE_NAME>ACCESS$</TABLE_NAME>
<COLUMN_NAME>D_OBJ#</COLUMN_NAME>
<DATA_TYPE>NUMBER</DATA_TYPE>
<DATA_LENGTH>22</DATA_LENGTH>
<NULLABLE>N</NULLABLE>
<COLUMN_ID>1</COLUMN_ID>
<NUM_DISTINCT>7454</NUM_DISTINCT>
<LOW_VALUE>C2083A</LOW_VALUE>
<HIGH_VALUE>C3031D18</HIGH_VALUE>
<DENSITY>,000134156157767642</DENSITY>
<NUM_NULLS>0</NUM_NULLS>
<NUM_BUCKETS>1</NUM_BUCKETS>
<LAST_ANALYZED>2012-01-28</LAST_ANALYZED>
<SAMPLE_SIZE>34794</SAMPLE_SIZE>
<GLOBAL_STATS>YES</GLOBAL_STATS>
<USER_STATS>NO</USER_STATS>
<AVG_COL_LEN>5</AVG_COL_LEN>
<CHAR_LENGTH>0</CHAR_LENGTH>
<V80_FMT_IMAGE>NO</V80_FMT_IMAGE>
<DATA_UPGRADED>YES</DATA_UPGRADED>
<HISTOGRAM>NONE</HISTOGRAM>
</ROW>
SQL> exec dbms_stats.gather_table_stats(user, 'XTAB_COLS');
PL/SQL procedure successfully completed.
SQL> set autotrace traceonly
SQL> set timing on
SQL> set lines 120
SQL> select x.table_name
2       , listagg(x.column_name, ',') within group (order by column_id)
3 from xtab_cols t
4     , xmltable('/ROW' passing t.object_value
5        columns table_name varchar2(30) path 'TABLE_NAME'
6              , column_name varchar2(30) path 'COLUMN_NAME'
7              , column_id   number       path 'COLUMN_ID'
8       ) x
9 group by x.table_name
10 ;
4714 rows selected.
Elapsed: 00:00:08.25
Execution Plan
Plan hash value: 602782846
| Id | Operation           | Name      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |           |   466M|   101G| 1580K (3)| 05:16:04 |
|   1 | SORT GROUP BY      |           |   466M|   101G| 1580K (3)| 05:16:04 |
|   2 |   NESTED LOOPS      |           |   466M|   101G| 1552K (1)| 05:10:32 |
|   3 |    TABLE ACCESS FULL| XTAB_COLS | 57079 |    12M|   408   (1)| 00:00:05 |
|   4 |    XPATH EVALUATION |           |       |       |            |          |
Statistics
          9 recursive calls
          1 db block gets
       1713 consistent gets
          0 physical reads
         96 redo size
     773516 bytes sent via SQL*Net to client
       3873 bytes received via SQL*Net from client
        316 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
       4714 rows processedAnd of course, even better after adding a structured XML index (4714 rows fetched in 1s) :
SQL> CREATE INDEX xtab_cols_sxi ON xtab_cols (OBJECT_VALUE) INDEXTYPE IS XDB.XMLIndex
2 PARAMETERS (
3 q'#XMLTable my_xtab
4 '/ROW'
5 columns table_name varchar2(30) path 'TABLE_NAME'
6        , column_name varchar2(30) path 'COLUMN_NAME'
7        , column_id number path 'COLUMN_ID' #');
Index created.
Elapsed: 00:00:13.42
SQL> select x.table_name
2       , listagg(x.column_name, ',') within group (order by column_id)
3 from xtab_cols t
4     , xmltable('/ROW' passing t.object_value
5        columns table_name varchar2(30) path 'TABLE_NAME'
6              , column_name varchar2(30) path 'COLUMN_NAME'
7              , column_id   number       path 'COLUMN_ID'
8       ) x
9 group by x.table_name
10 ;
4714 rows selected.
Elapsed: 00:00:01.00
Execution Plan
Plan hash value: 3303494605
| Id | Operation          | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |         | 57520 | 3201K|   174   (3)| 00:00:03 |
|   1 | SORT GROUP BY     |         | 57520 | 3201K|   174   (3)| 00:00:03 |
|   2 |   TABLE ACCESS FULL| MY_XTAB | 57520 | 3201K|   171   (1)| 00:00:03 |
Note
   - dynamic sampling used for this statement (level=2)
Statistics
        297 recursive calls
          1 db block gets
        989 consistent gets
          0 physical reads
        176 redo size
     773516 bytes sent via SQL*Net to client
       3873 bytes received via SQL*Net from client
        316 SQL*Net roundtrips to/from client
         21 sorts (memory)
          0 sorts (disk)
       4714 rows processed

Why can I not use any map website because I am prompted to download Maps Galaxy for Firefox which I do not want & am provided no opt out option?

I have attempted to use Google , MapQuest and Yahoo map and directions and cannot view the resulting directions because a message appears on the screen requiring me to download MapsGalaxy for Firefox toolbar. I am happy with what I can do currently with the map and direction web sites and do not care to download this toolbar but I am not even offered to opportunity to opt out. There is not even a description of the benefits offered if I would download the toolbar. I'm not one who enjoys being force fed things I did not request. What goes on and why am I being forced to download this toolbar in order to continue to use the map web sites? Thanks for your assistance.
I have a screenshot of the message but am unable to figure out how to include it with this detailed description.

Hi,
Firstly I'd like to clarify myself: I'm not working for any hardware and software vendor. I've posted few times: they (all of them) don't sell printers, they sell inks because in many cases total cost of a new set of inks is more expensive than a new printer with inks (I know cartridges are not full). Since inks are very expensive, many people use chip resetters, continuous inks systems .... to reduce printing cost such as some thing like one of this.
Regards.
BH
**Click the KUDOS thumb up on the left to say 'Thanks'**
Make it easier for other people to find solutions by marking a Reply 'Accept as Solution' if it solves your problem.

Can I hide/move a form that I am not using any longer but want to keep the template for the future?

I would like to hide or move old forms to get the list of "My Forms" shorter and easier to manage, but don't wish to delete them. Thanks for your help!

We also have an "Ideas" page we use to help prioritize new features, it shoulds like you would like some way to organize your forms, you might want to vote on this idea for Folders in the My Forms tab:
http://forums.adobe.com/ideas/1587
Thanks,
Josh

Why cant i not use any thing involving my apple ID

Im not able to use anything even remotely involving my apple ID , I cant update or download apps and cant sing into facetime

Me too. If you are signed in, do not sign out. You can still do some things. If you sign out, you will be unable to sign back in until Apple fixes this.

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

Similar Messages

Maybe you are looking for