This document explores how Oracle

databases manage memory using Huge

Pages, reducing page table overhead and
improving performance. It details real-
world examples where Huge Pages
optimize memory usage for large SGAs,
prevent excessive swapping, and lower
memory consumption, ensuring efficient
resource management for high-
performance Oracle environments.

Oracle
Memory
Management
Huge Pages, Swap and
Dynamic Memory

Aman Pandey
LinkedIn Profile
Introduction to Oracle's Dynamic Memory Management

1. Overview of Oracle and Its Memory Requirements

• Oracle Database relies heavily on physical RAM to execute queries, manage data, and
perform background tasks efficiently. It dynamically adjusts its memory usage based on the
system's workload, which allows it to operate optimally under different conditions.

• The goal is to keep as much data and execution information in RAM as possible to avoid
slower disk I/O. This dynamic memory management includes handling critical components
such as the System Global Area (SGA) and Program Global Area (PGA), which allow Oracle
to process transactions swiftly by utilizing available physical memory.

2. Key Oracle Memory Components

Oracle uses two primary memory structures: the SGA and PGA.

• System Global Area (SGA):

o A shared memory region that stores data and control information for the entire
Oracle instance.

o Major subcomponents include:

▪ Database Buffer Cache: Caches the most frequently accessed data blocks.

▪ Shared Pool: Stores SQL execution plans and dictionary information.

▪ Redo Log Buffer: Temporarily stores redo log entries before writing them to
disk.

• Program Global Area (PGA):

 o A non-shared memory region that contains data and control information for single
server processes. Each session in Oracle has its own PGA, used for operations like
sorting, hashing, and joins.

• Example Output When Starting Oracle: When Oracle starts up, it allocates memory
dynamically based on predefined parameters. Here’s an example of the startup log showing
memory allocation:

• Explanation:

o Total System Global Area: The overall memory allocated to Oracle’s shared memory
structures (SGA).

o Fixed Size: A small fixed-size portion of the SGA.

o Variable Size: This is the dynamically managed portion of the SGA, which adjusts
based on workload (includes shared pool and buffer cache).

o Database Buffers: Allocated space for caching data blocks.

o Redo Buffers: Space for logging changes before they are written to disk.

This output shows that Oracle dynamically allocates memory for its internal components, ensuring
efficient handling of data and queries.

3. Oracle's Interaction with Physical RAM

• Kernel-Level Memory Limits for Oracle: To prevent Oracle from over-consuming system
resources, administrators set certain limits at the kernel level, which governs how much
shared memory Oracle can use.

These parameters must be set properly in the Linux kernel to ensure Oracle can allocate the
necessary memory without hitting system limits. For example:

• Process Memory in Oracle (Stack, Heap, BSS, Data, Text) A process in Oracle, like any other
process in a Linux system, has various memory segments:
 o Stack: This is the area of memory used for managing function calls, local variables,
and flow control. In Oracle, each process has its own stack.

o Heap: The heap is the memory dynamically allocated during runtime (e.g., for
queries or operations requiring large amounts of temporary memory).

o BSS (Block Started by Symbol): This section stores uninitialized global variables.

o Data Segment: Contains initialized global and static variables.

o Text Segment: Stores the executable code of a process.

Out-of-Memory Scenario:

o In certain cases, particularly when there’s memory pressure, the heap and stack
segments can collide. This happens when both grow towards each other within the
same address space.

o In Oracle, if a process requests more memory than is available in the heap or stack,
this can lead to an Out of Memory (OOM) error. This is especially true in scenarios
with large, complex queries that demand extensive memory allocation (heap) and
deep recursion or function calls (stack).

Example: Suppose a large query in Oracle requires substantial memory allocation for joins or sorting
(heap), while at the same time, deep recursive PL/SQL function calls are being made, leading to
significant stack usage. As both memory segments expand, they may collide, resulting in an OOM
error if they exhaust the available process memory.
Oracle and Memory Management — Huge Pages, Swap, and
Dynamic Memory

1. What Are Huge Pages?

Huge Pages is a feature of the Linux kernel that allows larger memory pages to be used for managing
memory instead of smaller default-sized pages (usually 4KB). Huge Pages are typically 2MB or larger,
depending on the hardware and kernel version. The key idea behind Huge Pages is to reduce the
overhead associated with managing large numbers of small pages, especially when dealing with large
memory areas like Oracle’s SGA (System Global Area).

Why Use Huge Pages?

For Oracle databases with large SGAs (starting from 2GB or more) or systems with many concurrent
sessions, the number of page table entries (PTEs) required to manage regular-sized pages becomes
unmanageable. This results in high overhead, increased memory consumption, and performance
degradation.

• Example Scenario:
Imagine an Oracle database with an SGA size of 25GB and 500 sessions. If regular 4KB pages
are used, the number of page table entries becomes enormous, causing memory
inefficiency. Huge Pages significantly reduce this overhead by consolidating multiple 4KB
pages into fewer, larger pages.

2. How Huge Pages Work in Oracle

In a typical Linux system, memory is divided into small 4KB pages. These pages are tracked by the
operating system through page tables, which map virtual addresses to physical memory addresses.
When Oracle’s SGA grows large, managing these small 4KB pages leads to inefficient use of system
resources, especially in memory-intensive applications.

With Huge Pages, each page is much larger (e.g., 2MB or more). This means fewer pages and fewer
entries in the page table, leading to more efficient memory management.

3. Benefits of Huge Pages in Oracle

• Less Page Table Overhead:

o In an Oracle database using a large SGA, regular-sized pages require a significant

number of page table entries (PTEs) to map memory, which leads to increased
memory consumption.

o Huge Pages reduce the number of pages the operating system needs to manage.
This leads to a smaller page table, reducing the overhead involved in managing and
maintaining page entries. (shown in examples, sec5)
 • Faster Memory Operations:

o Since the system has fewer pages to manage, operations like memory lookups and
TLB (Translation Lookaside Buffer) hits are faster, improving the overall performance
of the database.

• Pinned Memory:

o Huge Pages remain pinned in memory, meaning they are not swappable. This
eliminates the risk of slow page-in/page-out operations and reduces the CPU
workload that manages page swapping (i.e., kswapd).

Example:

For a database with an SGA of 25GB and 500 sessions, without Huge Pages, the memory usage can
grow significantly due to the size of the page tables. With Huge Pages, the same database will require
fewer PTEs, resulting in more efficient memory usage and improved performance.

4. Configuration of Huge Pages in Oracle Linux

To configure Huge Pages, several kernel parameters need to be set, and the database needs to be
restarted for changes to take effect.

Steps to Configure Huge Pages:

1. Calculate the Required Huge Pages:

o Use a script like hugepages_settings.sh to calculate the number of Huge Pages

required based on your SGA size and session load.

2. Set Kernel Parameters:

o Edit /etc/sysctl.conf to add the required number of Huge Pages:

 3. Set Memlock Limit:

o Update /etc/security/limits.conf to lock the memory:

4. Restart the System:

o Reboot the system to apply the changes and allocate Huge Pages.

5. Validate Huge Pages:

o After the system restarts, check if Huge Pages have been properly allocated:

5. Issues Addressed by Huge Pages

• Avoiding ORA-4030 Errors:

o Oracle can throw ORA-4030 (out-of-memory) errors when page tables grow too
large and consume more memory than expected. Huge Pages reduce this overhead,
making more memory available for Oracle processes.

• Preventing Excessive Swapping:

o Without Huge Pages, Oracle databases can experience excessive swapping,

especially in environments with a large number of sessions or a large SGA. Huge
Pages prevent this by pinning memory, ensuring that critical memory areas like the
SGA are not swapped out.
Example (Scenario Based):
I created a custom setup, providing similar load in each case. Below are the environment details:

RAM 5.9GB
SWAP 6GB
Oracle DB Version 19.22
SGA – PGA 1315MB – 280MB

Load Details: 200+ User Login

10,000+DMLs / Sec
1100+Txn/Sec
Load Duration: 5-10 mins

❖ Without Huge Pages Configured

Page Table Size: 750MB
Swap Util: 90MB
 ❖ With Huge Pages Configured
Page Table Size: 190MB
Swap Util: 6.5MB

6. Best Practices for Using Huge Pages

• Disable Automatic Memory Management (AMM):

o Huge Pages are not compatible with Automatic Memory Management (AMM) in
Oracle. To use Huge Pages, you must disable AMM by setting the MEMORY_TARGET
and MEMORY_MAX_TARGET initialization parameters to 0.

• Monitor and Adjust Huge Pages:

o Regularly monitor your Huge Pages configuration to ensure that the number of pages
allocated matches the memory requirements of your database instances. If you
increase the SGA or add new instances, you may need to adjust the number of Huge
Pages allocated.

7. Limitations of Huge Pages

• No Swapping:

o While the non-swappable nature of Huge Pages is a benefit, it can also lead to
system memory exhaustion if not configured correctly. If the number of Huge Pages
allocated exceeds the required amount, memory reserved for Huge Pages becomes
unavailable for other system processes, leading to out-of-memory conditions for
non-Oracle applications.
 • Requires Kernel Tuning:

o Configuring Huge Pages requires careful tuning of kernel parameters, which can be
complex for administrators unfamiliar with the Linux kernel or memory
management.

Conclusion: Why Huge Pages Matter for Oracle

Huge Pages are essential for Oracle environments with large memory requirements, particularly
when running large SGAs or many concurrent sessions. By reducing page table overhead, speeding
up memory operations, and preventing swapping, Huge Pages ensure that Oracle databases run
efficiently in memory-constrained environments. Proper configuration of Huge Pages can lead to
significant performance gains, making it a crucial best practice for Oracle DBAs managing high-
performance databases.

Bonus Tip: How to clear Swap Memory?

✓ Requires root privilege

✓ be sure you have the RAM to support this operation
✓ moves all data from swap memory back into RAM