ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-7445(ktcirs)错误

ORA-7445(ktcirs)错误

原创 Linux操作系统 作者:yangtingkun 时间:2008-04-02 23:56:59 0 删除 编辑

9204 for Linux数据库的alert文件中发现了这个错误。

 

 

错误文件中,错误信息如下:

Errors in file /data/admin/testcen/udump/testcen_ora_28657.trc:
ORA-07445: exception encountered: core dump [ktcirs()+67] [SIGSEGV] [Address not mapped to object] [0x2A9682A240] [] []
ORA-03111: break received on communication channel

metalink上寻找了很久,发现只有下面文章的描述和当前问题比较接近:Doc ID:  Note:432571.1

错误信息描述为:ORA-07445 [KTCIRS()+62] on using dblinks。造成这个问题的原因是用户通过数据库链访问当前数据库环境。错误现象为ORA-7445 [KTCIRS]错误,后面还跟随ORA-3113错误。

而当前的至少存在下面几个不同:首先当前出现问题的版本是9204而不是10g,其次,出现问题虽然报错ORA-7445 [KTCIRS],但是随后跟着的错误信息为ORA-3111

其实这两处区别倒是可以自圆其说,首先ORA-3111ORA-3113都是通信异常问题,而且如果同样的问题在9i中报错311110g报错3113是很可能的。

目前最重要的是要证明,当前这个错误是通过数据库链访问当前数据库时产生的。

打开上面的跟踪文件,搜索更加详细的错误信息:

ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [ktcirs()+67] [SIGSEGV] [Address not mapped to object] [0x2A9682A240] [] []
ORA-03111: break received on communication channel
Current SQL statement for this session:
SELECT "ID","CODE","CODE12_ID","CODE16_ID",……,"PHARMACOLOGY_ID" FROM "CAT_DRUG" "CD"

出错的SQL语句就是一个普通的单表扫描,没有任何特别之处,在检查trace中的其他信息:

    SO: 0x1151e6e90, type: 4, owner: 0x115199a38, flag: INIT/-/-/0x00
    (session) trans: 0x1174e6468, creator: 0x115199a38, flag: (41) USR/- BSY/-/-/-/-/-
              DID: 0001-0016-000009EF, short-term DID: 0000-0000-00000000
              txn branch: 0x1174ff040
              oct: 3, prv: 0, sql: 0x129ee8630, psql: 0x129ee8630, user: 37/SELE
    O/S info: user: jiangping, term: , ospid: 28607, machine: datasrv2
              program: oracle@datasrv2 (TNS V1-V3)
    application name: oracle@datasrv2 (TNS V1-V3), hash value=0
    last wait for 'SQL*Net more data to client' blocking sess=0x0 seq=32094 wait_time=58
                driver id=54435000, #bytes=7df, =0
    temporary object counter: 0

在会话信息中,发现了一些可疑的地方。从programapplication name看,这个会话是Oracle发出的,从machine信息看,会话发起的服务器就是数据库服务器,但是这里的O/S info: user信息有问题,这个用户是开发人员的台式机用户,而不是数据库服务器上面的操作系统用户。

只有通过数据库链访问当前的数据库才能够产生这种信息的会话。但是普通的数据库链访问并不能模拟出当前的现象。

SQL> SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
--------------------------------------------------
YTK.YANGTINGKUN

SQL> CREATE DATABASE LINK TESTCEN
  2  CONNECT TO SELE IDENTIFIED BY CENSELE
  3  USING 'TESTCEN';

数据库链接已创建。

SQL> SELECT * FROM DUAL@TESTCEN;

D
-
X

在其他的数据库服务器上建立数据库链,访问当前的数据库服务器,并在服务器上检查会话信息:

SQL> SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
---------------------------------------------------------------------------------------
TESTCEN.EMEDCHINA.COM

SQL> SELECT SID, PROGRAM, MACHINE, OSUSER, USERNAME FROM V$SESSION
  2  WHERE USERNAME = 'SELE';

       SID PROGRAM                             MACHINE         OSUSER          USERNAME
---------- ----------------------------------- --------------- --------------- -------------
        28 ORACLE.EXE                          yangtingkun     ytk             SELE

通过上面的模拟可以看到,如果直接通过数据库链访问,得到的会话信息与TRACE文件中的差别很大。下面尝试在本地通过数据库链访问当前服务器:

SQL> CONN SELE@TESTCEN
Enter password:
Connected.
SQL> CREATE DATABASE LINK TESTCEN@TESTCEN 
  2  CONNECT TO SELE IDENTIFIED BY CENSELE USING 'TESTCEN';

Database link created.

SQL> SELECT * FROM DUAL@TESTCEN@TESTCEN;

D
-
X

在服务器上新开一个会话,建立一个指向当前数据库的数据库链,并通过数据库链进行查询。

然后再次查询会话情况:

SQL> SELECT SID, PROGRAM, MACHINE, OSUSER, USERNAME FROM V$SESSION
  2  WHERE USERNAME = 'SELE';

       SID PROGRAM                             MACHINE         OSUSER          USERNAME
---------- ----------------------------------- --------------- --------------- ---------------
        28 ORACLE.EXE                          yangtingkun     ytk             SELE
        31 sqlplus@datasrv2 (TNS V1-V3)        datasrv2        oracle          SELE
        46 oracle@datasrv2 (TNS V1-V3)         datasrv2        oracle          SELE

可以看到两个新增会话,一个是SQLPLUS产生的会话,第二个是指向本地数据库的数据库链产生的会话。而这个会话的会话信息已经和TRACE文件中十分类似了,唯一的区别在于OSUSER信息为远端服务器用户,而不是本地数据库服务器的操作系统用户。

下面在第一个测试的数据库服务器上再次访问,为了远端可以访问本地建立的数据库链,在本地首先建立一个同义词指向数据库链访问的对象:

SQL> CREATE OR REPLACE SYNONYM A FOR DUAL@TESTCEN@TESTCEN;

Synonym created.

下面就可以在远端通过数据库链访问A了:

SQL> SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
-----------------------------------------------
YTK.YANGTINGKUN

SQL> SELECT * FROM A@TESTCEN;

D
-
X

再次检查会话信息:

SQL> SELECT SID, PROGRAM, MACHINE, OSUSER, USERNAME FROM V$SESSION
  2  WHERE USERNAME = 'SELE';

       SID PROGRAM                             MACHINE         OSUSER          USERNAME
---------- ----------------------------------- --------------- --------------- ---------------
        22 oracle@datasrv2 (TNS V1-V3)         datasrv2        ytk             SELE
        28 ORACLE.EXE                          yangtingkun     ytk             SELE
        31 sqlplus@datasrv2 (TNS V1-V3)        datasrv2        oracle          SELE
        46 oracle@datasrv2 (TNS V1-V3)         datasrv2        oracle          SELE

观察新增的SID22的会话信息,除了OSUSER的名称与TRACE中不同,其他信息已经完全和TRACE中一样。

可以说现在已经模拟出TRACE文件中会话情况,而这种情况和bug中的描述恰好吻合。那么可以断定,即使这个问题不完全和bug中描述的一样,至少也和这个bug有一定的关系。

 

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

上一篇: ORA-600(729)错误
下一篇: ORA-7445(kkojnp)错误
请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10486843