Yes, 10gR2 more likely - I haven't really worked in 10gR1, only 10GR2, and there I don't remember hitting the bug. I think it's more related to the cursor being invalidated or not, I remember noticing that systems with a lot of reloads hit the bug more often - it's probably a dangling pointer to the memory structure that holds access_predicates and filter_predicates. I remember also that not full-scanning v$sql_plan, but fetching only the "plan rows" you are interested into, seemed to reduce the frequency of the ORA-600. Just some intuitions I had, I haven't really tried to pinpoint the bug precisely - that is the work of Support. On 3/16/07, Wolfgang Breitling <breitliw@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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 ______________________________________________________________________
-- Alberto Dell'Era "Per aspera ad astra" -- //www.freelists.org/webpage/oracle-l