DMDSC 集群出现数据库实例或者节点硬件故障时，DMSERVER 的 VOTE 磁盘（非镜像环境下）或 DCRV 磁盘（镜像环境下）心跳信息不再更新，DMCSS 一旦监控到 DMSERVER 发生故障，会马上启动故障处理（参考[5 DMCSS 介绍](#5 DMCSS 介绍)），各节点 DMSERVER 收到故障处理命令后，启动故障处理流程。
在 DMDSC 故障处理机制下，一旦产生节点故障，登录到故障节点的所有连接将会断开，所有未提交事务将被强制回滚；活动节点上的用户请求可以继续执行，但是一旦产生节点间信息传递（比如：向故障节点发起 GBS/LBS 请求、或者发起 Remote Read 请求），当前操作就会被挂起；在 DMDSC 故障处理完成后，这些被挂起的操作可以继续执行。也就是说，DMDSC 产生节点故障时，活动节点上的所有连接会保留，正在执行的事务可能被阻塞一段时间，但最终可以正常完成，不会被强制回滚，也不会影响结果的正确性。
DMDSC 环境 DMSERVER 故障处理主要包括以下工作：
- 暂停所有会话线程、工作线程、日志刷盘线程、检查点线程等，避免故障处理过程中产生并发错误；
- 收集所有活动节点的 Buffer，丢弃无效数据页，获取最新数据页和需要重做 REDO 日志的数据页信息，并在排除故障节点后重新构造 LBS/GBS 信息；
- 重做 REDO 日志；
- 收集所有节点事务信息，重新构造锁对象，并重构相应的 LLS/GLS/LTV/GTV 系统；
- 控制节点执行故障节点活动事务回滚和故障节点已提交事务修改的 PURGE 操作。
DMDSC 故障处理分为三个阶段；第一阶段由所有活动节点共同参与，进行全局的信息收集、重构；第二阶段由控制节点执行，重演 REDO 日志；第三阶段由控制节点执行，将故障节点的活动事务回滚、并 PURGE 故障节点已提交事务的修改。在第一阶段执行期间，数据库实例不提供数据库服务，所有用户请求将被挂起。根据故障处理策略（由 INI 参数 DSC_CRASH_RECV_POLICY 控制）的不同，在第二阶段操作之前，会选择是否唤醒所有活动节点，正常提供数据库服务，也就是说故障处理第二阶段的操作与正常的数据库操作在系统内部同时进行。默认故障处理策略时，第二阶段重做所有节点 REDO 日志，且在此期间数据库服务挂起，直到第三阶段结束重新唤醒所有活动节点。选择新的故障处理策略，第二阶段只重做故障节点 REDO 日志，且在第二阶段开始前唤醒所有活动节点。第三阶段执行完成之前，DMDSC 故障处理仍然没有真正结束，在此期间，不能处理节点重加入，也不能处理新的节点故障，如果有新的节点故障会主动中止所有节点。
说明1.通常意义上讲的故障处理，包含故障检测和故障处理两部分。
2.故障检测时间由DCR_GRP_DSKCHK_CNT决定。
3.影响故障处理时间的因素比较多，主要包括：故障节点REDO日志数量、修改涉及的数据页数量、需要ROLLBACK、PURGE的事务数，以及活动节点Buffer使用情况等。
