Chinaunix首页 | 论坛 | 博客
  • 博客访问: 698962
  • 博文数量: 147
  • 博客积分: 5347
  • 博客等级: 大校
  • 技术积分: 1453
  • 用 户 组: 普通用户
  • 注册时间: 2005-06-06 11:11
文章分类

全部博文(147)

文章存档

2014年(4)

2012年(9)

2011年(5)

2010年(28)

2009年(21)

2008年(29)

2007年(15)

2006年(17)

2005年(19)

我的朋友

分类: 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_id, dbid, sql_text, command_type, snap_id, ref_count)
  SELECT sqlid_kewrstx,
         :dbid,
         sqlfulltext_kewrstx,
         cmdtype_kewrstx,
         :lah_snap_id,
         0 ref_count
    FROM x$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-600oracle的内部错误,基本上都与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$SQLSQL语句相关视图的查询。

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:

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

BUG的详细资料如下所示

3.问题处理建议 3.1 ORA-600[kole_t2u]问题处理建议

数据库的当前版本是10.2.0.3,该BUG10.2.0.4 及以后版本的patchset中修复。在AIX下有相应的小补丁可以解决该问题,或者是修改应用的程序代码防止sql语句中的第一千个字节刚好是中文的问题也可以解决该bug

虽然该错误没有大的影响,只是影响到辅助功能AWR的正常使用(Top sql显示不完整)或者是对V$SQLSQL语句相关视图的查询,但是依然建议安装补丁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

                                                       

阅读(3643) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~