ORA-07445 (kssadpm_stage)错误

最近这两天一个linux上的准正式环境，在alert文件中报了大量的ORA-07445错误：ORA-07445: exception encountered: core dump [kssadpm_stage()+44] [SIGSEGV] [Address not mapped to object] [0x0] [] []。平均每个小时就要出现几次。

ITPUB个人空间uC;y q)S6bG/C

查询了METALINK上的信息，找到一个比较相似的：Bug 3030282。其中Bug 3030282的描述信息和碰到的情况是否相似，无论是trace文件中失败的参数名称还是，数据库版本信息都很相似。

唯一有出入的是Oracle描述的错误原因：Dump in kssadpm_stage can occur if certain DDL/truncate is interrupted。数据库的连接绝大部分来自于程序，一般不大可能出现DDL的情况。而且，也不大可能出现这么多DDL语句被中止的情况。

今天在登陆的时候，不小心敲错了密码，结果除了正常的不正确的用户名/密码错误外还出现了ORA-00600错误。错误信息如下：

ORA-00600: internal error code, arguments: [1157], [], [], [], [], [], [], []

ORA-01017: invalid username/password; logon denied

通过METALINK查询ORA-600的1157错误，结果发现其中一条信息的基础bug就是Bug 3030282。这个现象应该不会是巧合，看来这个ORA-600错误的根源也是前面出现的那个ORA-7445错误。

不过，从错误频率上看，确实不像METALINK上描述的那样，于是，通过DBMS_SYSTEM包跟踪系统进程，检查Oracle在出现ORA-7445错误之前是否在执行DDL语句。

跟踪了半天，也没有找到任何DDL语句，错误发生之前都是很正常的DML操作：

PARSING IN CURSOR #1 len=204 dep=0 uid=41 oct=2 lid=41 tim=1123224340047055 hv=901400046 ad='9a52d86c'

INSERT INTO UNC_USER_LOG(ID, ORG_ID, ORG_NAME, ACTION, ACTION_RESULT, VERSION, OPERATE_USER, OPERATE_DATE) VALUES (:ID, :ORG_ID, :ORG_NAME, :ACTION, :ACTION_RESULT, :VERSION, :OPERATE_USER, :OPERATE_DATE)

END OF STMT

PARSE #1:c=0,e=55,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1123224340047046

EXEC #1:c=0,e=5523,p=1,cr=1,cu=5,mis=0,r=1,dep=0,og=4,tim=1123224340052719

XCTEND rlbk=0, rd_only=0

*** 2006-06-13 14:58:44.670

XCTEND rlbk=0, rd_only=1

Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x0, PC: [0x825e058, kssadpm_stage()+44]

Registers:

%eax: 0x00000006 %ebx: 0x962b9958 %ecx: 0x0000001e

%edx: 0x0000000c %edi: 0x00000005 %esi: 0x00000000

%esp: 0xbfffbc64 %ebp: 0xbfffbc74 %eip: 0x0825e058

%efl: 0x00010202

kssadpm_stage()+24 (0x825e044) movzb 0xa77126c(%edx,%ecx,2),%edx

kssadpm_stage()+32 (0x825e04c) testb $0x4,%dl

kssadpm_stage()+35 (0x825e04f) jz 0x825e161

kssadpm_stage()+41 (0x825e055) mov 0xc(%ebp),%esi

> kssadpm_stage()+44 (0x825e058) movzb (%esi),%edi

kssadpm_stage()+47 (0x825e05b) lea (%edi,%edi,4),%edx

kssadpm_stage()+50 (0x825e05e) lea (%edx,%edx),%eax

kssadpm_stage()+53 (0x825e061) movb 0xa77126c(%eax,%edx,2),%cl

kssadpm_stage()+60 (0x825e068) testb $0x1,%cl

*** 2006-06-13 14:58:44.681

ksedmp: internal or fatal error

ORA-07445: exception encountered: core dump [kssadpm_stage()+44] [SIGSEGV] [Address not mapped to object] [0x0] [] []

Current SQL information unavailable - no session.

----- Call Stack Trace -----

calling call entry argument values in hex

location type point (? means dubious value)

-------------------- -------- -------------------- ----------------------------

ksedmp()+269 call ksedst()+0 1 ? 5000646C ? 0 ? 1 ?

252C3178 ? 25006C63 ?

ssexhd()+1108 call ksedmp()+0 3 ? 0 ? 0 ? 0 ? 0 ? 0 ?

__pthread_sighandle call ssexhd()+0 B ? BFFFB8F8 ? BFFFB978 ? 0 ?

r_rt()+122 0 ? 0 ?

kssadpm_stage()+44 signal __pthread_sighandle B ? BFFFB8F8 ? BFFFB978 ?

.

.

.

从数据库的日志分析不出有价值的东西，但是却从操作系统的/var/log目录下发现下列错误：

Jun 13 15:32:23 asdemo kernel: EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure

Jun 13 15:33:03 asdemo sshd(pam_unix)[9962]: session opened for user root by (uid=0)

Jun 13 15:33:06 asdemo kernel: scsi0: ERROR on channel 0, id 0, lun 0, CDB: Read (10) 00 01 93 2f e5 00 00 08 00

Jun 13 15:33:06 asdemo kernel: Info fld=0x50a365, Current sd08:02: sense key Medium Error

Jun 13 15:33:06 asdemo kernel: Additional sense indicates Unrecovered read error

Jun 13 15:33:06 asdemo kernel: I/O error: dev 08:02, sector 26214424

Jun 13 15:33:06 asdemo kernel: EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block - inode=1632054, block=3276803

看来很可能是操作系统的错误引起的ORA-7445错误。

重启系统修复磁盘错误后，错误消失。

看来当发现Oracle系统异常的时候，在检查Oracle找不到头绪时，可以对操作系统进行相应的检查，同时也说明对于DBA来说，必要的操作系统方面的知识是不可或缺的。