If kernel parameters define how big the room is, user limits define how freely Oracle can move inside it.

Introduction

When preparing a Linux server for Oracle Database 19c, most DBAs focus heavily on kernel parameters — shared memory, semaphores, file handles, etc.

However, many real-world Oracle failures occur even when kernel parameters are perfectly configured.

The missing piece?

👉 Oracle OS User Limits

User limits (ulimits) control how many resources a specific OS user (like oracle) is allowed to consume. If these limits are too low, Oracle will fail in subtle, confusing, and sometimes catastrophic ways — especially in production.

This article explains:

What user limits are
Why Oracle needs them
What problems they solve
Minimum and recommended values for Oracle 19c
How to calculate and tune them
How to verify and apply them correctly
Official references for further learning

What Are User Limits in Linux?

Plain-English Definition

User limits restrict how much of certain system resources a specific user can consume.

These limits are enforced by:

PAM (Pluggable Authentication Modules)
ulimit
/etc/security/limits.conf

They apply per user session, not system-wide.

Why Oracle Needs User Limits

Oracle Database:

Spawns many processes
Opens thousands of files
Uses deep call stacks
Locks memory
Runs long-lived sessions

Linux default user limits are designed for normal users, not database engines.

Without proper user limits:

Oracle may install successfully
Database may start successfully
Failures appear only under load

These are the most dangerous kinds of failures.

Core Difference: Kernel Parameters vs User Limits

Aspect	Kernel Parameters	User Limits
Scope	System-wide	Per user
Purpose	Upper hard ceiling	Per-user allowance
Oracle dependency	SGA, IPC, I/O	Processes, files, memory
Typical mistakes	Too small	Forgotten entirely

Both must be configured.

Key Oracle User Limits Explained

Oracle primarily relies on the following user limits:

1️⃣ `nofile` — Open File Descriptors

What It Controls

Maximum number of files a user can open simultaneously

Why Oracle Needs It

Oracle opens files for:

Datafiles
Tempfiles
Redo logs
Archive logs
Control files
Trace files
Network sockets

A busy database can easily exceed tens of thousands of open files.

Symptoms If Too Low

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

Minimum & Recommended Values

Type	Value
Soft limit	1024
Hard limit	65536

Best Practice Calculation (Guideline)

nofile ≥ (Number of datafiles + redo logs + sessions × 2)

Oracle’s recommendation is to always use 65536 for production.

2️⃣ `nproc` — Number of Processes

What It Controls

Maximum number of processes a user can create

Why Oracle Needs It

Each Oracle session spawns:

1 server process
Additional background processes

Large systems easily exceed thousands of processes.

Symptoms If Too Low

New connections fail
Background processes fail to start
Database hangs under load

Minimum & Recommended Values

Type	Value
Soft limit	2047
Hard limit	16384

Best Practice Calculation

nproc ≥ PROCESSES parameter in Oracle × 1.2

For most production systems:

16384 is safe and standard

3️⃣ `stack` — Stack Size

What It Controls

Maximum stack memory per process

Why Oracle Needs It

Oracle performs:

Deep recursive calls
Complex SQL parsing
PL/SQL execution

Too small stack sizes cause segmentation faults.

Symptoms If Too Low

Random process crashes
ORA-7445 errors
Core dumps

Recommended Values

Type	Value (KB)
Soft	10240
Hard	32768

4️⃣ `memlock` — Locked Memory

What It Controls

Amount of memory a process can lock into RAM

Why Oracle Needs It

When using:

HugePages
Performance-critical SGA

Oracle locks memory to:

Prevent swapping
Reduce latency

Symptoms If Too Low

HugePages not used
Severe performance degradation

Recommended Value

memlock = unlimited

Or (HugePages calculation):

memlock = SGA size in KB

5️⃣ `core` — Core Dump Size

What It Controls

Size of core dump files

Why Oracle Needs It

Core dumps are essential for:

Oracle Support (SRs)
Diagnosing crashes

Recommended Value

core = unlimited

Minimum Required Oracle User Limits (Oracle 19c)

Add the following to /etc/security/limits.conf:

oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft stack 10240
oracle hard stack 32768
oracle soft memlock unlimited
oracle hard memlock unlimited
oracle soft core unlimited
oracle hard core unlimited

PAM Configuration (Critical Step)

User limits will not work unless PAM is enabled.

Verify:

grep pam_limits.so /etc/pam.d/login
grep pam_limits.so /etc/pam.d/sshd

If missing, add:

session required pam_limits.so

Then:

logout
login

Verifying Oracle User Limits

su - oracle
ulimit -a

Expected output (partial):

open files            (-n) 65536
max user processes    (-u) 16384
stack size            (-s) 10240
locked memory         (-l) unlimited
core file size        (-c) unlimited

Why User Limits Matter in Production

Real-World Failures Caused by Bad Limits

Issue	Root Cause
Random ORA-7445	Stack too small
Session hangs	nproc too low
RMAN failures	nofile too low
Poor performance	memlock not set
No diagnostics	core disabled

Best Practices Summary

✔ Always configure user limits before installation
✔ Use hard limits generously
✔ Match nproc to Oracle PROCESSES parameter
✔ Set memlock unlimited for HugePages
✔ Verify with ulimit -a
✔ Never rely on Linux defaults

Official Oracle & Linux References

Oracle 19c Installation Guide – User Limits
https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/checking-resource-limits-for-oracle-software-installation-users.html
Oracle Linux Administrator’s Guide
https://docs.oracle.com/en/operating-systems/oracle-linux/
Linux ulimit Documentation
https://man7.org/linux/man-pages/man3/ulimit.3.html
PAM Limits Documentation
https://man7.org/linux/man-pages/man5/limits.conf.5.html

What Happens to User Limits When There Are Multiple Oracle Installation Owners?

First: The Key Rule

User limits are applied per OS user, not per Oracle installation and not per database.

So if you have:

oracle1 → owns DB1
oracle2 → owns DB2
grid → owns GI / ASM

Each user:

Has its own independent limits
Does not share ulimit values with other users

How Linux Applies User Limits (Important)

User limits are enforced:

At login/session creation
Through PAM
Independently per user

This means:

A bad limit on one Oracle owner will break only that owner’s databases
Other Oracle owners may work perfectly

Scenario 1: Multiple Oracle Owners, Correct Limits for All

Setup

User	Purpose
oracle	DB1
oracle2	DB2
grid	ASM + GI

`/etc/security/limits.conf`

oracle   soft nofile 1024
oracle   hard nofile 65536
oracle   soft nproc 2047
oracle   hard nproc 16384
oracle   soft stack 10240
oracle   hard stack 32768
oracle   soft memlock unlimited
oracle   hard memlock unlimited

oracle2  soft nofile 1024
oracle2  hard nofile 65536
oracle2  soft nproc 2047
oracle2  hard nproc 16384
oracle2  soft stack 10240
oracle2  hard stack 32768
oracle2  soft memlock unlimited
oracle2  hard memlock unlimited

grid     soft nofile 1024
grid     hard nofile 65536
grid     soft nproc 2047
grid     hard nproc 16384
grid     soft memlock unlimited
grid     hard memlock unlimited

Result

✅ All databases work
✅ GI/ASM stable
✅ Predictable behavior

Scenario 2: One Oracle Owner Has Bad Limits

Setup

oracle → correct limits
oracle2 → default Linux limits (forgotten)

What Happens?

Database	Result
DB1 (oracle)	Works fine
DB2 (oracle2)	Random failures
ASM / GI	Works

Typical errors for DB2:

ORA-27041
ORA-00020
ORA-7445
Listener instability

This leads to very confusing troubleshooting.

Scenario 3: Using Wildcards (`*`) in limits.conf

Example

* soft nofile 1024
* hard nofile 65536
* soft nproc 2047
* hard nproc 16384

What Happens?

All users (including oracle, oracle2, grid) get the limits
BUT:
- Security teams often restrict this
- App users might get too much access
- Can violate hardening policies

Best Practice

✔ Prefer explicit users
✔ Or use groups

LAB: Demonstrating Oracle Failures Caused by Bad User Limits

This lab is designed so you see real Oracle failures, then fix them and immediately see recovery.

⚠️ IMPORTANT

Do this ONLY on a test VM / sandbox

Never on production

You need sudo/root access

Lab Objectives

By the end of this lab, you will:

See Oracle fail due to low nofile
See Oracle fail due to low nproc
Trigger ORA-7445 / crashes due to bad stack
Observe performance impact from bad memlock
Learn how to diagnose & fix each issue

Lab Environment

Component	Value
OS	Oracle Linux / RHEL / CentOS
Oracle	19c
DB	Single instance
User	oracle
Environment	NON-PRODUCTION

Baseline: Verify Current User Limits

su - oracle
ulimit -a

Save this output — you’ll compare later.

DEMO 1: Failure Due to Low `nofile` (Open Files)

🎯 Goal

Show Oracle failing when it cannot open enough files.

Step 1: Artificially Reduce `nofile`

As oracle:

ulimit -n 256

Verify:

ulimit -n

Step 2: Force File Usage

Connect multiple sessions quickly:

for i in {1..50}; do sqlplus user/pass@db & done

Or run:

SELECT COUNT(*) FROM v$open_file;

❌ Expected Failure

You may see:

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

Or:

New sessions fail
Background operations fail (archiving, RMAN)

Step 3: Fix `nofile`

Exit oracle session and set limits properly:

exit
sudo vi /etc/security/limits.conf

Add:

oracle soft nofile 1024
oracle hard nofile 65536

Re-login:

su - oracle
ulimit -n

Retry workload → ✅ works.

🧠 Learning

Oracle silently depends on thousands of open file descriptors.

DEMO 2: Failure Due to Low `nproc` (Processes)

🎯 Goal

Show Oracle unable to create processes under load.

Step 1: Reduce Process Limit

ulimit -u 100

Verify:

ulimit -u

Step 2: Open Sessions

for i in {1..150}; do sqlplus user/pass@db & done

❌ Expected Failure

New connections fail
Some background processes may stop
Alert log shows process creation errors

Typical errors:

ORA-00020: maximum number of processes exceeded
Linux Error: Resource temporarily unavailable

Step 3: Fix `nproc`

exit
sudo vi /etc/security/limits.conf

Add:

oracle soft nproc 2047
oracle hard nproc 16384

Re-login and retry → ✅ stable.

🧠 Learning

Oracle sessions = OS processes.
No processes → no database.

DEMO 3: ORA-7445 / Crash Due to Low Stack Size

🎯 Goal

Show unpredictable crashes caused by insufficient stack.

Step 1: Reduce Stack Size

ulimit -s 1024

Verify:

ulimit -s

Step 2: Execute Stack-Heavy SQL

Run recursive SQL:

WITH r (n) AS (
  SELECT 1 FROM dual
  UNION ALL
  SELECT n+1 FROM r WHERE n < 10000
)
SELECT COUNT(*) FROM r;

❌ Expected Behavior

Session crash
ORA-7445
Core dump generated

Alert log:

ORA-07445: exception encountered: core dump

Step 3: Fix Stack Limit

exit
sudo vi /etc/security/limits.conf

Add:

oracle soft stack 10240
oracle hard stack 32768

Re-login → SQL works.

🧠 Learning

Stack issues cause random, hard-to-debug crashes.

DEMO 4: Performance Impact Due to Bad `memlock`

🎯 Goal

Show performance degradation when memory cannot be locked.

Step 1: Disable Memory Locking

ulimit -l 0

Verify:

ulimit -l

Step 2: Start Database Using HugePages

startup

Check:

SELECT * FROM v$sgainfo WHERE name LIKE '%Huge%';

❌ Expected Result

HugePages = NOT USED
SGA swapped under memory pressure
Performance drops

Step 3: Fix `memlock`

exit
sudo vi /etc/security/limits.conf

Add:

oracle soft memlock unlimited
oracle hard memlock unlimited

Restart DB → HugePages used.

🧠 Learning

Memory locking prevents Oracle from being swapped to death.

DEMO 5: Missing Core Dumps (`core` Limit)

🎯 Goal

Show why core dumps matter.

Step 1: Disable Core Dumps

ulimit -c 0

Trigger crash (repeat Demo 3).

❌ Result

No core file
Oracle Support cannot diagnose

Step 2: Enable Core Dumps

ulimit -c unlimited

Crash again → core file generated.

🧠 Learning

No core dump = no root cause.

Final Verification (Golden State)

ulimit -a

Expected:

open files            (-n) 65536
max user processes    (-u) 16384
stack size            (-s) 10240
locked memory         (-l) unlimited
core file size        (-c) unlimited

Summary Table: Failures vs Root Cause

Symptom	Root Cause
ORA-27041	nofile too low
ORA-00020	nproc too low
ORA-7445	stack too low
Poor performance	memlock disabled
No diagnostics	core disabled

One-Line Takeaway

Kernel parameters let Oracle exist.
User limits decide whether Oracle survives under load.

Extra note on HugePages (Additional)

HugePages on Linux

What It Is, Why It Exists, and Why Oracle Loves It

1️⃣ The Problem HugePages Solves

How Normal Memory Works

Linux normally manages memory in small chunks called pages.

Standard Linux page size: 4 KB
Memory is divided into millions of these pages

Example:

16 GB RAM = ~4,194,304 pages (4 KB each)

Managing millions of pages has overhead:

Page tables become huge
More CPU time spent translating virtual → physical addresses
Higher TLB (Translation Lookaside Buffer) misses

This overhead becomes painful for large-memory applications like databases.

2️⃣ What Are HugePages?

Definition

HugePages are much larger memory pages that reduce management overhead.

Typical HugePage sizes:

2 MB (most common)
1 GB (less common, special cases)

Example:

16 GB using 2 MB HugePages = 8192 pages

That’s orders of magnitude fewer pages.

3️⃣ Why HugePages Exist (Plain English)

Think of memory like a book:

Normal pages → individual sheets
HugePages → entire chapters

It’s faster to say:

“Go to chapter 5”

Than:

“Find page 1, 2, 3, 4… repeatedly”

4️⃣ HugePages in Oracle

What Oracle Uses HugePages For

Oracle uses HugePages only for the SGA (shared memory).

SGA is large
Shared by many processes
Frequently accessed
Perfect candidate for HugePages

Oracle does NOT use HugePages for:

PGA
Stack
Temporary allocations

5️⃣ Why Oracle Recommends HugePages

Key Benefits

Benefit	Why It Matters
Reduced page table size	Less kernel memory used
Fewer TLB misses	Faster memory access
No swapping of SGA	Stability
Predictable performance	No sudden slowdowns
Lower CPU overhead	Better throughput

6️⃣ What Happens Without HugePages

When HugePages are not used:

SGA is allocated using normal 4 KB pages
Under memory pressure:
- Linux may swap out SGA pages
- Oracle performance collapses
Random performance spikes
OS spends CPU managing page tables

This is why:

A system with enough RAM can still perform badly without HugePages

7️⃣ HugePages vs AMM (Important)

Automatic Memory Management (AMM)

If you use:

MEMORY_TARGET

👉 HugePages CANNOT be used.

Best Practice

Memory Model	HugePages
AMM	❌ Not supported
ASMM (`SGA_TARGET`)	✅ Supported
Manual SGA	✅ Supported

This is why Oracle recommends ASMM + HugePages for production.

8️⃣ How HugePages Work Internally

Kernel reserves HugePages at boot time
Oracle requests shared memory for SGA
Kernel allocates HugePages
Oracle locks memory (via memlock)
SGA becomes non-swappable

9️⃣ HugePages Sizing Concept (High Level)

Rule of Thumb

HugePages = Total SGA Size / HugePage Size

Example:

Total SGA = 24 GB
HugePage Size = 2 MB

HugePages = 24 × 1024 / 2 = 12288

(Exact sizing requires subtracting small SGA components)

🔟 Relationship to Kernel Parameters & User Limits

HugePages require all three layers to be correct:

Layer	Requirement
Kernel	HugePages reserved
User Limits	memlock unlimited
Oracle	ASMM or manual SGA

If any layer is wrong → HugePages not used.

1️⃣1️⃣ How to Check HugePages Usage

OS Level

grep Huge /proc/meminfo

Key fields:

HugePages_Total
HugePages_Free
HugePages_Rsvd

Oracle Level

SELECT * FROM v$sgainfo WHERE name LIKE '%Huge%';

Expected:

HugePages used by this instance = TRUE

1️⃣2️⃣ Common DBA Mistakes

❌ Using AMM and expecting HugePages
❌ Forgetting memlock limits
❌ Over-allocating HugePages
❌ Running multiple DBs without adjusting HugePages
❌ Thinking HugePages auto-adjust dynamically

1️⃣3️⃣ One-Line Summary

HugePages reduce memory overhead, eliminate SGA swapping, and make Oracle performance predictable.

Disclaimer

This article provides general best-practice guidance based on Oracle documentation and industry experience. Actual user limit values may vary depending on:

Application workload
Number of concurrent users
Oracle configuration
Linux distribution and kernel version

Always validate changes in a non-production environment and follow your organization’s change management and security policies. Oracle documentation remains the authoritative source for all installation and configuration requirements.

Introduction

What Are User Limits in Linux?

Plain-English Definition

Why Oracle Needs User Limits

Core Difference: Kernel Parameters vs User Limits

Key Oracle User Limits Explained

1️⃣ nofile — Open File Descriptors

What It Controls

Why Oracle Needs It

Symptoms If Too Low

Minimum & Recommended Values

Best Practice Calculation (Guideline)

2️⃣ nproc — Number of Processes

What It Controls

Why Oracle Needs It

Symptoms If Too Low

Minimum & Recommended Values

Best Practice Calculation

3️⃣ stack — Stack Size

What It Controls

Why Oracle Needs It

Symptoms If Too Low

Recommended Values

4️⃣ memlock — Locked Memory

What It Controls

Why Oracle Needs It

Symptoms If Too Low

Recommended Value

5️⃣ core — Core Dump Size

What It Controls

Why Oracle Needs It

Recommended Value

Minimum Required Oracle User Limits (Oracle 19c)

PAM Configuration (Critical Step)

Verifying Oracle User Limits

Why User Limits Matter in Production

Real-World Failures Caused by Bad Limits

Best Practices Summary

Official Oracle & Linux References

What Happens to User Limits When There Are Multiple Oracle Installation Owners?

First: The Key Rule

How Linux Applies User Limits (Important)

Scenario 1: Multiple Oracle Owners, Correct Limits for All

Setup

/etc/security/limits.conf

Result

Scenario 2: One Oracle Owner Has Bad Limits

Setup

What Happens?

Scenario 3: Using Wildcards (*) in limits.conf

Example

What Happens?

Best Practice

Lab Objectives

Lab Environment

Baseline: Verify Current User Limits

DEMO 1: Failure Due to Low nofile (Open Files)

🎯 Goal

Step 1: Artificially Reduce nofile

Step 2: Force File Usage

❌ Expected Failure

Step 3: Fix nofile

🧠 Learning

DEMO 2: Failure Due to Low nproc (Processes)

🎯 Goal

Step 1: Reduce Process Limit

Step 2: Open Sessions

❌ Expected Failure

Step 3: Fix nproc

🧠 Learning

DEMO 3: ORA-7445 / Crash Due to Low Stack Size

🎯 Goal

Step 1: Reduce Stack Size

Step 2: Execute Stack-Heavy SQL

❌ Expected Behavior

Step 3: Fix Stack Limit

🧠 Learning

DEMO 4: Performance Impact Due to Bad memlock

🎯 Goal

Step 1: Disable Memory Locking

1️⃣ `nofile` — Open File Descriptors

2️⃣ `nproc` — Number of Processes

3️⃣ `stack` — Stack Size

4️⃣ `memlock` — Locked Memory

5️⃣ `core` — Core Dump Size

`/etc/security/limits.conf`

Scenario 3: Using Wildcards (`*`) in limits.conf

DEMO 1: Failure Due to Low `nofile` (Open Files)

Step 1: Artificially Reduce `nofile`

Step 3: Fix `nofile`

DEMO 2: Failure Due to Low `nproc` (Processes)

Step 3: Fix `nproc`

DEMO 4: Performance Impact Due to Bad `memlock`

Step 3: Fix `memlock`

DEMO 5: Missing Core Dumps (`core` Limit)