ORA-600 [kole_t2u], [34]

jialiguo

　　用户alert日志中出现如下错误：
　　Mon Sep 15 00:01:37 2014
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_j001_12124.trc  (incident=27811):
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_27811\orcl_j001_12124_i27811.trc
SYS_AUTO_SQL_TUNING_TASK exiting with error "600" for execution "EXEC_1302".  See DBA_ADVISOR_EXECUTIONS for more details.
End automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_j001_12124.trc  (incident=27812):
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], [], [], [], [], []
ORA-06512: at "SYS.PRVT_ADVISOR", line 2693
ORA-06512: at "SYS.DBMS_ADVISOR", line 241
ORA-06512: at "SYS.DBMS_SQLTUNE", line 772
ORA-06512: at line 4
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_27812\orcl_j001_12124_i27812.trc
Mon Sep 15 00:01:42 2014
Sweep [inc][27811]: completed
Sweep [inc2][27811]: completed
Mon Sep 15 00:01:43 2014
Trace dumping is performing id=[cdmp_20140915000143]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_j001_12124.trc:
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], [], [], [], [], []
ORA-06512: at "SYS.PRVT_ADVISOR", line 2693
ORA-06512: at "SYS.DBMS_ADVISOR", line 241
ORA-06512: at "SYS.DBMS_SQLTUNE", line 772
ORA-06512: at line 4
Trace dumping is performing id=[cdmp_20140915000145]

　　

ORA-600 [kole_t2u], [34] - description,bugs, and reasons (Doc ID 734474.1)

http://onexin.iyunv.com/source/plugin/onexin_bigdata/https://support.oracle.com/epmos/ui/images/quicklink_smlarrowdown_enabled.gifToBottomhttp://onexin.iyunv.com/source/plugin/onexin_bigdata/https://support.oracle.com/epmos/adf/images/t.gifhttp://onexin.iyunv.com/source/plugin/onexin_bigdata/https://support.oracle.com/epmos/adf/images/t.gif　　In this Document

Purpose Scope Details The meaning of ORA-600 [kole_t2u], [34] What are incomplete codepoints or partial multibyte characters? Circumstances under which ORA-600 [kole_t2u], [34] can come up Cause type-1: Invalid multibyte data being inserted into a CLOB Cause type-2: Invalid multibyte data copied from VARCHAR2 into CLOB Cause type-3: Incorrect CLOB splits Cause type-4: Other Oracle "internal" issues References　　
APPLIES TO:
Oracle Database - Enterprise Edition - Version 9.2.0.1 to 11.2.0.4 [Release 9.2 to 11.2]
Information in this document applies to any platform.
Oracle Server Enterprise Edition - Version: 9.2.0.1 to 11.1.0.6
***Checked for relevance on 20-Jan-2014***

PURPOSE
　　This bulletin explains the error ORA-600 [kole_t2u], [34], and it explains in which circumstances the error comes up (including some bugs).
SCOPE
　　This article is intended for anybody who finds any occurrence of ORA-600 [kole_t2u], [34], and wants to find out what this means, and how to resolve the error.
DETAILS
The meaning of ORA-600 [kole_t2u], [34]
　　The error ORA-600 [kole_t2u], [34] (note that both arguments are important here) is closely related to the more normal looking error ORA-29275.
Both errors can only come up in a database that is using multibyte character sets (ie, a character set in which at least some characters are represented by more than 1 byte), and both mean that a malformed byte sequence has been found which cannot representa character.
ORA-29275 comes up in case this occurs for normal VARCHAR2 data. ORA-600 [kole_t2u], [34] is thrown under similar circumstances, but (usually) when CLOB data is being used.

Example 1: A (legitimate) 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], [], [], [], [], [], []　　In the AL32UTF8 character set, the byte 0xEC does not represent a character on its own (more about this in the next paragraph). Therefore the database expects more bytes, and because those aren't available, this codepoint is classed as incomplete and theerror is thrown.


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　　Again we use the same incomplete codepoint in this example, but this time we put it into a VARCHAR2. Note that in this case the data is allowed to be stored in the database in the first place, as it isn't checked for character set rules through this wayof inserting. The problem with the incomplete codepoint is only noticed when the data is selected, and then the error is thrown.
What are incomplete codepoints or partial multibyte characters?
　　In multibyte character sets, the database is aware how many bytes are needed to form a complete character (or complete codepoint). Depending on the value of the first byte in a codepoint, the database knows how many more bytes need to follow it. If thereare fewer bytes left in the string, then the database knows there is a malformed codepoint stored, and can raise either ORA-29275 or ORA-600 [kole_t2u], [34].

See Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications
Circumstances under which ORA-600 [kole_t2u], [34] can come up
　　As stated, this error can come up in multibyte environments. Secondly it is clear that whenever this error comes up, there must be at least 1 incomplete codepoint used in the data.
In general we can split these occurrences in 3 categories:

• Invalid multibyte data is being inserted by an application into a CLOB
  
• Invalid multibyte data has been inserted in a VARCHAR2 (without initially being detected), and the stored data is moved to a CLOB at a later stage (either through application code, or by a Oracle process like Auditing).
  
• Existing correctly stored CLOB data is incorrectly "split" into chunks. This could leave a codepoint "split" in the middle of the byte stream, leaving a incorrect number of bytes for the last codepoint before the split. This could either happen in applicationcode, or could be due to bug in the database.
  

　　We will look at all these 3 categories in depth in the following paragraphs.
Cause type-1: Invalid multibyte data being inserted into a CLOB
　　This is the simplest of occurrences of this error. It can be immediately spotted because the error will be raised as a direct result of the statement that tries to load the incorrect data into the CLOB. Example 1 above is an example of this type.

Resolution
If the cause of this problem is that the application is indeed pushing incorrect data into the CLOB, then this is a application error that needs to be correct.
Alternatively this type of problem could be the result of encrypted data trying to be loaded into a CLOB. In this case the problem is not with the data, but with the fact a binary string is trying to be loaded in a CLOB. To resolve this the data model needsto be adapted and the data should be loaded in a RAW or BLOB column.
See point B.10) in Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications
Cause type-2: Invalid multibyte data copied from VARCHAR2 into CLOB
　　This type of issue can often look like a bug, but is in actual fact related to the fact that incomplete codepoints are already used in the database. Example 2 above shows how this data might be inserted into a VARCHAR2 column. If this data is subsequentlymoved to a CLOB column, then this error will come up.

A relatively easy way of detecting this sort of data would be to select the data from the VARCHAR2 column, in which case a ORA-29275 error would be expected as well. However, there could be more complex cases in which data is processed in the application orin PL/SQL first before being attempted to be loaded into the CLOB. If this processing causes incomplete codepoints to appear then we would also see ORA-600 [kole_t2u], [34], but this could not be detected from the base data.

Typical example
Typically this type of the error can be seen when extended database auditing is used, and the database has invalid multibyte data stored. This could for example be as a result of wrongly implemented encryption (see paragraph above).
In this scenario the extended auditing will cause bind values used in SQL statements to be written to a auditing record, which uses a CLOB column for this purpose. If the bind values are fetched from the invalid multibyte data, the copy to the CLOB which isperformed by the auditing system will fail with ORA-600 [kole_t2u], [34]. At first sight this will look like a bug in the auditing system, but the core problem is that invalid data is stored in the first place, and this needs to be addressed.
Other mechanisms (either Oracle provided, or application based) which copy data between VARCHAR2 and CLOB columns could run into the same problems.

Resolution
As per the above example, this case represents a problem in the stored data in the database, and this needs to be addressed. The fact that the "copying process" runs into the ORA-600 is simply a result of the underlying problems.

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, ifa 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
　　This type of problem is the hardest to detect, and usually requires extensive debugging before the problem can be located, before going down this path it is usually preferable to go through the list of known issues and apply any known patches to rule outany known problems.
The background of this type of error comes from the fact that CLOB data is sometimes split into more manageable chunks of data of a certain length. It this split is made after a certain number of bytes (for example 1000, or 4000, etc etc), then it could happenthat the split happens in the middle of a multibyte codepoint. This then leaves the previous chunk with a incomplete codepoint at the end of the data, and this error can be expected. If this type of problem occurs, it is therefore due to a bug in the way CLOBdata is split into chunks. Rather than making the split based on bytes it should always be made based on full characters.

Resolution
If this split is made in an application (for processing on the application side), then this represents a application bug that needs to be corrected. There are also a number of known bugs in the Oracle database that can cause this to happen, and anybodywho suspects they might run into this is advised to apply the relevant patches.

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 6407486first 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.
  

Cause type-4: Other Oracle "internal" issues
　　Other than the Oracle bugs mentioned above there is a further issue which could cause this error:

* Bug 7378401 & Bug 8216864 - both fixed in 10.2.0.5 and 11.2.0.1
Bug 7378401 can cause this error to occur in the Oracle auditing system when the AUDIT_TRAIL parameter is set to "db_extended", and there are bind vaiables of the NCHAR datatype. In order for this bug to be hit, the bind variables have to be of the NCHAR datatype.If the datatype is a normal CHAR or VARCHAR, then this bug can not be suspected.
Note that the fix for bug 7378401 exposes a new bug 8216864 causing the same error code. Patches for both bugs should therefore be applied at the same time.

* Bug 10334711 - update statement encounter ora-600 [kole_t2u] While auditing sql bind data ORA-600[KOLE_T2U] is raised when a multibyte character starts at 4000th byteof the character string, this bug could be suspected.
Workaround: Do not use EXTENDED feature of AUDIT_TRAIL
Fixed in 11.2.0.3 and 12.1
　　

　　可以看到，该错误是11.2.0.1的一个BUG，估计跟CLOB字段有关系，
　　建议升级，目前最简单的办法就是禁止SYS_AUTO_SQL_TUNING_TASK，避免调用SYS.DBMS_ADVISOR，待后续有时间对数据库实例进行升级。

　　
         版权声明：本文为博主原创文章，未经博主允许不得转载。