This is the scenario
SQL> exec dbms_stats.gather_table_stats(user,'TM', cascade=>true)
PL/SQL procedure successfully completed.
SQL> SELECT SEGMENT_NAME , SEGMENT_TYPE , BYTES / 1024 / 1024 MB , BLOCKS FROM DBA_SEGMENTS WHERE SEGMENT_NAME IN ('TM', 'TM_LD_IX');
SEGMENT_NAME SEGMENT_TYPE MB BLOCKS
------------------------------------------ ---------- ----------
TM TABLE 296 37888
TM_LD_IX INDEX 46 5888
SQL> select index_name , column_name from user_ind_columns where index_name = 'TM_LD_IX';
INDEX_NAME COLUMN_NAME
------------ ------------------------------
TM_LD_IX LD
SQL> explain plan for select distinct LD from TM;
Explained.
SQL> @ex
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 4241255022
--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 693 | 4158 | 7920 (8)| 00:01:36 |
| 1 | HASH UNIQUE | | 693 | 4158 | 7920 (8)| 00:01:36 |
| 2 | TABLE ACCESS FULL| TM | 2549K| 14M| 7486 (3)| 00:01:30 |
--------------------------------------------------------------------------------------
9 rows selected.
SQL> explain plan for select /*+ index(x , TM_LD_IX) */ distinct LD from TM x;
Explained.
SQL> @ex
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 4241255022
--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 693 | 4158 | 7920 (8)| 00:01:36 |
| 1 | HASH UNIQUE | | 693 | 4158 | 7920 (8)| 00:01:36 |
| 2 | TABLE ACCESS FULL| TM | 2549K| 14M| 7486 (3)| 00:01:30 |
--------------------------------------------------------------------------------------
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
As you can see oracle is not using the index on LD
and chooses a full table scan instead. I can't even make him use the index with a hist.
In the simple query above I would expect an index fast full scan of TM_LD_IX
. my db_file_multiblock_read_count
is set to 32 so i'm expecting a cost of about 5888 / 32 = 184 (using the index I can also save the cost of a hash unique).
So, what am I missing here ?
Best Answer
The reason for this behaviour is that rows where LD is NULL cannot be found in the index. Therefore Oracle has to scan the full table. If the table is created with LD as a NOT NULL column then the optimizer uses this information and does an INDEX FAST FULL SCAN. If you add a "CHECK(LD is not null)" constraint to the table that has not NOT NULL defined for the column LD then the optimizer does not use the information provided by the constraint and makes a full table scan again, even if you gave him a hint. Jonathan Lewis wrote about this behaviour.
The following scripts demonstrate this behaviour for Oracle 11.2.0.3.0
*create_table.sql* inserts data into the table and creates index and statistics
Now run the following script:
This gives the following output
Summary
If there is a normal B*-tree index on the column NULL values are possible in the column, then the optimizer cannot rely only on the information of the index to do the 'select distinc' and makes a TABLE ACCESS FULL.
If there is a normal B*-tree index and a NOT-NULL check constraint on the column the optimizer also does not rely on the information of the index and makes a TABLE ACCESS FULL.
If there is a normal B*-tree index and the column is defined NOT NULL then the optiomizer relies on the information of the index and does a INDEX FAS FULL SCAN.
If there is a bitmap index on the column then the optimzer knows that all information is in the index and does a BITMAP INDEX FAST FULL SCAN