Avoid fts

Question

Hello,
i am on 11gr2, 11.2.0.3.0
and i am trying to avoid fts because query takes too long and the cost is too high.
This is the explain plan :
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 309652726
| Id  | Operation                | Name             | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT         |                  |  4232K|   314M|       | 66586   (2)| 00:13:20 |       |       |
|*  1 |  HASH JOIN               |                  |  4232K|   314M|    46M| 66586   (2)| 00:13:20 |       |       |
|   2 |   VIEW                   | index$_join$_002 |  1869K|    24M|       |  5741   (1)| 00:01:09 |       |       |
|*  3 |    HASH JOIN             |                  |       |       |       |            |          |       |       |
|   4 |     PARTITION LIST ALL   |                  |  1869K|    24M|       |   410   (1)| 00:00:05 |     1 |     4 |
|   5 |      INDEX FAST FULL SCAN| KLI_MBR_I        |  1869K|    24M|       |   410   (1)| 00:00:05 |     1 |     4 |
|   6 |     INDEX FAST FULL SCAN | KLI_PK           |  1869K|    24M|       |   318   (1)| 00:00:04 |       |       |
|   7 |   TABLE ACCESS FULL      | PARTIJA          |  4245K|   259M|       | 43238   (2)| 00:08:39 |       |       |
Predicate Information (identified by operation id):
   1 - access("KLI"."ID"="P"."KLI_ID")
   3 - access(ROWID=ROWID)
20 rows selected.Am I right if I assume that the fts on partija table is due to lack of filters(and,where), as it uses only the join KLI"."ID"="P"."KLI_ID ?
also,when I try to force a btree index access on p.kli_id using a hint , plan is even worse.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2491098214
| Id  | Operation                    | Name             | Rows  | Bytes |TempSpc| Cost (%CPU)| Time  | Pstart| Pstop |
|   0 | SELECT STATEMENT             |                  |  4232K|   314M|       |   204K  (1)| 00:40:55 |       |       |
|   1 |  MERGE JOIN                  |                  |  4232K|   314M|       |   204K  (1)| 00:40:55 |       |       |
|   2 |   TABLE ACCESS BY INDEX ROWID| PARTIJA          |  4245K|   259M|       |   189K  (1)| 00:37:55 |       |       |
|   3 |    INDEX FULL SCAN           | PARTIJA_KLI_FK_I |  4209K|       |       |   616   (1)| 00:00:08 |       |       |
|*  4 |   SORT JOIN                  |                  |  1869K|    24M|    85M| 15008   (1)| 00:03:01 |       |       |
|   5 |    VIEW                      | index$_join$_002 |  1869K|    24M|       |  5741   (1)| 00:01:09 |       |       |
|*  6 |     HASH JOIN                |                  |       |       |       |            |       |  |       |
|   7 |      PARTITION LIST ALL      |                  |  1869K|    24M|       |   410   (1)| 00:00:05 |     1 |     4 |
|   8 |       INDEX FAST FULL SCAN   | KLI_MBR_I        |  1869K|    24M|       |   410   (1)| 00:00:05 |     1 |     4 |
|   9 |      INDEX FAST FULL SCAN    | KLI_PK           |  1869K|    24M|       |   318   (1)| 00:00:04 |       |       |
Predicate Information (identified by operation id):
   4 - access("KLI"."ID"="P"."KLI_ID")
       filter("KLI"."ID"="P"."KLI_ID")
   6 - access(ROWID=ROWID)
23 rows selected.here is the env
SQL> show parameter optimizer
NAME                                 TYPE        VALUE
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.2.0.3
optimizer_index_caching              integer     95
optimizer_index_cost_adj             integer     5
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE
SQL> show parameter db_file_multi
NAME                                 TYPE        VALUE
db_file_multiblock_read_count        integer     16
SQL> show parameter db_block_size
NAME                                 TYPE        VALUE
db_block_size                        integer     8192
SQL> show parameter cursor_sharin
NAME                                 TYPE        VALUE
cursor_sharing                       string      EXACT
SQL>and this is the query , with the hint
select /*+ index (p partija_kli_fk_i) */ p.par_sifpar as account_id
           ,  p.par_vposla ||'-'|| p.par_sifpar as account_ref_id
           ,  alc_accounts_pck.f_account_name (p.par_kredep, p.par_vposla) as account_name
           ,  kli.maticni_broj as customer_id
           ,  case
                 when     p.par_vazido = 0
                      and p.par_sporni = 0 then
                    'ACTIVE'
                 when     p.par_vazido = 0
                      and p.par_sporni > 0 then
                    'BLOCKED'
                 when par_vazido > 0 then
                    'INACTIVE'
                 else
                    null
              end
                 as account_status_code
           ,  alc_accounts_pck.f_account_type (p.par_kredep, p.par_vposla) as account_type
           ,  case
                 when p.par_kredep = 0 then 'D'
                 when p.par_kredep > 0 then 'C'
                 else null
              end
                 as credit_debit_code
           ,  alc_util_pck.f_currency_code as currency_code
           ,  case when  p.par_vaziod = 0 then  null else p.par_vaziod end as date_opened
           ,  case when  p.par_vazido = 0  then null  else p.par_vazido end as date_closed
           ,  alc_accounts_pck.f_account_balance (p.par_sifpar) as account_balance
           ,  p.par_posjed as branch_id
           ,  alc_accounts_pck.f_relation_mng_id (p.par_sektor
                                                ,    p.par_centar
                                                ,    p.par_sluzba
                                                ,    p.par_orgjed
                                                ,    p.par_siftim)as relationship_mgr_id
           ,  trim (p.par_ibanbr) as iban
           ,  'OTHER' as product_source_type_code
           ,  alc_util_pck.f_risk_account_flag (kli.id) as risk_flag
           ,  'N' as non_face_to_face_flag
           ,  alc_accounts_pck.f_trustee_flag (p.par_sifpar) as trustee_flag
        from partija p
             join klijenti kli
                on (kli.id = p.kli_id)
       where 1=1Edited by: Vili Dialis on Nov 22, 2012 1:10 AM
forgot to add query

Answer 1

Hi Vili,
full table scans are very efficient for retrieving large percentage of rows from a table for several reasons:
1) they can benefit from multiblock reads (as opposed to index range/unique scans which use single-block reads)
2) they don't read rowid's
3) they don't need to navigate through root/branch blocks, i.e. only data block are read
Contrary to a popular belief, indexes only provide benefits in a limited number of cases:
1) a small percentage of rows is needed (index range/unique/skip scan)
2) only column(s) contain in the index are needed (index fast full scan)
3) rows are needed in sorted order, and sorting would be expensive (index full scan)
So it's not surprising that the optimizer decides in favor of a full table scan in your case.
Best regards,
Nikolay