ORA-00600: internal error code, arguments: [kole_t2u], [34], [],

巡检中，发现有以下告警：
Thu Jun  3 07:37:01 2015
Errors in file /opt/oracle/admin/crmdb/udump/crmdb1_ora_2941248.trc:
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []
Thu Jun  3 07:37:01 2015
Errors in file /opt/oracle/admin/crmdb/udump/crmdb1_ora_2458222.trc:
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []

查阅了下MOS，有可能是某些错误导致，或者是系统的BUG。这里也没说明白，就大致的把文档理解了一些，以下是对MOS文档 ID 734474.1的笔记，希望对该报错的理解有用

Example 1:ORA-600 [kole_t2u], [34] raised in a database with AL32UTF8 character set:

SQL> create table t(a clob);
Table created.

SQL> insert into t values(utl_raw.cast_to_varchar2('EC'));
insert into t values(utl_raw.cast_to_varchar2('EC'))
            *
ERROR at line 1:
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []

什么原因呢？这是由于在AL32UTF8字符集，字符'EC'不代表字符本身的值，而Oracle数据库需要更多的数据字节，因此抛出错误，表示此代码点不完整。

Example 2: ORA-29275 error in a database with a AL32UTF8 character set:
SQL> create table t2(a varchar2(10));
Table created.

SQL> insert into t2 values(utl_raw.cast_to_varchar2('EC'));
1 row created.

SQL> select * from t2;
ERROR:
ORA-29275: partial multibyte character

此过程和上面的差不多，不过这时候使用的是varchar2()类型。注意，在这种情况下，数据被允许存储在数据库中的第一个地方，因为它不通过这种方式插入的检查字符集的规则。与不完全编码点的问题，当被选择的数据只注意到了，然后将引发错误。

什么是不完整的代码点和部分多字节字符？
在多字节字符集，数据库知道有多少字节需要形成一个完整的字符（也叫完整的代码点）。这取决于第一字节的代码点的值，这样数据库就知道需要有多少的字节。如果有剩下的字符串中较少的字节，那么数据库知道有存储格式不正确的代码点，而且可以提高或者ORA-29275或ORA-600[kole_t2u]，[34]。

总的来说，会有以下三种情况导致：

Cause type-1: Invalid multibyte data being inserted into a CLOB
这种错误是比较简单的，可以很快就发现，因为他视图提供一个直接结果，而把错误的类型加到CLOB。前面的第一个例子，就是这种类型。
解决方法就是，匹配正确的参数值

Cause type-2: Invalid multibyte data copied from VARCHAR2 into CLOB
这种类型的问题往往看起来像一个BUG，但在实际上涉及到了未完成代码点已经被用在数据库中的事实。上述的例子2展示出了这些数据可能被插入到一个VARCHAR2里。如果该数据随后被转移到一个CLOB列，那么这个错误就会抛出。
检查这种数据的相对简单的方法是从VARCHAR2列，在这种情况下ORA-29275错误可以看出。然而，可能有些数据开始的时候被试图被装入CLOB，而之前在应用程序或在PL / SQL里，那么处理这种就比较复杂。如果该处理会导致不完全的编码点出现那么我们也将看到ORA-600[kole_t2u]，[34]。
当然，Oracle也认为有可能是个BUG，如下：
Known related bugs
Bug 4562807 - Fixed in 10.2.0.4 patchset and 11.1 and higher base release.
This bug addresses a ORA-600 [kole_t2u], [34] when using Oracle Text. Before this 'bug' was addressed, this ORA-600 was raised during gisting of a document with invalid multibyte characters. As a result of this fix, rather than raising this ORA-600 and crashing, the gisting of a document with invalid multibyte characters now ends with error 11432: "gisted document contains invalid characters". Individual patches for some platforms are available on top of 10.2.0.2 and 10.2.0.3.
Note therefore that as a final resolution it is still needed to address the fact that these invalid characters are used in the document that is being gisted.
Bug 10334711 - Fixed in 11.2.0.3 patchset and 12.1 base release.
In bug an update statement can encounter ORA-600 [kole_t2u] when database auditing is set to DB_EXTENDED. This feature captures the bind data which is written in a CLOB column of size 4000, and the audited data is cut off at 4000 bytes. Due to this bug, if a multibyte character starts at the 4000th byte, the data gets truncated after the first byte of this character. This leaves an incomplete character, resulting in ORA-600 [kole_t2u]. With the fix the data is truncated before the last incomplete character starts. Individual patches for various platforms and releases exist, and further are available on request

Cause type-3: Incorrect CLOB splits
这种类型的问题是最难查看出，通常在此之前需要大量的调试，才能发现该类型。通常最好要经过已知问题列表和应用任何已知的补丁程序，以排除任何已知的问题。
这种类型的错误的背景来自以下事实CLOB数据有时被分成一定长度的数据的更可管理的块。它这种分裂是一定数量的字节的后制成（例如1000，或4000，等等等等），那么它可能发生的分裂发生在多字节编码点的中间。这随后离开前一个块具有一个不完整的编码点处的数据的末尾，并且可以预期该错误。如果发生这种类型的问题，因此有由于被分裂成块的方式CLOB数据的一个错误。而不是使基于它应始终以饱满的字符做字节的分裂
同上，这也被认为可能是个系统BUG
Known bugs
Bug 10399808 (fixed in 11.2.0.3 and 12.1) & Bug 6407486 (fixed in 10.2.0.5 and 11.2)
When appending data to lob in a loop, incorrect data splits can occur when the internal source buffer does not end on a character boundary. When you are indeed appending data to a lob and hit this error, then these bugs can be suspected. Note that bug 6407486 first attempted to address this issue, but in order to fully resolve this a fix for bug 10399808 is required. This fix is included in the 11.2.0.3 Patchset and in PSUs 11.2.0.2.4 and 11.1.0.7.8 (and higher). Also various one off fixes for this bug are available.
Bug 5017909 - fixed in 10.2.0.4 (and higher 10.2 patchsets) and 11.1 (and higher)
Due to a bug in the "cut" in the data as described above, this bug can cause v$sqlarea.sql_fulltext and v$sql.sql_fulltext to contain sql statements in which invalid multibyte codepoints are used. These can subsequently lead to a variety of issues, like:
SQL Tuning advisor failing with ORA-904, ORA-911 and/or ORA-1740, and ORA-600 [kole_t2u], [34] can be found in the background.
The MMON process periodically running into ORA-600 [kole_t2u], [34] errors
Background processes (like MMON) running into this error when inserting into history tables like wrh$_sqltext
ORA-600 [kole_t2u], [34] errors when using DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
Many of these issues have been individually raised as bugs in the past, but in most cases they go back to the bad data introduced by bug 5017909.
Individual patches for some platforms are available on top of 10.1.0.5, 10.2.0.2 and 10.2.0.3.
Bug 8332730 (also known as duplicate bug 7023252) - fixed in 11.2
This error can be returned when querying the OTHER_XML column of the V$SQL_PLAN view due to this bug.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30430420/viewspace-1792287/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30430420/viewspace-1792287/