企业官网建设流程全解析

凌晨三点手机响，RAC集群里第二个节点被驱逐，业务中断，值班同事火急火燎地把告警转给你。你睡眼惺忪地打开告警日志，看到一行ORA-29740，后面跟着几行进程堆栈和十六进制地址，没了。这时候你面临一个尴尬局面：只知道节点被踢出去了，但到底是网络抖动、锁竞争还是块传输超时，日志里给的信息根本不够用。你只能在一堆trace文件里翻来翻去找线索，运气好半小时能定位到方向，运气不好就得靠着这些零碎日志找原厂支持，来回好几轮才搞明白根因。

这就是RAC环境下做故障排查最折磨人的地方：Oracle RAC最核心的机制是Cache Fusion（缓存融合），它负责在多个实例之间传递数据块，保证每个实例都能读到最新版本的数据。一旦这个机制在任意环节出错——私网延迟、锁资源卡死、LMS进程异常——整个集群就可能触发节点驱逐。但问题在于，传统的错误报告只能告诉你“出事了”，却很少告诉你“为什么出事”。Oracle显然也清楚这个痛点，于是后续版本引入了Enhanced Cache Error Reporting（增强的缓存错误报告），专门改善Cache Fusion相关故障的诊断体验。

这篇文章就围绕这个特性展开，聊清楚三件事：增强的缓存错误报告到底增强了什么、怎么把它用好、以及拿到增强报告之后如何顺着线索定位真正的根因。如果你是RAC环境的运维人员、DBA，或者正在准备数据库高可用相关的认证，这部分内容应该能帮你省下不少排查故障的时间。

1. 先对齐背景：Cache Fusion在RAC里扮演什么角色

1.1 块传输的本质逻辑

很多刚开始接触RAC的人会误以为多个实例各自负责一部分数据文件，互不干涉。实际完全不是这样。RAC里的所有实例访问的是同一套底层存储，任何一个数据块都可能同时被多个实例读写。为了保证数据一致性，Oracle引入了Cache Fusion机制——某个实例要读一个块，产生块请求；拥有该块最新版本的实例通过网络把它传过去；请求实例收到块数据后完成本地缓存更新。整个过程透明得像个高效的快递网络，业务侧根本感知不到。

这个机制的关键在于，块传输依赖一组后台进程来调度，其中最有名的是LMS（Lock Manager Server）进程和LMD（Lock Manager Daemon）进程。它们负责维护全局资源目录（GRD），记录哪个实例当前拥有哪些块的哪个版本。你可以把GRD想象成一份全集群范围内的快递签收表，每个块在哪、状态如何，都记在这张表里。

一旦某个块请求发出之后迟迟等不到响应，或者锁资源在多个实例之间形成循环等待，LMS/LMD就需要决定“要不要继续等”。RAC内部有一个基于超时的判定逻辑，超过阈值就触发特权操作，极端情况下会主动驱逐异常节点，把影响控制在最小范围。这个判定本身是合理的——一个节点僵死，不能拖累整个集群。

1.2 驱逐发生前的信号往往藏在细节里

节点驱逐不是一瞬间发生的。在驱逐之前的几秒甚至几分钟内，通常会有大量细节信号：私网网卡重传率上升、LMS进程的CPU飙升、块请求队列堆积、全局锁等待时间异常。这些信号在传统报告中要么被淹没在冗余日志里，要么压根没被记录下来。

我遇到过最典型的情况是私网交换机端口协商失败，从一个万兆口降速到千兆口，但网络并没有完全中断。业务侧只是觉得偶尔变慢，数据库层面已经开始出现块请求超时。若是在12c之前的版本，这种问题排查起来非常费劲，因为alert日志里只有零散的错误码，没有块地址、没有对象信息、没有锁持有者的完整列表，你根本没法把“网络变慢”和“Cache Fusion超时”这两件事关联起来。

增强的缓存错误报告恰恰解决了这个问题：它希望在错误发生的瞬间，把现场尽可能完整地拍照存档，让后续的诊断有据可查。

2. 增强的缓存错误报告到底改进了什么

2.1 传统错误报告的薄弱环节

先说说老版本为什么难排查。拿最常见的ORA-29740（实例被驱逐）举例，传统alert日志里能看到的信息大致是：错误码、被驱逐的实例号、触发驱逐的进程名、进程栈地址。这些信息对开发者定位代码缺陷很有用，但对运维人员的帮助非常有限——就像你收到一条“您的快递运输出现问题”的短信，但既没有运单号、也没有问题网点、更没有预计恢复时间，全靠猜。

更难受的是，Cache Fusion相关的问题往往和“时间窗口”“状态快照”强相关。锁资源在A时刻被实例1持有，B时刻被实例2请求，C时刻触发超时。如果日志只记录了C时刻的结果，没有A、B时刻的状态，排查就只能靠复现或者猜测。而生产环境里，复现一个偶发的RAC问题几乎不可能，后续的调整大多基于经验和运气。

2.2 增强特性的四大核心改进

增强的缓存错误报告通过几个维度的改进，把“事故现场”还原得更完整：

错误上下文的完整记录。触发错误时，系统会把涉及的数据块地址（DBA）、对象ID、SCN号、缓存标签等信息一并写入错误信息中。比如一个块传输超时错误，增强报告会明确指出是哪个文件的哪个块、属于哪张表或索引、请求方是哪个实例、持有方是哪个实例。有了这些信息，你就能直接关联到具体对象，快速判断是不是某种特定操作导致的。

锁状态与资源持有链路的快照。Cache Fusion的很多问题本质上是锁问题。增强报告会自动抓取GES/GCS资源目录中的关键资源状态，包括锁的持有者、请求者、转换状态等。这就好比快递系统在丢件时，把整个分拣台的包裹流转记录都导出来，你一眼就能看到是哪个中转环节出了问题。

自动写入ADR并生成诊断事件。Oracle 12c之后的版本越来越依赖自动诊断仓库（ADR）来统一管理错误信息。增强缓存错误报告会作为一个个独立的incident写入ADR，并自动关联相关的trace文件、健康检查报告和集群日志。之后你可以用adrci工具一条命令看到完整的事故包，不用手工四处找文件。

与节点驱逐评估机制的联动。驱逐发生前，健康监控（Health Monitor）会做一轮诊断检查，增强报告会把检查结果（比如网络延迟测试、IO响应测试）一并记录。很多时候，节点驱逐的根因其实是底层基础设施的某个瓶颈，这部分联动数据能让DBA更快地把问题递交给网络或存储团队。

所以，增强的缓存错误报告本质上不是改变了Cache Fusion的工作方式，而是改变了对Cache Fusion故障的记录和呈现方式。它让你在错误发生之后，有更多可供推导的证据。

3. 怎么启用和确认增强缓存错误报告在工作

3.1 版本与默认行为

先确认一个常见误区：增强的缓存错误报告不是一个需要单独购买或手动开启的独立功能，它是Oracle诊断基础设施的一部分，内嵌在数据库内核中。在Oracle 11gR2及之后的版本里，只要数据库的自动诊断仓库（ADR）功能正常工作，增强报告就会默认激活，不需要额外的License。

不过，默认激活不等于每个集群都能完整发挥它的价值。我碰到过一些环境，为了省一点磁盘空间，DBA手动禁用了诊断相关的后台任务，比如关闭了Health Monitor的定期检查，或者设置了过小的ADR文件和incident空间上限。这种情况下，增强报告能记录的内容会大打折扣，甚至可能因为写不进去而直接丢弃关键上下文。

3.2 关键配置项：别让诊断能力被静默阉割

基于我的实际经验，建议重点检查以下几个配置点：

确认诊断包和ADR处于开启状态。查看初始化参数diagnostics_dest是否指向了有效路径，control_management_pack_access是否设置为DIAGNOSTIC+TUNING。如果这些被改掉，增强报告的部分关联数据是拿不到的。

检查事件级别设置。Oracle提供了一些和Cache Fusion诊断相关的内部事件，比如通过ALTER SYSTEM SET EVENT='10049 trace name context forever, level 10'可以开启GCS相关的详细trace。生产环境开启trace需要谨慎，但其实在故障期间临时开启，对性能影响有限，却可能为问题分析留下宝贵的第一手信息。

确保集群日志有足够的保留周期。Cache Fusion的错误经常需要回溯驱逐前几分钟到几小时的私网通信情况。而这些信息主要记录在Clusterware的crsd.log、cssd.log以及$GRID_HOME/log/<hostname>/client的日志里。默认保留周期通常足够，但如果你调小了日志滚动策略，关键时刻会发现历史数据已经被覆盖。

3.3 验证特性是否生效

配置完成后，怎么知道增强报告真的在工作而不是形同虚设？

最简单的办法是查看alert_<sid>.log中的错误记录格式。如果某次和Cache Fusion相关的错误（比如ORA-29740、ORA-32701、LMS相关的内部错误）发生后，日志里出现了“Following errors are being logged in the ADR”或者带有完整块地址和对象信息的描述，说明增强报告已经介入。你也可以用adrci命令检查incident列表：

adrci> show incident -last 30

如果输出里有ORA-29740相关的incident，且每个incident都带有配套的trace文件和健康检查快照，那说明整个诊断链路是通的。反之，如果incident是空的或者缺少关联文件，大概率是某个诊断组件被关掉了。

4. 一次节点驱逐的实战分析：顺着增强报告找根因

4.1 第一现场：alert日志里多出来的内容

为了让你更直观地理解这个特性的价值，我用一个我实际处理过的场景来走一遍排查链路。

某客户一套两节点RAC，某天下午两点左右，节点2突然被驱逐，业务侧有短暂闪断。运维同事第一时间把alert日志发给我，里面有典型的ORA-29740，但和以前不同的是，日志中多了一段关于块传输超时（block transfer timeout）的上下文记录：

2025-06-12 14:02:31.123 ORA-29740: instance 2 is being evicted Detailed cache fusion error information: Block address: 0x0000000100a1b2c3 Object ID: 52391 Object name: T_CORE_ORDER.DATA_SEGMENT Requested by instance: 2 Holding by instance: 1 Last transfer duration: 3214 ms Transfer threshold: 2000 ms GCS resource: [0x1001],[BLOCK][TRANSFER]

这一段在传统版本里是完全不可能出现的。有了块地址和对象ID，排查方向瞬间就收窄了——这不是一个随机的集群通信问题，而是某个具体数据块在从实例1传给实例2的时候，耗时超过了阈值。

4.2 顺着增强报告里的线索往下挖

拿到这个上下文后，我做了三件事：

确认那个块是什么业务对象。通过对象ID 52391定位到T_CORE_ORDER表，这是业务核心的订单表。此时心里大概有个假设——节点2在14:02左右一定有大量对该表的读操作，并且需要从节点1拉取最新版本的数据块。

查GV$CACHE_TRANSFER，看块传输的历史趋势。于是我执行了类似下面的查询：

SELECT inst_id, file_id, block_id, transfers, force_requests, gcs_ping_time, gcs_recv_time FROM gv$cache_transfer WHERE file_id = (SELECT file_id FROM dba_data_files WHERE tablespace_name = 'TBS_ORDER') AND block_id BETWEEN 100 AND 200;

结果发现这个范围的数据块在14:00到14:02之间，gcs_ping_time明显上扬。所谓gcs_ping_time指的就是跨实例块传输的耗时，正常在几毫秒级别，异常时能到几百甚至几千毫秒。这一下子就证实了：不是锁死，不是进程卡住，就是块传输路径变慢。

调出ADR里的健康检查报告。因为增强报告会自动关联驱逐前的健康检查数据，我用adrci进入实例的ADR目录，查看关联的健康检查输出：

adrci> show healthcheck adrci> show incident -p "ORA-29740"

健康检查里记录了一条私网通信测试结果，节点1到节点2之间的往返延迟在14:00之后从正常的0.2ms飙到了30ms，丢包率也在同步上升。到这里，根因基本就浮出水面了。

4.3 最终确认是私网基础设施问题

把以上证据放在一起，整条逻辑链就闭合了：14:00之前私网通信正常，所以块传输很快；14:00之后私网开始出现延迟和丢包，节点2频繁向节点1请求最新的订单块，每个块的传输都卡在网络上；当累积的块请求超时达到阈值后，节点2被强制驱逐。

后续让网络团队检查私网链路，发现是其中一台交换机上的光模块收发光功率异常，导致端口间歇性丢包。更换光模块后，集群运行恢复平稳，再没有出现过驱逐。

如果是在老版本环境，这个案例的排查过程会非常痛苦。alert日志里只有孤零零的错误码，没有块地址，没有传输耗时，没有健康检查联动数据。你只能一边观察Oracle Support给出的通用检查项，一边组织网络团队做各种网络测试，耗时至少一个通宵。而增强的缓存错误报告把原本需要手动推理的链路，直接简化成了“读日志、查对象、定位方向”三步。

5. 把增强报告用到极致：个人经验与容易踩的坑

5.1 不要过度依赖默认开启的配置

虽然增强报告默认是开的，但它依赖的底层组件太多，任何一个环节出问题都可能让报告内容不完整。我建议定期做一次“诊断链路巡检”：

• 检查ADR空间使用率，别让adrci里的增量文件把磁盘涨满
• 确认diag_adr_enabled等参数没有被修改
• 留意集群日志的滚动周期和保留量，尤其是在大促、压测等业务高峰前后

有一次我在客户现场排查问题时发现，他们的节点驱逐错误在alert日志里根本没有自动关联的块信息。后来一查，原来是有人为了清理磁盘空间，把$GRID_HOME/log下的一部分历史目录手动删掉了，破坏了集群日志的连续性，导致增强报告的关联数据缺失。这种情况等故障发生后再去补救就晚了。

5.2 处理大对象热点块时要格外上心

增强报告里经常出现的“Block address”如果指向了某个大对象的Segment Header或者高并发修改的索引根块，那问题往往不只是网络。我见过不少案例，实际上是应用层某个SQL对单行记录发起了高频更新，导致同一个块在多个实例间反复流传，最终触发超时驱逐。此时即使网络正常，块传输也会因为锁竞争而变慢。

判断方法很简单：如果在增强报告中看到的全是同一个对象、同一个块地址反复出现，且gv$cache_transfer里的force_requests特别高，那就别把锅甩给网络，重点看看应用侧有没有热点更新。配合ASH（Active Session History）里该块相关的等待事件，很快能锁定是哪个SQL造成的。

5.3 保留现场信息是最高优先级

增强报告的价值在于“事故现场”，所以一旦发生驱逐类故障，建议第一时间先把ADR里的相关文件原样备份出来，再去做后续处理。不要急着重启节点或者清空告警，更不要顺手把trace文件删掉。很多时候，你在处理后回头看，才能从trace文件里发现当时被忽略的次要线索。

我的习惯是，在任何RAC故障处理完、集群恢复正常之后，马上把以下内容打包归档：alert日志片段、ADR中的incident目录、ocrdump输出（如果涉及节点驱逐）、crsctl stat res -t的输出、私网通信测试的记录。这些文件组合起来就是一个完整的事故档案，后续无论是复盘还是交给原厂支持做二次分析，都能用得上。

5.4 与其它诊断工具搭配才完整

增强的缓存错误报告解决的是“错误发生时记录什么”的问题，但RAC的故障排查还需要配合“持续观测”的工具：

• **Cluster Health Monitor（CHM）**记录OS级别的资源、网络、存储指标，能看到驱逐前操作系统层的异常
• OSWatcher可以补足CHM未覆盖的时间段，尤其适合在自建环境里长期跑着
• v$instance_recovery / gv$cache_transfer能从数据库内部持续反映缓存融合的健康度

我的建议是把这些工具当成常态监控的一部分，而不是故障了才想起来装。增强报告解决的是“最后一公里”的诊断问题，而持续观测解决的是“故障之前那一公里”的预警问题。两者结合，RAC的故障排查效率才会真正上一个台阶。

整套思路跑下来，最深的感受是：RAC的稳定性除了靠内核本身的健壮性，很大程度上也依赖于出事之后能不能快速定位根因。增强的缓存错误报告把那些曾经藏在底层、要靠经验才能翻出来的细节，直接结构化地摆到了你面前。技术本身不难理解，真正重要的反而是平时把诊断环境维护好、把日志留全，这样真出事的时候，这份报告才能最大化地发挥作用。希望这篇文章能帮你少走几个夜路，遇到Cache Fusion相关的问题时，第一反应不再是打开浏览器搜索错误码碰运气，而是直接去ADR里拿线索。