Oracle Database Discussions

Hi,Experts,

I have an old Sun E6800, Solaris 9,Veritas Volum manager 3.5 , HDS 9570, oracle 9.2.0.4, run good from 2004 until 2009, recently, it paniced twice.
the message log:
Sep 15 15:45:17 gupdb unix: [ID 836849 kern.notice]
Sep 15 15:45:17 gupdb panic[cpu8]/thread=3002f9882c0:
Sep 15 15:45:17 gupdb unix: [ID 340138 kern.notice] BAD TRAP: type=31 rp=2a100dd68d0 addr=64 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference
Sep 15 15:45:17 gupdb unix: [ID 100000 kern.notice]
Sep 15 15:45:17 gupdb unix: [ID 839527 kern.notice] oracle:
Sep 15 15:45:17 gupdb unix: [ID 520581 kern.notice] trap type = 0x31
Sep 15 15:45:17 gupdb unix: [ID 381800 kern.notice] addr=0x64
Sep 15 15:45:17 gupdb unix: [ID 101969 kern.notice] pid=1108, pc=0x104c99c, sp=0x2a100dd6171, tstate=0x9980001602, context=0x19f0


and the crash log show 1108 is dbwrite.
and I check the alert log , there are some ora-600 4511 error, but the last error was Sep 15 15:09, not the panic time.
Anybody can give some idea how to avoid the machine panic again.

God bless you
Simon Lai

PANIC occurred on this thread

***
process id 1108 is ora_dbw1_pipeline, parent process is 1
uid is 0x3e9 0t1001, gid is 0x65 0t101

thread addr 0x3002f9882c0, proc addr 0x3002966e110, lwp addr 0x30035e1f890
Thread bound to cpu id 0x8

t_state is 0x4 - TS_ONPROC

Scheduling info:
t_pri is 0x3b, t_epri is 0x0, t_cid is 0x1
scheduling class is: TS
t_disp_time: is 0x3df1fe5e, 0t1039269470
last switched: 30 secs ago on cpu 0x8

pc is 0x104ddb0, sp is 0x2a100471ad0, t_stk 0x2a100dd7af0

Stack trace is:

unix: setjmp ()
unix: panicsys+0x44 (0x105da90,0x2a100dd6688,0x23,0x1,0x8,0x8)
unix: vpanic (0x105da90,0x2a100dd6688)
unix: panic+0x1c (0x105da90,0x31,0x2a100dd68d0,0x64,0x0,0x148c24f)
unix: die+0x80 (0x31,0x2a100dd68d0,0x64,0x0)
unix: trap+0x874 (0x2a100dd68d0)
unix: ktl0
pcisch: pci_dma_pgpfn+0x44 (0x30011b91cd8,0x30028509388,0x4)
pcisch: pci_dma_pfn+0x12c (0x30011b91cd8,0x2a100dd6c30,0x30028509388)
pcisch: pci_dma_bindhdl+0x6c (0x30000a6caf8,0x30000a6b410,0x30028509388,0x2a100dd6c30,0x300e516bbb8,0x2a100dd6d2c)
genunix: ddi_dma_buf_bind_handle+0xfc (0x30028509388,0x3194f88a558,0x1,0x0,0x0,0x300e516bbb8)
qla2300: qla2x00_tran_init_pkt+0x290 (0x30000b73300,0x0,0x3194f88a558,0xa,0x20,0x0)
scsi: scsi_init_pkt+0x90 (0x30000b73300,0x0,0x3194f88a558,0xa,0x20,0x0)
sd: sd_initpkt_for_buf+0x124 (0x3194f88a558,0x2a100dd6fd8)
sd: sd_start_cmds+0x164 (0x30000ba4f80,0x0)
sd: sd_core_iostart+0x27c (0x4,0x30000ba4f80,0x3194f88a558,0x1507318,0x7fffffff,0x0)
sd: sd_xbuf_strategy (0x3194f88a558,0x30037fbe8c8,*0x30000b708e8)
sd: xbuf_iostart+0x138 (0x30000b70898,0x30000b70898,0x20,0x3001b93e9c8,0x1,0x8000)
sd: ddi_xbuf_qstrategy (0x3194f88a558,*0x30000ba4fd0)
sd: sdstrategy+0x12c (0x3194f88a558)
genunix: bdev_strategy+0x90 (0x3194f88a558)
vxdmp: gendmpstrategy+0x3c0 (0x34c464c96d8)
vxdmp: dmpstrategy (0x34c464c96d8)
genunix: bdev_strategy+0x90 (0x34c464c96d8)
vxio: voldiskiostart+0x6bc (0x36dfa6e0c70,0x300155df350,?,0xa8352c0?,0x40,0x1)
vxio: vol_subdisksio_start (0x36dfa6e0c70,0x2a100dd77d0)
vxio: volkcontext_process+0x518 (0x2a100dd77d0)
vxio: volkiostart+0x7fc (0x30037f5d118,0x2a100dd77d0,0x0)
vxio: vxiostrategy+0xa8 (0x30037f5d118)
genunix: aphysio+0x33c (0x1295848,0x107acf0,0x8000?,0x100,0x11ecda0,0x30037f5d090)
kaio: driver_aio_write (0x3001b86b080,*0x2a100dd79b8)
kaio: arw+0x144 (0x1,0x102,0x55fee0000,0x8000,0xebd8000,0x10370f8a8)
kaio: kaioc+0x80 (0x1,0x102,0x55fee0000,0x8000,0xebd8000,0x10370f8a8)
unix: syscall_trap+0x88 (0x1,0x102,0x55fee0000,0x8000,0xebd8000,0x10370f8a8)

Edited by: Simon Lai on 2009-9-21 上午2:56