ORA-7445(ktcirs)错误

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

错误文件中，错误信息如下：

Errors in file /data/admin/testcen/udump/testcen_ora_28657.trc:ITPUB个人空间#chLKuy
ORA-07445: exception encountered: core dump [ktcirs()+67] [SIGSEGV] [Address not mapped to object] [0x2A9682A240] [] []
GV\w%Ilp0ORA-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
oJV1Bdr,y0ORA-07445: exception encountered: core dump [ktcirs()+67] [SIGSEGV] [Address not mapped to object] [0x2A9682A240] [] []
bi9STt^.[;~0ORA-03111: break received on communication channelITPUB个人空间h8@Ao;i,R@6r
Current SQL statement for this session:
%Hm9N]0i?5b${0SELECT "ID","CODE","CODE12_ID","CODE16_ID",……,"PHARMACOLOGY_ID" FROM "CAT_DRUG" "CD"

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

    SO: 0x1151e6e90, type: 4, owner: 0x115199a38, flag: INIT/-/-/0x00
5L%?.c^0HB!r0    (session) trans: 0x1174e6468, creator: 0x115199a38, flag: (41) USR/- BSY/-/-/-/-/-ITPUB个人空间 ?i:e0TedND.?7W5Z
              DID: 0001-0016-000009EF, short-term DID: 0000-0000-00000000ITPUB个人空间3AHQ J%V
no
              txn branch: 0x1174ff040ITPUB个人空间)L#r-[ J,[1J1I
              oct: 3, prv: 0, sql: 0x129ee8630, psql: 0x129ee8630, user: 37/SELE
1Qz"FR9zf0    O/S info: user: jiangping, term: , ospid: 28607, machine: datasrv2ITPUB个人空间,Oy/Awm
              program: oracle@datasrv2 (TNS V1-V3)ITPUB个人空间(P~0]7Fk,BU
    application name: oracle@datasrv2 (TNS V1-V3), hash value=0ITPUB个人空间}1|/m)U2MM{cc3s
    last wait for 'SQL*Net more data to client' blocking sess=0x0 seq=32094 wait_time=58ITPUB个人空间Idr0m#TUu
                driver id=54435000, #bytes=7df, =0ITPUB个人空间5wRk
P`e^B+Qx
    temporary object counter: 0

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

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

SQL> SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
'pNG^9w'K0--------------------------------------------------
6Y3D5Q,T%xO0YTK.YANGTINGKUN

SQL> CREATE DATABASE LINK TESTCEN
C;j"]3OGJ0  2  CONNECT TO SELE IDENTIFIED BY CENSELE
Z8t ~&h#V%]wKg0  3  USING 'TESTCEN';

数据库链接已创建。

SQL> SELECT * FROM DUAL@TESTCEN;

D
0n6by b9|,h ?0-ITPUB个人空间$X*hIdmKw
X

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

SQL> SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
OLX'J
M)d8okR QY0---------------------------------------------------------------------------------------ITPUB个人空间hj"e
Vu*Vt#[hT l
TESTCEN.EMEDCHINA.COM

SQL> SELECT SID, PROGRAM, MACHINE, OSUSER, USERNAME FROM V$SESSIONITPUB个人空间NMb\vq
  2  WHERE USERNAME = 'SELE';

       SID PROGRAM                             MACHINE         OSUSER          USERNAME
U}|Cu$T.r)Q0---------- ----------------------------------- --------------- --------------- -------------
:JG]5[Y0        28 ORACLE.EXE                          yangtingkun     ytk             SELE

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

SQL>CONNSELE@TESTCENITPUB个人空间P7}'B/R`
Enter password:
ma1c.QQ!Ty+b0Connected.ITPUB个人空间7w"}:r3s;g7A%m V,N
SQL> CREATE DATABASE LINK TESTCEN@TESTCEN 
LE:K3B$~0  2  CONNECT TO SELE IDENTIFIED BY CENSELE USING 'TESTCEN';

Database link created.

SQL> SELECT * FROM DUAL@TESTCEN@TESTCEN;

D
1jL!oJd7J0-ITPUB个人空间/C-Lx)]]O:`3TS
X

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

然后再次查询会话情况：

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

       SID PROGRAM                             MACHINE         OSUSER          USERNAME
{1E%`bQ4YZ7U0---------- ----------------------------------- --------------- --------------- ---------------ITPUB个人空间;[NE;yD
X3{AV
        28 ORACLE.EXE                          yangtingkun    ytk             SELEITPUB个人空间V F:A w{m
M
        31 sqlplus@datasrv2 (TNS V1-V3)        datasrv2        oracle          SELEITPUB个人空间 B#AX ~ ~,GK
        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
S"Lx+uUh~0-----------------------------------------------
{!K-r h6k |F"Va1e ~I0YTK.YANGTINGKUN

SQL> SELECT * FROM A@TESTCEN;

D
$g~oQ6w0-ITPUB个人空间C;^5jx n:t`0s7z
X

再次检查会话信息：

SQL> SELECT SID, PROGRAM, MACHINE, OSUSER, USERNAME FROM V$SESSION
-q F!H"o8Y1u!I p"a _5V`0  2  WHERE USERNAME = 'SELE';

       SID PROGRAM                             MACHINE         OSUSER          USERNAME
r\ \y:x&V9E0---------- ----------------------------------- --------------- --------------- ---------------ITPUB个人空间%U uk0r#Cc k
        22 oracle@datasrv2 (TNS V1-V3)         datasrv2        ytk             SELE
*ER
Z1D*i'y0        28 ORACLE.EXE                          yangtingkun     ytk             SELE
}I1lcn h0        31 sqlplus@datasrv2 (TNS V1-V3)        datasrv2        oracle          SELEITPUB个人空间d0nO%l(U
        46 oracle@datasrv2 (TNS V1-V3)         datasrv2        oracle          SELE

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

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