Resource Master（RM）

在 Oracle RAC（Real Application Clusters）里，"Resource Master（RM）" 并不是指某个单独的后台进程，而是一套内嵌在 **GCS（Global Cache Service）** 与 **GES（Global Enqueue Service）** 中的"分布式资源目录 + 动态协调"机制。下面从概念、数据结构、生命周期、算法流程、可观测性与调优五个维度，对它做系统性梳理。

## 一、概念定位：为什么要有 Resource Master

1. **多节点缓存共存**
每个实例都有自己的 SGA，数据块可能同时在 N 个节点的 Buffer Cache 里出现。RAC 必须回答三个问题：
- 集群范围内谁持有最新版本？
- 谁正在修改？
- 谁有资格读取？

2. **中心化目录 vs. 分布式目录**
如果每一次块访问都向所有节点广播，私网会瞬间爆炸。于是 Oracle 把"目录"拆成分片，每片指派一个 **Resource Master** 节点，负责"记账"与"仲裁"。其它节点只需访问这个 Master，就能拿到全局信息，显著降低消息量。

3. **动态 vs. 静态**
9i 及以前是静态 Master，表空间或文件第一次被打开时就固定 Master 节点；10g 引入 **DRM（Dynamic Resource Mastering）** 后，Master 可根据负载漂移，实现"热点跟着 Master 走"，这就是 Resource Master 机制的核心价值。

## 二、数据结构：RM 在内存里长什么样

1. **Resource 名称**
用三段式表示：`<file#><block#><class>`。GES 按名称做哈希，决定默认 Master。

2. **GRD（Global Resource Directory）**
不是集中一块内存，而是被哈希切片后分散在各节点。RM 所在的节点保存该片 GRD 的"主副本"，内容包括：
- **Role**：Local/Global（是否由远程改写过）
- **SCN**：最新块版本号
- **Holder List**：哪些实例持有以及锁模式（N/S/X）
- **Past Image（PI）**：写回磁盘前保留的脏块前像

3. **锁模式兼容矩阵**
N(Null) S(Shared) X(eXclusive) 三种模式，兼容规则用一张 3×3 表硬编码在内核，任何申请先经 Master 做"矩阵运算"，冲突则排队。

4. **后台进程角色**
- **LMSn**：负责跨节点块传输
- **LMD0**：处理 GES 消息、死锁检测
- **LMON**：集群成员变更时触发 reconfiguration，重建 GRD
- **CKPT、DBWn**：与 PI 交互，保证写盘一致性
RM 的"逻辑代码"主要跑在 LMS 与 LMD 的上下文里。

## 三、生命周期：一次块访问的隐形之旅

1. **解析阶段**
用户进程发出 `db file sequential read` → 先在本节点 Cache 找，未命中则进入 **Global Cache** 流程。

2. **哈希定位 Master**
用对象 ID+块号哈希，算出默认 Master 节点（可能在本节点，也可能在远端）。

3. **发送请求**
进程向 Master 节点的 LMD0 发一条 **"lock request for block"** 消息，携带自己需要的锁模式（S 或 X）。

4. **Master 裁决**
- 若无冲突，直接 grant，返回 **"owner is node X"**；
- 若冲突，把请求放进等待队列，并向持有者发 **"convert lock"** 要求其降级或写回。

5. **Cache Fusion 传块**
持有者收到 convert 后，通过 LMSn 把块发送给申请者，状态可能是 Current、CR（consistent read）或 PI。

6. **更新目录**
传块完成后，Master 把最新 Holder 信息写回 GRD，并唤醒后续等待者。整个流程通常 < 5 ms（1 Gb 私网、空闲系统）。

## 四、动态重配（DRM）算法剖析

1. **采样周期**
`_gc_policy_time` 默认 10 min，LMSn 每周期统计各节点对该资源的访问次数。

2. **亲和度阈值**
`_gc_affinity_limit` 默认 50 次且占比 > 90 %，满足即触发 **affinity computation**。

3. **渐进式 remastering**
- 先对 **object**（10gR2 后按段）级别打标记；
- 在 **"Quiesce"** 阶段，短暂冻结该对象所有块的新请求（毫秒级）；
- LMON 协调各节点，把旧 Master 的 GRD 片传向新 Master；
- 更新完资源哈希表后，解除冻结，继续正常服务。
块本身 **不移动**，只移动"账本"，所以网络开销远小于重新复制 8 KB 块。

4. **Undo 段的特殊处理**
写密集场景下，Undo 块也会成为热点。Oracle 引入 **"_gc_undo_affinity"**，可让 Undo 段同样动态 remaster。

## 五、可观测性与日常调优

1. **实时视图**
- `V$GCSPFMASTER_INFO` — 查看每个数据块的 **current_master**；
- `V$GES_RESOURCE`/`V$GES_ENQUEUE` — 看锁的 Master 节点与等待队列；
- `V$DLM_MISC` — 统计 remastering 次数与耗时。

2. **AWR 与 trace**
AWR 的 **"Global Cache Workload"** 一节会列出 **"Remastering Operations"** 与 **"CR Blocks Received"**。若每小时间 remastering > 50 次，通常说明热点漂移过快，需关闭 DRM 或拆分业务。

3. **关闭场景与参数**
- `_gc_policy_time = 0` — 彻底关闭采样，不再动态漂移；
- `_gc_affinity_limit = 100000` — 把阈值提到极高，变相禁用；
- `_gc_undo_affinity = FALSE` — 仅对 Undo 段关闭。
关闭后，Master 只在 **实例启动/关闭** 或 **LMON reconfig** 时重新计算，系统行为回归"静态 Master"时代，性能更 predictable。

4. **正向优化思路**
若决定保留 DRM，可通过以下手段降低抖动：
- 把热点表做成 **hash partition**，打散访问；
- 使用 **Service** 或 **应用层分片**，让固定模块只连固定节点，形成天然亲和；
- 升级私网到 10 Gb/25 Gb，并开启 **RDMA**，让 remastering 消息更快；
- 打最新 PSU，避免已知 BUG（19557234、29980354 等）。

## 六、小结：一句话记住 Resource Master

Resource Master 就是"分布式缓存账本"的**动态账房先生**——它自己不存数据块，只记录"块在谁手里、锁级别是什么"；通过把目录拆片并允许 Master 节点跟随业务热点漂移，Oracle 在 **"一致性"** 与 **"高性能"** 之间取得了可伸缩的平衡。理解并监控好这套机制，是每一个 RAC DBA 排查 **gc buffer busy**、**interconnect storm** 乃至决策是否关闭 DRM 的必备基础。