达梦 DM9 初体验：DM8 单机数据库升级实录

前言

我们现有的数据库环境大部分仍在使用 DM8。这次选择一套 CentOS 7.9 单机环境，尝试保留原数据库文件，通过替换数据库软件升级到 DM9。

升级后，数据库进入 OPEN 状态，业务模式的对象总数与升级前一致，启动日志也记录了数据字典和回滚段版本的变化。创建系统包时出现了编译警告，现有记录没有给出后续处理结果，业务读写和恢复演练也缺少完整记录。下面整理这次原库升级的操作过程，并标出后续验收需要补充的检查。

1. 本次升级的范围与版本

这次先正常关闭 DM8 并完成脱机备份，再安装 DM9 软件，由 DM9 启动原有实例。整个过程沿用原数据库文件，不涉及新建业务库或逻辑导出、导入。

本文记录的是表中的单机版本组合。DM8 官方《版本升级》介绍了正常停库和跨版本格式变化的要求，并未给出所有 DM8 构建直接升级到 DM9 的依据。换用其他版本前，应核对目标 DM9 安装介质随附的升级说明和支持范围，并在数据库副本上演练。DM8 官方《版本升级》

项目	本次环境
操作系统	CentOS 7.9
CPU / 架构	4 核 / x86_64
内存	16 GB
部署方式	单机
数据库端口	5236
升级前数据库	DM Database Server x64 V8
DM8 构建号	03134284368-20250917-293539-20149
DM9 安装介质	dm9_20260514_x86_centos7_64.iso
升级后构建号	03151060506-20260417-322930-20218
数据库软件目录	/home/dmdba/dmdbms
数据目录	/dmdata/data
实例配置文件	/dmdata/data/DAMENG/dm.ini
归档目录	/dmdata/arch
备份目录	/dmdata/dmbak
操作系统服务名	DmServiceDAMENG
数据库实例名	DMSERVER

服务名中的 DAMENG 是注册服务时指定的后缀，与查询得到的实例名 DMSERVER 不同。后面检查服务时使用前者，查询实例和查找本次日志时使用后者。

介质文件名中的日期与数据库构建号中的日期并不相同，应分别记录，实际运行版本以数据库查询结果为准。本次使用试用许可，启动日志提示许可到期日为 2027-04-17；其他环境需要核对自己的许可类型和有效期。

CentOS Linux 7 已于 2024 年 6 月 30 日结束维护。本文保留 CentOS 7.9 的环境信息，以便对照现有环境的升级过程。新项目选型仍需检查操作系统的支持周期。CentOS 官方生命周期说明

文中的版本、日志和对象数量均来自本次操作记录，业务模式名统一脱敏为 APP_RULE。“补充检查”和“演练示例”是整理流程时增加的内容，尚无本次执行通过的记录。

2. 升级前保存版本和业务基线

2.1 确认连接的是待升级实例

使用 DM8 安装目录中的客户端连接，按提示输入密码，不把密码写入命令或截图。

# dmdba 用户
/home/dmdba/dmdbms/bin/disql SYSDBA

SELECT * FROM V$VERSION;

SELECT NAME,
       INSTANCE_NAME,
       HOST_NAME,
       SVR_VERSION,
       DB_VERSION,
       BUILD_VERSION,
       BUILD_TIME,
       STATUS$
  FROM V$INSTANCE;

本次升级前记录到的主要信息如下。

检查项	升级前结果
数据库版本	DM Database Server 64 V8
构建号	03134284368-20250917-293539-20149
DB Version	0x7000d
实例名	DMSERVER
实例状态	OPEN

使用绝对路径可以减少新旧客户端混用，但客户端显示的 disql V8 或 disql V9 仍然只表示客户端版本。服务端版本要看 V$VERSION 和 V$INSTANCE。

2.2 保存业务对象和数据核对基线

SELECT USERNAME FROM DBA_USERS ORDER BY USERNAME;

-- 补充检查：按实际类型展开，避免遗漏未单列的对象。
-- APP_RULE 为脱敏示例，执行时替换成实际业务模式名。
SELECT OWNER, OBJECT_TYPE, COUNT(*) AS OBJECT_COUNT
  FROM DBA_OBJECTS
 WHERE OWNER = 'APP_RULE'
 GROUP BY OWNER, OBJECT_TYPE
 ORDER BY OWNER, OBJECT_TYPE;

SELECT COUNT(*) AS TOTAL_OBJECTS
  FROM DBA_OBJECTS
 WHERE OWNER = 'APP_RULE';

升级前的统计结果为 18 张表、19 个索引，总对象数为 39；单列的视图、序列、过程、函数和触发器数量均为 0。表和索引合计只有 37 个，还有 2 个对象没有在原查询的分类列中展示，需要用上面的分组查询确认其类型。

对象数量可用于初步比较。补充检查还应保存对象名称及定义、关键表实际行数，以及业务能够核对的汇总值，例如固定日期范围内的记录数和金额合计。停止业务写入后保存最终基线，升级后使用相同的查询条件复核。

2.3 检查 PURGE 状态和升级条件

SELECT * FROM V$PURGE;

本次返回：

OBJ_NUM    IS_RUNNING    PURG_FOR_TS
0          N             N

这条结果只反映 PURGE 状态，业务连接和未提交事务还需另行检查。停库前应停止应用写入、暂停定时任务，并确认事务已经收尾。跨越历史格式版本时，还要按相应升级章节核对额外条件。DM8 官方《版本升级》

补充检查时，应记录页大小、字符集、大小写敏感设置、兼容模式，以及实际使用的驱动版本、归档和备份配置。涉及加密、外部文件、空间数据等功能时，还要单独核对其升级要求和依赖。

在操作系统侧检查剩余空间：

# dmdba 用户；检查数据、归档、备份和软件所在文件系统。
df -h /home/dmdba /dmdata/data /dmdata/arch /dmdata/dmbak
du -sh /home/dmdba/dmdbms /dmdata/data /dmdata/arch /dmdata/dmbak

空间预算应同时包含 DM9 软件、旧软件副本、数据库备份、升级日志，以及恢复演练所需空间。备份文件的大小也不能直接当作数据库占用空间。

3. 正常停库，保留可用于回退的备份

3.1 停止业务并正常关闭 DM8

先停止应用和其他写入入口，保存停写后的核对结果，再关闭数据库服务。

# dmdba 用户
/home/dmdba/dmdbms/bin/DmServiceDAMENG stop

本次返回：

Stopping DmServiceDAMENG: [ OK ]

补充检查时，结合服务状态、数据库日志和进程信息确认目标实例正常退出。

# root 用户，输出中的其他实例需要分别识别。
systemctl status DmServiceDAMENG.service --no-pager
pgrep -a dmserver

进程退出后，还要查日志确认数据库正常关闭。如果旧库异常退出，应先用原 DM8 版本恢复到能够正常启动、正常关闭的状态，再继续升级。跨日志格式版本的升级对正常停库有明确要求。DM8 官方《版本升级》

3.2 使用原 DM8 工具做脱机备份

在替换软件之前，使用原安装目录的 dmrman。此时先保留旧版 DmAPService，待备份和校验完成后再停止它。

# dmdba 用户
/home/dmdba/dmdbms/bin/dmrman

在 RMAN 提示符下执行以下命令。备份集应使用本次专用的新目录，下面保留实际使用的目录名。

BACKUP DATABASE '/dmdata/data/DAMENG/dm.ini' BACKUPSET '/dmdata/dmbak/FULL20260825';

原始输出包括：

backup successfully!
time used: 00:00:05.657

备份目录中生成了 .bak 和 .meta 文件，ls -lh 显示 .bak 约为 1.6 GB。5.657 秒是这条备份命令的耗时。

补充检查：执行备份集校验，并保存结果。

CHECK BACKUPSET '/dmdata/dmbak/FULL20260825';
EXIT;

backup successfully! 表示备份命令成功；CHECK BACKUPSET 检查备份集有效性；恢复演练还需实际还原并启动数据库，三者应分别记录。这次保留了备份成功输出，校验和恢复能力仍待验证。DM8 官方《备份还原实战》

3.3 保存软件、配置和服务定义

回退需要同时准备原 DM8 软件和升级前的数据状态，还要保留配置、许可及加密相关文件。只备份软件目录不够。

补充留档内容包括 dm.ini、实际使用的归档及其他实例配置、控制文件、软件环境配置、有效许可文件、加密所需文件，以及服务定义和自启动状态。数据文件可能分布在多个路径，备份范围应按实例实际文件清单核对。

下面是服务定义的留档示例，保存目录应由管理员预先创建并限制访问权限。

# root 用户；PRE_DM9_20260825 为补充留档目录。
mkdir -p /dmdata/dmbak/PRE_DM9_20260825
chmod 700 /dmdata/dmbak/PRE_DM9_20260825
systemctl cat DmServiceDAMENG.service > /dmdata/dmbak/PRE_DM9_20260825/DmServiceDAMENG.unit.txt
systemctl cat DmAPService.service > /dmdata/dmbak/PRE_DM9_20260825/DmAPService.unit.txt
systemctl is-enabled DmServiceDAMENG.service
systemctl is-enabled DmAPService.service

这些文本可用于核对配置，恢复服务还需保留服务覆盖配置、权限、/etc/dm_svc.conf 和用户环境变量。归档配置及实际启用状态也要单独核查，目录存在并不能说明已经启用归档。

备份、校验和留档完成后，停止旧版 DmAPService，再复制软件目录。

# root 用户
systemctl stop DmAPService.service
pgrep -a dmap

# dmdba 用户
# 确认目标备份目录不存在，避免重复执行时形成嵌套目录。
cp -a /home/dmdba/dmdbms /home/dmdba/dmdbms8_bak

核对副本内容和权限后，再腾出原路径安装 DM9。补充建议是将旧软件目录改名保留，便于升级失败后核对文件。

# dmdba 用户；先确认 dmdbms8_retired 不存在，所有相关旧进程已停止。
mv -T /home/dmdba/dmdbms /home/dmdba/dmdbms8_retired

备份、校验或目录操作失败时，先处理原因，再继续安装。同机保存的软件和备份只能应对部分操作失败，正式升级还应在独立存储上保留副本。

4. 安装 DM9，并将服务指向原实例

4.1 安装数据库软件

将介质挂载到空闲挂载点。示例假定当前目录中已有该 ISO 文件；执行前应核对介质来源及提供方的校验信息。

# root 用户
mount -o loop,ro dm9_20260514_x86_centos7_64.iso /mnt

# dmdba 用户
cd /mnt
./DMInstall.bin -i

本次安装选择服务器组件，安装目录为 /home/dmdba/dmdbms。安装器提示系统存在其他版本时，应先核对旧进程和安装路径，避免影响同机其他实例。

安装结束后，根据本次安装器提示，以 root 用户执行：

/home/dmdba/dmdbms/script/root/root_installer.sh

本次脚本创建了相关监控服务和 DmAPService，并启动 DmAPService。不同介质的提示可能有差异，应以正在安装的版本为准。

软件安装完成后，将使用已有的 /dmdata/data/DAMENG/dm.ini 启动实例。不要对原数据路径运行 dminit 创建新库。

4.2 注册数据库服务并核对路径

# root 用户
cd /home/dmdba/dmdbms/script/root
./dm_service_installer.sh -t dmserver \
  -dm_ini /dmdata/data/DAMENG/dm.ini \
  -p DAMENG

本次返回：

创建服务(DmServiceDAMENG)完成

补充检查：核对系统服务和脚本指向的 DM9 软件目录、原实例配置文件，以及运行用户。

# root 用户
systemctl cat DmServiceDAMENG.service
ls -l /home/dmdba/dmdbms/bin/DmServiceDAMENG

如果已有同名服务，应按目标版本脚本说明处理旧注册项，再复查最终配置。本次返回“创建完成”，并不说明其他环境也允许直接覆盖。采用新路径并行安装时，需要相应修改服务和环境变量。DM8 官方《Linux 脚本使用手册》

5. 首次启动：用日志确认升级动作

以 dmdba 用户启动实例：

/home/dmdba/dmdbms/bin/DmServiceDAMENG start

本次实例日志为 /home/dmdba/dmdbms/log/dm_DMSERVER_202608.log。下面按时间顺序摘取关键原文，省略时间戳、进程号和重复的初始化信息；其他环境应按实际日志配置查找文件。

DM Database Server 64 V9 03151060506-20260417-322930-20218 startup...
Update DM8_DCT_VERSION from 113 to 134, rebuild dynamic tables begin...
Update DM8_DCT_VERSION from 113 to 134, rebuild dynamic tables end.
System upgrade from 0x8010450 to 0x901001a
System DM8_DCT_VERSION upgrade from 113 to 134
System PSEG_VERSION change from 0x7000b to 0x7000c
local instance name is DMSERVER, mode is NORMAL, status is OPEN.
SYSTEM IS READY.

这段日志记录了本次 DM9 启动时的字典升级，并显示实例最终进入 OPEN 状态。DM8_DCT_VERSION 是日志使用的内部字段名，出现 DM8 字样不意味着服务端仍在运行 DM8。

回退方案也要考虑这些变化：新版本已经执行了字典和内部版本更新，不能假设只把软件目录换回 DM8 就能继续打开这份数据。本次按恢复升级前备份来设计回退，不将旧程序直接启动已升级数据作为操作方案。

日志记录了自动字典升级，是否还需执行其他升级脚本，应核对目标 DM9 的版本说明。DM8 手册提到的 V8.1.1.15 对应历史 REDO 日志格式升级，不能用来判断任意 DM8 到 DM9 的字典处理要求。“自动执行”也不等于可以跳过升级。DM8 官方《版本升级》

6. 处理启动告警和系统包编译警告

6.1 TEMP_SIZE 参数调整

首次启动时出现：

Global parameter value of TEMP_SIZE is illegal, use min value!
INI parameter TEMP_SIZE changed, the original value 10, new value 32

实例将 TEMP_SIZE 从 10 调整为 32 后继续启动。日志没有说明 dm.ini 是否同步修改，32 也不能作为所有 DM9 环境的通用最小值。

DM8 公开手册将 TEMP_SIZE 定义为以 MB 为单位的静态参数，最小值与页大小有关：4096 个 8 KB 页对应 32 MB。该说明有助于理解日志中的数值，目标 DM9 构建的取值范围仍需查阅随附手册。DM8 官方《DM 物理存储结构》

处理时先保存原配置，核对本次实例页大小和参数范围，再在停库状态下修改 /dmdata/data/DAMENG/dm.ini 中已有的参数项。对于本次日志报告的取值，修改示例为：

TEMP_SIZE = 32

如果配置了非零的 TEMP_SPACE_LIMIT，还应确认它不小于 TEMP_SIZE。修改后重新启动，复查生效值和新的启动日志。32 MB 只是本次日志采用的下限，业务需要的临时空间还要根据实际负载安排。

此次尚无修改后的重启日志，告警是否消失仍待复查。日志中的 DPC_2PC、TRX_VIEW_SIZE 等参数也发生了调整，应一并保存并核对其影响。

6.2 缺少 libgssapi_krb5.so

另一条告警是：

fail to load libgssapi_krb5.so, libgssapi_krb5.so: cannot open shared object file: No such file or directory

操作记录中给出了以下处理命令：

# root 用户；确认软件源和匹配的软件包后执行。
yum install -y krb5-libs krb5-devel

执行前可先补充检查软件包安装情况和文件来源：

rpm -q krb5-libs krb5-devel
yum provides '*/libgssapi_krb5.so'

根据仓库查询结果确认提供该文件的软件包及架构，再安装缺失依赖。告警缺少的是 libgssapi_krb5.so，检查时应核对这个文件名，其他带版本号的文件不能代替它的加载验证。系统已结束维护，也要确认当前配置的软件源可用。

数据库随后进入了 OPEN，这条告警没有阻止本次启动。安装依赖后的重启日志和相关认证功能测试仍未记录，告警是否消失、功能是否受影响还有待确认。

6.3 创建系统包时出现编译警告

本次执行了以下语句，列出它们是为了说明编译警告出现的过程。这不是所有 DM9 升级都必须执行的步骤。

SP_CREATE_SYSTEM_VIEWS(0);
SP_CREATE_SYSTEM_VIEWS(1);
SP_CREATE_SYSTEM_PACKAGES(0);
SP_CREATE_SYSTEM_PACKAGES(1);

这些语句包含删除和创建操作。在 DM8 官方文档中，系统视图过程的 0 和 1 分别表示删除和创建；系统包过程同样区分这两种操作，且有专门的覆盖范围。因此，重建前需要核对目标版本要求、已启用功能及依赖，不宜将整组语句笼统称为“编译系统包”。系统视图过程说明、系统包创建与删除说明

执行最后一条语句时，本次输出为：

警告: 创建的对象带有编译错误
DMSQL 过程已成功完成

“DMSQL 过程已成功完成”并不表示所有系统包都创建成功。官方文档说明，批量创建时即使某个包失败，过程也会继续处理后续包，需要检查具体包的创建结果。DM8 官方《系统包概述》

后续应保存完整会话输出，定位具体失败的对象，核对依赖、权限及对应功能要求，再按目标版本文档处理。诊断范围应包含系统对象，不能只检查 APP_RULE。对未能创建出来的对象，也需要与所需系统包清单比对。

操作记录尚未列出具体失败对象及处理结果，原因也待确认，目前不能归因于空间包或某个缺失视图。业务验收前应完成排查并复核所需系统包的可用性。

7. 升级后的核对结果与业务验收

7.1 确认服务端版本和实例状态

使用 DM9 客户端重新连接，并执行第 2 节的版本查询。

# dmdba 用户
/home/dmdba/dmdbms/bin/disql SYSDBA

本次 V$VERSION 的关键输出为：

DM Database Server 64 V9
DB Version: 0x7000d
03151060506-20260417-322930-20218

V$INSTANCE 显示服务端为 V9，构建时间为 May 13 2026 15:49:55，实例状态为 OPEN。

升级前后的 DB Version 都是 0x7000d，而服务端大版本和启动日志中的字典、回滚段版本已经变化。这些字段反映不同的版本信息，不能只凭 DB_VERSION 相同就判断没有升级，或判断旧版本能够回退打开。

7.2 比较业务对象，继续核对数据内容

重复升级前的用户和业务对象查询，得到以下汇总结果。

检查项	DM8	DM9
表	18	18
索引	19	19
原查询单列的视图、序列、过程、函数和触发器	均为 0	均为 0
未被上述分类列单列的对象	2，类型待核对	2，类型待核对
总对象数	39	39

升级前后对象数量一致，对象定义、表内数据、权限和业务行为仍需继续核对。这次业务模式中没有过程和函数，因此也未覆盖复杂存储程序的兼容性验证。

补充数据检查时，可用下面的查询生成业务表行数统计 SQL，检查生成结果后再逐条执行。运行下面这条查询本身不会统计所有表。

SELECT 'SELECT COUNT(*) AS ROW_COUNT FROM "'
       || REPLACE(OWNER, '"', '""') || '"."'
       || REPLACE(TABLE_NAME, '"', '""') || '";' AS CHECK_SQL
  FROM DBA_TABLES
 WHERE OWNER = 'APP_RULE'
 ORDER BY TABLE_NAME;

对较大表应评估扫描开销；对关键数据，还应比较事先保存的业务汇总值和抽样记录。若两个检查时点之间仍有写入，需先解释增量变化，再判断差异。

7.3 通过应用完成验收

数据库能够打开后，应使用实际应用账号、连接池和驱动完成回归，至少覆盖应用登录、关键查询、事务提交与回滚、定时作业，以及应用使用到的存储过程或系统包。测试写入应使用事先约定的测试数据，并核对清理结果。

性能比较需要保持数据、SQL 参数和负载条件一致。几次管理 SQL 的毫秒级耗时不足以说明升级后的性能变化，还需安排单独的性能回归。

验收项	已有记录与待完成事项
DM9 启动并进入 OPEN	已有日志和查询结果
字典及内部版本升级	已有启动日志
用户和业务对象数量比较	已有结果，其他 2 个对象类型待展开
TEMP_SIZE、依赖告警复查	有原始告警和处理方法，缺少复查输出
系统包编译警告	已记录，具体对象和处理结果待补充
关键表数据、应用读写和性能回归	尚无检查记录
备份集校验、DM8 恢复演练	尚无检查记录

业务验收通过后，还应在 DM9 上建立新的备份基线，检查备份作业、归档和监控是否正常，并按保留策略继续保存升级前的 DM8 备份。

8. 回退应恢复升级前的数据状态

回退条件和最晚决策时间需要在停机前确定。例如，数据库无法正常打开、关键数据核对不一致，或应用回归发现无法在维护窗口内解决的问题，就应按演练过的方案回退。

对于这次原库升级，回退设计是停止 DM9，保留现场，再用原 DM8 软件恢复升级前的备份。软件目录、服务定义和配置文件也要同步恢复，避免服务继续指向 DM9。

以下是备份恢复部分的演练示例，尚无本次实际执行结果。执行前，先隔离升级后的数据和配置，由原 DM8 版本创建恢复目标实例，匹配必要的初始化参数，再按原库文件清单核对所有恢复目标路径。恢复目标须保持停库状态。仅修改 dm.ini 路径不足以隔离全部数据文件。

先将 FULL20260825 整个备份集目录（含全部 .bak 和 .meta 文件）复制到恢复主机的示例路径，校验通过后再还原。

在独立恢复环境中，使用与备份匹配的原 DM8 dmrman。下面的程序路径是该环境安装原 DM8 软件的示例，必须替换成实际路径。

# 恢复主机上的 dmdba 用户；仅用于本文磁盘备份示例。
/opt/dm8/dmdbms/bin/dmrman USE_AP=2

USE_AP=2 让 DM RMAN 自身执行备份还原，避免依赖另一版本的 DMAP；该模式不适用于 TAPE 第三方备份。若使用默认的 DMAP 模式，则要保证服务也与原 DM8 工具匹配。DM8 官方《备份还原实战》

在 RMAN 提示符下执行：

CHECK BACKUPSET '/dmdata/dmbak/FULL20260825';

RESTORE DATABASE '/dmrestore/data/DAMENG/dm.ini'
  FROM BACKUPSET '/dmdata/dmbak/FULL20260825';

RECOVER DATABASE '/dmrestore/data/DAMENG/dm.ini'
  FROM BACKUPSET '/dmdata/dmbak/FULL20260825';

RECOVER DATABASE '/dmrestore/data/DAMENG/dm.ini' UPDATE DB_MAGIC;

/dmrestore/data/DAMENG/dm.ini 是演练目标的示例路径，需要事先准备。RESTORE 负责还原数据，RECOVER 按备份条件完成恢复，最后更新 DB_MAGIC。脱机备份在 BEGIN_LSN = END_LSN 等相应条件下不需要重做 REDO；这里保留完整恢复流程，实际步骤按备份类型和原 DM8 手册确认。DM8 官方《备份还原实战》、《备份还原原理》

恢复后，用 DM8 启动目标实例，核对版本、关键数据和业务访问，并记录总恢复时间，作为安排维护窗口的依据。

恢复升级前的备份，会回到该备份对应的数据状态。如果 DM9 已经接收新的业务写入，这些增量不会因为恢复旧备份而自动保留。接入业务前应明确回退边界；接入后再回退，则需要另外制定增量数据处理方案。