My thanks to Terry Rosenbaum (<radiology.msu.edu!tlr@snowbird>),
the only respondent from the list, who appears to have the answer
to my problem.
I'm sending the summary now since I'm very involved with another
problem and haven't yet had a chance to try it.
The original request is included below, followed by Terry's
response.
***************************Original Query***************************
We have an application that interfaces with Oracle V7.0.9 Developer's
Release on an IPC running Solaris 1.1 with 24M RAM, with no problem.
I installed Oracle V7.0.12 Production release on a SPARC10/30 running
Solaris 1.1 with 128M RAM. When our application starts up on the SPARC10,
it is able to talk to Oracle for a short time, but then the application
goes away (on its third query--the first query that includes a blob or
long raw).
So I deleted Oracle V7.0.12 from the SPARC10 and tried to install V7.0.9
Developer's Release to see if that would run. When Oracle tried to create
the database files, it exited with an error "ORA-7331: smsnsg: Unable to
allocate the variable portion of the SGA", which means the following
(according to Oracle documentation):
"The variable portion of the SGA is too big to fit continuously into one
segment. Reconfigure the UNIX kernel to have bigger segments."
Well, I have set the SHMSIZE up to various levels (as high as 32K) and
still have the same problem.
We have called Oracle Customer Support but as usual they are slow to
respond.
Questions:
How can I get the shared memory segment size jacked up so that Oracle
can run? Is there another parameter I need to be setting?
Does anyone have Oracle7 Production Release installed on a SPARC10/30
and had any problems accessing blobs?
Any help you can offer would be greatly appreciated. I need to get this
resolved quickly!
Thanks.
******************************Response******************************
Hi David,
I too experienced a similar problem under Solaris 1.1 (SunOS 4.1.3 ?).
I was unable to increase the shared memory segment size (or was it the
maximum # of segments ? -- sorry, I forget).
It seemed that, for a reason I never took time to figure out, the
config parameters for shared memory in the config file were being
overriden when config was run.
My solution was to directly modify the shminfo structure in the kernel
executable using adb.
>From /usr/include/sys/shm.h:
/*
* Shared Memory information structure
*/
struct shminfo {
int shmmax, /* max shared memory segment size */
shmmin, /* min shared memory segment size */
shmmni, /* # of shared memory identifiers */
shmseg, /* (obsolete) */
shmall; /* (obsolete) */
};
All that you need to do is to use adb (as root) to update the above
structure in the kernel executable, and then reboot:
toy* adb -wk /vmunix /dev/mem
physmem 3f99
shminfo?D
_shminfo:
_shminfo: 1048576
_shminfo+4: 1
_shminfo+8: 1024
_shminfo+0xc: 0
_shminfo+0x10: 0
The structure members correspond as follows:
_shminfo: shminfo.shmmax /* max shared memory segment size */
_shminfo+4: shminfo.shmmin /* min shared memory segment size */
_shminfo+8: shminfo.shmmni /* # of shared memory identifiers */
_shminfo+0xc: shminfo.shmseg /* (obsolete) */
_shminfo+0x10: shminfo.shmall /* (obsolete) */
To modify the maximum segment size, all you need to do is modify the
shminfo.shmmax member with a W command:
shminfo?W 2000000
_shminfo: 0x100000 = 0x2000000
<ctrl-D>
toy*
The above would set shmmax to 32K * 1024 bytes, equivilant to setting
config item SHMSIZE to 32K. (Don't forget to reboot.)
I recommend ensuring that your config source file reflects the change, even
though the change doesn't take effect when rebuilding the kernel from the
config file (liberal comments explaining what's going on and what to do are
useful too :).
Regards,
Terry
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:44 CDT