HugePages Pool Exhaustion After SGA Increase
Your 19c single-instance database runs on Oracle Linux 7 on a host with 512 GB RAM. The SPFILE has memory_target unset, sga_target=320G, pga_aggregate_target=80G, and use_large_pages=ONLY. After increasing sga_target from 256G to 320G and rebooting, startup fails with ORA-27102: out of memory, followed by Linux-x86_64 Error: 28: No space left on device. /proc/meminfo shows HugePages_Total=0, HugePages_Free=0, Hugepagesize=2048 kB. The OS, monitoring agent, and backup client consume about 40 GB, so physical memory is available. The alert log repeats ORA-27102. You cannot schedule another reboot for ten days; the database must start with the 320G SGA and use hugepages. The server has 32 CPUs and runs no other Oracle instances.
1. Explain why the instance fails with "No space left on device" and what use_large_pages=ONLY changes about the allocation path.
Read the worked answer
Error 28 (ENOSPC) here is not a filesystem-full condition. During SGA attachment Oracle requests a shared memory segment backed by hugepages; the kernel reports ENOSPC when the hugepage pool cannot satisfy the request. Because HugePages_Total=0, no hugepages exist. With use_large_pages=ONLY, Oracle refuses to fall back to 4 KB pages, so a 320 GB SGA cannot be allocated. That is why the alert log repeats ORA-27102 even though the host has free RAM. If the parameter were TRY or FALSE, Oracle could use normal pages (subject to /dev/shm and memory limits), but that would violate the requirement and may still fail. Diagnosis: confirm grep Huge /proc/meminfo, ulimit -l, and the use_large_pages value in the SPFILE. The fix is to allocate a hugepage pool large enough for the SGA, not to reduce sga_target blindly.
2. Compute the required hugepage count and describe how to allocate it without another reboot.
Read the worked answer
320 GB = 327,680 MB; at 2 MB per page that is 163,840 pages for the SGA alone. Add roughly 3-5% for fixed/overhead and future growth: about 168,000-172,000 pages. Verify the host can spare it: 512 GB total minus about 40 GB OS leaves about 472 GB; 172,000 x 2 MB = 344 GB, leaving headroom. At runtime, as root: sysctl -w vm.nr_hugepages=170000 (or echo 170000 > /proc/sys/vm/nr_hugepages), then check HugePages_Total/Free and HugePages_Rsvd. Hugepages are allocated on demand; runtime allocation may fail if physical memory is fragmented, in which case a reboot is the reliable option. Ensure the oracle user's memlock limit is unlimited (ulimit -l unlimited). Start the instance and confirm V$PARAMETER.use_large_pages is ONLY and the SGA is mapped to hugepages by checking /proc/<pid>/smaps.
3. What must you do to make this configuration persistent and verifiable before the next reboot?
Read the worked answer
Create /etc/sysctl.d/99-oracle-hugepages.conf with vm.nr_hugepages = 170000, and set oracle soft memlock unlimited / oracle hard memlock unlimited in /etc/security/limits.d/. If the system uses tuned profiles, ensure they do not override vm.nr_hugepages. Add a startup check that compares SGA_TARGET to HugePages_Total and alerts. Also record why a runtime sysctl is not sufficient: the setting is not persistent, and if the instance later grows the SGA, the pool must grow. After startup, query V$SGASTAT and V$PARAMETER to confirm, and run a small workload; if HugePages_Free stays at zero but HugePages_Rsvd is positive, that is normal because reserved pages count against free. Do not set use_large_pages=TRY as a permanent workaround; it hides misconfiguration.