ORA-0600错误表示Oracle本身存在内部错误。你很可能碰到了Oracle的一个bug。
如果您转到http://metalink.oracle.com，您可以通过将“参数”和完整的堆栈跟踪粘贴到ORA-0600查找工具中来查找确切的bug（如果已知）。参见metalink注解153788.1。
如果存在具有该描述的已知错误，则很可能已经有可用的修补程序供您下载和安装。如果这不是已知的错误，请联系支持部门。

什么是完整查询？
http://www.orafaq.com/wiki/ORA-00600建议您向oracle报告错误。

祝你好运，获得Oracle的支持。
不过说真的，每次遇到这个问题时，稍微重新安排一下查询通常会有所帮助。也许还在索引上乱翻了一下。

ORA-00600基本上意味着你已经崩溃了oracle服务器（不是示例，只是服务于你的请求的服务器）。
在您的bdump位置中几乎总是会有一个跟踪文件。这可能不会对您有很大的帮助，但对Oracle的支持非常有帮助。
这通常是由Oracle错误引起的，根据经验，除了通过metalink引发SR（这是Oracle推荐的解决方案）之外，您对此没有太多可以做的事情。他们将尝试复制这个问题，如果运气好的话，如果它是一个错误，它最终会找到一个补丁。
在短期内（例如，几天-几个月），主要的现实解决方案是围绕它的工作.
虽然提高SR并不能真正帮助你，而且可能是一个令人沮丧的经历，但它值得做，因为一旦bug被修复，它可能会保存其他人的时间。

这些bug通常与优化器有关。我认为，即使是查询中最小的更改，例如在FROM子句中切换table1和table2的顺序，也可能迫使优化器选择一个不会遇到此错误的不同计划。

我的解决方案：
问题

这不工作是得到错误[0600]

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 1904054272 bytes
Fixed Size                  2404024 bytes
Variable Size             570425672 bytes
Database Buffers         1325400064 bytes
Redo Buffers                5824512 bytes
Database mounted.
SQL> recover database
Media recovery complete.
SQL> alter database open
  2
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[108], [615], [655], [], [], [], [], [], [], []`

以下是我对这个问题的解决方案：

SQL> Startup mount
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> shutdown abort
ORACLE instance shut down.
SQL>
SQL> startup mount
ORACLE instance started.

Total System Global Area 1904054272 bytes
Fixed Size                  2404024 bytes
Variable Size             570425672 bytes
Database Buffers         1325400064 bytes
Redo Buffers                5824512 bytes
Database mounted.
SQL> Show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      C:\APP\USER\ORADATA\ORACLEDB\C
                                                 ONTROL01.CTL, C:\APP\USER\FAST
                                                 _RECOVERY_AREA\ORACLEDB\CONTRO
                                                 L02.CTL
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT'
  2
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT';

MEMBER
--------------------------------------------------------------------------------

    GROUP# STATUS
---------- ----------------
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
         3 CURRENT

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 1904054272 bytes
Fixed Size                  2404024 bytes
Variable Size             570425672 bytes
Database Buffers         1325400064 bytes
Redo Buffers                5824512 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 4234808 generated at 01/21/2014 18:31:05 needed for thread 1
ORA-00289: suggestion :
C:\APP\USER\FAST_RECOVERY_AREA\ORACLEDB\ARCHIVELOG\2014_01_22\O1_MF_1_108_%U_.AR

C
ORA-00280: change 4234808 for thread 1 is in sequence #108

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;

Database altered.

终于成功了：

ORA-00600通常意味着有一些非常意外的事情，它可能与数据库损坏有关。症状可能是查询是否有效，这取决于它是如何制定的。

生活示例：

• LOB字段更新对id=的特定行出错
• 使用SELECT * FROM时该行不可见
• 但是：SELECT * FROM WHERE id=无法执行，并给出ORA-006000。
  （可能）用于上述示例的解决方案
• 导出所有可访问的表内容
• 删除表
• 重新导入内容

祝你好运！**

我曾经在使用PL/SQL Developer时，在表中有XMLTYPE列时看到过类似的错误。如果我让PL/SQL Developer为我创建查询框架，这就不会发生，因为它会向XMLTYPE列请求添加一些语法，我不记得具体是什么。

我在涉及USER_TAB_COLS的记录类型的情况下遇到了这种情况。对于记录中应该保存USER_TAB_COLS. DATA_DEFAULT的字段，我使用了VARCHAR2（128）。好吧，不管出于什么原因，这是一个LONG，当我在命令窗口（PL/SQL Developer）中运行代码时，这个Map工作正常，但当我在执行各种任务的伞形脚本中嵌入相同的代码时，它失败了。一旦我将记录的数据类型正确设置为使用锚定类型（USER_TAB_COLS. DATA_DEFAULT %TYPE）而不是VARCHAR2（128），执行此工作的sp将在任一上下文中运行。我被它“独立”工作的事实所迷惑，但当从另一个脚本调用时却不能。
下面是我使用的记录类型：

TYPE PON_DICT_RECORD_TYPE Is RECORD(
    TABLE_NAME USER_TAB_COLS.TABLE_NAME%TYPE,
    PK         NUMBER(1),
    REQUIRED   NUMBER(1),
    COL_ORDER  NUMBER(3),
    COL_NAME   USER_TAB_COLS.COLUMN_NAME%TYPE,
    DATA_TYPE  USER_TAB_COLS.DATA_TYPE%TYPE,
    LENGTH     NUMBER(4),
    SCALE      NUMBER(2),
    DEF_VALUE  USER_TAB_COLS.data_default%TYPE, -- a LONG in U T C
    ID         NUMBER(1),
    FORCE_DEF  NUMBER(1),
    ACTIVE_PK NUMBER(1),
    NEW_COL_OLD_TABLE NUMBER(1),
    REPLACEMENT_KEY NUMBER(1)
    );

  TYPE PON_DICT_TABLE_TYPE IS TABLE OF PON_DICT_RECORD_TYPE;

  pdtab PON_DICT_TABLE_TYPE;

您可以在其中看到字段DEF_VALUE的定义现在是一个锚定类型。
这是奇怪的，我不得不说。我本以为它在这两种情况下都会失败。