How to make optimizer fetch and join values from Indexes, no table access.

Question

Hi All,
i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
Execution Plan
Plan hash value: 1209914516
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | | 6 (17)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | | | | | |
|* 2 | FILTER | | | | | | | |
| 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |
| 4 | NESTED LOOPS | | 1 | 24 | 4 (25)| 00:00:01 | | |
| 5 | SORT UNIQUE | | 1 | 10 | 2 (0)| 00:00:01 | | |
| 6 | TABLE ACCESS BY INDEX ROWID | INVOICELINEDISB | 1 | 10 | 2 (0)| 00:00:01 | | |
|* 7 | INDEX RANGE SCAN | IDX_INVLINEDISB_UOMCD | 1 | | 1 (0)| 00:00:01 | | |
| 8 | PARTITION HASH ITERATOR | | 1 | 14 | 1 (0)| 00:00:01 | KEY | KEY |
|* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB | 1 | 14 | 1 (0)| 00:00:01 | ROWID | ROWID |
|* 10 | INDEX UNIQUE SCAN | P_INVOICEHEADERDISB_PART | 1 | | 0 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
"INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
"INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
Statistics
0 recursive calls
0 db block gets
14 consistent gets
0 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client

Answer 1

Jonathan Lewis wrote:
930254 wrote:
Hi All,
i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
Execution Plan
Plan hash value: 1209914516
| Id  | Operation                              | Name                     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT                       |                          |     1 |       |     6  (17)| 00:00:01 |       |       |
|   1 |  SORT AGGREGATE                        |                          |     1 |       |            |          |       |       |
|*  2 |   FILTER                               |                          |       |       |            |          |       |       |
|   3 |    FAST DUAL                           |                          |     1 |       |     2   (0)| 00:00:01 |       |       |
|   4 |    NESTED LOOPS                        |                          |     1 |    24 |     4  (25)| 00:00:01 |       |       |
|   5 |     SORT UNIQUE                        |                          |     1 |    10 |     2   (0)| 00:00:01 |       |       |
|   6 |      TABLE ACCESS BY INDEX ROWID       | INVOICELINEDISB          |     1 |    10 |     2   (0)| 00:00:01 |       |       |
|*  7 |       INDEX RANGE SCAN                 | IDX_INVLINEDISB_UOMCD    |     1 |       |     1   (0)| 00:00:01 |       |       |
|   8 |     PARTITION HASH ITERATOR            |                          |     1 |    14 |     1   (0)| 00:00:01 |   KEY |   KEY |
|*  9 |      TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB        |     1 |    14 |     1   (0)| 00:00:01 | ROWID | ROWID |
|* 10 |       INDEX UNIQUE SCAN                | P_INVOICEHEADERDISB_PART |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
"INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
"INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
The sort unique at line 5 is surprising, I can't think of an obvious reason why it should appear unless the optimizer is trying to do something very clever to work around a problem we can't see (such as a statistics error with the hash partitioned indexe).
Assuming that the test would do better starting with invoiceheaderdisn.paypkl I have to ask if you have an index on INVOICELINEDISB(INVOICEPK).The optimizer's choice of driving table indeed looks odd. Could it be due to misleading statistics or plain bug or just a case of CBO preferring a non-partitioned table over partitioned table when deciding the driving table? I must admit this design does look odd as it appears INVOICEHEADERDISB is a parent table and INVOICELINEDISB is a child table but somehow the parent table has been partitioned (using hash partitioning, I assume) but the child table is not.
However, once CBO has decided the driving table, the SORT UNIQUE is not quite surprising. Assuming optimizer knows that there is a parent-child relationship between INVOICEHEADERDISB and INVOICELINEDISB table (based on INVOICEPK column), CBO needs to access only INVOICEPK and UNITOFMEASURECD columns fron the INVOICELINEDISB table in order to process the join. It uses index range scan on UNITOFMEASURECD table in order to get (part of) the necessary data and then accesses INVOICELINEDISB table to get the values of INVOICEPK column. Being a child table, it is possible that the driving row source will contain duplicate values for INVOICEPK column but not necessarily sorted. As CBO knows that outer table (i.e. INVOICEHEADERDISB) has a PK on INVOICEPK column, each row in driving row source will have either 1 or 0 rows matching from outer table. It appears that CBO "decides" that by eliminating the duplicate values of the INVOICEPK from driving row source, it can reduce the number of times the INVOICEHEADERDISB table is accessed.
Now I am not sure if CBO does all this (eliminating duplicates from driving row source) only because the outer table is partitioned.
Coming back to OP's original question, I believe OP will have to change the index definitions in order to avoid table access for this query. But there has to be a strong and logical argument to make this kind of change for just one query.
Hope this helps.