...the same thing occur if you run statspack level 6 or higher on
10gR2/Linux...the workaround is to set as Wolfgang said
_cursor_plan_unparse_enabled = false for the session but in this case the
*_predicates info is not collected...
On 3/16/07, Wolfgang Breitling <breitliw_at_centrexcc.com> wrote:
>
> 10gR2 if I'm not mistaken. A client encountered the ora-600 errors on
> a 10.1.0.5 system. Interestingly enough not on their 9.2.0.7 system.
> It probably depends on the complexity of the sql whether you hit the
> bug or not.
>
> They were given a workaround: set _cursor_plan_unparse_enabled =
> false. As far as I recall, Could also be _cursor_plan_enabled = false;
>
> At 11:10 AM 3/16/2007, Alberto Dell'Era wrote:
> >On 3/16/07, Ankur Godambe <agodambe_at_ketera.com> wrote:
> >>changes. I hit this bug#4434689 with 9.2.0.7 where selects on v$sql_plan
> >>failes with ora-600 [504].
> >
> >I haven't found the bug on Metalink; if the bug is similar to 2525630,
> >you can avoid the ORA-600 by not selecting access_predicates
> >and filter_predicates. These informations are lost, but at least you have
> >the rest of the plans.
> >
> >The bug is solved in 10g.
>
>
>
>
> Regards
>
> Wolfgang Breitling
> Centrex Consulting Corporation
> www.centrexcc.com
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Mar 27 2007 - 06:25:16 CDT
