AWR不能直接判断是否需开启大页，但可通过DB CPU异常偏高、latch等待陡增且Physical Reads未升等现象识别TLB miss；需结合/proc/meminfo和/proc/pid/maps验证实际大页使用量。
awr 本身不提供“是否需要开启大页”的直接判断依据，但能暴露 tlb miss 导致的 cpu 开销异常——这是开启大页最核心的动因。
看 AWR 里 DB CPU 和等待事件是否异常偏高
大页未启用时，SGA 超过几 GB 后，TLB（Translation Lookaside Buffer）频繁失效，CPU 被迫反复遍历页表，表现为：DB CPU 占比显著高于业务负载应有水平，同时 latch: shared pool 或 latch: library cache 等 latch 等待陡增，而 Physical Reads 并未同步上升。
- 重点对比 AWR 的「Top 5 Timed Foreground Events」：若
DB CPU排名前二，且无明显 SQL 执行计划退化或 I/O 延迟，优先怀疑 TLB miss - 检查「Instance Efficiency Percentages」：Buffer Nowait % 低于 99.5% 或 Redo NoWait % 持续下降，常伴随大页碎片或缺失
- 注意排除干扰：确保对比的是相同业务时段（如每日 9:00–10:00），避开备份、统计信息收集等后台任务
查 SGA 分配趋势是否触发非大页内存申请
Oracle 11g 在 SGA 动态 resize 时，新分配的内存段默认走常规 4KB 页，除非大页池已预留且 use_large_pages 配置得当。AWR 中 Shared Pool Memory Statistics 若出现 Free memory (bytes) 剧烈波动（如 2GB ⇄ 200MB 反复跳变），说明 shared pool 在收缩/扩展，每次扩展都可能引入非大页内存。
- 对比两份间隔数小时的 AWR：SGA_TARGET 调大后，若
parse time elapsed显著增加，但 SQL 硬解析率未变，大概率是新增 shared pool 段没落入大页 - 确认 AMM/ASMM 是否关闭：
MEMORY_TARGET > 0时 Oracle 不支持大页，必须设为 0；否则 AWR 中任何 SGA 趋势都不可信 - 查看
V$SGA_DYNAMIC_COMPONENTS的CURRENT_SIZE与MIN_SIZE差值：若长期 > 0 且不缩容，说明动态增长部分未被大页覆盖
用 /proc/meminfo 和 /proc//maps 验证 OS 层真实使用量
AWR 和 v$sgainfo 都是 Oracle 自报，/proc/meminfo 和 /proc/<pid>/maps</pid> 才是内核视角的硬证据。仅靠 HugePages_Free 有余量就认为“已启用”，是常见误判。
- 先确认内核是否真分配了大页：
grep HugePages_ /proc/meminfo，必须HugePages_Total > 0，而非只看HugePages_Free - 查 Oracle 进程 PID：
ps -eo pid,comm | grep pmon→ 得到 PID，再用ps -o ppid= -p <pid></pid>找到实例主进程 PID - 执行：
grep -i huge /proc/<pid>/maps | awk '{sum += $2-$1} END {print sum/1024/1024 " MB"}'</pid>，结果即实际使用的大页内存量 - 若该值远小于
SGA_TARGET（例如 SGA=64GB，但命令输出仅 8GB），说明大部分 SGA 落在 4KB 页上，必须调大vm.nr_hugepages并重启实例
真正难的不是算出该配多少大页，而是理解 Oracle 启动时对 use_large_pages 的严格语义：设成 ONLY 会拒绝启动，设成 TRUE 却可能只让部分组件（如 buffer cache）进大页，而 shared pool 或 java pool 仍走普通页——这需要结合 /proc/<pid>/maps</pid> 逐段验证，不能依赖单一指标。
