SQL trace changes explain plan

[fraze]

I've got a select query that is taking 20 secs when it should take under 1 sec. I've done some tracing etc and have noticed that when I put a trace on the query it chooses a different (and correct) plan than when there's no tracing. Can anyone help me understand why!?

9204 Oracle on Solaris:

SQL> variable b1 varchar2(20)
SQL> exec :b1 := 'ABC';

PL/SQL procedure successfully completed.

SQL> @sel

  COUNT(*)
----------
         0

Elapsed: 00:00:20.93

SQL>  alter session set events '10046 trace name context forever, level 12';

Session altered.

Elapsed: 00:00:00.00
SQL> @sel

  COUNT(*)
----------
         0

Elapsed: 00:00:00.57
SQL> alter session set events '10046 trace name context off';

Session altered.

Elapsed: 00:00:00.01
SQL> @sel

  COUNT(*)
----------
         0

Elapsed: 00:00:20.76
SQL> alter session set sql_trace=true;

Session altered.

Elapsed: 00:00:00.00
SQL> @sel

  COUNT(*)
----------
         0

Elapsed: 00:00:00.54
SQL> alter session set sql_trace=false;

Session altered.

Elapsed: 00:00:00.01
SQL> @sel

  COUNT(*)
----------
         0

Elapsed: 00:00:20.83

[fraze]

I think I'm a victim of bind variable peeking here. I've flushed the shared pool and hard parsed the query with a selective bind variable and it now uses the correct plan.
I'm still confused as to why the trace ignored the sub-optimal plan and came up with the optimal plan though. Could it be that a trace forces a hard parse?

[fraze]

Should have thought about the last question before I posted it! The trace doesnt force a hard parse - checked the tkprof and there was no librabry cache miss for when the trace was put on:

Misses in library cache during parse: 0

Still confused as to why the trace forced the query to use the optimal plan though?