DRM动态资源重组高频误触发会引发gc current split、gc buffer busy等等待事件激增，需通过LMD trace中“DRM start”出现频次、x$object_affinity_statistics.opens是否持续增长及等待事件突增200%以上来确认其正在捣乱而非优化。
DRM动态资源重组不是越活跃越好，监控重点不在“有没有发生”，而在“是否高频误触发”——禁用或调参前必须确认它正在制造 gc current split 和 gc buffer busy 等等待事件。
怎么看 DRM 正在捣乱而不是帮忙
别只查参数值，先看运行态证据。DRM 本意是减少跨节点访问，但如果它频繁迁移 master，反而会放大 GRD 冻结开销和锁广播延迟。
- 查等待事件：如果
gc current split、gc buffer busy、enq: TX - row lock contention在批量插入/索引重建期间突增 200% 以上，且集中在某几个对象上，大概率是 DRM 在反复重主 - 查 LMD trace：路径通常是
$ORACLE_HOME/rdbms/log/lmd*.trc，搜索DRM start或remastering。每小时出现 5 次以上就属于异常频次 - 查对象级热度：运行
SELECT object_name, opens FROM x$object_affinity_statistics WHERE opens > 1000，再结合V$SEGMENT_STATISTICS对比物理读/逻辑读。若某索引块opens高但实际访问极少，说明 affinity 统计被噪声干扰
_gc_affinity_time=0 是最快止血手段，但得全集群统一
设成 0 表示彻底禁用动态重主，只保留实例启停、节点驱逐等必要 reconfiguration 触发的静态重主。这不是“关功能”，而是关掉那个容易被业务毛刺带偏的自适应逻辑。
- 必须所有 RAC 节点同时执行：
ALTER SYSTEM SET "_gc_affinity_time"=0 SCOPE=SPFILE，单节点修改会导致 affinity 统计残留，引发 GRD 不一致 - 重启后验证：
SELECT ksppinm, ksppstvl FROM x$ksppi a, x$ksppcv b WHERE a.indx = b.indx AND ksppinm = '_gc_affinity_time'结果应为 0；同时x$object_affinity_statistics.opens应停止增长 - 副作用真实存在：节点长期离线后恢复，其 buffer cache 可能持续访问远端 master，增加跨节点通信。若集群稳定无扩缩容，这个代价可接受
_gc_affinity_limit 和 _gc_affinity_minimum 怎么调才不白忙
这两个参数控制 DRM 启动门槛，但只对 10gR2+ 的对象级重主生效，对文件级（如 10.1）完全无效。调错版本等于没调。
-
_gc_affinity_limit默认 50：指“非当前 master 节点”访问次数需超过当前 master 多少次才考虑迁移。压测后建议设为 200–500，避免单次误判（比如一个 SQL 扫描触发几十次访问）就触发重主 -
_gc_affinity_minimum默认 2400（即每分钟 40 次）：是统计启动的冷启动阈值。若业务峰值访问频次低于此值（例如报表库每分钟仅 10 次），DRM 根本不会启动，此时调低毫无意义 - 关键陷阱：这两个参数和
_gc_affinity_time是联动的。若_gc_affinity_time已设为 0，它们就彻底失效，不用再调
验证 DRM 是否真被抑制，不能只信参数值
参数写进 SPFILE 不代表运行时生效，尤其在 RAC 中，LMD 进程可能还在用旧缓存。
- 最硬核验证方式：在业务低峰期执行一次手动 DRM（
ALTER SYSTEM FLUSH BUFFER_CACHE+ 强制访问热点块），然后立刻查lmd*.trc。禁用后应完全看不到DRM start日志行 - 辅助验证：
SELECT COUNT(*) FROM x$object_affinity_statistics WHERE opens > 0，如果该值长期不变或缓慢爬升（ - 容易忽略的一点：DRM 抑制效果在实例重启后才完全落地。如果只改了 SPFILE 没重启，监控数据仍可能显示“假活跃”
