Why don't be used composite index in partition table.

A table has done range list partition.
Then, I create a composite index named INDEX_N2(COLUMN_005, COLUMN_002). --COLUMN_005 AND COLUMN_002 ARE VARCHAR2
When I run the SQL
select 1
from table1 T1
where T1.COLUMN_005 = 'x'
and T1.COLUMN_002 = 'y'
And view the explain plan, INDEX_N2 has been used.
But when I join the COLUMN_005 to other column, the index will not be used.
The SQL is like below.
select 1
from table1 T1, table T2
where T1.COLUMN_005 = T2.COLUMN_002 --T2.COLUMN_002 IS VARCHAR2
and T1.COLUMN_002 = 'y'
The explain plan is like below
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
|* 1 | HASH JOIN | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
| 2 | PARTITION RANGE ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 32 |
| 3 | PARTITION LIST ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 8 |
|* 4 | TABLE ACCESS FULL| TABLE1 | 8 | 792 | 5 (0)| 00:00:01 | 1 | 256 |
| 5 | PARTITION RANGE ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 34 |
| 6 | PARTITION LIST ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | LAST |
| 7 | TABLE ACCESS FULL| TABLE2 | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 442 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
4 - SEL$1 / T1@SEL$1
7 - SEL$1 / T2@SEL$1
Predicate Information (identified by operation id):
1 - access("T1"."COLUMN_005"="T2"."COLUMN_002")
4 - filter("T1"."COLUMN_002"='y')
Column Projection Information (identified by operation id):
1 - (#keys=1)
2 - "T1"."COLUMN_005"[VARCHAR2,150]
3 - "T1"."COLUMN_005"[VARCHAR2,150]
4 - "T1"."COLUMN_005"[VARCHAR2,150]
5 - "T2"."COLUMN_002"[VARCHAR2,20]
6 - "T2"."COLUMN_002"[VARCHAR2,20]
7 - "T2"."COLUMN_002"[VARCHAR2,20]
Note
- dynamic sampling used for this statement
My Questin is:
Two columns are include the columns of index.
Why it can't be used?
Thanks

I create a new index on column2, (INDEX_N3)
and change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
This time INDEX_N3 will be used.
but change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
and T1.COLUMN_004 = '1000'
The explain plan will show full scan.
Why？
Thanks.

Similar Messages

Why don't you use feather touch home button?

why don't you use feather touch home button?

We found out the feathers we were gonna use came from protected birds, so we had to scrap that idea.
Oh, and there are not enough pigeons.

Why don't we use flash player on ipad ? Too much aplication is need flas player.

Why don't we use flash player on ipad ? Too much aplication is need flas player.

rahmioyekcin wrote:
Why don't we use flash player on ipad ? Too much aplication is need flas player.
Because, as has been stated numerous times today, Adobe has been unable to create a version of flash that met Apple's requirements
Stedman

Architecture: Mware View Horizon 5.3 with SVGA K1 GRID, W7 64 bit 4GB RAM and 3 CPU and 512MB VRAM Issue 1: Photoshop setting is gpu[0].MemoryMB=128. Why ? It wolud be 512MB. Issue 2: Sometimes, We get the error not enough Vram. Why don't Photoshop use

Architecture: Mware View Horizon 5.3 with SVGA K1 GRID, W7 64 bit 4GB RAM and 3 CPU and 512MB VRAM
Issue 1: Photoshop setting is gpu[0].MemoryMB=128. Why ? It wolud be 512MB.
Issue 2: Sometimes, We get the error not enough Vram. Why don't Photoshop use all 512MB vRAM?@

Photoshop can only see what your video card driver reports.
You might want to update your video card driver from the GPU maker's website.

How to make use of Index of a table in report to fetch data?

Hi,
I need a sample code for select statement which is making use of INDEX of a table
to fetch data.
Doubt:
Can I fetch all the fields in the table by passing certain key fields of INDEX in where condition?

Hi Raja,
1) Mention the fields that you wish from database table (incase you don't need all the fields from the database table).
2) Don't use the INTO CORRESPONDING FIELDS OF TABLE ztable clause.
3)Instead use INTO TABLE ztable (But take care that during the declaration of the ztable, the fields declared are in order that in database table to fetch the Records in sequence).
Please Find the Syntax and Code Below..
SELECT * FROM <TABLE>
WHERE <WHERE>
%_HINTS ORACLE 'INDEX("<TABLE>~<INDEX ID")'.
SELECT carrid
INTO TABLE t_spfli
FROM spfli
WHERE carrud IN s_carrid AND
connid IN s_connid
%_HINTS ORACLE 'INDEX("&SPFLI&" "SPFLI~XXX")'.
Hope this Is helpFul
Thanks
kalyan

Local index vs global index in partitioned tables

Hi,
I want to know the differences between a global and a local index.
I'm working with partitioned tables about 10 millons rows and 40 partitions.
I know that when your table is partitioned and your index non-partitioned is possible that
some database operations make your index unusable and you have tu rebuid it, for example
when yo truncate a partition your global index results unusable, is there any other operation
that make the global index unusable??
I think that the advantage of a global index is that takes less space than a local and is easier to rebuild,
and the advantage of a local index is that is more effective resolving a query isn't it???
Any advice and help about local vs global index in partitioned tables will be greatly apreciatted.
Thanks in advance

here is the documentation -> http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#sthref2570
In general, you should use global indexes for OLTP applications and local indexes for data warehousing or DSS applications. Also, whenever possible, you should try to use local indexes because they are easier to manage. When deciding what kind of partitioned index to use, you should consider the following guidelines in order:
1. If the table partitioning column is a subset of the index keys, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 2.
2. If the index is unique, use a global index. If this is the case, you are finished. If this is not the case, continue to guideline 3.
3. If your priority is manageability, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 4.
4. If the application is an OLTP one and users need quick response times, use a global index. If the application is a DSS one and users are more interested in throughput, use a local index.
Kind regards,
Tonguç

Can I create unpartitioned index on partitioned table??

Hi,
I am not clear about the concepts of partitioned and non partitioned index.I was under impression that If we create a index on partitioned table it will be automatically becomes a partitioned index.But I cheked in my DB there are many unpartitioned indexes on large partitioned tables.
Which one of these is efficient? wht is the concept of local and global related to these partitioned and unparitioned.I am bit confused.pls help me.
Thanks

There's nothing prevent you from creating a nonpartitioned index on partitioned table. The official name for it is Global Nonpartitioned Indexes
Global Nonpartitioned Indexes
Global nonpartitioned indexes behave just like a nonpartitioned index. They are commonly used in OLTP environments and offer efficient access to any individual record.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#i461446

Indexing on partitioned tables

I was wondering if there are any good standards for indexing very large partitioned tables (i.e. what should I index). Also, if there are any good standards for indexing these partitioned tables when running queries that do not include the partitioned column in the query?

There's no real difference in what you would index, other than maybe a slightly lower requirement for indexing on tha partitioning key column(s).
You ought to be considering whether you need local or global indexes though, and you'll find a lot of information on that over at http://asktom.oracle.com and in the documentation -- to simplify, OLTP usually uses global indexes and DWH usually uses local indexes. You'll want to understand the pro's and con's or each before deciding on your own situation though.

How   to find global index in partition table

Hi guys ,
need one help
How to find global index on partition table
How to find local index on partition table
Need query
Thanks in advance
Edited by: nav on Feb 17, 2012 6:51 AM

nav wrote:
Hi Solomon,
so I have to identify partition & index are created or not,
also I have check the status of index ( both global and local)So what's the problem? Table/index partition is an object, so you can query DBA_OBJECTS:
SELECT SUBOBJECT_NAME,
        CREATED
FROM DBA_OBJECTS
WHERE OWNER = partitioned-table-owner
    AND OBJECT_NAME = partitioned-table-name
    AND CREATED >= TRUNC(SYSDATE)
/This will give you partitions created today. So if you run this right after your job (I hope your job doen't run too close to midnight), you'll get table partition name your job created. Same logic can be applied to indexes.
SY.

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

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.

Using Composite Index Performance Issue

Hi,
Need help:
I have a table 'TABLEA' which has composite index on CODE and DEPT_CODE
While fetching the data from the table 'TABLEA' in the WHERE condition I am using only CODE and not DEPT_CODE.
Is the usage of the WHERE condition by using only the CODE column and not DEPT_CODE column affects the performance?
Any help will be needful for me

See the test case below
SQL> create table test_emp
2 (
3 emp_ssn number,
4 emp_name varchar2(50),
5 emp_state varchar2(15),
6 emp_city varchar2(20)
7 );
Table created
SQL> create index test_emp_idx on test_emp(emp_ssn,emp_name);
Index created
SQL> insert into test_emp values (123456789,'Robben','New York','Buffalo');
1 row inserted
SQL> insert into test_emp values (223456789,'Jack','Florida','Miami');
1 row inserted
SQL> insert into test_emp values (323456789,'Peter','Texas','Dallas');
1 row inserted
SQL> insert into test_emp values (423456789,'Johny','Georgia','Atlanta');
1 row inserted
SQL> insert into test_emp values (523456789,'Carmella','California','San Diego');
1 row inserted
SQL> commit;
Commit complete
SQL> explain plan for select /*+ index(test_emp test_emp_idx) */ * from test_emp where emp_ssn = 323456789;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2345760695
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
|   0 | SELECT STATEMENT            |              |     1 |    61 |   163   (1)
|   1 | TABLE ACCESS BY INDEX ROWID| TEST_EMP     |     1 |    61 |   163   (1)
|* 2 |   INDEX RANGE SCAN          | TEST_EMP_IDX |     1 |       |     2   (0)
Predicate Information (identified by operation id):
   2 - access("EMP_SSN"=323456789)
Note
   - dynamic sampling used for this statement
18 rows selected
SQL> explain plan for select /*+ INDEX_SS(test_emp test_emp_idx) */ * from test_emp where emp_name = 'Robben';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 85087452
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
|   0 | SELECT STATEMENT            |              |     1 |    61 |    15   (0)
|   1 | TABLE ACCESS BY INDEX ROWID| TEST_EMP     |     1 |    61 |    15   (0)
|* 2 |   INDEX SKIP SCAN           | TEST_EMP_IDX |     1 |       |    11   (0)
Predicate Information (identified by operation id):
   2 - access("EMP_NAME"='Robben')
       filter("EMP_NAME"='Robben')
Note
   - dynamic sampling used for this statement
19 rows selectedThanks,
Andy

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

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

Use of substr function will avoid the use of indexes in a table

i have one table which will contain some 3,00,000 records, it contains some 11 primary keys i am using some update statements to update some fields in the records (of 3,00,000 i will compare some 1,50,000 records with 1,50,000 another records) i am using substr function in all the select statements. whether usage of substr function will avoid the use of index
can any one clarify?

contains some 11 primary keys by this I suppose you mean to say the table has a composite PK on 11 columns.
i am using substr function in all the select statementsCould you please post your SQL statement?

Why don't be used composite index in partition table.

Similar Messages

Maybe you are looking for