Configuring SUN Solaris For Hosting Oracle Databases

Prior to installation of Oracle, the UNIX Server needs to be prepared for Oracle installation. This is a task that will be performed by the local UNIX System Administrator (and it should not be assumed that he/she will be familiar with all aspects of RDBMS set-up i.e. preparing a UNIX box as an Oracle database host). Briefly speaking check the following with the UNIX SA:

The UNIX operating system level to be installed. This must be an approved Solaris version with the patch level as specified in Oracle 9i installation guide for Solaris. Oracle 9i should not have any problem with Solaris 2.8

Shared Memory settings

The shared memory value of the operating system needs to be adjusted, otherwise Oracle instance cannot be created. On Solaris 2.8 which is a 64 bit O/S, the maximum shared addressable memory is 7FFFFFFFFFFFFFFF in HEX or 4096GB decimal. For 32 bit O/S, the maximum value that can be set is 4096 MB.

The maximum size of a single shared memory is set by the shmsys:shminfo_shmmax paramerter in /etc/system.

For 32 bit O/S this setting would be:
Set shmsys:shminfo_shmmax = (4096 x 1024 x 1024)-1 =  4294967295

For 64 bit O/S:
Set shmsys:shminfo_shmmax = (4096000000 x 1024 x 1024)-1 =  4294967295999999

Note that the 32 bit Oracle cannot address more than 3.5-3.75GB of memory per server in practice. That is to say the total SGA cannot be more than 3750MB. For Oracle 9 (64 bit) the maximum amount of shared memory that has been set so far is something around 150+ GB.

Assuming that you have 10GB of RAM on your Solaris host, then you can safely allocate 8GB of RAM to the shared memory. In that case, the maximum shared memory seeting would be:

Set shmsys:shminfo_shmmax = (8192 x 1024 x 1024)-1 =  8589934591

The shared memory segments parameter in /etc/system file may need to be adjusted. The default value is 6, which should be sufficient for most of your requirements. Otherwise if you are using multiple Oracle instances, you may have to increase this.

Set shmsys:shminfo_shmseg = 50

In addition, to ensure that enough semaphores are available for latches, there should be a forceload of semaphores in /etc/system. An example is shown below:

forceload: sys/semsys
forceload: sys/shmsys 
set semsys:seminfo_semmap=250
set semsys:seminfo_semmni=500
set semsys:seminfo_semmns=500
set semsys:seminfo_semmsl=500
set semsys:seminfo_semmnu=500
set semsys:seminfo_semume=100

Swap space

As an additional data point, large applications such as Oracle tend to have processes with large virtual address spaces. This is typically the result of attaching to large shared memory segments used by Oracle and large copy-on-write (COW) segments that get mapped but sometimes never actually get touched. The net effect of this is that on this host supporting multiple Oracle instances, the virtual address space requirements will grow to be quite large, typically exceeding the physical memory size of 8GB in this case. Consequently, we will require a fair amount of swap disk configured to support these multiple Oracle instances with large Virtual Address space running concurrently. As a result we will need to configure between 1 or 1.5 times the amount of max shared memory for swap so Oracle processes can fully utilize all of the physical memory without running out of virtual swap space.


The UNIX server needs to be rebooted after shared memory and semaphore settings.

"top" will show you how much RAM you have or do

/usr/sbin/prtconf|grep Mem ## shows available RAM

/usr/sbin/psrinfo -v  ## shows the CPUs and their speed

/usr/bin/ipcs -o      ## shows if shared memory is allocated

/usr/bin/ ipcs -sa |grep oracle ## counts used semaphores

/usr/sbin/ifconfig -a  ## show me the available IP addresses on this host