查v$memory_target_advice和v$sga_dynamic_components不能反映rac真实内存压力，因rac内存非节点独占，需结合free -h、crsctl stat res -t、ipcs -m及/proc/meminfo等os层指标综合判断。
查 v$memory_target_advice 和 v$sga_dynamic_components 不能反映 rac 真实内存压力
oracle rac 的内存不是按节点独立切分的，sga 和 pga 都是实例级资源，但实际物理内存消耗受本地进程、大页配置、操作系统缓存影响很大。直接查单实例视图会漏掉跨节点争用和 os 层内存抖动。真实瓶颈常出现在：节点间 ipc 共享内存段膨胀、hugepages 分配不均、或某个节点上大量 parallel slave 进程吃光本地 pga 导致 swap。
用 crsctl stat res -t + free -h 对比各节点 OS 内存水位
这是最直接有效的起点——RAC 实例跑在各自节点 OS 上，free -h 显示的 available 值比数据库内部视图更可信。配合 crsctl stat res -t 确认实例是否都在预期节点运行（避免 failover 后分布失衡）：
crsctl stat res -t | grep ora.*.svc # 输出类似：ora.db1.db ONLINE ONLINE node1
关键动作：
- 在每个节点分别执行
free -h，重点关注available是否持续低于 2GB（尤其在业务高峰） - 对比
buff/cache占比：若某节点异常高，可能是内核缓存被大量文件读写撑满，挤压 Oracle 进程可用内存 - 检查
swap使用量：只要swapped列非零，就说明该节点已触发内存回收，此时oraagent.bin日志里大概率有ORA-04030或ORA-27102
v$pgastat 按节点查 total PGA allocated 时注意 inst_id 过滤
v$pgastat 是 GV$ 视图，必须加 WHERE inst_id = X 才能分离出单节点数据。默认不带条件查出来的是所有实例聚合值，毫无参考价值：
SELECT inst_id, name, value
FROM gv$pgastat
WHERE name IN ('total PGA allocated', 'aggregate PGA auto target')
AND inst_id IN (1,2); -- 显式指定节点号
常见误判点：
-
total PGA allocated接近pga_aggregate_target不代表有问题——它只统计 Oracle 主动分配的 PGA，不含 OS malloc、JVM heap、甚至某些并行操作的临时内存 - 若某节点
total PGA allocated突增但free memory（来自v$process）没同步下降，大概率是大量短生命周期进程（如 JDBC thin client 连接）反复申请释放，需结合v$session的paddr和v$process的pga_used_mem定位
用 ipcs -m 查共享内存段大小，确认是否 hugepages 生效
RAC 节点间通过共享内存通信，ipcs -m 输出的 SEGSZ 列能验证 hugepages 是否被真正使用。若全是 4KB 段，说明 memlock 未设或 vm.nr_hugepages 不足：
ipcs -m | awk '$5 > 1048576 {print $5/1024/1024 " MB", $0}' | head -5
必须检查的三项：
-
/proc/meminfo中HugePages_Free是否远小于HugePages_Total（否则 hugepages 未被 Oracle 拿走） -
cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages值是否 ≥ 实例sga_target/ 2MB 向上取整 -
ulimit -l在 oracle 用户下是否为unlimited（否则即使配了 hugepages，Oracle 启动时也会 fallback 到普通页）
内存分布不均往往不是 SQL 或参数问题，而是某个节点的 nr_hugepages 比其他节点少 2–4 个，导致该节点 SGA 被拆成几百个 4KB 页，TLB miss 暴涨，间接抬高内存延迟和争用。
