Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> [OT?] RHEL ES4 dies during attempts to create another 10gR2 datab ase via dbca

[OT?] RHEL ES4 dies during attempts to create another 10gR2 datab ase via dbca

From: Branimir Petrovic <BranimirP_at_cpas.com>
Date: Mon, 6 Feb 2006 17:53:00 -0500
Message-ID: <33678E78A2DD4D418396703A750048D4010259A8@RIKER>


Experiencing strange problem: on a small Dell "box" (dual CPU PE1850 with 6GB RAM, build in SCSI and 2x146GB HDDs) with RHEL 4 EL and Oracle 10gR2 with 5 toy databases, attempt to create sixth toy database while other five are running (nay - idling is better term) would consistently end up crashing OS!?

System have plenty of available RAM before starting dbca:

$ free

             total       used       free     shared    buffers     cached
Mem:       6232024    1930540    4301484          0      43336    1442824
-/+ buffers/cache:     444380    5787644
Swap:      4192956          0    4192956


15 minutes into creating sixth database (typically while adding XML DB) and my Linux host disappears from the network. Clue found in /var/log/messages:

Feb  6 14:39:52 s-ora-014 kernel: ------------[ cut here ]------------
Feb  6 14:39:52 s-ora-014 kernel: kernel BUG at mm/prio_tree.c:528!
Feb  6 14:39:52 s-ora-014 kernel: invalid operand: 0000 [#1]
Feb  6 14:39:52 s-ora-014 kernel: SMP 
Feb  6 14:39:52 s-ora-014 kernel: Modules linked in: parport_pc lp parport
autofs4 i2c_dev i2c_core sunrpc dm_mirror dm_mod button battery ac md5 ipv6 uhci_hcd ehci_hcd hw_random shpchp e1000 floppy sg ext3 jbd mptscsih mptbase sd_mod scsi_mod
Feb 6 14:39:52 s-ora-014 kernel: CPU: 1 Feb 6 14:39:52 s-ora-014 kernel: EIP: 0060:[<c0145299>] Not tainted VLI
Feb  6 14:39:52 s-ora-014 kernel: EFLAGS: 00010202   (2.6.9-22.0.2.ELsmp) 
Feb  6 14:39:52 s-ora-014 kernel: EIP is at vma_prio_tree_add+0x36/0x95
Feb  6 14:39:52 s-ora-014 kernel: eax: 0000000e   ebx: f706af3c   ecx:
00000000 edx: 000000cf
Feb 6 14:39:52 s-ora-014 kernel: esi: f3dcdc7c edi: b5d34000 ebp: f28e2080 esp: f56b9ee0
Feb 6 14:39:52 s-ora-014 kernel: ds: 007b es: 007b ss: 0068 Feb 6 14:39:52 s-ora-014 kernel: Process oracle (pid: 5706, threadinfo=f56b9000 task=f21accb0)
Feb 6 14:39:52 s-ora-014 kernel: Stack: d8be58b4 f706af3c c014e62d 00000000 00000000 00000000 e177934c ee8d4680
Feb 6 14:39:52 s-ora-014 kernel: f5983d80 f5983d64 00000000 b5c64000 de4594ec f706af3c b5d34000 00000000
Feb 6 14:39:52 s-ora-014 kernel: c014f916 00000000 de4594ec f28e2080 b5da4000 f706af3c b5d34000 f28e2080
Feb  6 14:39:52 s-ora-014 kernel: Call Trace:
Feb  6 14:39:52 s-ora-014 kernel:  [<c014e62d>] vma_adjust+0x20d/0x2d6
Feb  6 14:39:52 s-ora-014 kernel:  [<c014f916>] split_vma+0xc6/0xd2
Feb  6 14:39:52 s-ora-014 kernel:  [<c014f9c8>] do_munmap+0xa6/0x137
Feb  6 14:39:52 s-ora-014 kernel:  [<c014eced>] do_mmap_pgoff+0x311/0x666
Feb  6 14:39:52 s-ora-014 kernel:  [<c010b69b>] sys_mmap2+0x7e/0xaf
Feb  6 14:39:52 s-ora-014 kernel:  [<c02d137f>] syscall_call+0x7/0xb
Feb  6 14:39:52 s-ora-014 kernel:  [<c02d007b>] _read_lock_irq+0x4/0x1e
Feb  6 14:39:52 s-ora-014 kernel: Code: c3 39 ca 74 08 0f 0b 0f 02 83 4e 2e
c0 8b 43 08 2b 43 04 c1 e8 0c 8d 54 02 ff 8b 46 08 2b 46 04 c1 e8 0c 8d 44 01 ff 39 c2 74 08 <0f> 0b 10 02 83 4e 2e c0 c7 43 34 00 00 00 00 83 7e 34 00 c7 43
Feb  6 14:39:53 s-ora-014 kernel:  <0>Fatal exception: panic in 5 seconds
Feb  6 14:49:43 s-ora-014 syslogd 1.4.1: restart.
Feb  6 14:49:43 s-ora-014 syslog: syslogd startup succeeded
Feb  6 14:49:43 s-ora-014 kernel: klogd 1.4.1, log source = /proc/kmsg
started.

Not being *nix "blessed" at all, I stare in bewilderment in the above log trace not knowing what (if anythging) to make of it... Workaround for the issue appears to lie in having other databases on Linux host stopped before attempting to create yet another one, but this "solution" does not sound right at all (although in my situation it is acceptable to do so).

Any better idea?

Branimir

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Feb 06 2006 - 16:53:00 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US