Skip to main content

ABOUT SHMALL, SHMMAX AND SHMMNI KERNAL PARAMETER

SHMALL => MAXIMUM SHARED MEMORY ALLOCATED THAT THE SERVER CAN USE APART FROM THE PROCESSES UNIX TO RUN.

SHMMAX => WHAT SHOULD BE THE MAXIMUM SIZE THAT EACH SHARED MEMORY CAN HAVE IN PHYSICAL RAM.

SHMMNI => This parameter sets the system-wide maximum number of shared memory segments.

using below we ca check and edit these parameters

KERNAL PARAMETERS: LOCATION:  /PROC/SYS/KERNAL

cd /prod/sys/kermal

 
:-) ls -ltr shm*

-rw-r--r-- 1 root root 0 May 15 05:46 shmmax

-rw-r--r-- 1 root root 0 May 15 09:23 shmmni

-rw-r--r-- 1 root root 0 May 15 09:23 shmall

sysctl -a | grep shm


TO CHANGE KERNAL PARAMETERS:


sysctl -w kernal.shmmax="xxxxxx"

vi /etc/sysctl.conf  => edit and save the file.

run sysctl -p command after editing the file. the changes will affect without restarting the server.


SHMMAX and SHMALL are two key shared memory parameters that directly impact the way by which Oracle creates an SGA. While trying to create an SGA during a database startup, Oracle chooses from one of the 3 memory management models a) one-segment or b) contiguous-multi segment or c) non-contiguous multi-segment. The adoption of any of these models is dependent on the size of SGA and values defined for the shared memory parameters in the Linux kernel, most importantly SHMMAX.


While trying to create an SGA during a database startup, Oracle chooses from one of the 3 memory management models a) one-segment or b) contiguous-multi segment or c) non-contiguous multi-segment. The adoption of any of these models is dependent on the size of SGA and values defined for the shared memory parameters in the Linux kernel, most importantly SHMMAX.

What’s the optimal value for SHMALL?

As SHMALL is the total size of Shared Memory Segments System-wide, it should always be less than the Physical Memory on the System and should be greater than the sum of SGA’s of all the oracle databases on the server. Once this value (sum of SGA’s) hit the limit, i.e. the value of shmall, then any attempt to start a new database (or even an existing database with a resized SGA) will result in an “out of memory” error (below). This is because there won’t be any more shared memory segments that Linux can allocate for SGA.

 
ORA-27102: out of memory

Linux-x86_64 Error: 28: No space left on device.

 
What’s the optimal value for SHMMAX?

Oracle makes use of one of the 3 memory management models to create the SGA during database startup and it does this in the following sequence. First Oracle attempts to use the one-segment model and if this fails, it proceeds with the next one which’s the contiguous multi-segment model and if that fails too, it goes with the last option which is the non-contiguous multi-segment model.

So during startup, it looks for shmmax parameter and compares it with the initialization parameter *.sga_target. If shmmax > *.sga_target, then oracle goes with a one-segment model approach where the entire SGA is created within a single shared memory segment.

But the above attempt (one-segment) fails if SGA size otherwise *.sga_target > shmmax, then Oracle proceeds with the 2nd option – contiguous multi-segment model. Contiguous allocations, as the name indicates are a set of shared memory segments that are contiguous within the memory and if it can find such a set of segments then the entire SGA is created to fit in within this set.

But if it cannot find a set of contiguous allocations then last of the 3 options is chosen – non-contiguous multi-segment allocation and in this Oracle has to grab the free memory segments fragmented between used spaces.

So let’s say if you know the max size of SGA of any database on the server stays below 1GB, you can set shmmax to 1 GB. But say if you have SGA sizes for different databases spread between 512MB to 2GB, then set shmmax to 2Gigs and so on.
Labels:

Comments

Post a Comment

Popular posts from this blog

ORA-28007: THE PASSWORD CANNOT NE REUSED

             - Here will see how to deal with  => ORA-28007: the password cannot be reused -  I got a request from client user, stating his account has been locked. When I check the status of the account I found the below. connect to SYS user & execute the below query of that database. SQL> select password,username,account_status,profile from dba_users where username='TEST'; PASSWORD               USERNAME   ACCOUNT_STATUS                 PROFILE ------------------             ----------------  -------------------------------           -------------------- AB2Aa8AC9971521e3     TEST       EXPIRED(GRACE)&LOCKED    NONAPP_USERS So, then I have unlocked the account and checked the same again & I found the below results. ...
Post a Comment
Read more

ORA-39014: One or more workers have prematurely exited.ORA-00018: maximum number of sessions exceeded

ERROR: I was Performing a full database import and during the import I faced the below error. ORA-39014: One or more workers have prematurely exited. ORA-39029: worker 6 with process name "DW07" prematurely terminated ORA-31672: Worker process DW07 died unexpectedly. Job "SYSTEM"."SYS_IMPORT_FULL_04" stopped due to fatal error at 00:59:40 ORA-39014: One or more workers have prematurely exited. SOLUTION:  Run the import with fewer parallel processes, like PARALLEL=2 instead of 8. I was able to run the import successfully. NOTE 1: This errors occurs when there are less session allocation in the database. check the session,process parameters and increase them accordingly. To avoid such errors again. NOTE 2 : Note: Increasing processes parameter increases the amount of shared memory that needs to be reserved & the OS must be configured to support the larger amount of shared memory. So here we first need to increase the Memory & SG...
Post a Comment
Read more