Comments on: Test Case Showing Oracle Database 11.2.0.1 Completely Ignoring an Index Even when Hinted http://hoopercharles.wordpress.com/2010/09/22/test-case-showing-oracle-database-11-2-0-1-completely-ignoring-an-index-even-when-hinted/ Miscellaneous Random Oracle Topics: Stop, Think, ... Understand Mon, 13 May 2013 14:10:06 +0000 hourly 1 http://wordpress.com/ By: Charles Hooper http://hoopercharles.wordpress.com/2010/09/22/test-case-showing-oracle-database-11-2-0-1-completely-ignoring-an-index-even-when-hinted/#comment-1879 Wed, 22 Sep 2010 19:21:57 +0000 http://hoopercharles.wordpress.com/?p=3349#comment-1879 Randolf Geist demonstrated in the OTN thread that the OP’s table definition is probably missing a NOT NULL constraint. Randolf was able to generate an execution plan with a NOT NULL constraint on the C200000020 column when an index hint was also provided. Randolf used a slightly different test case, so I have adapted his test case to work with my sample table. Let’s take a look at the execution plans:

ALTER TABLE T1 MODIFY (C200000020 NOT NULL);
ALTER SYSTEM FLUSH SHARED_POOL;
 
SET AUTOTRACE TRACEONLY EXPLAIN
 
SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = '';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   100K|    20M| 82353   (1)| 00:16:29 |
|*  1 |  TABLE ACCESS FULL| T1   |   100K|    20M| 82353   (1)| 00:16:29 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter('BOSS'='' OR "C200000020" LIKE 'BOSS%')

Without an index hint the optimizer still selected to perform a full table scan.

Now with the index hint:

SELECT /*+ INDEX(T1 IND_T1) */
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = '';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3418867520
 
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |   100K|    20M|  9980K  (1)| 33:16:04 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T1     |   100K|    20M|  9980K  (1)| 33:16:04 |
|   2 |   INDEX FULL SCAN           | IND_T1 |    10M|       | 31855   (1)| 00:06:23 |
--------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter('BOSS'='' OR "C200000020" LIKE 'BOSS%')

An index full scan, so we are using the index now. But look at the estimated time – it jumped from just 16 minutes to 33 hours and 16 minutes!

Let’s test the performance (your results will be different):

SET AUTOTRACE OFF
SET TIMING ON
 
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
 
SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = '';
 
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
 
SELECT /*+ INDEX(T1 IND_T1) */
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = '';
 
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
 
SELECT /*+ INDEX(T1 IND_T1) */
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%';

The results that I received follow:

SQL> SELECT
  2    *
  3  FROM
  4    T1
  5  WHERE
  6    C200000020 LIKE 'BOSS' || '%'
  7    OR 'BOSS' = '';
 
C200000020
--------------------
PADDING
---------------------------------------
BOSS3000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

BOSS6000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

BOSS9000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


Elapsed: 00:00:04.49
SQL>
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

Elapsed: 00:00:00.06
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

Elapsed: 00:00:00.06
SQL>
SQL> SELECT /*+ INDEX(T1 IND_T1) */
  2    *
  3  FROM
  4    T1
  5  WHERE
  6    C200000020 LIKE 'BOSS' || '%'
  7    OR 'BOSS' = '';

C200000020
--------------------
PADDING
---------------------------------------
BOSS3000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

BOSS6000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

BOSS9000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


Elapsed: 00:02:32.81
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

Elapsed: 00:00:00.15
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

Elapsed: 00:00:00.09
SQL>
SQL> SELECT /*+ INDEX(T1 IND_T1) */
  2    *
  3  FROM
  4    T1
  5  WHERE
  6    C200000020 LIKE 'BOSS' || '%';

C200000020
--------------------
PADDING
---------------------------------------
BOSS3000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

BOSS6000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

BOSS9000000
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


Elapsed: 00:00:00.07

4.49 seconds to perform the full table scan, 2 minutes and 32.81 seconds for the index full scan, and 0.07 seconds to do it the correct way.

The table and index extent sizes follow:

SELECT
  SEGMENT_NAME SEGMENT,
  COUNT(*) EXTENTS,
  BYTES/1024 EXT_SIZE_KB,
  (COUNT(*) * BYTES)/1048576 TOTAL_MB
FROM
  DBA_EXTENTS
WHERE
  OWNER=USER
  AND SEGMENT_NAME IN ('IND_T1','T1')
GROUP BY
  SEGMENT_NAME,
  BYTES
ORDER BY
  SEGMENT_NAME,
  BYTES;
 
SEGMENT       EXTENTS EXT_SIZE_KB   TOTAL_MB
---------- ---------- ----------- ----------
IND_T1             16          64          1
IND_T1             63        1024         63
IND_T1             24        8192        192
T1                 16          64          1
T1                 63        1024         63
T1                120        8192        960
T1                 21       65536       1344
]]> By: Charles Hooper http://hoopercharles.wordpress.com/2010/09/22/test-case-showing-oracle-database-11-2-0-1-completely-ignoring-an-index-even-when-hinted/#comment-1873 Wed, 22 Sep 2010 14:50:13 +0000 http://hoopercharles.wordpress.com/?p=3349#comment-1873 In my opinion, if ” is treated as NULL, the second half of the OR clause should always be false, because nothing is ever equal to NULL, not even NULL. I agree with you that with the bind variables, the second half of the OR clause *could* be true, even if it cannot be true on the initial hard parse – a full table scan should be expected in that case.

Before running the tests, I would assume that ‘BOSS’ = ‘SUPERCALIFRAGILISTICEXPEALIDOCIOUS’ should be handled the same as the case where I used a single space between the two ‘ characters. Here are the test results:

SET AUTOTRACE TRACEONLY EXPLAIN
 
SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = 'SUPERCALIFRAGILISTICEXPEALIDOCIOUS';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 634656657
 
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |   213 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |   213 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IND_T1 |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C200000020" LIKE 'BOSS%')
       filter("C200000020" LIKE 'BOSS%')

Above used an index range scan, as would be expected.

SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = NULL;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 634656657
 
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |   213 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |   213 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IND_T1 |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C200000020" LIKE 'BOSS%')
       filter("C200000020" LIKE 'BOSS%')

Above used an index range scan, as would be expected.

SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' IS NULL;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 634656657
 
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |   213 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |   213 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IND_T1 |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C200000020" LIKE 'BOSS%')
       filter("C200000020" LIKE 'BOSS%')

Above used an index range scan, as would be expected.

SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = ' ';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 634656657
 
--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |   213 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1     |     1 |   213 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IND_T1 |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C200000020" LIKE 'BOSS%')
       filter("C200000020" LIKE 'BOSS%')

Above used an index range scan, as would be expected.

SELECT
  *
FROM
  T1
WHERE
  C200000020 LIKE 'BOSS' || '%'
  OR 'BOSS' = '';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   100K|    20M| 82353   (1)| 00:16:29 |
|*  1 |  TABLE ACCESS FULL| T1   |   100K|    20M| 82353   (1)| 00:16:29 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter('BOSS'='' OR "C200000020" LIKE 'BOSS%')

The above used a full table scan because the index access paths were not even considered.

]]> By: niall litchfield http://hoopercharles.wordpress.com/2010/09/22/test-case-showing-oracle-database-11-2-0-1-completely-ignoring-an-index-even-when-hinted/#comment-1871 Wed, 22 Sep 2010 13:23:01 +0000 http://hoopercharles.wordpress.com/?p=3349#comment-1871 Charles, is this a null effect? I.E does the behavior reproduce with ‘BOSS’ = ‘SUPERCALIFRAGILISTICEXPEALIDOCIOUS’? I agree that Oracle should know that a string of length 4 is not null, it wouldn’t know that a bind was of course. Can’t test right now

]]>