drm是dynamic resource remastering，非dynamic readmost；其冻结阶段会全局阻塞资源访问，引发gc current request等链式等待，真正卡顿根源在于五阶段不可中断执行模型，而非read-mostly本身。
drm 本身不是 “dynamic readmost”，而是 dynamic resource remastering。名称混淆是第一个坑——很多 dba 看到日志里出现 readmostlytransfer 就误以为是某种“读优化模式”，其实它只是 drm 过程中一种资源迁移类型（针对 read-mostly 对象的 remaster），和“卡顿”没有直接因果关系，但它是 drm 触发后的典型痕迹。
真正导致卡顿的，是 DRM 的五阶段执行模型在高负载下暴露的固有缺陷：静默 → 冻结 → 清除 → 重建 → 解冻。其中 冻结（freeze）阶段会全局阻塞对目标资源的所有新请求，而这个过程无法被中断或降级。
DRM 冻结阶段引发的会话级阻塞
- 当 LMON 启动一次 DRM（比如
DRM(36333)），所有涉及的资源会被标记为“正在迁移”，LMS 进程立刻进入gcs drm freeze in enter server mode等待。 - 此时任何新发起的
gc current request、gc cr request都会被挂起，直到该 DRM 完成。 - 如果 DRM 涉及大量资源（例如某张高频插入的流水表对应数万 pkey），冻结时间可能达数秒 —— 这期间所有等待这些块的会话全部堆在
gc current request上，形成链式阻塞。 - 你看到的
log file switch (checkpoint incomplete)或buffer busy waits都是下游效应：redo 写不下去、checkpoint 卡住、DBWn 无法刷脏块。
_gc_affinity_limit 和 _gc_affinity_minimum 参数的实际作用
这两个参数不是“关闭 DRM”，而是大幅提高 DRM 触发门槛，让绝大多数日常访问达不到触发条件：
-
_gc_affinity_limit控制“单节点连续访问次数上限”，设为250意味着：即使某节点 10 分钟内访问某对象 249 次，也不会触发 DRM。 -
_gc_affinity_minimum是“全集群每分钟最小访问总次数”，设为10485760（10MB）相当于要求该对象每分钟被访问超千万次才考虑 remaster。 - 它们是动态参数，
alter system set "_gc_affinity_limit"=250 scope=both sid='*';立即生效，无需重启。 - 注意：不要设为
0或负值，某些版本会触发未定义行为；也不要依赖_gc_policy_time=0，该参数在 11.2.0.4+ 已被弃用，且设为 0 可能反而激活异常路径。
为什么 read-mostly 相关操作也会卡住
11g 引入的 read-mostly locking 本意是减少跨节点 S-lock 通信，但它依赖 DRM 完成对象级别 affinity 建立：
- 当一个对象首次被识别为 read-mostly，Oracle 会启动 DRM 将其 master 迁移到该节点，并广播 S-affinity 锁。
- 如果此时该对象正被大量并发读写，DRM 的
freeze阶段会和anti-lock广播竞争资源，LMS 进程可能陷入长时间同步等待。 - trace 文件中若同时出现
Rcvd DRM(...)和kjxgm_Notify_Eviction，说明 DRM 过程已干扰到实例间心跳，这是 RAC 不稳定的关键信号。
DRM 的设计初衷没问题，但它的实现粒度太粗（以 resource group 为单位冻结）、阶段不可打断、且与 LMS/LMON 的调度强耦合。在 OLTP 类系统中，哪怕一次小规模 DRM 都可能成为性能雪崩的起点。真正要规避，不能只盯着“是否 read-mostly”，得从触发机制本身下手——调参比禁用更可控，而监控 gcs drm freeze 等待事件比等 hang 再查 trace 更有效。
