Re: Discontiguous SGA under Solaris 2.5.1? Why?

Jim,

If you haven't received a reply yet, here is what you do:- Solution: relocate the base address of the SGA Method:
1. in the ORACLE_HOME/rdnms/lib directory there should be a file called 'ksms.s'. If this doesn't exist, use 'genksms > ksms.s'. 2. Edit the file and change the FIRST occurence of 'sgabeg' from say '0xe0000000' to '0xc0000000' (decreasing the alphanumeric increase the allowable shared memory segment.
3. Shutdown the database and relink the kernel - depending on the version of Oracle you are using, there may be 2 make files in the lib directory. If there are two, then one of them says it is for relinking the kernel. If only one, it is probably called 'oracle.mk'. Perform a 'make -f oracle.mk oracle' 4. Replace the ORACLE_HOME/bin/oracle file with the new one in the ORACLE_HOME/rdbms/lib directory.
5. Set the permissions on the file by 'chmod 4751'. 6. Restart the database with the amended init.ora file.

HTH Tim Moss

In article <5lnl6f$e1g_at_vu-vlsi.ee.vill.edu>, Jim Reynolds <reynolds_at_vuvlsi. ee.vill.edu> writes
>We're running Oracle 7.3.2 on a two processor Sun Ultra 2 with 512MB RAM.
>Here are some parameters from /etc/system:
>
>set shmsys:shminfo_shmmax=402653184
>set shmsys:shminfo_shmmni=100
>set shmsys:shminfo_shmseg=10
>
>Is 384 MB the largest size of the shared memory space, or the largest size
>of a single segment of shared memory (of which there can be up to 10).
>
>Either way, we have a 60MB SGA and would like to have around 300MB of
>buffer cache. The problem is that we're stuck at ~256MB, and the shared
>memory usage refuses to go any higher(i.e. oracle won't start up). So we
>ran tstshm-- the output is very confusing, and I'm wondering if it's even
>working correctly:
>
>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 = -2621440 bytes
>Default shared memory address = 0xef300000
>Lowest shared memory address = 0xfff80000
>Highest shared memory address = 0xef300000
>Total shared memory range = -279445504
>Total shared memory attached = 20971520
>Largest single segment size = 2097152
>Segment boundaries (SHMLBA) = 8192 (0x2000)
>
>This seems to indicate that oracle is only using ~20MB of shared memory,
>which is not the case-- it's more like 256MB. And it also appears that
>oracle is getting 2MB chunks of memory, as opposed to one large chunk
>which it should.
>
>Here's the output from ipcs -mb:
>
>Shared Memory:
>m 600 0x0b21b0d5 --rw-rw---- oracle dba 256040960
>
>That's about as high as we can get it (to within 1%) that will still
>allow oracle to start. You'll notice that the memory addresses don't jive
>with what tstshm is reporting. And neither do the sizes. Also, oracle
>reports multiple segments while ipcs reports a single one.
>
>We're going to try increasing the number of segments from 10 to 100, and
>we susepct that will allow us to further increase the SGA. However, I'd
>like to understand why a) oracle is grabbing small chunks of memory and b)
>how to read the output of tstshm (an oracle command) so that it makes
>sense.
>
>Any help would be appreciated. Thanks.
>
>Jim.
 

-- 
Tim Moss