Semaphores and Shared Memory for Oracle
Semaphores and shared memory are two extremely different sets of operating system substances. Semaphores are a system resource that Oracle exploits for internal communication system of background processes and foreground processes and they dwell in a reasonably very small memory space. Shared memory is employed to hold the shared global area and can acquire a large portion of physical memory space. Means, semaphores occupy very small memory and shared memory contains large memory. Segment which resides in shared memory is called as shared memory segment and SGA resides in shared memory. Due to this reason, SGA is called as shared memory segment of operating system.
System memory resource allocation to semaphores and shared memory is organized by operating system kernel. Operating system kernel is core component of system. All resources are managed by kernel in Unix and Linux. For configuring semaphores there are three operating system kernel parameters available. These parameters allocate, control resource management to semaphores. Those are called as SEMMNI, SEMMSL, and SEMMNS. SEMMNI stands for semaphores identifiers or set of semaphores. Each semaphore set contains maximum number of SEMMSL value of semaphores. Total semaphores are available as value of SEMMNS. Maximum number of semaphores can be allocated on a system will be lesser of either (SEMMSL * SEMMNI) or value of SEMMNS.
When we are performing increment of total process of Oracle then we also need to consider semaphore management and configuration of kernel. Because sometimes we will get mysterious error like ORA-7239 “spcre: maximum number of semaphore sets exceeded”
Operating system kernel parameters of semaphore and shared memory segment can be altered but for getting effect we need to restart server and this is worst scenario for 24/7 running databases. When you are remote dba services then this scenario is very problematic for you. Due to this reason, you need to take of these parameters proactively. If you will be able to assume this kind of alteration then you can modify those parameters prior. When server will be rebooted as schedule maintenance or due to any disaster then your modified parameter will take effect automatically. You don’t need to set special downtime for same.
Means, every remote dba experts need to consider system kernel parameters with number of instances are running of single server, memory consumption and number of session/process running in same instance. If you are remotely monitoring your databases then you are able to plan DBA tasks proactively. Proactive DBA tasks are very important in remote dba area.
Expert DBA team of Dbametrixhttps://www.dbametrix.com published one another article how to be an Expert in Oracle tuning here. You can get more knowledge gaining articles for database administrator in our Expert DBA Team Club blog. Stay connected.