在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/