When I was in Oracle support (years ago), my favorite Oracle error to resolve was ORA-600. Since I was taught Oracle internals, ORA-600 errors were challenging to me. During those days in support, I enjoyed reading file dumps, trace files and debugging. Ok, I admit, I am weird.

An ORA-600 error is not necessarily an Oracle bug. When an internal inconsistency is encountered or some unexpected condition is met, the kernel code of Oracle raises an ORA-600 error. Conditions that can cause ORA-600 other than an Oracle bug are hardware failures, problems with the operating system, not enough resources, to name a few.

The ORA-600 error has a list of arguments that are enclosed in square brackets.

An example of an ORA-600 error from Version 7 looks like:
ORA-600 [3398] [603992043], [603992043], [1], [50], [16150], [548]

The key information in identifying the problem is in the first argument. The first argument tells where in the Oracle code the error was caught. The other remaining arguments give the other related information. Hence, in our ORA-600 example, which is a Block Corruption in Memory, the remaining arguments provide supporting information related to the data block address (DBA).

A trace file is generated whenever an ORA-600 error occurs. The trace file contains important information on what led to the error condition. The trace file is generated in the USER_DUMP_DEST or BACKGROUND_DUMP_DEST. The error is also written in the alert log along with the name of the trace file.

Oracle Metalink provides more information on ORA-600. If after searching Metalink you still cannot identify the cause and possible fix for an ORA-600 error, give Oracle support a call. Make sure you are thorough on reporting your problem, including any recent changes to the system environment, e.g. upgrades, power failures, etc. It will facilitate in resolving your ORA-600.