About SGA set of Limited of 32 bit or 64 bit in Unix
How to Create a Large SGA Without Relocating sgabeg on 32-bit Oracle?

One of our production data warehouse servers (Oracle 8.1.7.4 Solaris 2.6 sun4u
12GB memory) had a 256MB shmmax set in /etc/system for years, yet the total SGA
was over 2GB:

Total System Global Area 2367844512 bytes
Fixed Size 73888 bytes
Variable Size 187043840 bytes
Database Buffers 2129920000 bytes
Redo Buffers 50806784 bytes

One day we realized this mistake and changed shmmax to 4GB per Oracle817 Install
Guide A85471_01.pdf. Then we couldn't startup the instance and got the familiar
error:

SVRMGR> startup
ORA-27123: unable to attach to shared memory segment
SVR4 Error: 22: Invalid argument
Additional information: 1
Additional information: 106

How interesting! You could create a greater than 1.75 GB SGA without relocating
sgabeg (procedure outlined in Metalink Note:1028623.6). So I did some test on a
small Ultra2 box running Oracle 9.0.1.3 Solaris 2.6 with only 512MB RAM. What I
find is quite surprising. When shmmax is set to 268435456, 1073741824,
1610612736, 1879048192, 2013265920, 2076386194 or 2111934921, the instance can
startup OK: [note]

Total System Global Area 2131529288 bytes
Fixed Size 282184 bytes
Variable Size 218103808 bytes
Database Buffers 1912602624 bytes
Redo Buffers 540672 bytes

But when it's 2139506468, I get ORA-27123 when I try to startup Oracle. Why is
the jump from 2111934921 to 2139506468 significant? Because SGA is 2131529288,
a number between them! So, here's my conclusion:

********************************************************************************
If shmmax < SGA, you can always startup Oracle even with SGA > 1.75GB; but if
shmmax > SGA, the one segment rule will be enforced and therefore you can't
have an SGA > 1.75GB unless you relocate sgabeg.
********************************************************************************

There's of course an upper limit to which you can increase SGA. 32-bit OS only
allows 2^32 or 4GB virtual address space. The binary oracle, stack and many
shared libraries have to take some space. When you arbitrarily increase SGA,
you're squeezing down heap (used by Oracle PGA) to a smaller value. The above
conclusion basically states that sgabeg loses its meaning when shmmax < SGA and
some segments will be created under "sgabeg", achieving the same effect of
relocating the SGA beginning address to a lower value, only that multiple
segments instead of a single one are created.

Oracle Support's "explanation" why the one-segment rule is not enforced when
shmmax < SGA didn't convince me (see Tars 3018781.999 and 13791543.6 for those
who can view them).

By the way, there're some wrong or misleading notes on Meatalink. Note:221805.1
says 64-bit OS limits virtual address space to 29GB and therefore you can only
create an SGA smaller than 29-14=15GB (14 is sgabeg for 64-bit Oracle). But even
for UltraSPARC-I/II, the OS limit on virtual address space is 2^44 or 16TB
(see groups.google.com/groups?&selm=8i39dp%24j23%241%40new-usenet.uk.sun.com and
groups.google.com/groups?selm=2002510.22527.9963%40cable.prodigy.com). Oracle
Install Guide A96167-01 tells users to set shmmax to 4GB without a caveat that
this advice is only for 32-bit Oracle, except in the HPUX section where shmmax
is advised to set to "Available physical memory", the best advice of all!

Yong Huang