RE: 10053 trace for sql fired from pl/sql (stored code)

I'm not sure I understand your reasoning there. Not sure why you find stored outlines to \ be so costly/difficult - they're actually pretty simple and effective. Also not sure what \ either solution has to do with having to identify all the problematic SQL - that is \ something you should do regardless of how you decide tune/stabilize them. If your goal is \ stability, then why are you concerned about the plan being able to change with a stats \ update - seems like you'd want to test that in a test environment first and then update \ your stored outline if appropriate.

Regards,
Brandon

-----Original Message-----

From: Boris Dali [mailto:boris_dali_at_yahoo.ca] Sent: Wednesday, December 28, 2005 10:13 AM To: Allen, Brandon; tanel.poder.003_at_mail.ee; ORACLE-L Subject: RE: 10053 trace for sql fired from pl/sql (stored code)

Brandon,

It is an option of course, but more like a last resort really. If there's a much cheaper alternative . . .

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 Received on Wed Dec 28 2005 - 18:25:27 CST