Oracle 9206 RAC环境访问LOGMINER视图时报错。

错误信息：

Wed Aug 10 17:06:37 2011
Errors in file /opt/app/oracle/admin/orcl/udump/orcl2_ora_20704.trc:
ORA-07445: exception encountered: core dump [000000010069AB88] [SIGSEGV] [Address not mapped to object] [0x000000008] [] []
Wed Aug 10 17:07:22 2011
Trace dumping is performing id=[cdmp_20110810170722]

对应的TRACE信息为：

*** 2011-08-10 17:06:37.463
*** SESSION ID:(49.28760) 2011-08-10 17:06:37.461
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x8, PC: [0x10069ab88, 000000010069AB88]
*** 2011-08-10 17:06:37.463
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [000000010069AB88] [SIGSEGV] [Address not mapped to object] [0x000000008] [] []
Current SQL statement for this session:
select count(*) from v$logmnr_contents
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+328 CALL ksedst() 00000000B ? 000000000 ?
000000000 ? 00000004A ?
FFFFFFFF7FFF0658 ?
1032E18E8 ?
ssexhd()+676 CALL ksedmp() 000103705 ? 103705000 ?
103705468 ? 10370A000 ?
000102C00 ? 000000000 ?
sigacthandler()+44 PTR_CALL 0000000000000000 00010370D ?
FFFFFFFF7FFF76F0 ?
10370D000 ? 10370A620 ?
000000000 ? 10370D578 ?
ksfd_odmwat()+968 PTR_CALL 0000000000000000 00000000B ?
FFFFFFFF7FFF76F0 ?
FFFFFFFF7FFF7410 ?
000004400 ? 000103400 ?
00000000E ?
ksfdwtio()+812 CALL ksfd_odmwat() FFFFFFFF7B7E63A8 ?
000000000 ? 1037077D4 ?
000000000 ? 000000000 ?
0FFFFFFFB ?
ksfdwat1()+64 CALL ksfdwtio() 38000A800 ? 1037077D4 ?
380011054 ? 000000000 ?
0FFFFFFFB ? 01CBA91A7 ?
ksfdrwat0()+212 CALL ksfdwat1() 0FFFFFFFB ? 000000000 ?
000000000 ? 000000000 ?
10370A000 ? 00000FC00 ?
kcrfais()+752 CALL ksfdwat() 38000A000 ? 000000000 ?
000000000 ? 000000000 ?
00000001B ? 10370AA10 ?
kcrfdr()+292 CALL kcrfais() FFFFFFFF7B7E1478 ?
FFFFFFFF7B7E1400 ?
FFFFFFFF7B7E1210 ?
000000800 ? 000002002 ?
FFFFFFFF7FFF9D7C ?
kcrfrgv()+452 CALL kcrfdr() FFFFFFFF7B7E10F0 ?
FFFFFFFF7B7E1168 ?
000000040 ? 000103400 ?
00010370B ? 000000002 ?
krvxrgr_GetRedo()+1 CALL kcrfrgv() FFFFFFFF7B7E10F0 ?
04 0000002D0 ? 0000002D0 ?
000000080 ? 000000000 ?
00000FC00 ?
krvxror_ReadOneReco CALL krvxrgr_GetRedo() FFFFFFFF7B7E6818 ?
rd()+1284 FFFFFFFF7B7E10F0 ?
FFFFFFFF7FFFB018 ?
FFFFFFFF7B7E10E0 ?
1033E7E98 ? 1033E7E88 ?
krvxread()+432 CALL krvxror_ReadOneReco FFFFFFFF7B7E10E0 ?
rd() FFFFFFFF7B7E3118 ?
FFFFFFFF7B7E2F90 ?
000000007 ?
FFFFFFFF7FFFB910 ?
000000000 ?
krvxgtsp_GetTxnSing CALL krvxread() FFFFFFFF7B7E6818 ?
leProcess()+28 000000000 ? 000000000 ?
0990FD824 ? 000000000 ?
FFFFFFFF7B7E2F90 ?
krvxgt()+604 CALL krvxgtsp_GetTxnSing FFFFFFFF7B7E6818 ?
leProcess() 000000000 ? 103708000 ?
FFFFFFFFFFFFFFFF ?
000000000 ? 000000000 ?
krvfcact()+1940 CALL krvxgt() FFFFFFFF7B7E6818 ?
000000001 ?
FFFFFFFF7FFFB2D4 ?
FFFFFFFF7FFFB2B8 ?
FFFFFFFF7FFFB2C0 ?
0000000CA ?
qerfxFetch()+1056 PTR_CALL 0000000000000000 FFFFFFFF7B7E6818 ?
000001000 ?
FFFFFFFF7B7E7768 ?
FFFFFFFF7B7E0068 ?
47CABB0D8 ?
FFFFFFFF7B7E2F90 ?
qergsFetch()+2268 PTR_CALL 0000000000000000 4C9EB4768 ? 102E54FC8 ?
000000000 ? 102DDC520 ?
102E53830 ? 000007FFF ?
opifch2()+1724 PTR_CALL 0000000000000000 000101800 ?
FFFFFFFF7B7E74E0 ?
000000000 ? 000000001 ?
100FD5400 ? 4C9EB46D0 ?
opiall0()+3860 CALL opifch2() 101001000 ? 102E55AD8 ?
100FD5400 ? 0000000C9 ?
FFFFFFFF7FFFB910 ?
FFFFFFFF7FFFBF3C ?
kpoal8()+1040 CALL opiall0() 000000000 ? 00000005E ?
FFFFFFFF7FFFC1C8 ?
103705808 ?
FFFFFFFF7B7E7B48 ?
FFFFFFFF7FFFC558 ?
opiodr()+1688 PTR_CALL 0000000000000000 000000000 ? 000000001 ?
FFFFFFFF7FFFEA10 ?
000000024 ? 000000000 ?
0000022B0 ?
ttcpip()+1556 PTR_CALL 0000000000000000 000103400 ? 100FBBFC0 ?
10370D808 ? 103705808 ?
103707D40 ?
FFFFFFFF7FFFCBB0 ?
opitsk()+984 CALL ttcpip() 10370D800 ? 000000014 ?
FFFFFFFF7FFFEA10 ?
000000000 ? 000000000 ?
FFFFFFFF7FFFDCFC ?
opiino()+1572 CALL opitsk() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
103707D28 ?
FFFFFFFF7FFFEB64 ?
opiodr()+1688 PTR_CALL 0000000000000000 000380007 ? 10370C658 ?
1037F9458 ?
FFFFFFFF7FFFF8A0 ?
000000000 ? 47DED9E20 ?
opidrv()+736 CALL opiodr() 000103400 ? 10100C380 ?
10370D808 ? 103705808 ?
103707D40 ?
FFFFFFFF7FFFF3C0 ?
sou2o()+16 CALL opidrv() 000000000 ? 000000004 ?
1037051EC ? 00000003C ?
1037056C8 ? 000103400 ?
main()+184 CALL sou2o() FFFFFFFF7FFFF8C0 ?
00000003C ? 000000004 ?
FFFFFFFF7FFFF8A0 ?
000039E70 ? 000000000 ?
_start()+380 CALL main() 000000002 ?
FFFFFFFF7FFFFA08 ?
FFFFFFFF7FFFFA20 ?
000000000 ? 000000000 ?
100000000 ?

--------------------- Binary Stack Dump ---------------------

当前的数据库采用ODM:VERITAS 4.1.20.00 ODM Library, Version 1.1，而在发生错误时等待的是ODM的IO操作。这个错误在MOS甚至是GOOGLE上都找不到，不过可以很容易的判断出，问题发生在Oracle与Veritas之间的配合有关。

发生错误的语句是SELECT COUNT(*) FROM V$LOGMNR_CONTENTS，但是观察会话的历史执行需要，之前已经做过对V$LOGMNR_CONTENTS的全表访问，并未引发异常：

Cursor Dump:
----------------------------------------
Cursor 1 (ffffffff7ca60490): CURROW curiob: ffffffff7ca69068
curflg: 4e curpar: 0 curusr: 0 curses 47e8b7800
cursor name: select * from v$logmnr_contents
child pin: 48f2da230, child lock: 490123c90, parent lock: 490123da0
xscflg: 80100074, parent handle: 4a8d79a90, xscfl2: 4200409
nxt: 15.0x00000008 nxt: 14.0x00000158 nxt: 13.0x00000fa8 nxt: 12.0x00000fa8
nxt: 11.0x00000158 nxt: 10.0x00000fa8 nxt: 9.0x00000180 nxt: 8.0x00000fa8
nxt: 7.0x00000fa8 nxt: 6.0x00000158 nxt: 5.0x00000fa8 nxt: 4.0x00000420
nxt: 3.0x000007c8 nxt: 2.0x000007c8 nxt: 1.0x000007c8
Cursor frame allocation dump:
frm: -------- Comment -------- Size Seg Off
bhp size: 160/600
whp size: 11066784/11067768
Dump of CURRENT WORK HEAP:
******************************************************
.
.
.
******************************************************
----------------------------------------
Cursor 2 (ffffffff7ca604e0): CURBOUND curiob: ffffffff7b7e8130
curflg: 4e curpar: 0 curusr: 0 curses 47e8b7800
cursor name: select distinct operation from v$logmnr_contents
child pin: 0, child lock: 48f491d08, parent lock: 48f492368
xscflg: 100024, parent handle: 4aa79cb50, xscfl2: 4200409
bhp size: 160/600
----------------------------------------
Cursor 3 (ffffffff7ca60530): CURFETCH curiob: ffffffff7b7e7b48
curflg: 4e curpar: 0 curusr: 0 curses 47e8b7800
cursor name: select count(*) from v$logmnr_contents
child pin: 48f2db030, child lock: 490125618, parent lock: 490125c78
xscflg: 80100074, parent handle: 4c9ec3038, xscfl2: 4200409
nxt: 4.0x00000008 nxt: 3.0x00000060 nxt: 2.0x000004c0 nxt: 1.0x000007c8
Cursor frame allocation dump:
frm: -------- Comment -------- Size Seg Off
bhp size: 160/600
whp size: 11046016/11046720
Dump of CURRENT WORK HEAP:
******************************************************

显然这个错误的发生是偶然的，目前并没有导致或解决这个问题的明确方式，不过考虑只是偶尔影响v$logmnr_contents的访问，可以忽略掉这个错误。