Re: Shared memory problems (Solaris 2.3 + Oracle 7.0.15)

In article <2lq44a$ilo_at_hafro.is> gunnaro_at_hafro.is (Gunnar Orvarsson) writes:
>We have been having major problems trying to get Oracle to run on this
>machine. The problems seem to be related to accessing shared memory.
>
>I have set up the shared memory parameters as recommended by Oracle:
>
> set shmsys:shminfo_shmmax=8388608
> set shmsys:shminfo_shmmin=1
> set shmsys:shminfo_shmmni=100
> set shmsys:shminfo_shmseg=10
>
> set semsys:seminfo_semmns=200
> set semsys:seminfo_semmni=70
> set semsys:seminfo_semmsl=100
>
>Running the Oracle program for testing shared memory (tstshm) results gives:
>
> Number of segments gotten by shmget() = 50
> Number of segments attached by shmat() = 10
> Segments attach at lower addresses
> Maximum size segments are not attached contiguously!
> Segment separation = -2359296 bytes
> Default shared memory address = 0xef480000
> Lowest shared memory address = 0xfff00000
> Highest shared memory address = 0xef480000
> Total shared memory range = -277348352
> Total shared memory attached = 20971520
> Largest single segment size = 2097152
> Segment boundaries (SHMLBA) = 4096 (0x1000)
>
>Although the database isn't under heavy load, it crashes the system with
>horrible messages like:
>
> panic: already allocated shared memory l1 ptp
> syncing file systems ...panic: panic sync timeout
> ....
>
>or:
> unix: panic: already allocated shared memory l1 ptp
> unix: syncing file systems...BAD TRAP:
> type=9 rp=f0804d8c addr=10 mmu_fsr=1a6 rw=2
> unix: oracle: Data fault
> unix: kernel write fault at addr=0x10,pme=0x0
> unix: MMU sfsr=1a6: Invalid Address on supv data stor
> ...
>
>Does anyone know what might be wrong with our configuration? Are there
>special problems that might arise, with this kind of hardware? Are
>there any special patches that must be installed?

You too? I thought I was alone in this. I'm running Solaris 2.3, with Oracle 7.0.15.4, and the server process either gets nuked with a SEGV signal, or it becomes a runaway, soaking up CPU time and not accomplishing anything. A user process can run for just a few transactions before the server process pulls off this magic trick.

Something is way wrong here, and I would appreciate any insight.

Thanx, Marty (output_at_netcom.com) Received on Fri Mar 11 1994 - 20:18:31 CET