全部博文(147)
分类: Oracle
2012-05-07 09:44:55
Scamadb ORA-600[kole_t2u]问题处理建议20120204.pdf Scamadb ORA-600[kole_t2u]问题处理建议
1.问题描述 1.1 ORA-600[kole_t2u]问题Scamadb ORACLE数据库2012年1月12日17:00在ALERT日志中有ORA-600[kole_t2u]的报错,并生成跟踪文件,具体日志如下:
Thu Jan 12 17:00:19 2012
Errors in file /oracle/admin/scamadb/bdump/scamadb_m000_929904.trc:
ORA-00600: internal error code, arguments: [kole_t2u], [34], [], [], [], [], [], []
2.问题分析 2.1 ORA-600[kole_t2u]问题分析(1) 错误的含义
具体的错误为ORA-600[kole_t2u]
Error Mnemonic(s) Functionality Description kol kolb kole kolf kolo objmgmt/objmgr support 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语句
INSERT INTO wrh$_sqltext |
该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_t2u <- koklwrite <- koklc_write <- kolaslWrite <- kolaWrite <- koklwrite <- qerfxCreateTempClob
(5) 出错原因确认
根据上述分析可知,该错误不涉及应用程序,是oracle后台进程出现问题,与oracle AWR本身处理多字节字符的缺陷有关系。检索ORACLE产品本身的BUG库,可知命中BUG 5017909,当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) o 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. o The MMON process periodically running into ORA-600 [kole_t2u], [34] errors o Background processes (like MMON) running into this error when inserting into history tables like wrh$_sqltext o 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 |
该BUG的详细资料如下所示
3.问题处理建议 3.1 ORA-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. 上传补丁至服务器,并解压
unzip p5017909_10203_AIX64-5L.zip
4. 上传补丁至服务器,并解压
unzip p5017909_10203_AIX64-5L.zip
5. 确认补丁应用环境
opatch lsinventory
6. 安装补丁
cd 5017909
opatch apply
7. 检查补丁安装情况:
opatch lsinventory
8. 起监听和应用
9. 打开数据库
startup
4.应急回退方案:
1.进入到补丁目录
cd 5017909
2.回退补丁
opatch rollback -id 5017909