第十二周博客DM8 3.162 DSC 双节点 + 单机 DW 备库搭建、xx项目恢复及集群故障修复周学习报告一、本周

DM8 3.162 DSC 双节点 + 单机 DW 备库搭建、xx项目恢复及集群故障修复周学习报告

环境：DM8 3.162 Pack17，ARM aarch64
架构：2 节点 DSC 主库 + 1 节点单机数据守护备库
涉及节点：46、47、48
本周内容：DSC 搭建、xx项目物理备份恢复、DW 备库搭建、GROUP SPLIT 排障、备库重同步、47 节点系统恢复、46/48 程序版本与架构修复、动态库问题排查、最终健康基线验证

[!NOTE]

由于在现场做这些工作的时候过程中很多过程并未截图，所以本篇报告缺少实际操作的具体截图，有些简单的截图内容放在每日汇报的pdf中了。

一、本周学习目标与整体工作脉络

本周的工作并不是两个互相独立的实验，而是围绕同一套 DM8 DSC + DW 环境连续完成了“搭建—恢复—排障—故障修复—最终验证”这一整条链路。

前半阶段主要解决的是：如何在 DM8 3.162 Pack17 环境中搭建 46、47 两节点 DSC 主库，将国机项目已有物理备份恢复到 DSC 中，再在 48 上建立单机数据守护备库，使其通过 REALTIME 归档与 DSC 主库建立实时日志同步关系。

在这个过程中，最关键的问题是 48 曾经以 NORMAL 数据库独立 OPEN，造成主库与备库的 SYSOPENHISTORY 从共同历史处分叉。表面上数据库能够进入 OPEN STANDBY，但数据守护仍然显示 WCTLSTAT = SPLIT、RSTAT = INVALID。最终通过重新从当前健康 DSC PRIMARY 做全备，仅重同步 48，重新建立数据、日志和 Open History，才真正消除了历史分叉。

后半阶段则进入了更复杂的真实故障修复：47 节点由于系统目录被破坏而进行了操作系统重装，46 节点在恢复过程中又出现了 x86 程序误覆盖 ARM 环境的风险，48 备库启动时报 126，同时还存在多套 DM 程序和动态库互相串用的问题。最终通过恢复设备映射与节点配置、校验程序架构和 SHA256、排查动态库实际加载路径、重新切换正确 Pack17 程序目录，并坚持让 48 以 MOUNT → STANDBY → watcher 接管 的方式恢复，最终使 DSC、CSS、ASM、Watcher、PRIMARY/STANDBY 角色和日志 LSN 全部恢复正常。

因此，本周最大的收获不是单独记住了若干命令，而是逐步建立了一套完整的 DM8 DSC + 数据守护故障分析方法：先判断层次，再判断状态；先保护已有数据，再恢复程序和配置；最后才恢复数据库角色和守护关系。

二、环境与最终架构

2.1 节点信息

项目	46 节点	47 节点	48 节点
业务 IP	xxxx.47	xxxx.47	xxxx.48
MAL/内部通信 IP	xxxx.46	xxxx.47	xxxx.48
实例名	CNDT_DSC0	CNDT_DSC1	DSC_STDB
数据库角色	DSC PRIMARY	DSC PRIMARY	STANDBY
数据库端口	5236	5236	5436
MAL_PORT	5246	5246	5246
MAL_DW_PORT	52141	52141	52141
MAL_INST_DW_PORT	33141	33141	33141
数据目录	`/data/dsc162/CNDT_DSC0`	`/data/dsc162/CNDT_DSC1`	`/data2/dsc162/rst/data/dsc`
DM 软件目录	`/data1/dm8_3_162_pack17`	`/data1/dm8_3_162_pack17`	`/data1/dm8_3_162_pack17`
数据守护 OGUID	260914	260914	260914

本次使用的软件基线为：

DM Database 64 V8
03134284194-20240920-243476-20108

服务器架构为：

ARM aarch64

DSC 的 CSS/DCR 层使用的 OGUID 为：

数据守护使用的 OGUID 为：

2.2 整体架构

┌───────────────────────────────────┐
│            DSC PRIMARY            │
│                                   │
│ xxxx.46  CNDT_DSC0            │
│ xxxx.47  CNDT_DSC1            │
│                                   │
│      两个节点共享 ASM 存储         │
└────────────────┬──────────────────┘
                 │
                 │ REALTIME
                 │
                 ▼
┌───────────────────────────────────┐
│          单机 STANDBY             │
│                                   │
│ 172.20.6.48  DSC_STDB             │
│ /data2/dsc162/rst/data/dsc        │
└───────────────────────────────────┘

2.3 DSC 共享 ASM 设备

46、47 两个 DSC 节点共同访问同一组共享存储。

用途	设备
DCR	`/dev/dm/asm-DCR`
VOTE	`/dev/dm/asm-VOTE`
REDO	`/dev/dm/asm-REDO`
ARCH	`/dev/dm/asm-ARCH`
DATA1	`/dev/dm/asm-DATA1`
DATA2	`/dev/dm/asm-DATA2`
DATA3	`/dev/dm/asm-DATA3`

这些设备承担的职责并不相同：

DCR：DSC 集群配置及节点信息；
VOTE：集群仲裁；
REDO：联机日志；
DATA：数据库数据文件；
ARCH：归档相关存储。

这一点在后续 47 节点操作系统重装恢复时非常重要。只要共享 SAN 数据和 ASM 元数据没有损坏，就不能因为操作系统重装而直接重新初始化这些共享设备，否则很可能把原本仍然完整的数据库集群元数据破坏掉。

第一阶段：DSC + DW 搭建与国机项目物理备份恢复

三、DSC 双节点基础搭建

3.1 DSC 初始化的本质

DSC 并不是在 46、47 上分别创建两套独立数据库，而是初始化一套共享数据库，由两个实例共同访问共享 ASM 中的数据文件。

因此 DSC 初始化前需要准备统一且相互匹配的：

DCR；
CSS；
ASM；
MAL；
DSC 实例配置；
初始化控制文件。

初始化时使用：

cd /data1/dm8_3_162_pack17/bin

./dminit CONTROL=/data/dsc162/CNDT_DSC0/dminit.ini

CONTROL= 指定 DSC 初始化控制文件。初始化控制文件中定义节点数量、实例名、端口、共享数据文件位置等。

数据库数据文件位于 ASM 中，例如：

+DMDATA/data/CNDT_DSC/system.dbf
+DMDATA/data/CNDT_DSC/roll.dbf
+DMDATA/data/CNDT_DSC/main.dbf

两个节点的配置目录分别为：

46：/data/dsc162/CNDT_DSC0
47：/data/dsc162/CNDT_DSC1

需要特别理解的是：dmserver 只是数据库实例进程。DSC 节点是否真正正常加入集群，并不能只看 dmserver 是否存在，还必须结合 DCR、CSS、ASM 和节点配置是否一致来判断。

46 节点典型 DCR 配置中涉及：

DMDCR_PATH=/dev/dm/asm-DCR
DMDCR_MAL_PATH=/data/dsc162/CNDT_DSC0/dmasvrmal.ini
DMDCR_SEQNO=0
DMDCR_ASM_RESTART_INTERVAL=30
DMDCR_ASM_STARTUP_CMD=/data1/dm8_3_162_pack17/bin/dmasmsvr
dcr_ini=/data/dsc162/CNDT_DSC0/dmdcr.ini
DMDCR_DB_RESTART_INTERVAL=60
DMDCR_DB_STARTUP_CMD=/data1/dm8_3_162_pack17/bin/dmserver /data/dsc162/CNDT_DSC0/dm.ini
dcr_ini=/data/dsc162/CNDT_DSC0/dmdcr.ini
DMDCR_AUTO_OPEN_CHECK=90

这也说明 DSC 服务启动并不是只读取 dm.ini，还依赖 dmdcr.ini 和 DCR 相关配置。

四、DSC 启动过程中 REMOTE 归档配置问题

第一次将 DSC0 启动到 MOUNT 时，出现：

Local instance is DSC cluster, need configure remote archive!

这个错误说明 DSC 两个节点除了本地归档，还需要配置 DSC 内部的 REMOTE 归档。

46 节点的归档结构最终采用：

ARCH_LOCAL_SHARE = 1

[ARCHIVE_LOCAL1]
ARCH_TYPE = LOCAL
ARCH_DEST = +DMARCH/LOCAL_ARCH_CNDT_DSC0
ARCH_FILE_SIZE = 512
ARCH_SPACE_LIMIT = 96000

[ARCHIVE_REMOTE1]
ARCH_TYPE = REMOTE
ARCH_DEST = CNDT_DSC1
ARCH_INCOMING_PATH = +DMARCH/LOCAL_ARCH_CNDT_DSC1
ARCH_FILE_SIZE = 512
ARCH_SPACE_LIMIT = 96000

[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME
ARCH_DEST = dsc_stdb

47 节点配置与 46 对称，其核心逻辑为：

本地归档目录：+DMARCH/LOCAL_ARCH_CNDT_DSC1
REMOTE 对端：CNDT_DSC0
REMOTE INCOMING：+DMARCH/LOCAL_ARCH_CNDT_DSC0
REALTIME 目标：dsc_stdb

三类归档的职责必须区分：

类型	作用
LOCAL	保存本节点产生的本地归档
REMOTE	保证 DSC 两节点之间能够共享和交换归档信息
REALTIME	将 DSC 主库 REDO 实时发送给 48 备库

REMOTE 配置补齐之后，DSC 才能够正常进入 MOUNT/OPEN。

五、将xx项目物理备份恢复到 DSC

5.1 备份位置与版本环境

国机项目原物理备份位于：

/data/guoji

备份集由多个 .bak 数据片和 .meta 文件组成，本质上属于同一个完整物理备份集。

服务器上存在多套 DM 版本，因此 DMAP 端口不能混用：

4.80 DMAP  → 4236
3.162 DMAP → 4237

如果 DMRMAN 错误连接到旧版本 DMAP，即使 DMAP 进程本身正常，也会发生版本通信不匹配。

5.2 恢复 DSC 数据库

本次成功恢复时显式指定 3.162 的 DMAP 端口和 DSC 的 DCR 配置：

./dmrman AP_PORT=4237 \
DCR_INI=/data/dsc162/CNDT_DSC1/dmdcr.ini \
CTLSTMT="RESTORE DATABASE '/data/dsc162/CNDT_DSC1/dm.ini' OVERWRITE FROM BACKUPSET '/data/guoji';"

参数含义：

AP_PORT=4237：连接 DM8 3.162 Pack17 对应的 DMAP；
DCR_INI=：告诉 DMRMAN 当前恢复对象是 DSC 数据库；
OVERWRITE：允许覆盖目标位置已经存在的数据库文件；
FROM BACKUPSET：指定恢复所使用的物理备份集。

恢复不能只做 RESTORE，后续必须继续进行：

RESTORE
→ RECOVER
→ RECOVER UPDATE DB_MAGIC

三个阶段作用不同：

RESTORE：从备份集中把数据文件还原到目标位置；
RECOVER：利用备份集中包含的日志，将还原出来的数据文件恢复到一致状态；
UPDATE DB_MAGIC：为恢复出来的数据库生成新的 DB_MAGIC，使其能够以新的数据库身份继续运行。

这一阶段让我明确认识到：“数据文件已经恢复出来”并不等于“数据库已经恢复完成”。

第二阶段：48 单机备库与 DSC + DW 配置

六、48 备库真实实例路径确认

48 最终实际使用的数据库目录为：

/data2/dsc162/rst/data/dsc

目录中包含：

dm.ini
dmmal.ini
dmarch.ini
dmwatcher.ini
system.dbf
roll.dbf
main*.dbf
各业务表空间 DBF
arch/
trace/

48 上曾经存在其他旧路径，因此排障时不能单纯根据“哪个目录看起来像数据库目录”进行判断，而应该以正在运行的 dmserver 实际命令行所使用的 dm.ini 为准。

这一点在后续故障修复中也再次得到验证：程序目录、数据库目录和动态库路径都必须根据实际运行对象确认，不能仅凭目录名称判断。

七、48 MAL 配置及端口含义

48 的 dmmal.ini 中需要同时包含 46、47、48 三个实例。

核心配置结构为：

MAL_CHECK_INTERVAL = 5
MAL_CONN_FAIL_INTERVAL = 5

[MAL_INST0]
MAL_INST_NAME = CNDT_DSC0
MAL_HOST = 192.168.100.46
MAL_PORT = 5246
MAL_INST_HOST = 172.20.6.46
MAL_INST_PORT = 5236
MAL_DW_PORT = 52141
MAL_INST_DW_PORT = 33141

[MAL_INST1]
MAL_INST_NAME = CNDT_DSC1
MAL_HOST = 192.168.100.47
MAL_PORT = 5246
MAL_INST_HOST = 172.20.6.47
MAL_INST_PORT = 5236
MAL_DW_PORT = 52141
MAL_INST_DW_PORT = 33141

[MAL_INST2]
MAL_INST_NAME = dsc_stdb
MAL_HOST = 192.168.100.48
MAL_PORT = 5246
MAL_INST_HOST = 172.20.6.48
MAL_INST_PORT = 5436
MAL_DW_PORT = 52141
MAL_INST_DW_PORT = 33141

端口作用需要明确区分：

参数	作用
MAL_PORT	MAL 通信端口
MAL_INST_PORT	数据库实例业务端口
MAL_DW_PORT	watcher/monitor 守护通信端口
MAL_INST_DW_PORT	实例与守护相关的内部通信端口

其中：

MAL_HOST

使用的是：

192.168.100.x

业务连接使用的是：

172.20.6.x

这样能够把数据库业务流量与内部同步流量分开。

八、48 归档、Watcher 与 Monitor

8.1 48 归档配置

48 的本地归档与实时归档结构为：

[ARCHIVE_LOCAL1]
ARCH_TYPE = LOCAL
ARCH_DEST = /data2/dsc162/rst/data/dsc/arch
ARCH_FILE_SIZE = 1024
ARCH_SPACE_LIMIT = 0

[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME
ARCH_DEST = CNDT_DSC0/CNDT_DSC1

这里：

ARCH_DEST = CNDT_DSC0/CNDT_DSC1

代表 48 的实时归档源对应整个 DSC 数据库，而不是单独依赖某一个 DSC 节点。

8.2 Watcher 配置

48 的 dmwatcher.ini 中主要参数包括：

[GRP1]
DW_TYPE = GLOBAL
DW_MODE = AUTO
DW_ERROR_TIME = 10
INST_RECOVER_TIME = 60
INST_ERROR_TIME = 10
INST_OGUID = 260914
INST_INI = /data2/dsc162/rst/data/dsc/dm.ini
INST_AUTO_RESTART = 1
INST_STARTUP_CMD = /data1/dm8_3_162_pack17/bin/dmserver
RLOG_SEND_THRESHOLD = 0
RLOG_APPLY_THRESHOLD = 0

关键含义：

INST_OGUID 必须和主库数据守护 OGUID 一致；
INST_INI 必须指向真实使用的备库 dm.ini；
INST_AUTO_RESTART=1 允许 watcher 管理实例；
DW_MODE=AUTO 表示自动守护模式。

8.3 Monitor 配置中的 DSC 特性

46、47 虽然是两个实例，但从数据库角度看属于同一个 DSC 数据库。

因此 monitor 中 46、47 不能被写成两个独立数据库，必须使用 / 合并到同一条 MON_DW_IP：

MON_DW_CONFIRM = 0
MON_LOG_PATH = /data/dsc162/CNDT_DSC0/monitor_log
MON_LOG_INTERVAL = 60
MON_LOG_FILE_SIZE = 32
MON_LOG_SPACE_LIMIT = 0

[GRP1]
MON_INST_OGUID = 260914
MON_DW_IP = 192.168.100.46:52141/192.168.100.47:52141
MON_DW_IP = 192.168.100.48:52141

曾经把 46、47 分别配置成两个 MON_DW_IP，monitor 会提示同一个数据库存在多个 MON_DW_IP，需要通过 / 合并。

这件事让我进一步理解了：

DSC0 + DSC1 = 一个共享数据库的两个实例
48          = 另一套独立数据库

第三阶段：GROUP SPLIT 与 SYSOPENHISTORY 分叉排障

九、故障现象

当基础配置基本完成之后，出现了本周最关键的一次故障：

GROUP SPLIT
WCTLSTAT = SPLIT
WSTATUS = STARTUP
RSTAT = INVALID

最初容易怀疑的问题包括：

OGUID 不一致；
watcher 没启动；
REALTIME 配置错误；
主备之间只差部分 LSN；
monitor 配置问题。

但继续检查后发现，真正的问题并不是简单的日志落后，而是：

SYSOPENHISTORY 已经发生分叉

十、通过 Open History 定位真正原因

使用 monitor 查询：

show open info GRP1.CNDT_DSC0
show open info GRP1.DSC_STDB

主库与备库在第 48 条历史之前是一致的。

公共历史：

CNDT_DSC1_48
2026-07-21 17:58:31

之后开始分叉。

主库侧：

CNDT_DSC0_49
2026-09-14 10:50
N_EP = 2
DB_MAGIC = 1607585400

CNDT_DSC0_50
PRIMARY

48 侧：

DSC_STDB_49
2026-09-13 13:36
NORMAL
N_EP = 1
DB_MAGIC = 1354340550

DSC_STDB_50
NORMAL

可以把这个分叉理解为：

公共历史
│
└── 第 48 条
    ├── 46/47 继续作为 DSC 数据库运行
    │   └── CNDT_DSC0_49 → CNDT_DSC0_50
    │
    └── 48 曾独立以 NORMAL 数据库 OPEN
        └── DSC_STDB_49 → DSC_STDB_50

也就是说，48 在正式成为 STANDBY 之前曾经独立 OPEN，并形成了自己的数据库打开历史。

因此这不是“备库日志比主库慢一点”这么简单，而是主备数据库已经形成了两条不同的身份历史。

十一、为什么 OPEN FORCE 无法真正修复

48 曾经执行：

ALTER DATABASE OPEN FORCE;

执行后数据库表面可以显示：

OPEN STANDBY

但是 monitor 仍然显示：

WCTLSTAT = SPLIT
RSTAT = INVALID

原因是：

OPEN FORCE 只能强制改变当前数据库的打开状态，不能修改已经形成的历史分叉。

因此判断数据守护是否正常，不能只看：

ISTATUS = OPEN
IMODE   = STANDBY

还必须同时确认：

WCTLSTAT = VALID
WSTATUS  = OPEN
RSTAT    = VALID

以及主备 LSN 是否真正一致。

这也是本周非常重要的认识：

数据库“OPEN”只是实例状态，不等于数据守护关系健康。

十二、最终策略：保留健康 DSC，只重同步 48

当时 46、47 主库已经表现为：

CNDT_DSC0 OPEN PRIMARY VALID
CNDT_DSC1 OPEN PRIMARY VALID

说明 DSC 主库本身没有必要重新初始化。

如果这时为了处理 48 而重新搭建整个 DSC，不但工作量大，还会增加对共享数据的风险。

所以最终采用的策略是：

保留 46/47 当前 PRIMARY
        ↓
从当前 DSC PRIMARY 重新做最新全备
        ↓
只覆盖恢复 48
        ↓
让 48 的数据、日志和 OPEN HISTORY
重新从当前主库建立

这是处理历史分叉的关键：不是修改旧历史，而是重新以健康主库作为基准创建新的备库。

第四阶段：48 重同步恢复

十三、从当前 DSC 主库重新做全备

在 47 上重新执行全备：

BACKUP DATABASE FULL BACKUPSET '/data/guoji_stdb_rebuild_260914';

第一次出现：

[-7169]: bakres与DMAP消息通信失败

继续排查发现：

4.80 DMAP  → 4236
3.162 DMAP → 4237

而当前数据库配置中还存在：

EXTERNAL_AP_PORT = 4236
BAK_USE_AP = 1

所以真正的问题不是“DMAP 没启动”，而是：

3.162 数据库连接到了 4.80 的 DMAP

调整为正确的 3.162 DMAP 后，完成全备。

备份目录：

/data/guoji_stdb_rebuild_260914

备份集一共包含 14 个 piece，最后一个为 LOG piece，说明联机全备中包含了完成一致性恢复需要的日志。

十四、48 使用 USE_AP=2 脱离 DMAP 恢复

为了避免 48 上再次受到多版本 DMAP 干扰，恢复时采用：

./dmrman USE_AP=2

即 DMRMAN 无辅助进程模式。

先验证备份集：

RMAN>
CHECK BACKUPSET '/data/guoji_stdb_rebuild_260914';

check backupset successfully

说明备份集可以被当前 DMRMAN 正常识别。

执行覆盖恢复：

./dmrman USE_AP=2 \
CTLSTMT="RESTORE DATABASE '/data2/dsc162/rst/data/dsc/dm.ini' OVERWRITE FROM BACKUPSET '/data/guoji_stdb_rebuild_260914';"

最终返回：

restore successfully.

这里有一个非常容易踩坑的点：

正确写法：

./dmrman USE_AP=2 CTLSTMT="RESTORE DATABASE ...;"

错误写法：

RESTORE DATABASE ... FROM BACKUPSET ... USE_AP=2

USE_AP=2 是 dmrman 启动参数，不属于 RESTORE SQL 语法。

十五、RECOVER 阶段的 -8363

RESTORE 完成后执行 RECOVER 时出现：

[-8363]: 从备份集生成临时日志文件失败

最终确认备份集本身并没有损坏，而是 DMRMAN 在 RECOVER 时需要在备份集目录中生成临时日志文件，但当时目录对 dmdba 不具备足够写权限。

排查：

ls -ld /data/guoji_stdb_rebuild_260914
touch /data/guoji_stdb_rebuild_260914/.rman_write_test

修正目录权限后重新执行：

./dmrman USE_AP=2 \
CTLSTMT="RECOVER DATABASE '/data2/dsc162/rst/data/dsc/dm.ini' FROM BACKUPSET '/data/guoji_stdb_rebuild_260914';"

recover successfully!

随后：

./dmrman USE_AP=2 \
CTLSTMT="RECOVER DATABASE '/data2/dsc162/rst/data/dsc/dm.ini' UPDATE DB_MAGIC;"

同样成功。

本次 Pack17 环境中，尝试：

RECOVER DATABASE ... FOR STANDBY ...

会在 FOR 处报：

[-2007]

因此当前环境实际采用的恢复流程为：

RESTORE
→ RECOVER FROM BACKUPSET
→ RECOVER UPDATE DB_MAGIC
→ MOUNT
→ 设置 OGUID
→ 设置 STANDBY

这也说明在生产排障时，不能机械照搬其他版本的语法，必须以当前二进制版本实际支持的语法为准。

十六、重新设置 48 为 STANDBY

恢复完成后，48 必须先以 MOUNT 启动。

不能直接 OPEN，更不能再次 OPEN FORCE。

设置过程：

SP_SET_PARA_VALUE(1,'ALTER_MODE_STATUS',1);
SP_SET_OGUID(260914);
ALTER DATABASE STANDBY;
SP_SET_PARA_VALUE(1,'ALTER_MODE_STATUS',0);

正确状态：

DSC_STDB MOUNT STANDBY 260914

确认数据库仍然处于 MOUNT、角色为 STANDBY、OGUID 正确以后，再启动 watcher：

nohup /data1/dm8_3_162_pack17/bin/dmwatcher \
/data2/dsc162/rst/data/dsc/dmwatcher.ini \
>/data2/dsc162/rst/data/dsc/dmwatcher.log 2>&1 &

之后由 watcher 自动接管数据库状态，不再人工强制 OPEN。

在 46 上进入 monitor：

./dmmonitor /data/dsc162/CNDT_DSC0/dmmonitor.ini

执行：

show

最终确认：

GRP1
OGUID = 260914
MODE = AUTO

以及：

WCTLSTAT = VALID
WSTATUS  = OPEN

三端最终达到：

CNDT_DSC0 OPEN PRIMARY REALTIME VALID
CNDT_DSC1 OPEN PRIMARY REALTIME VALID
DSC_STDB  OPEN STANDBY REALTIME VALID

并且：

FLSN = CLSN

GROUP SPLIT、STARTUP、INVALID 等异常状态消失。

第五阶段：从“搭建成功”进入“真实故障恢复”

前面的工作解决了 DSC + DW 的搭建、xx项目备份恢复以及备库历史分叉问题，已经形成一套可以正常运行的主备架构。

但随后发生的故障修复把前面建立的这些认识真正应用到了实际恢复中：47 节点操作系统被重装，46 节点程序目录出现了异构架构文件污染风险，48 备库启动失败，并且服务器上多套 DM 版本又带来了程序文件和动态库路径互相干扰的问题。

这时已经不能再按照“重新搭建一次”的思路处理，而必须转变为：

尽量保留现有数据
→ 判断哪一层损坏
→ 只修复损坏层
→ 逐层恢复
→ 最后恢复主备关系

也正因为前一阶段已经明确了 DSC、DW、MAL、归档、OGUID、Open History 和 watcher 之间的关系，所以后续修复才能避免再次使用 OPEN FORCE 或重新初始化共享 ASM 等高风险操作。

第六阶段：47 节点操作系统重装后的 DSC 恢复

十七、故障背景

本次故障不是单一问题，而是连续出现了多个风险点。

17.1 47 节点系统被破坏

47 节点曾发生严重误删除，系统目录被破坏，随后进行了操作系统重装。

幸运的是：

/data
/data1
/data2
/data3

等数据盘仍然保留，共享 ASM 设备也没有被破坏，因此 47 仍然具备原地恢复 DSC 节点的条件。

这里最重要的原则是：

操作系统重装不等于数据库必须重建。

只要共享 SAN 数据、DCR、VOTE、ASM 元数据没有被破坏，就应该优先恢复操作系统环境、用户权限、设备映射、DM 程序和节点配置，而不是重新初始化共享存储。

17.2 46 节点程序目录存在架构污染风险

恢复过程中，46 节点曾经发生过把一套 x86 程序文件覆盖进当前 ARM 环境 DM bin 目录的危险操作。

因此 46 不能直接被认为是“肯定健康的软件源”，而必须先做完整架构、版本和文件校验。

17.3 48 备库启动失败

最初执行：

./DmServicedsc_stdb start mount

[ FAILED ]

手工以等价方式启动：

nohup ./dmserver \
path=/data2/dsc162/rst/data/dsc/dm.ini \
-noconsole mount \
>/tmp/dsc_stdb_mount_start.log 2>&1 &

进程立即退出：

Linux 返回码 126 通常意味着：

文件存在，但无法执行

因此排障方向不应该首先放在 dm.ini、OGUID、归档或数据文件上，而应该先检查当前 dmserver 本身是否能够在这台机器上执行。

十八、故障修复总体思路

这次没有重新搭建整个集群，而是采用分层恢复：

先确认共享存储没有损坏
        ↓
确认 DM 程序版本与 CPU 架构正确
        ↓
恢复 CSS / ASM / DSC 基础集群
        ↓
确认 46、47 DSC 主库状态正常
        ↓
48 仅以 MOUNT 方式启动
        ↓
确认 STANDBY + OGUID
        ↓
启动 DMWatcher
        ↓
由数据守护自动完成 OPEN 与日志同步
        ↓
dmmonitor + dmcssm 双重验证

这套流程与前面处理 GROUP SPLIT 时形成的认识完全一致：

MOUNT
→ 确认 STANDBY
→ 确认 OGUID
→ watcher 接管

不能再让 48 独立 NORMAL OPEN，也不能使用 OPEN FORCE。

十九、恢复 47 的操作系统基础环境

47 操作系统重装后，首先恢复：

网络；
dmdba 用户；
dinstall 组；
UID/GID；
udev 设备映射；
DM 软件；
节点配置文件。

47 必须重新具备：

业务地址：172.20.6.47
MAL 地址：192.168.100.47

恢复 MAL 网络以后，需要确认 47 与 46、48 的内部通信地址能够正常互通。

同时 dmdba 用户和 dinstall 组的 UID/GID 需要与原环境保持一致，否则即使文件还在，也可能因为所有者编号改变而导致数据目录或设备权限异常。

随后恢复 udev 规则，使以下设备重新出现：

/dev/dm/asm-DCR
/dev/dm/asm-VOTE
/dev/dm/asm-REDO
/dev/dm/asm-ARCH
/dev/dm/asm-DATA1
/dev/dm/asm-DATA2
/dev/dm/asm-DATA3

恢复过程中明确不执行：

dminit
mkfs
fdisk
parted
pvcreate

等可能修改或破坏原共享盘元数据的命令。

二十、重建 47 的 DM 程序与节点配置

47 重装系统以后，需要重新准备：

dmdcr.ini
dmdcr_cfg.ini
dmasvrmal.ini
dmcssm.ini
dm.ini
dmmal.ini
dmarch.ini
dmwatcher.ini

47 的 DSC 序号保持：

DSC_SEQNO = 1

对应实例：

CNDT_DSC1

因为 46 与 47 属于同一 DSC，所以 DCR、ASM 和集群级参数必须一致，但以下内容必须使用 47 自己的值：

节点序号；
节点 IP；
实例名；
对应节点路径。

配置恢复完成后，按照顺序：

CSS
→ ASM
→ DSC

使 47 重新加入 46 所在的同一个 DSC 集群。

第七阶段：46 节点程序架构污染检查

二十一、确认 46 是否还能作为可信软件源

由于 46 曾经误覆盖过包含 x86 文件的程序目录，因此先检查核心程序架构：

file bin/disql bin/dmserver bin/dmwatcher bin/dmcss bin/dmasmsvr

正确结果应为：

ELF 64-bit ... ARM aarch64

随后对整个 bin 目录扫描：

find bin -type f -print0 \
| xargs -0 file \
| grep -Ei 'x86-64|Intel 80386' \
| head -50

最终没有任何输出，说明当前 bin 中没有发现 x86 程序残留。

然后进一步通过 SHA256 固定校验核心文件：

disql
7255be022bcfe3ab0c745da3811ba87f67b18049fb4fc5e07353fa393e0aba60

dmserver
c5b9da748ac7d02fbf1731bc90fdbea7c476cb98b6f8f263d4da27f47b629928

dmwatcher
80975330b938f0ce5a14c99c2d66d00ba535abbd09fc04958cdaa4167372b4b8

dmcss
9a55f99ab47f554d50dc1c92ab0afc2128f2217a2d528992744e49855a84bbcc

dmasmsvr
ae5c56857e7188cb7320ad4160064733c1fa3540b6b0f5f7bf98c0e9eed45cc9

版本确认：

DM Database 64 V8
03134284194-20240920-243476-20108

最终确认 46 的程序目录可以作为后续修复 48 的可信 Pack17 程序源。

第八阶段：48 启动失败与程序环境恢复

二十二、先区分“数据库启动失败”还是“程序无法执行”

46、47 恢复后曾处于：

CNDT_DSC0 MOUNT PRIMARY
CNDT_DSC1 MOUNT PRIMARY
REALTIME VALID
FLSN = CLSN

此时 DSC 层基础状态已经基本恢复。

48 仍然启动失败：

./DmServicedsc_stdb start mount

[ FAILED ]

手工执行：

nohup ./dmserver \
path=/data2/dsc162/rst/data/dsc/dm.ini \
-noconsole mount \
>/tmp/dsc_stdb_mount_start.log 2>&1 &

Shell 返回：

随后执行：

./disql -id

出现：

无法执行二进制文件: 可执行文件格式错误

到这里已经可以判断，问题还没有进入数据库参数和数据文件层面，而是在操作系统执行二进制文件阶段就失败了。

因此真实问题是：

48 当前 bin 中存在与 ARM aarch64 不匹配的程序

而不是：

dm.ini 配置错误；
OGUID 错误；
REALTIME 配置错误；
数据库文件损坏。

这一步对于排障思路非常重要：先根据错误发生在哪一层决定检查方向。

二十三、检查 48 上已有程序目录

48 当时存在：

bin
bin_bak_3_162
bin2

检查备份目录：

file bin_bak_3_162/disql
file bin_bak_3_162/dmserver

架构显示：

ARM aarch64

但版本检查得到：

DM Database 64 V8
03134284604-20260915-349400-20228

而本次需要的健康基线是：

03134284194-20240920-243476-20108

因此即使 CPU 架构正确，版本仍然不属于本次目标环境，不能直接使用。

bin2 中又只有：

SYSWORD.UTF8.LIB

没有 disql、dmserver 等核心程序，也无法作为恢复源。

最终决定从已经完成校验的 46 节点复制正确 Pack17 程序。

二十四、从 46 向 48 安全复制 Pack17 程序

为了保留回退能力，没有直接覆盖 48 原 bin，而是先创建临时目录：

/data1/dm8_3_162_pack17/bin_pack17_clean_20260917

同时先备份 48 自己的服务脚本：

DmServicedsc_stdb
DmWatcherServiceDW01

这样做的原因是：

46 是 DSC 主库节点，48 是单机备库。

即使核心 DM 可执行程序相同，两端的服务脚本用途也不同。如果直接把 46 整个 bin 原样覆盖到 48，有可能同时覆盖掉 48 专用服务脚本。

最初尝试：

scp -rp root@172.20.6.46:/data1/dm8_3_162_pack17/bin/. ...

出现：

error: unexpected filename: .

因此改用 tar + ssh：

ssh root@172.20.6.46 \
"tar -C /data1/dm8_3_162_pack17/bin -cf - ." \
| tar -C /data1/dm8_3_162_pack17/bin_pack17_clean_20260917 -xf -

这种方式能够：

完整复制目录；
保留权限；
保留隐藏文件；
不修改 46 源目录。

复制后恢复目录所有者：

dmdba:dinstall

并再次核对 SHA256 与 x86 扫描结果，确认传输过程中程序没有发生变化。

第九阶段：动态库串用问题

二十五、为什么文件 SHA256 一样，版本号却不一样

在 48 上直接执行临时目录中的：

bin_pack17_clean_20260917/disql -id

一度显示：

03134284604-20260915-349400-20228

但是该 disql 文件本身的 SHA256 又与 46 完全一致。

这两个结果明显矛盾：

文件完全相同
但运行出来的版本号不同

于是进一步使用：

ldd bin_pack17_clean_20260917/disql

发现实际加载的是：

libdisql_dll.so => /data/dm8/bin/libdisql_dll.so
libdmdpi.so     => /data/dm8/bin/libdmdpi.so

也就是说，48 上还存在另一套 DM 环境：

/data/dm8

当前 Shell 的动态库环境导致新复制过来的 Pack17 disql 加载了另一套 DM 的 .so。

通过强制指定当前 Pack17 的动态库路径：

LD_LIBRARY_PATH=/data1/dm8_3_162_pack17/bin_pack17_clean_20260917 \
./bin_pack17_clean_20260917/disql -id

版本立即恢复为：

03134284194-20240920-243476-20108

由此确认：

可执行程序本体是正确的
异常来自共享库加载路径

这一问题让我建立了一个很重要的检查原则：

当服务器上存在多套 DM 软件时，至少要同时检查：

file
disql -id
sha256sum
ldd
uname -m

不能只看目录名，也不能只看某一个可执行文件的 SHA256。

二十六、安全切换 48 正式 bin

确认临时目录完全正确后：

删除临时目录中来自 46 的 Dm*Service* 脚本；
把之前备份的 48 专用服务脚本放回；
将 48 原 bin 改名保留，作为回退；
再把新目录切换为正式 bin。

最终保留的 48 专用服务脚本包括：

DmServicedsc_stdb
DmWatcherServiceDW01

切换后验证：

cd /data1/dm8_3_162_pack17/bin
./disql -id

得到：

DM Database 64 V8
03134284194-20240920-243476-20108

检查动态库：

ldd ./dmserver | grep -i 'not found'

没有缺失动态库。

检查：

dmserver
disql
dmwatcher

均为：

ARM aarch64

至此 48 的程序环境恢复完成。

第十阶段：48 按正确顺序重新加入数据守护

二十七、48 只以 MOUNT 方式启动

程序恢复后执行：

./DmServicedsc_stdb start mount

虽然服务脚本内存在：

START_MODE=open

但脚本支持 start mount，该参数会使 dmserver 以 MOUNT 状态启动。

数据库启动后连接：

./disql

查询：

select instance_name,status$,mode$,oguid
from v$instance;

结果：

DSC_STDB  MOUNT  STANDBY  260914

这四个字段同时正确，说明：

当前启动的是 48 正确实例；
数据库没有被人工 OPEN；
数据库角色仍然是 STANDBY；
OGUID 与 46、47 数据守护组一致。

只有确认这些状态以后，才启动：

./DmWatcherServiceDW01 start

Watcher 启动成功以后，不再人工 OPEN，而是交给数据守护机制处理数据库状态转换。

这与前一阶段处理 GROUP SPLIT 时形成的安全顺序完全一致：

程序环境正确
→ 配置正确
→ MOUNT
→ STANDBY
→ OGUID 正确
→ watcher
→ 自动 OPEN

第十一阶段：最终验证

二十八、通过 dmmonitor 验证数据守护

48 watcher 启动以后，通过 monitor 最终看到：

实例	状态	模式	实时归档	RSTAT	FLSN	CLSN
CNDT_DSC0	OPEN	PRIMARY	REALTIME	VALID	105235054252	105235054252
CNDT_DSC1	OPEN	PRIMARY	REALTIME	VALID	105235054252	105235054252
DSC_STDB	OPEN	STANDBY	REALTIME	VALID	105235054252	105235054252

数据守护状态：

WCTLSTAT = VALID
WSTATUS  = OPEN
INST_OK  = OK

48 的日志状态：

RLSN = SLSN = KLSN = 105235054252
N_TSK = 0

说明 48 不存在日志积压，已经完全追平 46、47。

二十九、通过 dmcssm 验证底层 DSC/CSS/ASM

随后执行：

./dmcssm /data/dsc162/CNDT_DSC0/dmcssm.ini

最终 ASM 状态：

GRP_ASM:
sta = OPEN
crash process over flag is TRUE

ASM0 OPEN WORKING OK
ASM1 OPEN WORKING OK

DSC 状态：

GRP_DSC:
sta = OPEN
break ep = NULL
recover ep = NULL
crash process over flag is TRUE

CNDT_DSC0 OPEN WORKING OK
CNDT_DSC1 OPEN WORKING OK

其中：

crash process over flag is TRUE

是非常关键的恢复完成标志。

此前该值曾为：

FALSE

说明故障恢复流程还没有完全结束；最终恢复为 TRUE，说明 DSC 故障处理已经真正完成。

第十二阶段：本周问题、原因与处理汇总

三十、故障对照表

现象	实际原因	最终处理
`bakres与DMAP消息通信失败`	3.162 数据库连接到了 4.80 的 4236 DMAP	改用 3.162 对应的 4237
DMRMAN 提示服务器正在运行或存在其他进程操作同一库	48 的 dmserver / watcher 未彻底停止	停止目标实例与 watcher 后再执行 DMRMAN
`USE_AP=2` 语法错误	把 `USE_AP=2` 写到了 RESTORE 语句尾部	将其作为 `dmrman` 启动参数
`FOR STANDBY` 在 FOR 处报语法错误	当前 3.162 Pack17 不支持该写法	使用普通 RECOVER，再设置 STANDBY
`[-8363] 从备份集生成临时日志文件失败`	RECOVER 需要在备份目录生成临时日志，但 dmdba 没有写权限	给备份目录写权限后重新 RECOVER
`GROUP SPLIT`	48 曾以 NORMAL 独立 OPEN，Open History 与 DSC 分叉	从当前 PRIMARY 做新全备，只重同步 48
monitor 提示一个数据库有多个 `MON_DW_IP`	把 DSC0、DSC1 当成了两个独立数据库	46/47 用 `/` 写在同一条 `MON_DW_IP`
48 已 `OPEN STANDBY` 但 `RSTAT INVALID`	只改变了数据库状态，历史分叉没有消除	重新恢复 48，让 watcher 正常接管
48 启动返回 126	当前 bin 中存在无法在 ARM 执行的程序	先修复程序架构和版本，不盲目修改数据库参数
`disql` 文件 SHA256 正确但版本输出异常	程序加载了 `/data/dm8/bin` 中另一套共享库	用 `ldd` 定位，并修正 `LD_LIBRARY_PATH`
47 操作系统重装	系统层损坏，但共享 ASM 数据仍在	恢复网络、用户、udev、程序和配置，不重新初始化共享盘
46 曾发生 x86 程序覆盖 ARM bin	程序目录存在异构架构污染风险	`file`、全目录扫描、SHA256、版本号联合确认

【插图位置 9】
可以在此插入第一篇报告第 15 页的“现象—实际原因—最终处理”表格截图，作为本周踩坑总结图。

第十三阶段：本周形成的系统性认识

三十一、DSC 与数据守护必须分层理解

46、47 是：

一个共享数据库
两个数据库实例
共享同一套 ASM 数据

48 是：

另一套独立数据库
通过 REDO 实时同步
作为 STANDBY

所以需要把几个层次分开：

CSS / DCR
    ↓
ASM
    ↓
DSC 数据库实例
    ↓
MAL / ARCH
    ↓
DMWatcher / DMMonitor
    ↓
PRIMARY / STANDBY 数据守护关系

底层没有恢复正常，不应该直接处理上层。

三十二、数据库 OPEN 不等于数据守护健康

真正健康至少应该同时满足：

实例状态正确
数据库角色正确
OGUID 正确
watcher 正常
WCTLSTAT = VALID
WSTATUS  = OPEN
RSTAT    = VALID
REALTIME 正常
FLSN/CLSN 一致

仅仅看到：

OPEN STANDBY

不能作为恢复完成依据。

三十三、SYSOPENHISTORY 是判断主备历史分叉的重要依据

如果只是备库日志落后，可以继续接收并应用日志。

但如果主、备分别形成了各自独立 Open History，说明两边已经不再属于同一条数据库历史链。

此时不能通过：

修改 OGUID
删除状态文件
OPEN FORCE

来根本修复。

更可靠的方式是：

保留健康 PRIMARY
→ 从当前 PRIMARY 做新备份
→ 重建 STANDBY
→ 重新建立日志与 Open History

三十四、多版本 DM 并存时必须同时检查“程序”和“动态库”

仅检查：

disql -id

不够。

仅检查：

sha256sum

也不够。

建议至少形成以下组合：

检查项	用途
`uname -m`	判断操作系统 CPU 架构
`file`	判断 DM 程序本身的 ELF 架构
`disql -id`	判断实际运行时显示的 DM Build
`sha256sum`	判断核心文件是否与健康基线完全一致
`ldd`	判断程序运行时究竟加载了哪一套 `.so`
全目录架构扫描	判断 bin 内是否混入其他 CPU 架构文件

本次 48 的问题就是：

可执行文件是正确 Pack17
但共享库来自 /data/dm8/bin

因此才会出现“文件一样，但运行版本不一样”的现象。

三十五、共享 ASM 环境恢复的原则

47 的恢复证明：

只要共享 ASM 数据没有被破坏，即使节点操作系统重装，也可以重新恢复为原 DSC 节点。

正确思路：

恢复设备映射
→ 恢复用户权限
→ 恢复 DCR 配置
→ 恢复 CSS/ASM 配置
→ 恢复节点 DM 配置
→ 让节点重新加入原 DSC

而不是：

重新 dminit
重新格式化 ASM
重新创建 DCR/VOTE

三十六、单机备库恢复的安全顺序

本周两次不同场景都证明，48 最安全的恢复顺序是：

确认程序环境正确
        ↓
确认真实 dm.ini
        ↓
确认 MAL / ARCH 配置
        ↓
MOUNT 启动
        ↓
查询确认 STANDBY
        ↓
查询确认 OGUID
        ↓
启动 watcher
        ↓
由 watcher 自动 OPEN
        ↓
dmmonitor 验证
        ↓
核对 LSN

不能使用：

OPEN FORCE

也不能把备库独立启动为：

NORMAL

否则很容易再次造成数据守护历史分叉。

第十四阶段：最终健康基线

三十七、软件基线

DM Database 64 V8
03134284194-20240920-243476-20108
ARM aarch64

46、47、48 最终都恢复到同一套正确 ARM Pack17 软件基线。

三十八、DSC 主库状态

CNDT_DSC0 OPEN PRIMARY
CNDT_DSC1 OPEN PRIMARY
REALTIME VALID

CSS / ASM / DSC：

CSS0 OPEN WORKING OK
CSS1 OPEN WORKING OK

ASM0 OPEN WORKING OK
ASM1 OPEN WORKING OK

CNDT_DSC0 OPEN WORKING OK
CNDT_DSC1 OPEN WORKING OK

并且：

GRP_ASM crash process over flag = TRUE
GRP_DSC crash process over flag = TRUE

三十九、48 单机备库状态

DSC_STDB OPEN STANDBY
REALTIME VALID
OGUID = 260914

Watcher：

DmWatcherServiceDW01 = running

对应进程：

/data1/dm8_3_162_pack17/bin/dmwatcher \
path=/data2/dsc162/rst/data/dsc/dmwatcher.ini \
-noconsole

四十、数据守护状态

WCTLSTAT = VALID
WSTATUS  = OPEN
INST_OK  = OK

日志同步最终基线：

CNDT_DSC0 FLSN = CLSN = 105235054252
CNDT_DSC1 FLSN = CLSN = 105235054252
DSC_STDB  FLSN = CLSN = 105235054252

这意味着：

主库产生日志
    ↓
DSC 两节点内部一致
    ↓
REALTIME 发送到 48
    ↓
48 正常接收
    ↓
48 正常应用
    ↓
主备 LSN 完全追平

第十五阶段：业务级同步验证建议

除了 dmmonitor、dmcssm 和 LSN 验证之外，还可以继续完成一次业务级同步验证。

在 46/47 主库执行：

create table SYSDBA.DW_TEST_260914
(
    ID int,
    INFO varchar(100)
);

insert into SYSDBA.DW_TEST_260914
values(1,'DSC_DW_TEST_OK');

commit;

随后在 48 查询：

select * from SYSDBA.DW_TEST_260914;

如果返回：

1 DSC_DW_TEST_OK

并且三端 LSN 仍然保持一致，就形成了：

配置正常
+
实时日志同步正常
+
业务数据同步正常

的完整验证闭环。

十六、本周最终总结

本周从 DSC + DW 的搭建开始，先完成了 46、47 双节点 DSC 与 48 单机备库的整体架构，并将国机项目物理备份恢复到 DSC 中。

搭建过程中解决了 DSC REMOTE 归档、DMAP 版本端口、物理恢复、MAL、REALTIME、watcher、monitor 等一系列配置问题。

随后面对 GROUP SPLIT 时，通过 SYSOPENHISTORY 确认 48 曾独立以 NORMAL 数据库 OPEN，主备数据库历史已经发生真正分叉。由此认识到 OPEN STANDBY 并不代表数据守护健康，OPEN FORCE 也不能修复 Open History。最终通过保留健康 DSC PRIMARY、重新全备、只重同步 48，完成了历史重建。

在后续真实故障修复中，又进一步遇到 47 操作系统重装、46 程序目录异构架构污染风险、48 启动返回 126、程序 Build 不一致、动态库串用等问题。整个修复过程始终坚持分层判断，不在底层程序和系统环境还未确认正常时盲目修改数据库参数。

最终 47 在不破坏共享 ASM 元数据的前提下重新加入 DSC，46、47、48 三台服务器恢复到同一套 ARM Pack17 软件基线，48 通过 MOUNT、STANDBY、OGUID、watcher 的正确顺序重新加入数据守护。

最终状态达到：

CNDT_DSC0 OPEN PRIMARY REALTIME VALID
CNDT_DSC1 OPEN PRIMARY REALTIME VALID
DSC_STDB  OPEN STANDBY REALTIME VALID

并且：

WCTLSTAT = VALID
WSTATUS  = OPEN
INST_OK  = OK
FLSN     = CLSN
crash process over flag = TRUE

说明本周从“搭建”到“故障修复”的完整闭环已经形成。

最终可以沉淀出一条可复用的处理流程：

确认软件版本和真实实例路径
        ↓
确认共享存储与设备映射
        ↓
恢复 CSS / ASM / DSC
        ↓
配置 LOCAL / REMOTE / REALTIME
        ↓
恢复业务物理备份
        ↓
确认 PRIMARY / OGUID
        ↓
配置 STANDBY 的 MAL / ARCH / WATCHER / MONITOR
        ↓
MOUNT → STANDBY → watcher
        ↓
dmmonitor / dmcssm 验证
        ↓
如果出现 SPLIT
先查 SYSOPENHISTORY
        ↓
若 Open History 已经分叉
保留健康 PRIMARY，只重同步 STANDBY
        ↓
RESTORE → RECOVER → UPDATE DB_MAGIC
        ↓
重新 MOUNT → OGUID → STANDBY → watcher
        ↓
WCTLSTAT VALID + RSTAT VALID + LSN 一致

对于以后再次遇到：

DSC 正常但备库无法加入
OPEN 了但守护仍然 INVALID
OGUID 一致但 GROUP SPLIT
程序文件看起来一样但运行版本不同
节点操作系统重装但共享存储还在

这类问题时，已经可以按照以下五个层次逐步判断：

1. 操作系统与程序环境
2. CSS / ASM / DSC 基础集群
3. 数据库实例角色与 OGUID
4. watcher / monitor / Open History
5. REALTIME 日志链路与 LSN

而不是重复初始化、盲目修改参数或反复强制 OPEN。

如果后续进行版本升级，例如：

3.162 → 4.80 → 4.200 → 5.60

应该以本报告记录的当前健康状态作为升级前基线，并提前保留：

当前配置文件
服务脚本
程序 Build
SHA256
file / ldd 检查结果
dmmonitor show
dmcssm show
当前 LSN

用于后续升级失败时的回滚和差异比对。

eco.dameng.com/