查v$sgainfo中Granule Size为4194304（4MB）表明SGA组件已启用大页；结合/proc/<pid>/maps验证实际大页使用量，避免仅依赖AWR或视图判断。
查 v$sgainfo 和 v$memory_dynamic_components 看 SGA 实际分配是否启用大页
oracle 启用大页（hugepages）后，sga 不会自动全部落入大页池——它只对满足条件的内存段生效，且依赖启动时的 use_large_pages 参数值。常见错误是看到 /proc/meminfo 里 hugepages_free 有余量，就以为 sga 全部用了大页，其实可能只有 shared pool 或 buffer cache 的一部分进了大页。
-
use_large_pages=TRUE：强制所有可迁移 SGA 组件尝试用大页，失败则实例启动报错（ORA-27123） -
use_large_pages=ONLY：更严格，连 PGA 都不许 fallback，生产环境慎用 - 查
v$sgainfo中Granule Size字段：若为4194304（4MB），说明该组件已用大页；若为8388608（8MB），可能是 x86_64 上的透明大页（THP），但 Oracle 官方不推荐 THP 用于 SGA -
v$memory_dynamic_components的CURRENT_SIZE是动态值，但不反映底层页大小；需结合/proc/<pid>/maps</pid>手动验证
从 AWR 报告里定位大页未命中根源
AWR 本身不直接统计“大页命中率”，但能间接暴露问题：如果 DB CPU 占比异常高、latch: shared pool 或 latch: library cache 等待陡增，且 Physical Reads 未同步上升，大概率是 TLB miss 导致的页表遍历开销——尤其在 SGA > 16GB 且未配足 HugePages 时。
- 重点看 AWR 的 Instance Efficiency Percentages 区域：
Buffer Nowait %低于 99.5% 或Redo NoWait %下降，常伴随大页碎片化 - 检查
Shared Pool Memory Statistics：若Free memory (bytes)波动剧烈，说明 shared pool 在反复收缩/扩展，而每次 resize 都可能触发非大页内存申请 - 对比两份 AWR：SGA 调大前后若
parse time elapsed显著增加，不是 SQL 问题，而是新分配的 shared pool 段没落到大页上
用 /proc/<pid>/maps</pid> 和 grep -i huge 验证 OS 层映射真实情况
这是最硬的证据。AWR 和视图都是 Oracle 自报，而 /proc/<pid>/maps</pid> 是内核视角的真实内存布局。Oracle 进程（如 ora_smon_<sid>）的 maps 文件里，带 huge 标记的行才是真·大页映射。
- 先查 Oracle 进程 PID：
ps -eo pid,comm | grep pmon→ 得到pmonPID，再用ps -o ppid= -p <pid>找到数据库实例主进程 PID - 执行：
grep -i huge /proc/<pid>/maps | awk '{sum += $2-$1} END {print sum/1024/1024 " MB"}'，结果即为实际使用的大页内存量 - 若结果远小于
SGA_TARGET，说明部分 SGA 落在常规 4KB 页上；此时再查grep -v huge /proc/<pid>/maps | grep rw | awk '{sum += $2-$1} END {print sum/1024/1024 " MB"}'，这部分就是“危险区”——TLB 压力来源 - 注意：Linux 透明大页（THP）会在 maps 中显示为
htlb，但 Oracle 对其支持不稳定，建议在内核启动参数中禁用：transparent_hugepage=never
调整 vm.nr_hugepages 时必须避开的三个时间点
大页内存是静态预分配的，不能热增。改完 /etc/sysctl.conf 后立即 sysctl -p 并不等于立刻生效——内核要找连续物理内存块，而 Oracle 实例运行中会锁住大量内存页，导致 nr_hugepages 设置失败或静默截断。
- 重启数据库前必须停掉所有 Oracle 进程（包括
tnslsnr），否则ipcs -m里残留的共享内存段会抢占物理页，让 hugepages 分配失败 - 不要在 AWR 快照生成中（默认每小时整点）改参数，此时
MMAN进程频繁访问 SGA，容易引发ORA-27123或实例挂起 - 避免在 RMAN 备份期间调整，备份进程会 pin 住 buffer cache 中大量块，大幅降低大页可用连续内存空间
- 安全做法：在维护窗口先
shutdown immediate→sysctl -w vm.nr_hugepages=<new_value>→cat /proc/meminfo | grep -i huge确认生效 → 再startup
真正难的不是算需要多少大页，而是确认 Oracle 进程启动那一刻，OS 是否真给了它连续的、未被其他进程污染的物理内存块。这个空隙稍纵即逝，错过就得等下一个维护窗口。
