1.问题描述
1.1ORA-600[kole_t2u]问题
ScamadbORACLE数据库2012年1月12日17:00在ALERT日志中有ORA-600[kole_t2u]的报错，并生成跟踪文件，具体日志如下：
Thu Jan 12 17:00:19 2012
Errorsin file /oracle/admin/scamadb/bdump/scamadb_m000_929904.trc:
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []
2．问题分析
2.1ORA-600[kole_t2u]问题分析
(1) 错误的含义
具体的错误为ORA-600[kole_t2u]
ErrorMnemonic(s)FunctionalityDescription
kol kolbkolekolf kolo objmgmt/objmgrsupport for object Lob buffering , object lob evaluation and object Language/runtime functions for Opaque types
t2u 表示text to unicode,即做字符的转换
即在做lob大对象字段中字符的处理时出现问题。
oracle对该错误的官方解释是：
多字节表示的字符(比如两个字节表示中文)，如果按照字节顺序组织起来无法表示一个字符则报出错误，对于CLOB类型的字段抛出ORA-600 [kole_t2u], [34]错误，对于VARCHAR2类型的字段则抛出ORA-29275。这与程序处理多字节字符的缺陷有关系。
从alert日志数据库启动日志可知，该数据库使用的正式多字节表示的字符集。
SMON: enabling tx recovery
Sat Apr 30 10:13:35 2011
Database Characterset is ZHS16GBK
(2) 造成出错的程序
从所有错误的trace中，可以看到，造成该出错的程序都是
image: oracle@acrmdb_chl (m000)
m000进程是mmon进程的slave进程，mmon进程是数据库的后台进程，负责awr/ash报告的维护包括采样等工作，默认设置下，mmon进程将每隔一小时生成m000进程去做awr报告的抓取。
(3)造成出错的SQL语句
从trace中的“Current SQL statement for this session:”中，可知触发该ORA-600错误的都是以下的SQL语句
INSERTINTOwrh$_sqltext(sql_id,dbid, sql_text, command_type, snap_id, ref_count)SELECTsqlid_kewrstx,:dbid,sqlfulltext_kewrstx,cmdtype_kewrstx,:lah_snap_id,0 ref_countFROMx$kewrtsqltext
该SQL实现将shared pool中当前保存的SQL存放到AWR的历史表wrh$_sqltex表
从下面的输出可以看到，涉及的表(基表)都包含了CLOB字段，与上面的分析一致
SQL> desc wrh$_sqltext
Name Null? Type
----------------------------- -------- ---------------
SNAP_ID NUMBER
DBID NOT NULL NUMBER
SQL_ID NOT NULL VARCHAR2(13)
SQL_TEXT CLOB
COMMAND_TYPE NUMBER
REF_COUNT NUMBER
SQL> desc x$kewrtsqltext
Name Null? Type
----------------------------- -------- ---------------
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
SQLID_KEWRSTX VARCHAR2(13)
SQLIDNUM_KEWRSTX NUMBER
CMDTYPE_KEWRSTX NUMBER
SQLFULLTEXT_KEWRSTX CLOB
(4) 出错时的Call Stack
ORA-600是oracle的内部错误，基本上都与ORACLE产品本身的缺陷即BUG有关系。BUG有一定的触发场景，从CallStack可以得知进程在出错前都调用了哪些函数，这些函数结合在一起就知道了错误的触发场景。通过比对这些callStack可以确认是否符合BUG的触发场景。当然，也有不少的BUG是在某个函数上存在缺陷，由于不同的场景都可能调用该函数后触发该BUG，该情况下就不要要求完全核对CallStack.
从trace中的” ----- Call Stack Trace ----“部分可知m000进程出错时的CallStack如下所示
忽略kge/kse等出错后用来dump trace的函数，即callStack为
kole_t2ukoklwritekoklc_writekolaslWritekolaWritekoklwriteqerfxCreateTempClob
(5) 出错原因确认
根据上述分析可知，该错误不涉及应用程序，是oracle后台进程出现问题，与oracle AWR本身处理多字节字符的缺陷有关系。检索ORACLE产品本身的BUG库，可知命中BUG5017909，当SQL语句的第一千个字节刚好是中文时，由于该BUG，导致sqltext相关的CLOB字段中包含了无效的multibyte codepoints，触发该600错误。之前应用做过升级，应该是版本升级后出现了一些SQL语句，SQL语句的第一千个字节刚好是中文,因此升级后AWR采样出现了出错，该出错本身不影响SQL的执行，只是影响到辅助功能AWR或者是对V$SQL等SQL语句相关视图的查询。
Known bugs
·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:
oSQL Tuning advisor failing with ORA-904, ORA-911 and/or ORA-1740, and ORA-600 [kole_t2u], [34] can be found in the background.
oThe MMON process periodically running into ORA-600 [kole_t2u], [34] errors
oBackground processes (like MMON) running into this error when inserting into history tables like wrh$_sqltext
oORA-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
该BUG的详细资料如下所示
3．问题处理建议
3.1ORA-600[kole_t2u]问题处理建议
数据库的当前版本是10.2.0.3，该BUG在10.2.0.4及以后版本的patchset中修复。在AIX下有相应的小补丁可以解决该问题，或者是修改应用的程序代码防止sql语句中的第一千个字节刚好是中文的问题也可以解决该bug。
虽然该错误没有大的影响，只是影响到辅助功能AWR的正常使用(Top sql显示不完整)或者是对V$SQL等SQL语句相关视图的查询，但是依然建议安装补丁5017909。以下为补丁文件。
安装补丁步骤：
1.停止应用和监听
2.停数据库实例
shutdown immediate
3.上传补丁至服务器，并解压
unzipp5017909_10203_AIX64-5L.zip
4.上传补丁至服务器，并解压
unzipp5017909_10203_AIX64-5L.zip
5.确认补丁应用环境
opatch lsinventory
6.安装补丁
cd5017909
opatch apply
7.检查补丁安装情况：
opatch lsinventory
8.起监听和应用
9.打开数据库
startup
4.应急回退方案：
1.进入到补丁目录
cd 5017909
2.回退补丁
opatch rollback -id 5017909
4221
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
