How oracle decide whetehr to use index or full scan (statistics)

Question

Hi Guys,
Let say i have a index on a column.
The table and index statistics has been gathered. (without histograms).
Let say i perform a select * from table where a=5;
Oracle will perform a full scan.
But from which statistics it will be able to know indeed most of the column = 5? (histograms not used)
After analyzing, we get the below:
Table Statistics :
(NUM_ROWS)
(BLOCKS)
(EMPTY_BLOCKS)
(AVG_SPACE)
(CHAIN_COUNT)
(AVG_ROW_LEN)
Index Statistics :
(BLEVEL)
(LEAF_BLOCKS)
(DISTINCT_KEYS)
(AVG_LEAF_BLOCKS_PER_KEY)
(AVG_DATA_BLOCKS_PER_KEY)
(CLUSTERING_FACTOR)
thanks
Index Column (A)
======
1
1
2
2
5
5
5
5
5
5

Answer 1

I have prepared some explanation and have not noticed that the topic has been marked as answered.
This my sentence is not completely true.
A column "without histograms" means that the column has only one bucket. More correct: even without histograms there are data in dba_tab_histograms which we can consider as one bucket for whole column. In fact these data are retrieved from hist_head$, not from histgrm$ as usual buckets.
Technically there is no any buckets without gathered histograms.
Let's create a table with skewed data distribution.
SQL> create table t as
  2  select least(rownum,3) as val, '*' as pad
  3    from dual
  4  connect by level <= 1000000;
Table created
SQL> create index idx on t(val);
Index created
SQL> select val, count(*)
  2    from t
  3   group by val;
       VAL   COUNT(*)
         1          1
         2          1
         3     999998So, we have table with very skewed data distribution.
Let's gather statistics without histograms.
SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for all columns size 1', cascade => true);
PL/SQL procedure successfully completed
SQL> select blocks, num_rows  from dba_tab_statistics
  2   where table_name = 'T';
    BLOCKS   NUM_ROWS
      3106    1000000
SQL> select blevel, leaf_blocks, clustering_factor
  2    from dba_ind_statistics t
  3   where table_name = 'T'
  4     and index_name = 'IDX';
    BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
         2        4017              3107
SQL> select column_name,
  2         num_distinct,
  3         density,
  4         num_nulls,
  5         low_value,
  6         high_value
  7    from dba_tab_col_statistics
  8   where table_name = 'T'
  9     and column_name = 'VAL';
COLUMN_NAME  NUM_DISTINCT    DENSITY  NUM_NULLS      LOW_VALUE      HIGH_VALUE
VAL                     3 0,33333333          0           C102            C104So, Oracle suggests that values between 1 and 3 (raw C102 and C104) are distributed uniform and the density of the distribution is 0.33.
Let's try to explain plan
SQL> explain plan for
  2  select --+ no_cpu_costing
  3         *
  4    from t
  5   where val = 1
  6  ;
Explained
SQL> @plan
| Id  | Operation         | Name | Rows  | Cost  |
|   0 | SELECT STATEMENT  |      |   333K|   300 |
|*  1 |  TABLE ACCESS FULL| T    |   333K|   300 |
Predicate Information (identified by operation id):
   1 - filter("VAL"=1)
Note
   - cpu costing is off (consider enabling it)Below is an excerpt from trace 10053
BASE STATISTICAL INFORMATION
Table Stats::
  Table:  T  Alias:  T
    #Rows: 1000000  #Blks:  3106  AvgRowLen:  5.00
Index Stats::
  Index: IDX  Col#: 1
    LVLS: 2  #LB: 4017  #DK: 3  LB/K: 1339.00  DB/K: 1035.00  CLUF: 3107.00
SINGLE TABLE ACCESS PATH
  BEGIN Single Table Cardinality Estimation
  Column (#1): VAL(NUMBER)
    AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 0.33333 Min: 1 Max: 3
  Table:  T  Alias: T
    Card: Original: 1000000  Rounded: 333333  Computed: 333333.33  Non Adjusted: 333333.33
  END   Single Table Cardinality Estimation
  Access Path: TableScan
    Cost:  300.00  Resp: 300.00  Degree: 0
      Cost_io: 300.00  Cost_cpu: 0
      Resp_io: 300.00  Resp_cpu: 0
  Access Path: index (AllEqRange)
    Index: IDX
    resc_io: 2377.00  resc_cpu: 0
    ix_sel: 0.33333  ix_sel_with_filters: 0.33333
    Cost: 2377.00  Resp: 2377.00  Degree: 1
  Best:: AccessPath: TableScan
         Cost: 300.00  Degree: 1  Resp: 300.00  Card: 333333.33  Bytes: 0Cost of FTS here is 300 and cost of Index Range Scan here is 2377.
I have disabled cpu costing, so selectivity does not affect the cost of FTS.
cost of Index Range Scan is calculated as
blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017*0.33333 + 3107*0.33333) = 2377.
Oracle considers that it has to read 2 root/branch blocks of the index, 1339 leaf blocks of the index and 1036 blocks of the table.
Pay attention that selectivity is the major component of the cost of the Index Range Scan.
Let's try to gather histograms:
SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for columns val size 3', cascade => true);
PL/SQL procedure successfully completedIf you look at dba_tab_histograms you will see following
SQL> select endpoint_value,
  2         endpoint_number
  3    from dba_tab_histograms
  4   where table_name = 'T'
  5     and column_name = 'VAL'
  6  ;
ENDPOINT_VALUE ENDPOINT_NUMBER
             1               1
             2               2
             3         1000000ENDPOINT_VALUE is the column value (in number for any type of data) and ENDPOINT_NUMBER is cumulative number of rows.
Number of rows for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER for the previous ENDPOINT_VALUE.
explain plan and 10053 trace of the same query:
| Id  | Operation                   | Name | Rows  | Cost  |
|   0 | SELECT STATEMENT            |      |     1 |     4 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |     1 |     4 |
|*  2 |   INDEX RANGE SCAN          | IDX  |     1 |     3 |
Predicate Information (identified by operation id):
   2 - access("VAL"=1)
Note
   - cpu costing is off (consider enabling it)
BASE STATISTICAL INFORMATION
Table Stats::
  Table:  T  Alias:  T
    #Rows: 1000000  #Blks:  3106  AvgRowLen:  5.00
Index Stats::
  Index: IDX  Col#: 1
    LVLS: 2  #LB: 4017  #DK: 3  LB/K: 1339.00  DB/K: 1035.00  CLUF: 3107.00
SINGLE TABLE ACCESS PATH
  BEGIN Single Table Cardinality Estimation
  Column (#1): VAL(NUMBER)
    AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 5.0000e-07 Min: 1 Max: 3
    Histogram: Freq  #Bkts: 3  UncompBkts: 1000000  EndPtVals: 3
  Table:  T  Alias: T
    Card: Original: 1000000  Rounded: 1  Computed: 1.00  Non Adjusted: 1.00
  END   Single Table Cardinality Estimation
  Access Path: TableScan
    Cost:  300.00  Resp: 300.00  Degree: 0
      Cost_io: 300.00  Cost_cpu: 0
      Resp_io: 300.00  Resp_cpu: 0
  Access Path: index (AllEqRange)
    Index: IDX
    resc_io: 4.00  resc_cpu: 0
    ix_sel: 1.0000e-06  ix_sel_with_filters: 1.0000e-06
    Cost: 4.00  Resp: 4.00  Degree: 1
  Best:: AccessPath: IndexRange  Index: IDX
         Cost: 4.00  Degree: 1  Resp: 4.00  Card: 1.00  Bytes: 0Pay attention on selectivity, ix_sel: 1.0000e-06
Cost of the FTS is still the same = 300,
but cost of the Index Range Scan is 4 now: 2 root/branch blocks + 1 leaf block + 1 table block.
Thus, conclusion: histograms allows to calculate selectivity more accurate. The aim is to have more efficient execution plans.
Alexander Anokhin
http://alexanderanokhin.wordpress.com/