And now what?

Rg,
Damir

Thank you for posting a link to your article – always good to see links to articles that demonstrate helpful information. You certainly did capture all of the options.

The first time I read the article, my eyes became a bit blurry… why would Oracle’s optimizer select to use an INDEX FULL SCAN operation, which reads one block at a time (from disk), when it can just about as quickly read 8, 16, or 128 8KB blocks at a time (from disk) during a FULL TABLE SCAN operation. Then it hit me on the second read through… your test table only had 10 very narrow rows – the indexes probably contained only an index root block.

I extended your test case to 1,000,000 rows, with each row being much wider (column C_2 is padded to 255 characters) (tested on 11.2.0.2, I am explaining the steps for the other people who may read this comment, not necessarily for David):

create table test1(
       c_1 number not null,
       c_2 varchar2(255)
  );
 
INSERT INTO
  TEST1
SELECT
  ROWNUM,
  RPAD('Test '||ROWNUM,255,'A')
FROM
  DUAL
CONNECT BY
  LEVEL<=1000000;
 
create index test1_c_2 on test1(c_2);
create index test1_c_1 on test1(c_1);
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'TEST1',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL)
 
SET AUTOTRACE TRACEONLY STATISTICS EXPLAIN
SET LINESIZE 120
SET PAGESIZE 1000

Will the optimizer select to use the TEST1_C_2 index if c_2 IS NOT NULL is specified in the WHERE clause:

SELECT
  C_2
FROM
  TEST1
WHERE
  C_2 IS NOT NULL;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4122059633
 
---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |  1000K|   244M| 13143   (5)| 00:00:06 |
|*  1 |  TABLE ACCESS FULL| TEST1 |  1000K|   244M| 13143   (5)| 00:00:06 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C_2" IS NOT NULL)
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     103774  consistent gets
          0  physical reads
          0  redo size
  264867023  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

Well, in this case a FULL TABLE SCAN operation was selected with a calculated cost of 13,143.

Let’s force an index access path:

SELECT /*+ INDEX(TEST1) */
  C_2
FROM
  TEST1
WHERE
  C_2 IS NOT NULL;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2529630288
 
------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |  1000K|   244M| 54890   (2)| 00:00:22 |
|*  1 |  INDEX FULL SCAN | TEST1_C_2 |  1000K|   244M| 54890   (2)| 00:00:22 |
------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C_2" IS NOT NULL)
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     117174  consistent gets
          0  physical reads
          0  redo size
  264867023  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

An INDEX FULL SCAN operation was used, but it was not automatically selected because the 54,890 cost is greater than the 13,143 cost for the FULL TABLE SCAN operation.

Let’s try again with a narrower version of the table, with column C_2 restricted to 10 characters:

TRUNCATE TABLE TEST1;
 
INSERT INTO
  TEST1
SELECT
  ROWNUM,
  RPAD('Test '||ROWNUM,10,'A')
FROM
  DUAL
CONNECT BY
  LEVEL<=1000000;
  
COMMIT;
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'TEST1',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL,NO_INVALIDATE=>FALSE)

Repeating the test with C_2 IS NOT NULL specified in the WHERE clause:

SELECT
  C_2
FROM
  TEST1
WHERE
  C_2 IS NOT NULL;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4122059633
 
---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |  1000K|    10M|  1239  (23)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TEST1 |  1000K|    10M|  1239  (23)| 00:00:01 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C_2" IS NOT NULL)
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      69372  consistent gets
          0  physical reads
          0  redo size
   17867023  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

A full table scan again, this time with a calculated cost of 1,239.

Let’s force an index access path:

SELECT /*+ INDEX(TEST1) */
  C_2
FROM
  TEST1
WHERE
  C_2 IS NOT NULL;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2529630288
 
------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |  1000K|    10M|  5472   (6)| 00:00:03 |
|*  1 |  INDEX FULL SCAN | TEST1_C_2 |  1000K|    10M|  5472   (6)| 00:00:03 |
------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C_2" IS NOT NULL)
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      71481  consistent gets
          0  physical reads
          0  redo size
   11833627  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

The INDEX FULL SCAN operation had a calculated cost of 5,472, which is more than the 1,239 for the FULL TABLE SCAN operation, so that is why the full table scan was selected.

Let’s check selecting column C_1 to see if we also experience a FULL TABLE SCAN for this query:

SELECT
  C_1
FROM
  TEST1;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2062908727
 
----------------------------------------------------------------------------------
| Id  | Operation            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |  1000K|  4882K|   921  (20)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| TEST1_C_1 |  1000K|  4882K|   921  (20)| 00:00:01 |
----------------------------------------------------------------------------------
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      68759  consistent gets
          0  physical reads
          0  redo size
   11846825  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

No full table scan, but we did receive an INDEX FAST FULL SCAN operation, which performs multi-block reads (from disk) of the index blocks, much like what would happen with the table blocks during a FULL TABLE SCAN operation.

Let’s see what happens if we try to force an index access path using a hint for the same query:

SELECT /*+ INDEX(TEST1) */
  C_1
FROM
  TEST1;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2345822858
 
------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |  1000K|  4882K|  2509  (12)| 00:00:02 |
|   1 |  INDEX FULL SCAN | TEST1_C_1 |  1000K|  4882K|  2509  (12)| 00:00:02 |
------------------------------------------------------------------------------
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      68746  consistent gets
          0  physical reads
          0  redo size
   11846825  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

Notice that the cost increased dramatically, and that the execution plan shows an INDEX FULL SCAN operation rather than an INDEX FAST FULL SCAN operation.

For fun, let’s check the calculated cost of a FULL TABLE SCAN so that we are able to compare the cost with the INDEX FULL SCAN operation:

SELECT /*+ FULL(TEST1) */
  C_1
FROM
  TEST1
WHERE
  C_1 IS NOT NULL;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4122059633
 
---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |  1000K|  4882K|  1187  (19)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| TEST1 |  1000K|  4882K|  1187  (19)| 00:00:01 |
---------------------------------------------------------------------------
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      69372  consistent gets
          0  physical reads
          0  redo size
   11846825  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

The cost of the FULL TABLE SCAN is less than that of the INDEX FULL SCAN operation – so if the INDEX FAST FULL SCAN operation was not legal, the FULL TABLE SCAN operation would have been selected.

Maybe it is a problem with skewed system statistics?

COLUMN PNAME FORMAT A20
 
SELECT
  PNAME,
  PVAL1
FROM
  SYS.AUX_STATS$;
 
PNAME                     PVAL1
-------------------- ----------
STATUS
DSTART
DSTOP
FLAGS                         1
CPUSPEEDNW           2116.57559
IOSEEKTIM                    10
IOTFRSPEED                 4096
SREADTIM                     .4
MREADTIM                     .8
CPUSPEED                   1922
MBRC                          6
MAXTHR                155910144
SLAVETHR

The MBRC is just 6, so the optimizer definitely was not under-costing the FULL TABLE SCAN (and INDEX FAST FULL SCAN) operation.

Let’s bump the MBRC to 16 just to see what happens:

EXEC DBMS_STATS.SET_SYSTEM_STATS('MBRC',16)
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'TEST1',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL,NO_INVALIDATE=>FALSE)
 
SET AUTOTRACE TRACEONLY STATISTICS EXPLAIN
 
SELECT
  C_1
FROM
  TEST1;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2062908727
 
----------------------------------------------------------------------------------
| Id  | Operation            | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |  1000K|  4882K|   457  (39)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| TEST1_C_1 |  1000K|  4882K|   457  (39)| 00:00:01 |
----------------------------------------------------------------------------------
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      68759  consistent gets
          0  physical reads
          0  redo size
   11846825  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

The INDEX FAST FULL SCAN operation’s cost dropped from 921 to 457.

So, what would happen if an INDEX FAST FULL SCAN operation were not valid for this SQL statement?:

SELECT /*+ NO_INDEX_FFS(TEST1) */
  C_1
FROM
  TEST1;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4122059633
 
---------------------------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |       |  1000K|  4882K|   585  (38)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| TEST1 |  1000K|  4882K|   585  (38)| 00:00:01 |
---------------------------------------------------------------------------
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      69372  consistent gets
          0  physical reads
          0  redo size
   11846825  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

A full table scan with a cost of 585.

Let’s switch back to an INDEX FULL SCAN operation:

SELECT /*+ INDEX(TEST1) */
  C_1
FROM
  TEST1;
 
1000000 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2345822858
 
------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |  1000K|  4882K|  2509  (12)| 00:00:02 |
|   1 |  INDEX FULL SCAN | TEST1_C_1 |  1000K|  4882K|  2509  (12)| 00:00:02 |
------------------------------------------------------------------------------
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      68746  consistent gets
          0  physical reads
          0  redo size
   11846825  bytes sent via SQL*Net to client
     733686  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

The calculated cost is unchanged after the change of the MBRC system statistic.

—

David,

Would you be able to re-run your test with Oracle Database 11.2.0.1, 11.2.0.2, or 11.2.0.3 with a larger number of rows? I am curious to know if you will see INDEX FAST FULL SCAN operations, INDEX FULL SCAN operations, or TABLE ACCESS FULL operations in the execution plans.

http://oratips-ddf.blogspot.com/2008/04/tale-of-two-indexes.html

Well done. Another case where a single test case is insufficient, especially if an intentional (or unintentional) mistake is made in the test case

SQL> SELECT COLUMN_EXPRESSION FROM USER_IND_EXPRESSIONS WHERE INDEX_NAME='IND_T2_C3_FN';
 
COLUMN_EXPRESSION
----------------------------------------
DECODE(TO_CHAR("C3",'DD-MON-RR'),NULL,1)

Well, that is not what I requested – the problem extends beyond problems with CURSOR_SHARING=FORCE – NLS settings could also be an issue.

Back to the original test, and a fix.

SELECT /*+ INDEX(T2) */
  C1,
  C2,
  C3,
  NVL2(C3,NULL,1) C4
FROM
  T2
WHERE
  C2='D00000000000000'
  AND DECODE(C3,NULL,1)=1;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL'));
 
SELECT /*+ INDEX(T2) */
  C1,
  C2,
  C3,
  NVL2(C3,NULL,1) C4
FROM
  T2
WHERE
  C2='D00000000000000'
  AND DECODE(TO_CHAR("C3",'DD-MON-RR'),NULL,1)=1;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL'));

Results:

SQL_ID  8psj7gcwcn72m, child number 0
-------------------------------------
SELECT /*+ INDEX(T2) */   C1,   C2,   C3,   NVL2(C3,NULL,1) C4 FROM
T2 WHERE   C2='D00000000000000'   AND DECODE(C3,NULL,1)=1
 
Plan hash value: 1513984157
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |  3346 (100)|          |
|*  1 |  TABLE ACCESS FULL| T2   |   769 | 23070 |  3346   (1)| 00:00:01 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(("C2"='D00000000000000' AND
              DECODE(INTERNAL_FUNCTION("C3"),NULL,1)=1))
 
---
 
SQL_ID  8av2y4gms3baq, child number 0
-------------------------------------
SELECT /*+ INDEX(T2) */   C1,   C2,   C3,   NVL2(C3,NULL,1) C4 FROM
T2 WHERE   C2='D00000000000000'   AND
DECODE(TO_CHAR("C3",'DD-MON-RR'),NULL,1)=1
 
Plan hash value: 941108248
 
--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |       |       | 10024 (100)|          |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T2           |   100 |  3200 | 10024   (1)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IND_T2_C3_FN | 10000 |       |    20   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C2"='D00000000000000')
   2 - access("T2"."SYS_NC00005$"=1)

Apologies but the INTERNAL_FUNCTION appears because C3 is DATE datatype and it is being compared to NULL (which, by default, is VARCHAR2, I think). Hence the conversion for data type compatibility.

Guess what? I don’t get table scan when using DECODE. My results are same as that using NVL (again, apologies for not formatting)

SQL> drop INDEX IND_T2_C3_FN ;

Index dropped.

SQL> CREATE INDEX IND_T2_C3_FN ON T2 DECODE(C3,NULL,1);

Index created.

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE,ESTIMATE_PERCENT=>100,METHOD_OPT=>'FOR ALL HIDDEN COLUMNS SIZE 254 FOR ALL INDEXED COLUMNS SIZE 254',NO_INVALIDATE=>FALSE) ;

PL/SQL procedure successfully completed.

SQL> SELECT COLUMN_NAME,HIDDEN_COLUMN,VIRTUAL_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='T2';

COLUMN_NAME		       HID VIR
------------------------------ --- ---
C1			       NO  NO
C2			       NO  NO
C3			       NO  NO
C4			       NO  NO
SYS_NC00006$		       YES YES
SYS_NC00005$		       YES YES

6 rows selected.

SQL> select index_name, column_expression from user_ind_expressions where table_name = 'T2' ;

INDEX_NAME		       COLUMN_EXPRESSION
------------------------------ --------------------------------------------------------------------------------
IND_T2_C3_FN		       NULL
IND_T2_C3_FN		       1

SQL> set autotrace traceonly explain
SELECT /*+ INDEX(T2) */
  C1,
  C2,
  C3,
  NVL2(C3,NULL,1) C4
FROM
  T2
WHERE
  C2='D00000000000000'
  AND DECODE(C3,NULL,1)=1;
 10  
Execution Plan
----------------------------------------------------------
Plan hash value: 2303772603

--------------------------------------------------------------------------------------------
| Id  | Operation		    | Name	   | Rows  | Bytes | Cost (%CPU)| Time	   |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |		   |   100 |  3000 |  3743   (1)| 00:00:45 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T2	   |   100 |  3000 |  3743   (1)| 00:00:45 |
|*  2 |   INDEX FULL SCAN	    | IND_T2_C3_FN | 10000 |	   |  3225   (1)| 00:00:39 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("C2"='D00000000000000')
   2 - filter(DECODE(INTERNAL_FUNCTION("C3"),NULL,1)=1)

SQL> DROP INDEX IND_T2_C3_FN;

Index dropped.

SQL> CREATE INDEX IND_T2_C3_FN ON T2 (DECODE(C3,NULL,1)) nologging ;

Index created.

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE,ESTIMATE_PERCENT=>100,METHOD_OPT=>'FOR ALL HIDDEN COLUMNS SIZE 254 FOR ALL INDEXED COLUMNS SIZE 254',NO_INVALIDATE=>FALSE) ;

PL/SQL procedure successfully completed.

SQL> set autotrace off
SQL> SELECT COLUMN_NAME,HIDDEN_COLUMN,VIRTUAL_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='T2';

COLUMN_NAME		       HID VIR
------------------------------ --- ---
C1			       NO  NO
C2			       NO  NO
C3			       NO  NO
C4			       NO  NO
SYS_NC00005$		       YES YES

SQL> select index_name, column_expression from user_ind_expressions where table_name = 'T2' ;

INDEX_NAME		       COLUMN_EXPRESSION
------------------------------ --------------------------------------------------------------------------------
IND_T2_C3_FN		       DECODE("C3",NULL,1)

SQL> set autotrace traceonly explain
SELECT /*+ INDEX(T2) */
  C1,
  C2,
  C3,
  NVL2(C3,NULL,1) C4
FROM
  T2
WHERE
  C2='D00000000000000'
 10    AND DECODE(C3,NULL,1)=1;

Execution Plan
----------------------------------------------------------
Plan hash value: 941108248

--------------------------------------------------------------------------------------------
| Id  | Operation		    | Name	   | Rows  | Bytes | Cost (%CPU)| Time	   |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |		   |   100 |  3000 | 10023   (1)| 00:02:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T2	   |   100 |  3000 | 10023   (1)| 00:02:01 |
|*  2 |   INDEX RANGE SCAN	    | IND_T2_C3_FN | 10000 |	   |	20   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("C2"='D00000000000000')
   2 - access(DECODE(INTERNAL_FUNCTION("C3"),NULL,1)=1)

SQL> CREATE INDEX IND_T2_C3_FN ON T2 NVL2(C3,NULL,1);

Index created.

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE,ESTIMATE_PERCENT=>100,METHOD_OPT=>'FOR ALL HIDDEN COLUMNS SIZE 254 FOR ALL INDEXED COLUMNS SIZE 254',NO_INVALIDATE=>FALSE)
;

PL/SQL procedure successfully completed.

SQL> SELECT COLUMN_NAME,HIDDEN_COLUMN,VIRTUAL_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='T2';

COLUMN_NAME		       HID VIR
------------------------------ --- ---
C1			       NO  NO
C2			       NO  NO
C3			       NO  NO
C4			       NO  NO
SYS_NC00005$		       YES YES
SYS_NC00006$		       YES YES

6 rows selected.

SQL> select index_name, column_expression from user_ind_expressions where table_name = 'T2' ;

INDEX_NAME		       COLUMN_EXPRESSION
------------------------------ --------------------------------------------------------------------------------
IND_T2_C3_FN		       NULL
IND_T2_C3_FN		       1

SQL> set autotrace traceonly explain
SELECT /*+ INDEX(T2) */
  C1,
  C2,
  C3,
  NVL2(C3,NULL,1) C4
FROM
  T2
WHERE
  C2='D00000000000000'
 10    AND NVL2(C3,NULL,1)=1;

Execution Plan
----------------------------------------------------------
Plan hash value: 2303772603

--------------------------------------------------------------------------------------------
| Id  | Operation		    | Name	   | Rows  | Bytes | Cost (%CPU)| Time	   |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |		   |   100 |  3000 |  3734   (1)| 00:00:45 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T2	   |   100 |  3000 |  3734   (1)| 00:00:45 |
|*  2 |   INDEX FULL SCAN	    | IND_T2_C3_FN | 10000 |	   |  3216   (1)| 00:00:39 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("C2"='D00000000000000')
   2 - filter(NVL2("C3",NULL,1)=1)

SQL> set autotrace off
SQL> DROP INDEX IND_T2_C3_FN;

Index dropped.

SQL> CREATE INDEX IND_T2_C3_FN ON T2 (NVL2(C3,NULL,1)) nologging ;

Index created.

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE,ESTIMATE_PERCENT=>100,METHOD_OPT=>'FOR ALL HIDDEN COLUMNS SIZE 254 FOR ALL INDEXED COLUMNS SIZE 254',NO_INVALIDATE=>FALSE) ;

PL/SQL procedure successfully completed.

SQL> SELECT COLUMN_NAME,HIDDEN_COLUMN,VIRTUAL_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='T2';

COLUMN_NAME		       HID VIR
------------------------------ --- ---
C1			       NO  NO
C2			       NO  NO
C3			       NO  NO
C4			       NO  NO
SYS_NC00005$		       YES YES

SQL> select index_name, column_expression from user_ind_expressions where table_name = 'T2' ;

INDEX_NAME		       COLUMN_EXPRESSION
------------------------------ --------------------------------------------------------------------------------
IND_T2_C3_FN		       NVL2("C3",NULL,1)

SQL> set autotrace traceonly explain
SELECT /*+ INDEX(T2) */
  C1,
  C2,
  C3,
  NVL2(C3,NULL,1) C4
FROM
  T2
WHERE
  C2='D00000000000000'
  AND NVL2(C3,NULL,1)=1;
 10  
Execution Plan
----------------------------------------------------------
Plan hash value: 941108248

--------------------------------------------------------------------------------------------
| Id  | Operation		    | Name	   | Rows  | Bytes | Cost (%CPU)| Time	   |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	    |		   |   100 |  3000 | 10023   (1)| 00:02:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T2	   |   100 |  3000 | 10023   (1)| 00:02:01 |
|*  2 |   INDEX RANGE SCAN	    | IND_T2_C3_FN | 10000 |	   |	20   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("C2"='D00000000000000')
   2 - access(NVL2("C3",NULL,1)=1)