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@xxxxxxxx]
Sent: Wednesday, December 28, 2005 10:13 AM
To: Allen, Brandon; tanel.poder.003@xxxxxxx; 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

Other related posts: