Dynamic Resource Management（DRM）

下面给出一份面向 **Oracle 19c RAC** 场景、专门聚焦 **Dynamic Resource Management（DRM）** 的技术说明。为便于阅读，全文按“概念→原理→算法→优缺点→关闭原因→最佳实践”六个层次展开。

---

### 一、概念澄清：两种极易混淆的 DRM
在中文语境里，“DRM”常被同时用于
1. Digital Rights Management（数字版权保护）；
2. Dynamic Resource Management（Oracle RAC 的动态资源重配）。

本文只讨论后者，即 **Oracle RAC 为优化 Cache Fusion 而引入的“动态资源主节点重配”机制**。

---

### 二、为什么需要 DRM
在 RAC 中，数据块缓存在各节点的 Buffer Cache 里。为保持全局一致性，需要：
- **Master Node（主节点）**：记录每个数据块在集群中的最新版本位置；
- **Global Cache Service (GCS)**：借助 Master 信息完成跨节点数据传递。

早期版本（9i 及以前）采用 **Static Mastering**——块的 Master 节点在表空间级固定，无法跟随业务热点移动。若节点 1 是某表空间的 Master，而该表空间 90 % 的访问来自节点 2，则节点 2 的每一次逻辑读都必须跨私网询问节点 1，产生额外 **interconnect traffic** 与 **CPU overhead**。

DRM 的设计目标就是 **让 Master 节点跟随热点数据自动漂移**，从而减少跨节点流量、降低平均响应时间。

---

### 三、实现原理与关键数据结构

1. **Resource Master（RM）**
每个数据块在集群中对应一个锁资源；RM 结构体保存了该资源的当前 Master Node ID。

2. **Affinity（亲和度）统计**
后台每 10 s（由 `_gc_policy_time` 控制）采样各节点对该资源的访问次数。
- 当某节点连续 N 个周期占绝对优势（默认 50 次访问且超过阈值 90 %），就触发 **affinity computation**。

3. **Remastering（重配）流程**
1. 选取新 Master 节点；
2. 冻结该资源的所有锁请求；
3. 通过 **interconnect** 将 Master 元数据广播到所有节点；
4. 重建 **Global Resource Directory (GRD)**；
5. 解锁并恢复服务。

整个重配期间，对应数据块的所有访问都会被短暂阻塞（通常毫秒级，但在高并发场景可能达到秒级）。

---

### 四、相关参数与可观测性

| 参数/视图 | 作用说明 |
|-----------------------------|--------------------------------------------------------|
| `_gc_policy_time` | 采样周期，默认 10 s。 |
| `_gc_affinity_limit` | 触发 remastering 的访问次数阈值。 |
| `V$GCSPFMASTER_INFO` | 查看每个对象的当前 Master 节点。 |
| `V$GES_ENQUEUE` / `V$DLM_MISC` | 监控重配过程中锁队列的等待事件（`gcs drm freeze` 等）。 |
| AWR 报告 “Global Cache” 章节 | 观察 interconnect 流量和 remastering 次数。 |

---

### 五、优缺点与生产痛点

| 优势 | 劣势 |
|------|------|
| 热点数据与 Master 同节点，减少网络跳数，降低 **gc cr/current block busy** 等待。 | 重配本身带来 **CPU 抖动**、**interconnect storm**，极端情况下触发 **ORA-481`、`latch: gcs resource hash bucket`** 等 bug。 |
| 对 OLTP 短事务友好，平均响应时间下降。 | 对 **大表全表扫描**、**批量 ETL** 等长事务场景收益有限，反而因频繁 remastering 放大抖动。 |
| 理论上无需 DBA 干预，自适应。 | 与 **parallel query**、**partition-wise join** 并发时，易出现 **DRM vs. PX 死锁**（已知 bug 29980354）。 |

---

### 六、关闭 DRM 的核心原因与落地方法

#### 1. 为什么关闭
- **稳定性压倒性能**：在 10 g/11 g 早期版本，大量生产事故归因于 DRM；
- **业务特点决定**：数据热点变化快（如秒杀、批量跑批），remastering 频率 > 1 次/分钟，系统处于持续抖动；
- **已知 Bug**：
- Bug 19557234：大量 “kclDRM” 等待导致节点重启；
- Bug 29980354：并行查询与 DRM 死锁。

#### 2. 关闭步骤（19c 依旧有效）

```sql
-- 1. 禁用动态 remastering（立即生效，无需重启）
ALTER SYSTEM SET "_gc_policy_time"=0 SCOPE=SPFILE SID='*';

-- 2. 可选：保留 object affinity，但禁止跨节点迁移
ALTER SYSTEM SET "_gc_affinity_limit"=100000 SCOPE=SPFILE SID='*';
```

- `_gc_policy_time=0` 彻底关闭采样与重配；
- `_gc_affinity_limit` 设为大值可避免阈值触发；
- 若同时关闭 **object affinity**，可再设 `_gc_undo_affinity=FALSE`，避免 undo 段漂移。

#### 3. 关闭后验证
- AWR 报告中 **“remastering operations”** 计数降为 0；
- `V$GCSPFMASTER_INFO` 中 master_id 不再变化；
- 观察 **gc cr/current block busy** 与 **interconnect traffic** 是否上升；若上升，可通过分区、服务隔离、应用层分库分表等手段补偿。

---

### 七、最佳实践小结

1. **OLTP 轻量级场景**：保留 DRM，配合 `_gc_policy_time=30`、`_gc_affinity_limit=150` 降低触发频率。
2. **混合负载/批处理场景**：直接关闭 DRM，并通过服务（service）或分区（partition-wise）绑定方式手动均衡热点。
3. **上线前压测**：使用 Swingbench、TPC-C 或真实业务脚本，重点观察 **interconnect traffic** 与 **remastering events**；出现抖动即关闭。
4. **版本升级**：19c 虽修复了大量 DRM 相关 bug，但 **自适应逻辑依旧激进**，很多金融、电信核心库仍选择关闭以换取确定性。

---

### 八、一句话总结
DRM 是把双刃剑——在理论上能减少跨节点流量，却可能因频繁 remastering 而带来 **不可预期的性能抖动**；
对大多数追求 7×24 稳定性的核心系统而言，“关掉它，再通过架构手段均衡热点”往往是更可控的选择。