If it is the case of bind peeking, then it won’t be a good idea to change the CURSOR_SHARING parameter to EXACT as it may affect other queries as well ? So one should try to avoid using bind variables for that particular query (after being sure that it was actually due to bind peeking only) ? Do I make some sense ? ;)

Cheers !

That’s probably a classic issue of bind variable peeking where “wrong” bind variable values were used for initial hard parse of the statement. After you changed the parameter, a new cursor was hard parsed due this parameter change and now you got lucky and “right” bind variable values were seen when optimizing the cursor.

Believe it or not, on 1st November I had sent you a mail describing exact situation. A query on development database was running in few seconds, where as on the production database it was taking around 4 minutes to complete. Number of records were almost the same and the execution plan was showing the INDEX RANGE SCAN on both databases. I was really puzzled about this strange behavior. When I enable 10046 trace, I found that on the production database, it was doing a FTS, though the execution plan via dbms_xplan.display was showing the INDEX RANGE SCAN. However, when I use dbms_xplan.display_cursor to produce the execution plan, surprisingly it gave me FTS. The only change I found between these databases was the CURSOR_SHARING parameter. The development db was having EXACT value and the production db was having SIMILAR value. I had every little time to investigate further due to the tremendous pressure from the business guys, I changed the value on the production SIMILAR to EXACT and the query ran in few seconds as it was running on the development. I knew it could be definitely something to do with bind variable peeking.

If you want, I can resend you all the details if you could think it would help you to investigate further on this behavior.

Regards,

Jaffar