Re: LARGE Oracle Installation (Buffer Problems)

Alessandro Suardi (asuardi@uninetcom.it)
Thu, 25 Mar 1999 21:01:28 +0100

Michael Lausch wrote:
>
> >>>>> "cw" == Chris Wedgwood <cw@ix.net.nz>
> >>>>> wrote the following on Thu, 25 Mar 1999 14:28:48 +1200
>
> cw> On Tue, Mar 23, 1999 at 01:47:13PM +0100, Anas Nashif wrote:
> >> ORA-27123: unable to attach to shared memory segment
> >> Linux Error: 22: Invalid argument
> >> ^^^^^^^^^^^
>
> cw> I still think this is probably because your trying to use more sysV
> cw> memory that then kernel will allow.
>
> I found the problem. It's a bad interaction with glibc's malloc()
> implementation and programming proctice.
> malloc() uses mmap() for large memory chunks. Tghis mapping occurs at
> an memory area where the oracle programmers want to put their shared
> memory area. Look into the new strace oputput done with `strace -f '
> to catpure the child process.
>
> You see that mmap() happens around the same memory addres which is
> passed to the shmat() call as the desired address parameter.
>
> Solutions?
>
> o either change the program to use no address or another
> address for the shmat() call,

This is feasible. Oracle comes with a tool called genksms which, invoked,
generates output to redirect in a .s file which contains the SGA begin
address symbol (sgabeg). In fact,

[oracle@dogbert bin]$ genksms|head -5
.set sgabeg,0X20000000
.globl ksmsgf_
.set ksmsgf_,sgabeg+0
.globl ksmvsg_
.set ksmvsg_,sgabeg+4
[oracle@dogbert bin]$

Check ins_rdbms.mk for further details on how to relink Oracle to
start with a different sgabeg.

I'll try and reproduce it locally since I got different behaviors
with different values for Oracle init params and different SHMMAX's.

Cheers,

--alessandro <asuardi@uninetcom.it> <asuardi@it.oracle.com>

Linux 2.0.36/2.2.4 glibc-2.0.7-29 gcc-2.8.1 binutils-2.9.1.0.19a

"I hate bugs which disappear just as soon as you start trying to
narrow things down." -- Stephen Tweedie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/