ORA-7445(ktcirs)错误

在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-3111和ORA-3113都是通信异常问题，而且如果同样的问题在9i中报错3111在10g报错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

在会话信息中，发现了一些可疑的地方。从program和application 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

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

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

 

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

转载于:http://blog.itpub.net/4227/viewspace-225012/