awr不能直接判断是否需开启大页，但db cpu异常偏高、latch等待陡增且physical reads未升可暴露tlb miss；须结合/proc/meminfo和/proc/pid/maps验证真实大页使用量。
awr报告本身不显示“大页是否开启”，但能暴露tlb miss引发的cpu异常开销——这是判断是否该启用大页的最可靠信号。
看DB CPU占比和latch等待是否异常高
大页缺失时，SGA > 4GB 后TLB频繁失效，CPU被迫反复查页表，表现为DB CPU占比虚高，同时latch竞争加剧，但物理I/O无明显增长。
- 在AWR的「Top 5 Timed Foreground Events」中，若
DB CPU长期排前2，且latch: shared pool或latch: library cache同步陡增，而Physical Reads未上升，优先怀疑TLB miss - 检查「Instance Efficiency Percentages」：若
Buffer Nowait %Redo NoWait %持续下滑，常伴随大页碎片或未启用 - 排除干扰：确保对比的是相同业务时段（如每日 10:00–11:00），避开统计信息收集、备份等后台任务
查SGA动态分配是否引入非大页内存
Oracle 12c在ASMM模式下做SGA resize时，新分配段默认走4KB页——AWR里Shared Pool Memory Statistics的剧烈波动就是典型痕迹。
- 翻到AWR的「Shared Pool Memory Statistics」部分，观察
Free memory (bytes)：若在2GB ⇄ 200MB之间反复跳变，说明shared pool正在收缩/扩展，每次扩展都可能引入非大页内存 - 对比两份间隔数小时的AWR：若
SGA_TARGET调大后，parse time elapsed显著增加，但硬解析率未变，大概率是新增shared pool段没落入大页 - 确认AMM已关闭：执行
SELECT name, value FROM v$parameter WHERE name IN ('memory_target', 'sga_target', 'pga_aggregate_target');，若memory_target > 0，则大页完全不可用
用/proc//maps验证真实大页使用量
AWR和v$sgainfo都是Oracle自报，/proc/<pid>/maps</pid>才是内核视角的硬证据。只看HugePages_Free有余量就认为“已启用”，是常见误判。
- 先查Oracle主进程PID：
ps -eo pid,comm | grep pmon→ 得到pmonPID，再用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=50GB，但命令返回仅8GB），说明大量SGA落在4KB页上；此时再查v$sgainfo中Granule Size字段：若为8388608（8MB），可能是透明大页（THP），Oracle官方不推荐用于SGA
确认操作系统层大页配置是否到位
即使Oracle侧配置了use_large_pages=TRUE，若OS层/proc/meminfo中HugePages_Total为0，实例启动会直接失败（ORA-27123）；但若HugePages_Total有值却未被Oracle充分使用，问题更隐蔽。
- 执行：
grep HugePages_ /proc/meminfo，必须看到HugePages_Total > 0，且HugePages_Free不应长期接近HugePages_Total（说明未被Oracle进程映射） -
use_large_pages=TRUE表示Oracle尝试用大页，失败则启动报错；use_large_pages=ONLY更严格，连PGA都不允许fallback，生产环境慎用 - 注意RAC环境：每个实例需单独检查
/proc/<pid>/maps</pid>，不能只查一个节点
真正容易被忽略的是：SGA resize行为本身就会绕过大页池，哪怕use_large_pages=TRUE且HugePages_Total充足。AWR里Shared Pool Memory Statistics的波动不是“内存不够”的信号，而是“大页未覆盖”的指纹——这点必须结合/proc/<pid>/maps</pid>交叉验证，否则所有优化都可能打偏。
