I’ve been thinking about this a lot since I have a situation where a report generator spits out sql that causes the db to create a view and doesn’t push predicates up into the view, leading to full table scans within nested loops. So adding the really obvious index has no effect. Every time I run into this kind of thing I slap my forehead, it’s going to be a lot of work one way or another, can’t just hack some hints. The thought of an outlines solution gives me nightmares like comment #8 on http://jonathanlewis.wordpress.com/2008/02/17/pushing-predicates-2/ . Wondering why this doesn’t happen on similar processes leads me to discover it does, just no one has complained yet, users leave orphaned processes running, thinking they’ve canceled them.

If it were just me, no one would care. But I’m pretty sure I’m not the only one working on enterprise software with these kinds of issues.

CREATE INDEX TAB1_IX1 ON TAB1(N1);
CREATE INDEX TAB2_IX1 ON TAB2(N1);

thanks

Your answer is better than the one that I had in mind. The next line after your first quote of the documentation reference explains why the conversion is performed in only one direction: CHARACTER–>NUMBER. Here is an example:

CREATE TABLE T3(
  CHAR_COL VARCHAR2(10),
  C2 VARCHAR2(100),
  PRIMARY KEY (CHAR_COL));
 
INSERT INTO T3 VALUES('1','A');
INSERT INTO T3 VALUES('1.0','A');
INSERT INTO T3 VALUES('1.00','A');
INSERT INTO T3 VALUES('1.000','A');
INSERT INTO T3 VALUES('1.0000','A');
INSERT INTO T3 VALUES('1.00000','A');
INSERT INTO T3 VALUES('1.000000','A');
INSERT INTO T3 VALUES('1.0000000','A');
INSERT INTO T3 VALUES('1.00000000','A');
 
COMMIT;

Now consider the following – should all three queries return the same set of rows:

SELECT
  *
FROM
  T3
WHERE
  CHAR_COL=1;
 
CHAR_COL   C2
---------- -----
1          A
1.0        A
1.00       A
1.000      A
1.0000     A
1.00000    A
1.000000   A
1.0000000  A
1.00000000 A
 
9 rows selected.
 
---
 
SELECT
  *
FROM
  T3
WHERE
  TO_NUMBER(CHAR_COL)=1;
 
CHAR_COL   C2
---------- -----
1          A
1.0        A
1.00       A
1.000      A
1.0000     A
1.00000    A
1.000000   A
1.0000000  A
1.00000000 A
 
9 rows selected.
 
---
 
SELECT
  *
FROM
  T3
WHERE
  CHAR_COL=TO_CHAR(1);
 
CHAR_COL   C2
---------- -----
1          A

If the number was automatically converted by Oracle into a character value, it might need to test a nearly infinite number of 0 characters appended to the end of the converted value after the decimal point (up to the number of characters of precision) for a matching result – this is avoided by converting the character value to a number.

I did not have that exact answer in mind until I saw the documentation reference that you provided.

If I had to wager a guess I would say this is due to the implicit data conversion rules outlined in the SQL Reference Manual (11.1):

http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements002.htm#i163326

It states:

“When comparing a character value with a numeric value, Oracle converts the character data to a numeric value.”

In the first case since the column, CHAR_COL is a VARCHAR2 type and it is being compared to a constant of the NUMBER data type Oracle converts the column value to a NUMBER. This is also seen in the Predicate Information section.

In the second case the column value is a NUMBER data type and it is being compared to a constant of the VARCHAR2 data type. Therefore the constant is then converted to a NUMBER, leaving the NUM_COL unaffected from data type conversion.

Interestingly enough Oracle also states the following in the SQL Reference Manual:

“Algorithms for implicit conversion are subject to change across software releases and among Oracle products. Behavior of explicit conversions is more predictable.”

Good point.

Immediately after I saw your post I realized that the statement to which you replied in my comment (Fun bonus question) could be read two different ways. After seeing your post I replaced “and” with “, but instead” so that I could clarify that I was seeking the reason why the two cases were treated differently, rather than suggesting that they were both the same because they both had a similar problem (apples to oranges comparison – an implicit data type conversion as you correctly stated). I am sorry if this change caused confusion.

The link to the 10053 trace file now works if someone would like to take a peek.

I had not seen the answer on the clustering factor of Taral

thanks

A portion of your post between “WHERE ROWNUM” and “SELECT * FROM TAB1 WHERE N1 = 100;” disappeared when you posted it. I tried to recreate/fix that section of your post. Thank you for posting a test case for the data distribution possibility.

I believe that this test case is also suitable for Taral’s “Clustering Factor” answer.

1) usage hint NO_INDEX

2) modification parameter OPTIMIZER_INDEX_COST_ADJ

3) Data Distribution

CREATE TABLE TAB1 AS
SELECT TO_CHAR(ROWNUM) AS C1 
     , trunc((ROWNUM-1) / 10) N1
     , rownum * 10 N2
     , ROWNUM      N3
     , sysdate     d1 
FROM ALL_OBJECTS
WHERE ROWNUM <= 10000;


CREATE TABLE TAB2 AS
SELECT TO_CHAR(ROWNUM) AS C1 
     , MOD(ROWNUM, 1000) N1
     , rownum * 10 N2
     , ROWNUM      N3
     , sysdate     d1 
FROM ALL_OBJECTS
WHERE ROWNUM <= 10000;
 
CREATE INDEX TAB1_IX1 ON TAB1(N1);
CREATE INDEX TAB2_IX1 ON TAB2(N1);

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER, TABNAME=>'TAB1', CASCADE=>TRUE)
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER, TABNAME=>'TAB2', CASCADE=>TRUE)

SELECT * FROM TAB1 WHERE N1 = 100;



-----------------------------------------------------------------------------
| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |          |    10 |   260 |     2   (0)|
|   1 |  TABLE ACCESS BY INDEX ROWID| TAB1     |    10 |   260 |     2   (0)|
|   2 |   INDEX RANGE SCAN          | TAB1_IX1 |    10 |       |     1   (0)|
-----------------------------------------------------------------------------


SQL> SELECT * FROM TAB2 WHERE N1 = 100;


---------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    10 |   260 |    10   (0)|
|   1 |  TABLE ACCESS FULL| TAB2 |    10 |   260 |    10   (0)|
---------------------------------------------------------------

I saw Tom Kyte at OOW last year do a presentation on the importance of metadata. One of his examples showed why it is important to store numbers as number data type, dates as date data type and strings as varchar2 data type. And how not doing so really messes up the CBO.

CREATE TABLE T1 (
  CHAR_COL VARCHAR2(10),
  C2 VARCHAR2(100),
  PRIMARY KEY (CHAR_COL));
 
INSERT INTO
  T1
SELECT
  TO_CHAR(ROWNUM),
  RPAD('A',100,'A')
FROM
  DUAL
CONNECT BY
  LEVEL <=1000000;
 
COMMIT;
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T1',CASCADE=>TRUE)
 
SET AUTOTRACE TRACEONLY EXPLAIN
 
SELECT
  *
FROM
  T1
WHERE
  CHAR_COL = 10;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |   107 |  4416   (1)| 00:00:53 |
|*  1 |  TABLE ACCESS FULL| T1   |     1 |   107 |  4416   (1)| 00:00:53 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(TO_NUMBER("CHAR_COL")=10)

Notice the cost in the above is 4,416 with a predicted time of 53 seconds. Now look what happens when the access path is hinted (force, if possible) to use an index access path:

 
SELECT /*+ INDEX(T1) */
  *
FROM
  T1
WHERE
  CHAR_COL = 10;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 2890641821
 
--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |     1 |   107 |  3930   (1)| 00:00:48 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1           |     1 |   107 |  3930   (1)| 00:00:48 |
|*  2 |   INDEX FULL SCAN           | SYS_C0030633 |     1 |       |  3929   (1)| 00:00:48 |
--------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter(TO_NUMBER("CHAR_COL")=10)

A lower calculated cost and a lower calculated execution time. Must be that…

The optimizer parameters, for the most part, are the Oracle Database defaults:

SET AUTOTRACE OFF
SHOW PARAMETER OPTIMIZER
  
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.1.0.7
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE

(10053 trace file for test case OR11_ora_4400_WhyFullTableScanTest.trc edit: link to the trace file is fixed)
—-

Let’s try one more test. This time we will define a column as NUMBER and try essentially the same test, just with a WHERE clause with a string (VARCHAR2) specified as a predicate in the WHERE clause:

CREATE TABLE T2 (
  NUM_COL NUMBER,
  C2 VARCHAR2(100),
  PRIMARY KEY (NUM_COL));

INSERT INTO
  T2
SELECT
  ROWNUM,
  RPAD('A',100,'A')
FROM
  DUAL
CONNECT BY
  LEVEL <=1000000;

COMMIT;

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE)

SET AUTOTRACE TRACEONLY EXPLAIN

SELECT
  *
FROM
  T2
WHERE
  NUM_COL = '10';
 
Execution Plan
----------------------------------------------------------
Plan hash value: 621649307

--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |     1 |   105 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2           |     1 |   105 |     3   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | SYS_C0030634 |     1 |       |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("NUM_COL"=10)

Fun bonus question. Why is there an implicit datatype conversion of the table’s column in the first test case (table T1), but instead an implicit datatype conversion of the constant in the second test case (table T2).