Using to_date causes CBO to use wrong index

Question

I'm working on switching an application from using the Rule-based optimizer to use the Cost-based Optimizer on Oracle 9iR2. I'm having problems with the following query:
select report_rsn, reports.facility_code,
       exams.facility_code
  from exams join reports using (report_rsn)
where reports.transcribed_date
        between to_date('17-Mar-2005')
            and to_date('18-Mar-2005')
   and exams.dictated_for_rsn = 3323
   and exams.status IN ('S','T')There is an index on the reports.transcribed_date column and a compound index on (exams.dictated_for_rsn,exams.status).
EXPLAIN PLAN tells me this query will use the transcribed_date as the driving index, but when I run the query through SQL_TRACE, tkprof says that it used the other index instead. That took a long time. (90 seconds)
If I change the to_date() functions to be ANSI date literals (DATE '2005-03-17' and DATE '2005-03-18'), EXPLAIN PLAN says the same as before, and tkprof says that it actually used that plan. The query returned almost instantly.
We have CURSOR_SHARING set to 'SIMILAR', and my best guess is that there is something involving the "bind parameter peeking" that is causing the problem. It appears as if the optimizer does not evaluate the to_date() function between "peeking" at the bind variable and determining the execution plan, so it does not know that the two dates are only a day apart. However, I haven't been able to find anything in the docs to confirm my suspicions.
I've done a search for queries in our system that use the to_date() function as part of the where clause, and it doesn't look like a Herculean task to simply change them all, but I'm wondering two things:
1) Is there a better way to solve the problem?
2) Is there any information on this behavior out there that I can read to verify my suspicions? This might be the most important, because in order to finalize the switch to CBO, I need to be able to tell my supervisor that "this sort of thing" won't happen on our production box.
-- Jeff Beal

Answer 1

Jeff,
Could you post your plan under both scenarios? WhatHere are the relevant* (different) portions of the execution plan (as given by TKPROF):
* I actually ran TKProf against a much larger query, but the controlling part is the query that I included.
When using DATE literal:
Rows     Row Source Operation
      0               NESTED LOOPS 
      0                TABLE ACCESS BY INDEX ROWID REPORTS
      6                 INDEX RANGE SCAN IX_REPORTS_TRDATE (object id 109215)
      0                TABLE ACCESS BY INDEX ROWID EXAMS
      0                 INDEX RANGE SCAN IX_FK_EXAMS_11 (object id 96878)When using to_date function
Rows     Row Source Operation
  46517                NESTED LOOPS 
  46517                 INLIST ITERATOR 
  46517                  TABLE ACCESS BY INDEX ROWID EXAMS
  46517                   INDEX RANGE SCAN IX_FK_EXAMS_4 (object id 139880)
      0                 TABLE ACCESS BY INDEX ROWID REPORTS
  46517                   INDEX UNIQUE SCAN PK_REPORTS (object id 109164)
are the indexes on the tables and on what columns are
they present?'ix_fk_exams_4' is a compound index on the exams table.  The first column is 'dictated_for_rsn' and the second is 'status'.  'pk_reports' is an index on reports.report_rsn - the primary key of the table.  'ix_reports_trdate' is on the reports.transcribed_date column.  'ix_fk_exams_11' is on exams.report_rsn (the foreign key to the reports table).
Just to give you an idea on size, the exams table has about six million rows; the reports table has about 5.5 million.  I would categorize the transcribed_date column as evenly distributed, along with the values in dictated_for_rsn.  The status column is heavily skewed, with 'T' and 'S' being the two most common statuses.