This content has been marked as final. Show 4 replies
I'm not the administrator of the database, therefore i may not change any settings.you should ask DBA to take a look or you may check this error in Metalink (MOS) "ORA-600/ORA-7445 Error Look-up Tool [ID *153788.1*] "
As Ora-0600 is internal oracle error and you need to involve oracle support on this by raise SR.
An ORA-0600 is an unhandled exception in the Oracle kernel. Often means that some kind of unexpected condition has been encountered and Oracle does not know how to deal with it. Could be due to a bug.
On Metalink (now called My Oracle Support/support.oracle.com), note +Troubleshoot an ORA-600 or ORA-7445 Error Using the Error Lookup Tool [ID: 153788.1]+ can be used to troubleshoot an ORA-0600 crash.
It however does not turn up anything for module kkbnftn2 for 126.96.36.199.
A general search turned up an error/bug with module kkbnftn2 failing when dropping an object. From that bug, my guess is that your table could contain object columns of a child/sub class of ObjectClass that has been modified (or forcibly dropped), without cascading the change.
This would result in the object column containing an invalid object value - and when attempting to delete that row, Oracle fails as that row has a messed up object column.
But this is just a shot in the dark speculation.
The correct approach for an ORA-600 is usually to file a SR (Service Request) with Oracle Support to investigate the crash and advise you on what the fix/workaround/patch is.
You can however attempt to isolate this ORA-600 error. If it fails for a specific row, can you successfully select and display that row? What happens when you use a CTAS (Create Table As Select) to pull out that row into a brand new table and attempt to delete it from that table? If you first set that row's object column to null, can it then be deleted? Are any properties of that object column used elsewhere (e.g. as an index or constraint)? Etc.
But Oracle Support would be the best option to get this problem resolved.
Thank you both,
i already tried to look up this ORA-600, but as Billy mentioned, there's nothing to be found.
Setting the object field to null doesn't help either, i tried this yesterday, after i came up with the mentioned work around.
Maybe there's some corrupt data or object, i will have a look in this and come back in case i find something usefull.
Thank you for now :)
i found the following:
I create a super class similar to JAVAs Object class.
I use a table with an object type column using the super class, so it can hold any of it's subtypes.
Testrun starts here - Run 1 (The table and super class are always present and are not dropped before the run)
I start a new test run - Run 2 (The table and super class are always present and are not dropped before the run)
I create subtypes of the object type used to define the column. I insert instances of the subtypes into the table, including additional data like an id a.s.o. I delete the rows during a procedure run, so the table is empty. // At this point deleting the rows is no problem. I drop the created subtypes after the test run using the validate option, making sure there are no left over dependencies.
So it looks like oracle is keeping information about the subtypes in the table, even if there
I create subtypes of the object type used to define the column. I insert instances of the subtypes into the table, including additional data like an id a.s.o. I try to delete the rows during a procedure run again. // At this point i receive the ora-600.
are no instances of them stored anymore and the subtypes don't exist anymore. And somehow these
kept information don't cause any dependencies.
if i change Run 2 the following way, it works again. (The table and super class are always present and are not dropped before the run)
I solved this with a workaround using an xmltype column instead of the object type column and
I create subtypes of the object type used to define the column. I insert instances of the subtypes into the table, including additional data like an id a.s.o. I commit everything (again, since the PL/SQL-block ended successfully which usually causes an automatic commit) I try to delete the rows by hand. // now all rows are deleted again
updated my "put" and "get" routines to put xmltype (which is a walk in a park) and to retrieve the
correct instance (which needs a little piece of dynamic sql - and is based on Billy's getClassName function posted in another thread).
So i have now a nice workaround which by the way decouples the package and the table i use from the object types and
"accidently" provides the functionality of having a serialized version (xmltype.getClobVal) of the object on hand.
And finally my little object framwork is up and running, so i can handle objects in PL/SQL nearly the same way i can in Java :)