Introduction

Oracle Database is not just an application — it is a resource-intensive system that relies heavily on the operating system for memory management, inter-process communication, file handling, and networking.

On Linux, these resources are controlled by kernel parameters. If they are not configured correctly:

Oracle installation may fail
Database instances may not start
Performance issues can appear under load
Production outages can occur

This article explains Oracle 19c Linux kernel parameters in depth, including:

Why they are required
What problem each parameter solves
Minimum and recommended values
How to calculate them correctly
Best practices for multiple databases on a single server
Oracle user limits (often ignored, but critical)
Real-world production guidance

Why Oracle Requires Kernel Parameter Tuning

Oracle uses several Linux kernel facilities extensively:

Shared memory → for the SGA
Semaphores → for process synchronization
File descriptors → for datafiles, redo logs, archive logs
Asynchronous I/O → for database performance
Network buffers and ports → for client connections

Linux default kernel values are designed for general-purpose systems, not databases. Oracle therefore requires these limits to be raised to ensure stability and performance.

Important: Kernel parameters are system-wide, not per database.

🛠️ The Key Oracle-Relevant Kernel Parameters & What They Do

1) Shared Memory Parameters

Oracle uses shared memory for SGA and inter-process communication.

1️⃣ What Is a Shared Memory Segment?

Plain-English Definition

A shared memory segment is a region of physical RAM that:

Is created by the operating system
Can be attached to by multiple processes at the same time
Allows those processes to read/write the same data directly

👉 It is the fastest inter-process communication (IPC) mechanism available in Linux.

Why Shared Memory Exists

Normally, each Linux process has:

Its own private memory
No direct access to another process’s memory

But databases (like Oracle) need:

Many processes to work on the same data structures
Extremely fast access (not via files or sockets)

Shared memory solves this.

Simple Mental Model

Think of shared memory as:

🧠 A whiteboard in a room
Multiple people (processes) can look at it and write on it at the same time

Instead of each person having their own copy.

2️⃣ Shared Memory in Oracle

Oracle’s SGA = Shared Memory

In Oracle:

The System Global Area (SGA) is implemented using shared memory segments
Every Oracle background process and user session attaches to the same SGA

Examples of what lives in shared memory:

Buffer Cache
Shared Pool
Redo Log Buffer
Library Cache
Dictionary Cache

Parameter	What It Controls	Why Needed
`shmmax`	Maximum size of a single shared memory segment (in bytes)	Oracle’s SGA can require large contiguous memory; needs this upper bound large enough
`shmall`	Total shared memory pages (system-wide)	Must cover all shared memory segments Oracle will use
`shmmni`	Max number of shared memory segments	Controls how many segments can exist concurrently

👉 If these are too small, Oracle may not allocate enough memory and installation/instance startup fails.

2) Semaphore Parameters

Semaphores manage concurrent access by multiple Oracle processes to shared memory.

3️⃣ What Is a Semaphore?

Plain-English Definition

A semaphore is a kernel-managed synchronization mechanism that:

Controls who can access shared memory
Prevents data corruption when multiple processes act simultaneously

👉 Shared memory allows fast access
👉 Semaphores ensure safe access

Why Semaphores Are Needed

Imagine 50 Oracle processes:

All trying to update the same memory structure
At the same time

Without control:

Memory corruption
Inconsistent data
Database crashes

Semaphores prevent this chaos.

Simple Mental Model

Think of a semaphore as:

🚦 A traffic signal or a lock
Only a certain number of processes can pass at once

4️⃣ How Semaphores Work (Conceptually)

A semaphore maintains a counter:

If counter > 0 → process is allowed
If counter = 0 → process must wait

Operations:

P (wait) → decrement counter
V (signal) → increment counter

Linux manages this at kernel level.

5️⃣ Semaphores in Oracle

Oracle uses semaphores to:

Protect shared memory structures
Synchronize background and foreground processes
Manage latches, locks, and internal coordination

Every Oracle instance:

Allocates multiple semaphore sets
Uses thousands of semaphore operations per second

Relevant Kernel Parameter

kernel.sem = semmsl semmns semopm semmni

Field	Meaning	Oracle Impact
semmsl	Semaphores per set	Limits concurrency
semmns	Total semaphores	Affects max processes
semopm	Ops per call	Performance
semmni	Semaphore sets	Multiple instances

If semaphore limits are too low:

Database may start but fail under load
ORA-27300 / ORA-27301 errors
Sessions hang waiting for resources

6️⃣ Shared Memory vs Semaphores (Together)

They always work together.

Shared Memory	Semaphores
Stores data	Controls access
Fast	Safe
Passive	Active
Memory	Synchronization

Without Semaphores:

❌ Data corruption
❌ Race conditions
❌ Crashes

Without Shared Memory:

❌ Slow IPC
❌ File-based communication
❌ Terrible database performance

7️⃣ Oracle Startup Flow (Simplified)

Oracle requests shared memory for SGA
Kernel checks:
- shmmax
- shmall
Oracle creates semaphore sets
Kernel checks:
- kernel.sem
Oracle background processes attach to SGA
Database opens

If any step fails, the instance won’t start.

8️⃣ Why These Concepts Matter in Production

Real-World Scenarios

High concurrency OLTP
- Heavy semaphore usage
- Poor tuning → session waits
Multiple databases
- Shared kernel limits
- One DB can starve others
Memory pressure
- Insufficient shared memory
- OS kills processes (OOM)

9️⃣ Common Misunderstandings

❌ Shared memory is per database
✔ It’s system-wide

❌ Semaphores are optional
✔ Oracle cannot run without them

❌ Bigger SGA always means better performance
✔ Only if kernel limits support it

10️⃣ One-Line Summary

Shared memory lets Oracle processes share data fast.
Semaphores make sure they don’t destroy each other while doing it.

Parameter	Meaning
`semmsl`	Max semaphores per semaphore set
`semmns`	Total system semaphores
`semopm`	Max operations per semop call
`semmni`	Max semaphore sets

Oracle uses semaphores for locking shared memory regions between background and user processes. Too low → lock contention/fails.

3) File Handles

Parameter	Purpose
`file-max`	Maximum open files/handles system-wide

Databases open many files (datafiles, redo logs, control files, archive logs etc.). If file-max is too low, OS will refuse new file descriptors.

4) Asynchronous I/O

Parameter	Purpose
`aio-max-nr`	Max concurrent AIO requests

Oracle performs lots of async I/O; without enough slots, I/O subsystem bottlenecks occur.

5) Networking Buffers / Ports

For connection throughput and ephemeral (quick-temporary) port usage:

Parameter	Purpose
`ip_local_port_range`	Range of ephemeral TCP ports
`rmem_default`, `rmem_max`	Rx buffer sizes
`wmem_default`, `wmem_max`	Tx buffer sizes

These settings ensure the kernel supports enough ports and buffers for many client connections.

📊 Minimum Values Required by Oracle 19c

Here are the commonly used minimums (these are from Oracle’s official documentation) — you can paste these into /etc/sysctl.conf:

kernel.sem = 250 32000 100 128
kernel.shmmax = <half of physical RAM in bytes>
kernel.shmall = <shmmax / PAGE_SIZE>
kernel.shmmni = 4096
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576

✔ These values are minimum installation requirements only — Oracle recommends tuning above these for production.

📐 How to Calculate the Values

🎯 1) `shmmax`

This should be enough to hold your largest SGA:

👉 Oracle’s rule of thumb (minimum):

shmmax = min( half of RAM in bytes, (4GB - 1) )

Example:
If you have 16GB RAM → half = 8GB → use shmmax = 8GB
If you have 6GB RAM → half = 3GB → use shmmax = 3GB

🎯 2) `shmall`

Linux counts shared memory in pages (page sizes usually 4096 bytes)

shmall = ⌈shmmax / PAGE_SIZE⌉

Example:
shmmax = 8GB → 8 × 1024³ = 8,589,934,592 bytes
Page size = 4096
→ shmall = 8589934592 / 4096 = 2097152 pages

Set equal or higher.

🎯 3) Semaphore Counts

Oracle’s defaults are simple constants based on typical DB processes:

semmsl = 250
semmns = 32000
semopm = 100
semmni = 128

There’s no real formula — these come from Oracle testing and process model.

🎯 4) File Handles

Oracle’s own examples use:

fs.file-max = 6815744

But you can derive a guideline:

file-max ≥ 512 × PROCESSES

Where PROCESSES = expected Oracle processes (background + users).

🛠 Checking & Applying These

Check current values:

sysctl -a | grep sem
sysctl -a | grep shm
sysctl -a | grep file-max
sysctl -a | grep ip_local_port_range
sysctl -a | grep rmem

Apply new values:

Add to /etc/sysctl.conf, e.g.:

cat >> /etc/sysctl.conf <<EOF
kernel.sem = 250 32000 100 128
kernel.shmmax = 8589934592
kernel.shmall = 2097152
...
EOF

sysctl -p

📘 Why These Matter in Practice

Problem if not set	Symptom
`shmmax` too small	Oracle fails to start SGA; installer errors
`shmall` too small	Shared memory allocation fails
Semaphores too low	Locking and inter-process issues
`file-max` low	“Too many open files” errors
AIO too low	I/O stalls
Network buffers low	Poor connect performance

📚 References to Learn More

Here are the official Oracle docs you can study:

🔗 Oracle Database Installation Guide — Configuring Kernel Parameters for Linux — covers details on each param and how to set them manually.

🔗 Oracle Database Minimum Parameter Settings for Installation Table — gives values and defaults.

Scenario: assume the RAM size is 32 GB and on that production server we need to configure 3 databases- db1, db2, db3. For this configuration what would be the recommended, best practice approach to configure these parameter? Also a production server with RAM size 32 GB, how many databases can be configured?

Comment: This is exactly where real-world Oracle administration starts, because the answer is not “just follow the minimums.” For a 32 GB production server running multiple Oracle 19c databases, kernel tuning must be done holistically, not per-database.

Let’s break this into clear layers:

Core principle (very important)
How kernel parameters work with multiple databases
Recommended kernel parameter values for 32 GB RAM
How to size memory per database (SGA + PGA)
How many databases can realistically run on 32 GB
Best-practice architecture decisions
Common mistakes to avoid

1️⃣ Core Principle (Read This First)

👉 Kernel parameters are system-wide, not per database.

That means:

You do NOT divide kernel parameters among db1, db2, db3
Kernel limits must be large enough to support the sum total of:
- All SGAs
- All PGAs
- All Oracle background + user processes
- OS needs

Oracle instances then compete within those limits, controlled mainly by Oracle memory parameters, not sysctl.

2️⃣ How Kernel Parameters Work with Multiple Databases

Layer	Responsibility
Linux kernel	Upper hard limits (shared memory, semaphores, files)
Oracle instance	Uses memory within those limits
DBA	Ensures kernel > Oracle total requirement

Think of kernel parameters as “the size of the room”, and Oracle instances as “furniture inside it.”

3️⃣ Recommended Kernel Parameters for 32 GB RAM (3 DBs)

These values are safe, production-grade, and align with Oracle best practices for multi-instance servers.

🔹 Shared Memory

`kernel.shmmax`

Purpose: Maximum size of a single shared memory segment
Best practice: 70–80% of physical RAM

32 GB RAM
→ 32 × 1024³ = 34,359,738,368 bytes
→ Recommended shmmax ≈ 24 GB

✅ Set:

kernel.shmmax = 25769803776   # 24 GB

Why not half RAM?
Because modern Oracle uses AMM/ASMM, and production systems benefit from higher ceilings.

`kernel.shmall`

Purpose: Total shared memory pages system-wide

shmall = shmmax / PAGE_SIZE
PAGE_SIZE = 4096 bytes

= 25769803776 / 4096
= 6,291,456 pages

✅ Set:

kernel.shmall = 6291456

`kernel.shmmni`

Purpose: Number of shared memory segments

Oracle recommends:

kernel.shmmni = 4096

This easily supports multiple instances.

🔹 Semaphores

Semaphores are shared across all databases.

Recommended:

kernel.sem = 250 64000 100 4096

Explanation:

semmns increased to support multiple instances
semmni raised to allow more semaphore sets

🔹 File Handles

Production systems with multiple DBs open thousands of files.

fs.file-max = 6815744

Also ensure Oracle user limits:

oracle soft nofile 1024
oracle hard nofile 65536

🔹 Async I/O

fs.aio-max-nr = 1048576

Critical for datafile and redo performance.

🔹 Networking

net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576

Important when:

Multiple DB listeners
App servers with many connections

4️⃣ How to Size Memory for db1, db2, db3

This is more important than kernel tuning.

🔹 Rule #1: Leave Memory for OS

On a 32 GB server:

Reserve 6–8 GB for OS + filesystem cache

👉 Available for Oracle ≈ 24–26 GB

🔹 Rule #2: Decide Memory Model

Best practice in multi-DB environments:

Use ASMM, not full AMM
Explicitly control SGA + PGA

🔹 Example Balanced Layout (Production-Safe)

Database	SGA	PGA Target	Total
db1 (primary)	8 GB	2 GB	10 GB
db2 (medium)	6 GB	1.5 GB	7.5 GB
db3 (light)	4 GB	1 GB	5 GB
Total Oracle			22.5 GB

This fits safely under:

shmmax = 24 GB
Leaves OS breathing room

🔹 Example Initialization Parameters

*.sga_target=8G
*.sga_max_size=8G
*.pga_aggregate_target=2G

Repeat per DB with appropriate sizing.

5️⃣ How Many Databases Can a 32 GB Server Run?

❗ The honest answer:

It depends on workload, not RAM alone

Practical Guidelines

Type of Database	Approx. Count
Heavy OLTP	1–2
Medium OLTP	2–3
Light / reporting	3–5
Very small apps	6–8 (not recommended for prod)

Real-world best practice:

3 databases on 32 GB → ✔️ very reasonable
More than 4 → usually bad for production unless workloads are tiny

6️⃣ Production Best-Practice Architecture

✔ Recommended

1 OS
Multiple Oracle homes (optional but clean)
Separate listeners (or shared if ports managed)
Explicit SGA/PGA per DB
System-wide kernel tuned once

🚫 Not Recommended

Letting all DBs use AMM freely
sga_max_size left unlimited
Too many small databases on one host
Ignoring OS cache needs

7️⃣ Common Mistakes (Seen in Production 😬)

❌ Setting shmmax = 32GB and letting Oracle starve OS
❌ Assuming kernel params must be split per database
❌ Using AMM for multiple databases
❌ Running 6–7 production DBs on 32 GB
❌ Ignoring ulimit settings for oracle user

📌 Final Recommended Kernel Config (32 GB, 3 DBs)

kernel.shmmax = 25769803776
kernel.shmall = 6291456
kernel.shmmni = 4096
kernel.sem = 250 64000 100 4096
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576

📚 Official References (Must-Read)

Oracle 19c Linux Kernel Parameters
https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/configuring-kernel-parameters-for-linux.html
Minimum Kernel Settings
https://docs.oracle.com/en/database/oracle/oracle-database/19/cwlin/minimum-parameter-settings-for-installation.html
Oracle Memory Architecture Concepts
https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/memory-architecture.html

Demo: Understanding the Impact of Kernel Parameters on Oracle Database

Demo Objectives

By the end of this demo, you will visually see:

Oracle failing due to insufficient shared memory
Oracle failing due to insufficient semaphores
How kernel limits affect instance startup
Why kernel tuning is mandatory, not optional

Lab Setup (Minimal)

Component	Value
OS	Oracle Linux / RHEL / CentOS
RAM	8–16 GB (enough for demo)
Oracle	19c (single instance)
User	oracle
Environment	Non-production

DEMO 1: Shared Memory Impact (`shmmax`, `shmall`)

🎯 Goal

Show that Oracle cannot start if shared memory is too small.

Step 1: Check Current Kernel Values

sysctl -a | grep shm

Note:

kernel.shmmax
kernel.shmall

Step 2: Create a Database with a Large SGA

Set SGA deliberately high:

*.sga_target=4G
*.sga_max_size=4G

(Adjust based on your VM RAM)

Step 3: Artificially Reduce `shmmax`

sudo sysctl -w kernel.shmmax=1073741824   # 1 GB
sudo sysctl -w kernel.shmall=262144       # ~1 GB

Verify:

sysctl -a | grep shm

Step 4: Start Oracle

sqlplus / as sysdba
startup

❌ Expected Result

You will see errors like:

ORA-27102: out of memory
ORA-27123: unable to attach to shared memory segment
Linux-x86_64 Error: 28: No space left on device

🔍 What Happened?

Oracle requested 4 GB SGA
Kernel allowed only 1 GB shared memory
Kernel rejected the request
Oracle startup failed

Step 5: Fix the Kernel Parameter

sudo sysctl -w kernel.shmmax=5368709120   # 5 GB
sudo sysctl -w kernel.shmall=1310720

Retry:

startup

✅ Result

Database starts successfully.

🧠 Learning

Oracle SGA lives in shared memory, not private memory.
Kernel limits are hard stop points.

DEMO 2: Semaphore Impact (`kernel.sem`)

🎯 Goal

Show that Oracle depends on semaphores for synchronization.

Step 1: View Semaphore Settings

sysctl -a | grep kernel.sem

Example:

kernel.sem = 250 64000 100 4096

Step 2: Reduce Semaphore Limits (Dangerously Low)

sudo sysctl -w kernel.sem="10 100 10 10"

Step 3: Restart Oracle

shutdown immediate;
startup

❌ Expected Result

Possible errors:

ORA-27300: OS system dependent operation:semget failed
ORA-27301: OS failure message: No space left on device

Or:

Database starts
But hangs under session load

Step 4: Stress Semaphore Usage

From multiple terminals:

sqlplus user/pass@db

Open ~20–30 sessions quickly.

❌ Expected Behavior

New sessions hang
Background processes stall
Database becomes unstable

Step 5: Restore Proper Semaphore Values

sudo sysctl -w kernel.sem="250 64000 100 4096"

Restart database.

✅ Result

Stable startup
Sessions connect normally

🧠 Learning

Semaphores are invisible, but without them Oracle cannot coordinate processes safely.

DEMO 3: File Descriptor Limits (`fs.file-max` + ulimit)

🎯 Goal

Show that Oracle opens thousands of files.

Step 1: Reduce File Limits

sudo sysctl -w fs.file-max=10000

For oracle user:

ulimit -n 1024

Step 2: Run File-Heavy Operation

Examples:

Open many sessions
Force archive log generation
Run RMAN backup

❌ Expected Errors

ORA-27041: unable to open file
Linux Error: Too many open files

Step 3: Fix Limits

sudo sysctl -w fs.file-max=6815744
ulimit -n 65536

🧠 Learning

Oracle failures are often OS-level, not database bugs.

DEMO 4: Multiple Databases Competing for Kernel Resources

🎯 Goal

Show kernel parameters are system-wide.

Step 1: Start DB1 with Large SGA

db1: sga_target=6G

Step 2: Start DB2 with Large SGA

db2: sga_target=6G

Step 3: Reduce `shmall` Below Combined Requirement

sudo sysctl -w kernel.shmall=2097152   # ~8 GB

❌ Expected Result

One database starts
Second fails with shared memory errors

🧠 Learning

Kernel parameters are shared across all databases.
One instance can starve others.

DEMO 5: Observing Shared Memory & Semaphores Live

View Shared Memory Segments

ipcs -m

View Semaphore Sets

ipcs -s

Remove Stale IPC (⚠️ demo only)

ipcrm -m <shmid>
ipcrm -s <semid>

Final Mental Model After Demo

Concept	You Observed
Shared memory	Oracle fails immediately if insufficient
Semaphores	Oracle hangs or crashes under concurrency
Kernel limits	Apply to all databases
Oracle memory	Depends entirely on kernel
Production tuning	Mandatory, not optional

One-Line Takeaway

Oracle does not manage memory alone — the Linux kernel is its real boss.

Disclaimer

This article provides general best-practice guidance based on Oracle documentation and real-world production experience. Actual parameter values may vary depending on:

Linux distribution and kernel version
Workload type (OLTP, DSS, mixed)
Application behavior
Storage and network architecture

Always validate changes in a non-production environment and follow your organization’s change management policies. Oracle Corporation documentation remains the authoritative source.

Introduction

Why Oracle Requires Kernel Parameter Tuning

🛠️ The Key Oracle-Relevant Kernel Parameters & What They Do

1) Shared Memory Parameters

1️⃣ What Is a Shared Memory Segment?

Plain-English Definition

Why Shared Memory Exists

Simple Mental Model

2️⃣ Shared Memory in Oracle

Oracle’s SGA = Shared Memory

2) Semaphore Parameters

3️⃣ What Is a Semaphore?

Plain-English Definition

Why Semaphores Are Needed

Simple Mental Model

4️⃣ How Semaphores Work (Conceptually)

5️⃣ Semaphores in Oracle

Relevant Kernel Parameter

6️⃣ Shared Memory vs Semaphores (Together)

Without Semaphores:

Without Shared Memory:

7️⃣ Oracle Startup Flow (Simplified)

8️⃣ Why These Concepts Matter in Production

Real-World Scenarios

9️⃣ Common Misunderstandings

10️⃣ One-Line Summary

3) File Handles

4) Asynchronous I/O

5) Networking Buffers / Ports

📊 Minimum Values Required by Oracle 19c

📐 How to Calculate the Values

🎯 1) shmmax

🎯 2) shmall

🎯 3) Semaphore Counts

🎯 4) File Handles

🛠 Checking & Applying These

Check current values:

Apply new values:

📘 Why These Matter in Practice

📚 References to Learn More

1️⃣ Core Principle (Read This First)

2️⃣ How Kernel Parameters Work with Multiple Databases

3️⃣ Recommended Kernel Parameters for 32 GB RAM (3 DBs)

🔹 Shared Memory

kernel.shmmax

kernel.shmall

kernel.shmmni

🔹 Semaphores

🔹 File Handles

🔹 Async I/O

🔹 Networking

4️⃣ How to Size Memory for db1, db2, db3

🔹 Rule #1: Leave Memory for OS

🔹 Rule #2: Decide Memory Model

🔹 Example Balanced Layout (Production-Safe)

🔹 Example Initialization Parameters

5️⃣ How Many Databases Can a 32 GB Server Run?

❗ The honest answer:

Practical Guidelines

Real-world best practice:

6️⃣ Production Best-Practice Architecture

✔ Recommended

🚫 Not Recommended

7️⃣ Common Mistakes (Seen in Production 😬)

📌 Final Recommended Kernel Config (32 GB, 3 DBs)

📚 Official References (Must-Read)

Demo: Understanding the Impact of Kernel Parameters on Oracle Database

Demo Objectives

Lab Setup (Minimal)

DEMO 1: Shared Memory Impact (shmmax, shmall)

🎯 Goal

Step 1: Check Current Kernel Values

Step 2: Create a Database with a Large SGA

Step 3: Artificially Reduce shmmax

Step 4: Start Oracle

❌ Expected Result

🔍 What Happened?

Step 5: Fix the Kernel Parameter

✅ Result

🧠 Learning

🎯 1) `shmmax`

🎯 2) `shmall`

`kernel.shmmax`

`kernel.shmall`

`kernel.shmmni`

DEMO 1: Shared Memory Impact (`shmmax`, `shmall`)

Step 3: Artificially Reduce `shmmax`

DEMO 2: Semaphore Impact (`kernel.sem`)

DEMO 3: File Descriptor Limits (`fs.file-max` + ulimit)

Step 3: Reduce `shmall` Below Combined Requirement