Why isn't the CBO using my indexes?

Question

Why isn't Oracle using my indexes to join 2 big tables? I ran statistics last night before kicking off this job. I don't want to have to use hints.
STAGING_TXN_081 has Primary Key on VSYS_STAGE_ROW_ID
TRANSACTION has an index on STAGING_RECORD_ID
Record counts are as follows:
SQL> select count(*) from STAGING_TXN_081;
COUNT(*)
613071
1* select distinct count(staging_record_id) from transaction
SQL> /
COUNT(STAGING_RECORD_ID)
10,662,828
1* select distinct count(*) from transaction where staging_record_id is null
SQL> /
COUNT(*)
1,150,819
So 1,150,819 / 10,662,828 = approximately 10.8% of the rows are null.
This is the Query
select
    st.*,
    rlog.reject_code as rlogRejectCode
from       
    STAGING_TXN_081 st
    join transaction t
        on st.VSYS_STAGE_ROW_ID = t.STAGING_RECORD_ID
    left outer join txn_reject_log rlog
        on t.transaction_id = rlog.transaction_id
where
    not exists
    (select 1
    from
        rl_loyalty_txn_trans rl
        join loyalty_txn lt
            on lt.loyalty_txn_id=rl.loyalty_txn_id
    where
        rl.transaction_id=t.transaction_id)
order by st.VSYS_STAGE_ROW_ID, rlog.reject_code Here is the execution plan.
Execution Plan
Plan hash value: 447420266
| Id  | Operation                     | Name                    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                         |     1 |   223 |       |   144K  (6)| 00:29:00 |
|   1 |  SORT ORDER BY                |                         |     1 |   223 |       |   144K  (6)| 00:29:00 |
|   2 |   NESTED LOOPS OUTER          |                         |     1 |   223 |       |   144K  (6)| 00:29:00 |
|*  3 |    HASH JOIN ANTI             |                         |     1 |   203 |   121M|   144K  (6)| 00:29:00 |
|   4 |     VIEW                      |                         |   613K|   114M|       | 84466   (7)| 00:16:54 |
|*  5 |      HASH JOIN                |                         |   613K|    71M|    72M| 84466   (7)| 00:16:54 |
|   6 |       TABLE ACCESS FULL | STAGING_TXN_081         |   613K|    65M|       |  3237   (5)| 00:00:39 |
|*  7 |       TABLE ACCESS FULL | TRANSACTION             |    10M|   111M|       | 65229   (7)| 00:13:03 |
|   8 |     VIEW                      | VW_SQ_1                 |    10M|    69M|       | 44389   (6)| 00:08:53 |
|*  9 |      HASH JOIN                |                         |    10M|   197M|   192M| 44389   (6)| 00:08:53 |
|  10 |       INDEX FAST FULL SCAN    | PK_LOYALTY_TXN          |    10M|    71M|       |  7314   (7)| 00:01:28 |
|  11 |       INDEX FAST FULL SCAN    | PK_RL_LOYALTY_TXN_TRANS |    10M|   128M|       | 13947   (4)| 00:
|  12 |    TABLE ACCESS BY INDEX ROWID| TXN_REJECT_LOG          |     1 |    20 |       |     3   (0)| 00:00:01 |
|* 13 |     INDEX RANGE SCAN          | VIDX_309                |     1 |       |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("TRANSACTION_ID"="from$_subquery$_003"."TRANSACTION_ID")
   5 - access("ST"."VSYS_STAGE_ROW_ID"="T"."STAGING_RECORD_ID")
   7 - filter("T"."STAGING_RECORD_ID" IS NOT NULL)
   9 - access("RL"."LOYALTY_TXN_ID"="LT"."LOYALTY_TXN_ID")
  13 - access("T"."TRANSACTION_ID"="RLOG"."TRANSACTION_ID"(+))
Statistics
        467  recursive calls
          0  db block gets
     324842  consistent gets
     249318  physical reads
          0  redo size
        955  bytes sent via SQL*Net to client
        240  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          0  rows processed

Answer 1

Hi,
Take these points in consideration
- STAGING_TXN_081 has to be full table scanned as there is NO filter on that
- if all the matching 613071 rows from the TRANSACTION table are in different blocks, it might be equivallant to reading full TRANSACTION table (Oracle read blocks not rows)
- if we are reading all blocks from TRANSACTION table anyway, why waste resources in reading the index blocks
- How can we tell Oracle that, required TRANSACTION records are not located like 'each row in different block' ??? if that is really the case !!!
- Your 'not exists' clause, how may records from TRANSACTION table will be filtered out because of that
- If the 'not exists' will take out huge number of rows, I would suggest creating a in-line view of TRANSACTION table and the 'not exist' logic and then joining that with the STAGING*** table
- Try to minimise the number of rows taking part in these joins (I know, I am not telling anything new here !!!)
Cheers