awr报告不显示hugepages相关指标；应检查/proc/meminfo中hugepages_total是否>0且hugepages_free
看AWR里有没有“HugePages”相关指标
AWR报告本身不直接显示HugePages是否启用或使用情况。v$sga_target_advice、DB Time、Physical Reads这些常规项都和大页无关。别在AWR里找“HugePages Used”这种不存在的字段——它压根不采集、不汇总、不展示。
真正该查的是内核和Oracle启动日志，不是AWR
判断大页是否生效，必须跳出AWR，转向底层验证：
- 运行
grep HugePages_ /proc/meminfo：重点看HugePages_Total是否 > 0，且HugePages_FreeHugePages_Total（说明已被 Oracle 预留） - 检查 Oracle 告警日志（
alert_<sid>.log</sid>）：搜索Large Pages或use_large_pages，正常启用时会有类似Large Pages allocated: 6144的记录 - 确认启动参数：执行
SHOW PARAMETER use_large_pages，值必须是only或auto；若为false，即使系统配了大页也完全不触发
AWR能间接提示“可能需要大页”的信号
当出现以下组合现象时，应怀疑 SGA 分配受阻，进而排查 HugePages：
-
redo buffer allocation retries持续升高 +log file sync等待陡增 → 可能 SGA 共享池/日志缓冲区碎片化严重，而大页能缓解连续内存分配压力 -
DB Time中 CPU 占比异常低，但physical reads和buffer gets极高 → 若排除磁盘与SQL问题，可能是 TLB miss 频繁（普通4KB页导致地址翻译开销大），大页可显著减少页表项数量 - 多次 AWR 报告中
shared pool free memory波动剧烈，且library cache lock等争用上升 → 大页有助于稳定共享池内存布局，降低重分配频率
最常被忽略的硬性前提：AMM必须关掉
如果数据库启用了 AMM（即 memory_target > 0），HugePages 就完全失效 —— 这是 Oracle 官方明确限制的。AWR 里看到 memory_target 非零，就不用再查大页了，先执行：
ALTER SYSTEM RESET memory_target SCOPE=SPFILE; ALTER SYSTEM SET sga_target=8G SCOPE=SPFILE; ALTER SYSTEM SET pga_aggregate_target=2G SCOPE=SPFILE;
然后重启实例。不切到 ASMM 模式，所有大页配置都是空转。
