Optimizer bug in RDBMS versions 9.2.0.7.0 and 9.2.0.8.0

Question

This listing below demonstrates a bug in the Oracle optimizer that causes incorrect results to be returned after a table is analyzed. Rule based optimizer gives correct results.
Under cost-based optimization the predicate includes a condition from a check constraint on a nullable field. When the value of this field is NULL the record is excluded from the results even though that record does not violate the check constraint.
I have verified that this bug exists on both RDBMS versions 9.2.0.7.0 and 9.2.0.8.0.
ORA92080>
ORA92080>DROP TABLE test1;
Table dropped.
ORA92080>DROP TABLE test2;
Table dropped.
ORA92080>
ORA92080>CREATE TABLE test1
2 ( id     NUMBER NOT NULL
3 , date1     DATE NOT NULL
4 , date2     DATE
5 );
Table created.
ORA92080>
ORA92080>ALTER TABLE test1
2 ADD ( CONSTRAINT test1_chk_date1
3      CHECK ( date1 > TO_DATE( '01-JAN-1960', 'DD-MON-YYYY' ) )
4      );
Table altered.
ORA92080>
ORA92080>ALTER TABLE test1
2 ADD ( CONSTRAINT test1_chk_date2
3      CHECK ( date2 >= date1 )
4      );
Table altered.
ORA92080>
ORA92080>/* date2 is NULL */
ORA92080>INSERT INTO test1 VALUES ( 1, TO_DATE('16-JUN-2005 11:30:01', 'DD-MON-YYYY HH24:MI:SS'), NULL );
1 row created.
ORA92080>
ORA92080>/* date2 is filled in */
ORA92080>INSERT INTO test1 VALUES ( 2
2                     , TO_DATE('16-JUN-2005 11:30:01', 'DD-MON-YYYY HH24:MI:SS')
3                     , TO_DATE('16-JUN-2005 11:40:01', 'DD-MON-YYYY HH24:MI:SS')
4                );
1 row created.
ORA92080>
ORA92080>CREATE TABLE test2 AS
2 SELECT * FROM test1
3 WHERE 1=2;
Table created.
ORA92080>
ORA92080>ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
Session altered.
ORA92080>
ORA92080>SELECT * FROM test1;
ID DATE1 DATE2
1 16-JUN-2005 11:30:01
2 16-JUN-2005 11:30:01 16-JUN-2005 11:40:01
2 rows selected.
ORA92080>SELECT * FROM test2;
no rows selected
ORA92080>
ORA92080>/*
DOC>| Since no statistics were gathered, rule-based optimizer will be used.
DOC>| The correct count of two is returned.
DOC>*/
ORA92080>SELECT COUNT(*) FROM test1 t
2 WHERE EXISTS
3      ( SELECT 'X'
4      FROM ( SELECT id, date1
5                FROM test1
6           MINUS
7           SELECT id, date1
8                FROM test2
9           ) i
10      WHERE i.id = t.id
11           AND i.date1 = t.date1
12      );
COUNT(*)
2
1 row selected.
ORA92080>
ORA92080>EXPLAIN PLAN FOR
2 SELECT COUNT(*) FROM test1 t
3 WHERE EXISTS
4      ( SELECT 'X'
5      FROM ( SELECT id, date1
6                FROM test1
7           MINUS
8           SELECT id, date1
9                FROM test2
10           ) i
11      WHERE i.id = t.id
12           AND i.date1 = t.date1
13      );
Explained.
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | SORT AGGREGATE | | | | |
|* 2 | FILTER | | | | |
| 3 | TABLE ACCESS FULL | TEST1 | | | |
| 4 | VIEW | | | | |
| 5 | MINUS | | | | |
| 6 | SORT UNIQUE | | | | |
|* 7 | TABLE ACCESS FULL| TEST1 | | | |
| 8 | SORT UNIQUE | | | | |
|* 9 | TABLE ACCESS FULL| TEST2 | | | |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM ( (SELECT "TEST1"."ID"
"ID","TEST1"."DATE1" "DATE1" FROM "TEST1" "TEST1" WHERE
"TEST1"."DATE1"=:B1 AND "TEST1"."ID"=:B2)MINUS (SELECT "TEST2"."ID"
"ID","TEST2"."DATE1" "DATE1" FROM "TEST2" "TEST2" WHERE
"TEST2"."DATE1"=:B3 AND "TEST2"."ID"=:B4)) "I"))
7 - filter("TEST1"."DATE1"=:B1 AND "TEST1"."ID"=:B2)
9 - filter("TEST2"."DATE1"=:B1 AND "TEST2"."ID"=:B2)
Note: rule based optimization
28 rows selected.
ORA92080>
ORA92080>BEGIN
2 DBMS_STATS.GATHER_TABLE_STATS
3      ( ownname     => USER,
4      tabname     => 'TEST2',
5      estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
6      cascade     => TRUE
7      );
8 END;
9 /
PL/SQL procedure successfully completed.
ORA92080>
ORA92080>/*
DOC>| This is the identical query as above. With statistics gathered, the
DOC>| cost-based optimizer is used. An incorrect count of 1 is returned.
DOC>*/
ORA92080>SELECT COUNT(*) FROM test1 t
2 WHERE EXISTS
3      ( SELECT 'X'
4      FROM ( SELECT id, date1
5                FROM test1
6           MINUS
7           SELECT id, date1
8                FROM test2
9           ) i
10      WHERE i.id = t.id
11           AND i.date1 = t.date1
12      );
COUNT(*)
1
1 row selected.
ORA92080>
ORA92080>/* Using rule-based optimizer, the result is correct. */
ORA92080>SELECT /*+ RULE */ COUNT(*) FROM test1 t
2 WHERE EXISTS
3      ( SELECT 'X'
4      FROM ( SELECT id, date1
5                FROM test1
6           MINUS
7           SELECT id, date1
8                FROM test2
9           ) i
10      WHERE i.id = t.id
11           AND i.date1 = t.date1
12      );
COUNT(*)
2
1 row selected.
ORA92080>
ORA92080>EXPLAIN PLAN FOR
2 SELECT COUNT(*) FROM test1 t
3 WHERE EXISTS
4      ( SELECT 'X'
5      FROM ( SELECT id, date1
6                FROM test1
7           MINUS
8           SELECT id, date1
9                FROM test2
10           ) i
11      WHERE i.id = t.id
12           AND i.date1 = t.date1
13      );
Explained.
ORA92080>
ORA92080>SET ECHO OFF
Wrote file reset.sql
Session altered.
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 44 | 11 |
| 1 | SORT AGGREGATE | | 1 | 44 | |
|* 2 | HASH JOIN SEMI | | 1 | 44 | 11 |
| 3 | TABLE ACCESS FULL | TEST1 | 82 | 1804 | 2 |
| 4 | VIEW | | 1 | 22 | 8 |
| 5 | MINUS | | | | |
| 6 | SORT UNIQUE | | 1 | 31 | |
|* 7 | TABLE ACCESS FULL| TEST1 | 1 | 31 | 2 |
| 8 | SORT UNIQUE | | 1 | 22 | |
|* 9 | TABLE ACCESS FULL| TEST2 | 1 | 22 | 2 |
Predicate Information (identified by operation id):
2 - access("I"."ID"="T"."ID" AND "I"."DATE1"="T"."DATE1")
7 - filter("TEST1"."DATE1">TO_DATE(' 1960-01-01 00:00:00',
'syyyy-mm-dd hh24:mi:ss') AND "TEST1"."DATE2">TO_DATE(' 1960-01-01
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
9 - filter("TEST2"."DATE1">TO_DATE(' 1960-01-01 00:00:00',
'syyyy-mm-dd hh24:mi:ss'))
Note: cpu costing is off
27 rows selected.
ORA92080>/*
DOC>| Workaround: change the check constraint on the test1 table that is causing the problem.
DOC>*/
ORA92080>ALTER TABLE test1
2 DROP CONSTRAINT test1_chk_date2;
Table altered.
ORA92080>
ORA92080>ALTER TABLE test1
2 ADD ( CONSTRAINT test1_chk_date2
3      CHECK ( date2 >= date1 OR date2 IS NULL )
4      EXCEPTIONS INTO exceptions
5      );
Table altered.
ORA92080>
ORA92080>SELECT COUNT(*) FROM test1 t
2 WHERE EXISTS
3      ( SELECT 'X'
4      FROM ( SELECT id, date1
5                FROM test1
6           MINUS
7           SELECT id, date1
8                FROM test2
9           ) i
10      WHERE i.id = t.id
11           AND i.date1 = t.date1
12      );
COUNT(*)
2
1 row selected.
ORA92080>
ORA92080>EXPLAIN PLAN FOR
2 SELECT COUNT(*) FROM test1 t
3 WHERE EXISTS
4      ( SELECT 'X'
5      FROM ( SELECT id, date1
6                FROM test1
7           MINUS
8           SELECT id, date1
9                FROM test2
10           ) i
11      WHERE i.id = t.id
12           AND i.date1 = t.date1
13      );
Explained.
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 44 | 11 |
| 1 | SORT AGGREGATE | | 1 | 44 | |
|* 2 | HASH JOIN SEMI | | 1 | 44 | 11 |
| 3 | TABLE ACCESS FULL | TEST1 | 409 | 8998 | 2 |
| 4 | VIEW | | 20 | 440 | 8 |
| 5 | MINUS | | | | |
| 6 | SORT UNIQUE | | 20 | 440 | |
|* 7 | TABLE ACCESS FULL| TEST1 | 20 | 440 | 2 |
| 8 | SORT UNIQUE | | 1 | 22 | |
|* 9 | TABLE ACCESS FULL| TEST2 | 1 | 22 | 2 |
Predicate Information (identified by operation id):
2 - access("I"."ID"="T"."ID" AND "I"."DATE1"="T"."DATE1")
7 - filter("TEST1"."DATE1">TO_DATE(' 1960-01-01 00:00:00',
'syyyy-mm-dd hh24:mi:ss'))
9 - filter("TEST2"."DATE1">TO_DATE(' 1960-01-01 00:00:00',
'syyyy-mm-dd hh24:mi:ss'))
Note: cpu costing is off
26 rows selected.
ORA92080>

Answer 1

Justin,
Thanks for the reply. I have sent this test case to my DBA who may submit it to Metalink.
Since I have found and implemented a workaround, I can wait for the next service release. I just thought that this might be of interest to other Oracle users.
My work-around (buried near the end of my original post) was to modify all check constraints that fit the pattern:
( not_nullable_column condition IS TRUE )
AND ( nullable_column condition IS TRUE )
To:
( not_null_column condition IS TRUE )
AND ( nullable_column condition IS TRUE OR nullable_column IS NULL )
Redefining a check constraint in this way prevents it from being used in the optimizer's predicate.
If someone at Oracle Support wanted to submit code that identifies such potential problem constraints in the data dictionary, that would be great too.
- Doug