RE: Any way to invalidate/flush a single cursor

Another option (not tested, no test db at hand here at the CT site), might be using dbms_advanced_rewrite.

I think you can rewrite the statement at hand into one that includes the aforementioned fake object. Altering that object will invalidate the cursor then.

You will find an example of using this at asktom:

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:3696883368520

(concatenate the link)

Allen, you were involved in the thread yourself as well ;-)

Regards, Carel-Jan

===
If you think education is expensive, try ignorance. (Derek Bok) ===

> One option is to create view as select * from table and write your test
> query against this view.
> Then verify that you get the same execution plan against this view as
> against the table directly.
>
> Then just recompile that view when you want to invalidate your cursor.
>
> Btw, if you want to invalidate all cursors dependent on a table you could
> just add a comment to the table rather than reanalyzing it.
>
> There's one more way to selectively force hard parsing on already cached
> cursors, but I'd like to document this in a paper along its implications
> before publishing it..
>
> Tanel.
>
>
> _____
>
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Allen, Brandon
> Sent: Tuesday, August 22, 2006 05:30
> To: ORACLE-L
> Subject: Any way to invalidate/flush a single cursor
>
>
> Does anyone know of a way to invalidate or completely flush a single
> cursor?
>
> I'm doing some performance testing of queries that are having trouble with
> bind variable peeking and sharing plans between executions with
> drastically
> different bind values, so I need to invalidate the cursor in between
> executions in order to test the explain plans of different bind variables.
> Is there any more focused approach than gathering stats or issuing grants
> on
> one of the query's tables? That works, but of course invalidates all
> other
> queries referencing the table.
>
> Thanks,
> Brandon
> Privileged/Confidential Information may be contained in this message or
> attachments hereto. Please advise immediately if you or your employer do
> not
> consent to Internet email for messages of this kind. Opinions, conclusions
> and other information in this message that do not relate to the official
> business of this company shall be understood as neither given nor endorsed
> by it.
>
>

--
http://www.freelists.org/webpage/oracle-l