从零到一：DM9 在 CentOS 7.9 上的单机部署实战与试用手记
写在前面：一篇可以被"照着做出来"的部署实操记录
本文不是一个"读懂就好"的原理综述，而是一份可以直接照着敲、敲完就能跑起来的实操记录。
笔者在一台全新安装的 CentOS 7.9 虚拟机上，用一块 140 GB 空闲磁盘，从操作系统准备、LVM 存储规划、软件静默安装、实例初始化、服务注册、归档开启，一直到在线备份与干净卸载，完整地走了一遍 DM9 单机部署的全过程，并把每一步的真实命令、真实回显、真实耗时，以及踩到的 36 个坑全部记录在案。
三个问题，先给出答案：
| 你可能关心的问题 | 本文的答案 | 直达章节 |
|---|---|---|
| 装一套 DM9 单机，最快多久？ | 约 35 分钟（其中软件安装约 8 分钟、实例初始化约 2 分钟，其余为系统准备与验证） | 快速上手路线图 |
| 跟着官方文档做，为什么还会失败？ | 官方文档对"DM9 相对 DM8 的行为变化"着墨不多，本文整理了 20 项关键差异，多数是官方未标注的坑 | 附录 A |
| 遇到报错卡住了怎么办？ | 文档沉淀了 40+ 条常见报错现象 → 根因 → 处置，可按关键词直接查 | 附录 B |
阅读建议
- 急着上手：直接走下面的《快速上手路线图》，9 步到可用库；
- 要建生产库：从第 1 章顺序读，重点是第 1、3、5、12、13 章；
- 遇到报错：跳到附录 B 按现象检索，或查第 15.5 节；
- 想知道"为什么"：每章末尾的"设计取舍"小节，以及第 8.7 节的参数解读。
快速上手路线图（9 步到可用库）
下表是全流程的最短路径，每步都给出了对应章节与大致耗时。首次部署按此表顺次执行即可，无需事先通读全文。
| 步骤 | 做什么 | 章节 | 预计耗时 | 关键命令（速查） |
|---|---|---|---|---|
| 1 | 检查系统环境（内核参数、THP、SELinux、时间同步） | 第 2 章 | 5 分钟 | sysctl -p / getenforce |
| 2 | 规划存储：/dev/sdd 建 VG 与 3 个 LV 并挂载 |
第 3 章 | 5 分钟 | pvcreate → vgcreate → lvcreate → mkfs.ext4 |
| 3 | 创建 dmdba 管理员用户与 dinstall 组 |
第 4 章 | 2 分钟 | groupadd dinstall / useradd -g dinstall dmdba |
| 4 | 调整操作系统资源限制 | 第 5 章 | 2 分钟 | 改 /etc/security/limits.conf |
| 5 | 静默安装数据库软件 | 第 6 章 | 8 分钟 | ./DMInstall.bin -s install.xml |
| 6 | 配置环境变量 | 第 7 章 | 2 分钟 | 追加 .bash_profile |
| 7 | 初始化数据库实例 | 第 8 章 | 3 分钟 | dminit PATH=... DB_NAME=DMDB |
| 8 | 注册并启动操作系统服务 | 第 9、10 章 | 3 分钟 | dm_service_installer.sh → systemctl start |
| 9 | 开启归档并完成首次备份 | 第 12、13 章 | 5 分钟 | ALTER DATABASE ARCHIVELOG → BACKUP DATABASE |
提示：第 3 步之前的所有操作均以
root执行，从第 6 步起切换为dmdba用户，请留意每段命令前的用户标记（见《阅读约定》）。
文档说明
本指南基于达梦官方文档（安装前准备、数据库安装、配置实例、注册服务、启停数据库、目录结构六篇），针对 DM9 企业版 9.1.0.26 的实际行为进行了完整实测，并在以下方面超越官方文档：
| 强化点 | 官方文档 | 本指南 |
|---|---|---|
| 存储规划 | 仅建议 mkdir 建目录 |
完整 LVM 卷级隔离方案，数据/归档/备份分盘，含生产容量公式与在线扩容 |
| 安装方式 | 仅 -i 交互式 |
给出经实测的 -s 静默安装 XML 配置格式，可批量自动化 |
| 内核参数 | 未涉及 | 给出 sysctl 参数计算依据与持久化写法 |
| 透明大页 | 未涉及 | 临时+永久双方案 |
| 归档配置 | 笼统提及 | 明确"不开归档无法在线备份"这一关键约束，给出完整配置 |
| 备份验证 | 未涉及 | 给出 dmrman（停机）与 SQL（在线）两种方式的区别与选用 |
| 配置文件解读 | 仅列出文件 | 第 8.7 节给出 dm.ini/dmarch.ini/sqllog.ini 三大配置文件的完整内容、参数分组解读与调优建议 |
| 卸载 | 仅提及卸载程序 | 第 16 章给出经实测验证的干净卸载全流程（软件/服务/残留/资源四层），含 13 项卸载后核验清单 |
| DM9 差异 | 部分内容仍为 DM8 | 标注 DM9 相对 DM8 的 20 处行为差异 |
| 验收 | 无 | 46 项部署检查清单 + 作业记录表（含两轮实测） |
| 上手成本 | 需通读全文 | 《快速上手路线图》9 步直达可用库，含每步耗时估算，首次部署可照表执行 |
| 试用心得 | 无 | 第 17 章记录初次试用感受、易踩坑点与效率对比，供后来者参考 |
| 能力演进 | 未系统归纳 | 第 18 章从实测出发，归纳 DM9 相对 DM8 的三条演进主线（可编排 / 可观测 / 更稳健） |
| 实测复核 | 无 | 2026-09-16 连真实实例逐项复核，修正 6 处偏差：SQL 日志落盘路径、SYSAUX 表空间遗漏、备份集文件构成、limits 多产品冲突、THP defrag 漏配、创建期参数查询方式 |
| 从零重跑 | 无 | 服务器清理干净后，按本文档从第 2 章到第 14 章逐条重跑一遍（见附录 E.9）：命令、参数、路径、判据逐条可复现，并据此再更正 6 处"经验性表述"（THP 判据、备份集个数、映射文件改写、表空间个数、LVM 交互、归档大文件） |
目录
- 写在前面：一篇可以被"照着做出来"的部署实操记录
- 第 1 章 部署规划
- 第 2 章 系统环境准备
- 第 3 章 存储规划（LVM）
- 第 4 章 创建数据库管理员用户
- 第 5 章 操作系统资源限制调整
- 第 6 章 数据库软件安装
- 第 7 章 环境变量配置
- 第 8 章 初始化数据库实例
- 第 9 章 注册操作系统服务
- 第 10 章 数据库启停与状态检查
- 第 11 章 数据库目录结构说明
- 第 12 章 归档配置（在线备份前置）
- 第 13 章 数据库备份与恢复
- 第 14 章 部署后验证
- 第 15 章 日常运维要点
- 第 16 章 DM9 数据库干净卸载
- 第 17 章 初次试用感受与心得
- 第 18 章 DM9 相对 DM8 的能力演进（实测视角）
- 附录 A DM9 相对 DM8 的关键行为差异
- 附录 B 常见问题处理
- 附录 C 部署检查清单
- 附录 D 生产环境容量规划建议
- 附录 E 部署作业记录（本次实测）
阅读约定
命令均标注执行用户，请严格按标注切换：
| 标记 | 含义 |
|---|---|
[root]# |
以 root 用户执行 |
[dmdba]$ |
以 dmdba 用户执行 |
统一变量（文中命令引用变量值，便于按实际环境替换）：
| 变量 | 取值 | 说明 |
|---|---|---|
DM_HOME |
/home/dmdba/dmdbms |
软件安装目录 |
DM_DATA |
/dmdata/data |
数据文件目录 |
DM_ARCH |
/dmdata/arch |
归档日志目录 |
DM_BAK |
/dmdata/dmbak |
备份集目录 |
DB_NAME |
DMDB |
数据库名 |
INSTANCE_NAME |
DMSERVER |
实例名 |
PORT_NUM |
5236 |
监听端口 |
重要提示
页大小、簇大小、大小写敏感、字符集、空格填充模式、页检查模式这六项参数在实例初始化后永久不可修改，必须上线前一次性确定。详见第 8 章。
第 1 章 部署规划
1.1 环境信息
| 项目 | 本次部署取值 | 记录命令 |
|---|---|---|
| 主机名 | kb-db02 | hostname |
| 操作系统 | CentOS Linux release 7.9.2009 (Core) | cat /etc/redhat-release |
| 内核版本 | 3.10.0-1160.el7.x86_64 | uname -r |
| 硬件架构 | x86_64 | uname -m |
| CPU | 4 核 | lscpu | grep '^CPU(s)' |
| 物理内存 | 16 GB | free -m |
| 数据库 IP | 192.168.3.22 | ip -4 addr show |
| 软件包 | dm9_20260514_x86_centos7_64.zip | — |
| 软件版本 | DM9 企业版 9.1.0.26（内部版本 03151060506-20260417） | — |
1.2 目录与容量规划
核心设计原则：软件与数据分离、功能分盘隔离。
三类数据具有完全不同的 I/O 特征与增长规律：
- 数据文件：随机读写为主，持续增长，对 I/O 延迟最敏感；
- 归档日志：顺序追加写，增长快，写满会直接挂起数据库；
- 备份集：批量顺序写，瞬时占用大，一般不参与在线业务 I/O。
三者独立成卷可实现：容量互不侵占、I/O 互不干扰、单卷写满不影响其他功能、可在线扩容。
| 目录 | 用途 | 规划容量（本次） | 生产建议容量 |
|---|---|---|---|
/home/dmdba/dmdbms |
软件安装目录 | 系统盘 | 10 GB |
/dmdata/data |
数据文件（实例目录） | 60 GB | 1 TB 起，预留 3 年增长 |
/dmdata/arch |
归档日志 | 40 GB | ≥ 数据量 1.5 倍 |
/dmdata/dmbak |
备份集 | 30 GB | ≥ 数据量 2 倍 |
实例目录的"基线占用"必须先算清（实测数据）
规划
/dmdata/data容量时，除业务数据本身外，还需先扣除实例的固定基线开销。本次实测（PAGE_SIZE=16、采用默认LOG_SIZE）的基线构成如下：
组成 实测大小 说明 重做日志 DMDB01.log+DMDB02.log8 GB 各 4 GB（DM9 默认 LOG_SIZE=4096；小容量环境务必显式调小，见 8.4 节）SYSAWR.DBF（SYSAUX 表空间）5 GB AWR 性能仓库；仅在执行 SP_INIT_AWR_SYS(1)初始化 AWR 后才出现，属可选开销（见 8.6 节）SYSTEM.DBF192 MB（持续增长） 数据字典 ROLL.DBF+MAIN.DBF256 MB 回滚表空间 + 主表空间 TEMP.DBF64 MB 临时表空间 合计基线 约 13.5 GB（启用 AWR）
约 8.5 GB（未启用 AWR）此时尚未写入任何业务数据 也就是说，一个刚建好、不含任何业务数据的 DM9 实例，就已占用数据卷约 8.5～13.5 GB（取决于是否启用 AWR）。其中"重做日志 8 GB"是固定开销，SYSAUX 的 5 GB 则是启用 AWR 后的追加开销——这两项恰好是容量规划中最常被忽略的部分。规划生产容量请按 “业务数据量 + 基线 + 增长余量” 计算，切勿只按业务数据量估算。
为何软件目录不放在独立卷？
软件目录约 1.5 GB（DM9 实测 1.48 GB），生命周期与操作系统一致。若置于独立卷，软件升级与卸载时会额外牵扯逻辑卷管理，收益低而维护成本高。数据类目录才是隔离重点。
1.3 存储规划示意
本机 /dev/sdd 为 140 GB 空闲盘，规划如下：
/dev/sdd (140 GB)
└── LVM 卷组：dmvg
├── 逻辑卷 dmdata_lv 60 GB → /dmdata/data （实例/数据文件）
├── 逻辑卷 dmarch_lv 40 GB → /dmdata/arch （归档日志）
├── 逻辑卷 dmbak_lv 30 GB → /dmdata/dmbak （备份集）
└── 剩余约 10 GB 预留，用于在线扩容
第 2 章 系统环境准备
2.1 确认操作系统兼容性
DM9 的 x86_centos7_64 版本面向 CentOS 7 x86_64 编译，安装前确认运行时版本：
[root]# cat /etc/redhat-release # 操作系统版本
[root]# uname -r # 内核版本，要求 3.10 及以上
[root]# uname -m # 硬件架构，要求 x86_64
[root]# ldd --version | head -1 # glibc，要求 2.17 及以上
实测输出（本文在 192.168.3.22 实跑，下同）：
CentOS Linux release 7.9.2009 (Core) 3.10.0-1160.el7.x86_64 x86_64 ldd (GNU libc) 2.17
DM9 企业版 9.1.0.26 的构建基线（来自随包 README，实测确认）：
| 组件 | 版本 |
|---|---|
| OpenSSL | 3.5.4 |
| GCC | 4.8.5 |
| glibc | 2.17 |
| GLIBCXX | 3.4.19 |
CentOS 7.9 默认满足全部条件。
若在信创平台（麒麟、统信、openEuler）部署，必须下载与 CPU 架构、操作系统同时匹配的安装包，不可跨平台混用。
2.2 调整内核参数
达梦实例启动需申请大块共享内存。CentOS 7 默认的 kernel.shmmax 与 kernel.shmall 偏小，需按物理内存调大。
计算依据（以 16 GB 内存为例）：
kernel.shmmax：单段共享内存最大字节数，建议设为物理内存一半以上，本例取 8 GB = 8589934592；kernel.shmall：可用共享内存总页数，页大小 4096 字节，故 8 GB ÷ 4096 = 2097152；kernel.sem：信号量数组，达梦推荐250 32000 32 128及以上。
[root]# vi /etc/sysctl.d/99-dm.conf
# ---------- DM9 数据库内核参数 ----------
# 单个共享内存段的最大字节数：物理内存的一半（16GB/2 = 8GB）
kernel.shmmax = 8589934592
# 系统可分配的共享内存总页数：shmmax / 页大小(4096) = 2097152
kernel.shmall = 2097152
# 信号量：每信号集最大信号数 | 系统级最大信号总数 | 单次semop最大操作数 | 系统级最大信号集数
kernel.sem = 250 32000 32 128
# 交换倾向：数据库场景应尽量使用物理内存，降低换页概率
vm.swappiness = 10
# 内存超额分配策略：0 表示启发式分配，允许合理超额申请
vm.overcommit_memory = 0
# 脏页比例上限，避免集中刷盘造成 I/O 尖峰
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10
生效并验证：
[root]# sysctl -p /etc/sysctl.d/99-dm.conf
[root]# sysctl kernel.shmmax kernel.shmall kernel.sem vm.swappiness
实测输出：
kernel.shmmax = 8589934592 kernel.shmall = 2097152 kernel.sem = 250 32000 32 128 vm.swappiness = 10 vm.overcommit_memory = 0 vm.dirty_ratio = 20 vm.dirty_background_ratio = 10
为何写入
/etc/sysctl.d/而非直接改/etc/sysctl.conf？
CentOS 7 按文件名顺序加载/etc/sysctl.d/*.conf，单独建文件便于版本化管理和快速回滚，也不会与系统原有配置混杂。
2.3 关闭透明大页（THP）
透明大页在数据库场景会导致内存分配抖动与不可预测的延迟尖峰，属必须关闭项。
# 临时关闭（立即生效）
[root]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
[root]# echo never > /sys/kernel/mm/transparent_hugepage/defrag
# 永久关闭：写入开机脚本
[root]# cat >> /etc/rc.d/rc.local << 'EOF'
# 关闭透明大页：数据库场景要求，避免内存分配抖动
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi
EOF
[root]# chmod +x /etc/rc.d/rc.local
# 验证（两项都要查，缺一不可）
[root]# cat /sys/kernel/mm/transparent_hugepage/enabled
[root]# cat /sys/kernel/mm/transparent_hugepage/defrag
# 期望均为：always madvise [never] 方括号在 never 上
实测输出（两项均已生效，开机脚本两处均命中）：
--- 临时态验证(期望 [never]) --- always madvise [never] always madvise [never] --- rc.local 命中计数(期望各>=1) --- 1 1
⚠️ 实测复核提醒：
defrag是最容易漏配的一项在 192.168.3.22 上复核
/etc/rc.d/rc.local时发现：其中只有设置enabled的那一行，缺少设置defrag的对应语句。当时defrag之所以显示[never]，是因为运行期被手工echo过——这类临时设置重启即失效，重启后会回落到always。请在部署后复核开机脚本是否两处都写了：
# 推荐判据：分别确认两项都已写入（不要数总行数） [root]# grep -c 'transparent_hugepage/enabled' /etc/rc.d/rc.local # 期望 ≥ 1 [root]# grep -c 'transparent_hugepage/defrag' /etc/rc.d/rc.local # 期望 ≥ 1为什么不数总行数：上面给出的
rc.local片段中，每个设置各占 2 行（test -f判断行 +echo写入行），只写enabled一项就已命中 2 行；若同机还部署了别的产品（其开机脚本也写过 THP 设置），命中行数会更多。在混布其他数据库的机器上曾观察到命中 5 行的情况。按"两项是否各自出现"判断才不会误判。为什么
defrag同样要关：THP 的碎片整理（defrag）会在内存碎片化时触发同步内存回收，导致难以定位的延迟尖峰——只关enabled并不够。这是"配置看起来生效了、重启后问题复现"的典型来源。
2.4 配置主机名解析
[root]# vi /etc/hosts
确保包含本机记录：
192.168.3.22 kb-db02
验证：ping -c 2 kb-db02
实测输出：
--- /etc/hosts --- 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 192.168.3.22 kb-db02 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 --- ping 本机名 --- PING kb-db02 (192.168.3.22) 56(84) bytes of data. 64 bytes from kb-db02 (192.168.3.22): icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from kb-db02 (192.168.3.22): icmp_seq=2 ttl=64 time=0.020 ms 2 packets transmitted, 2 received, 0% packet loss
2.5 安全策略与防火墙
达梦默认监听 TCP 5236。生产环境不建议直接关闭防火墙，按最小授权放通端口：
[root]# getenforce # 输出 Disabled 或 Permissive 即可
[root]# systemctl is-active firewalld
# 若 firewalld 运行中，放通数据库端口（勿整机关闭防护）
[root]# firewall-cmd --permanent --add-port=5236/tcp
[root]# firewall-cmd --reload
[root]# firewall-cmd --list-ports
实测输出（5236/tcp 已成功放行）：
SELinux: Disabled firewalld 状态: active success success --- 已放行端口 --- 1521/tcp 8008/tcp 2379/tcp 2380/tcp 5000/tcp 6000/tcp 5236/tcp
2.6 时间同步
集群与归档恢复均依赖准确时间戳：
[root]# timedatectl
[root]# systemctl status chronyd # 或 ntpd
[root]# date
实测输出（时钟已同步，NTP synchronized: yes）：
Local time: Mon 2026-09-21 08:37:50 CST Universal time: Mon 2026-09-21 00:37:50 UTC Time zone: Asia/Shanghai (CST, +0800) NTP enabled: yes NTP synchronized: yes --- chronyd/ntpd 状态 --- active inactive Mon Sep 21 08:37:50 CST 2026
2.7 依赖工具检查
[root]# rpm -q unzip tar bc | grep -v 'not installed'
[root]# yum install -y unzip tar bc # 如缺失则安装
实测输出（三个工具齐备）：
unzip-6.0-21.el7.x86_64 tar-1.26-35.el7.x86_64 bc-1.06.95-13.el7.x86_64
第 3 章 存储规划（LVM）
本章为超越官方文档的强化章节。官方仅建议创建普通目录，未给存储规划方法；生产环境必须做到卷级隔离。
3.1 确认目标磁盘状态
任何磁盘操作前必须先确认目标盘未被使用，这是不可省略的安全动作：
[root]# lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
[root]# df -Th # 确认目标盘未挂载
[root]# pvs # 确认目标盘未加入其他卷组
本次 /dev/sdd 为 140 GB 裸盘，无分区、无文件系统、不属于任何卷组，可安全使用。
实测输出：
===== 3.1 确认磁盘空闲 ===== NAME SIZE TYPE MOUNTPOINT FSTYPE sdd 140G disk sdd 未加入任何VG
危险操作警示
后续pvcreate、vgcreate会清空目标磁盘上所有数据。执行前务必用上述命令二次确认磁盘标识（如sdd而非sdb）。误操作将导致不可恢复的数据丢失。
3.2 创建物理卷（PV）
# 【复用磁盘必做】清除盘上残留的文件系统/LVM 签名，避免 LVM 弹交互提示
[root]# wipefs /dev/sdd # 先看有没有残留签名
[root]# wipefs -a /dev/sdd # 有则清除
# 创建物理卷（-ff 强制、-y 对提示自动回答 yes）
[root]# pvcreate -ff -y /dev/sdd
# 输出 Physical volume "/dev/sdd" successfully created. 表示成功
实测输出：
===== 3.2 PV ===== Physical volume "/dev/sdd" successfully created.
3.3 创建卷组（VG）
[root]# vgcreate dmvg /dev/sdd
[root]# vgs # 验证，应显示 dmvg 共 140 GB
实测输出：
===== 3.3 VG ===== Volume group "dmvg" successfully created VG #PV #LV #SN Attr VSize VFree centos 2 2 0 wz--n- 71.99g 0 dmvg 1 0 0 wz--n- <140.00g <140.00g
3.4 创建逻辑卷（LV）
# 数据卷：60 GB，承载实例目录与数据文件
[root]# lvcreate -y -L 60G -n dmdata_lv dmvg
# 归档卷：40 GB，独立成卷避免归档写满影响数据文件
[root]# lvcreate -y -L 40G -n dmarch_lv dmvg
# 备份卷：30 GB
[root]# lvcreate -y -L 30G -n dmbak_lv dmvg
[root]# lvs # 验证
为什么必须加
-y（实战教训）在复用磁盘（该盘此前承载过其他数据）的场景下，
lvcreate会检测到盘上残留的旧文件系统签名（如ext4 signature detected ... at offset 1080），并弹出交互提示Wipe it? [y/n]。若不加-y，进程会卡在等待终端输入——本次实测曾因此挂起 31 分钟；而更迷惑的是，此时 LV 设备其实已创建成功，lsblk看一切正常，只有进程不退出。三重保险：① 执行前
wipefs -a /dev/sdd清残留签名；② 所有 LVM 命令加-y；③ 若放在脚本中，脚本开头加exec </dev/null，让任何意外交互直接失败而非挂死。
实测结果：
LV VG Attr LSize
dmdata_lv dmvg -wi-ao---- 60.00g
dmarch_lv dmvg -wi-ao---- 40.00g
dmbak_lv dmvg -wi-ao---- 30.00g
实测提示：本次在复用过的盘上执行时，
lvcreate输出中出现了Wiping xfs signature .../Wiping ext4 signature ...字样，说明盘上确有残留签名被自动清除——这正是必须加-y的直接证据。
3.5 创建文件系统（ext4）
本次数据盘 140 GB，远小于 16 TB，选 ext4。
文件系统选型说明
- 小于 16 TB：选 ext4。单文件系统上限 16 TB、单文件上限 16 TB，成熟稳定，支持在线扩容（
resize2fs），元数据开销小；- 大于 16 TB：选 xfs。ext4 超过 16 TB 后受
fsck效率与上限限制，xfs 支持到 8 EB，大容量下格式化与检查更快；- 固定挂载选项：
noatime,nodiratime可显著降低文件时间戳更新带来的写 I/O。
[root]# mkfs.ext4 -L dmdata /dev/mapper/dmvg-dmdata_lv
[root]# mkfs.ext4 -L dmarch /dev/mapper/dmvg-dmarch_lv
[root]# mkfs.ext4 -L dmbak /dev/mapper/dmvg-dmbak_lv
实测输出（三卷均成功创建，以数据卷为例）：
===== 3.5 文件系统 ===== mke2fs 1.42.9 (28-Dec-2013) Filesystem label=dmdata OS type: Linux Block size=4096 (log=2) 3932160 inodes, 15728640 blocks 786432 blocks (5.00%) reserved for the super user Allocating group tables: 0/480 done Writing inode tables: 0/480 done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: 0/480 done
3.6 创建挂载点并持久化挂载
[root]# mkdir -p /dmdata/data /dmdata/arch /dmdata/dmbak
# 获取 UUID（比设备名可靠，设备名可能因内核枚举顺序漂移）
[root]# blkid /dev/mapper/dmvg-dmdata_lv /dev/mapper/dmvg-dmarch_lv /dev/mapper/dmvg-dmbak_lv
实测 UUID（本文实跑环境取值，请以你机器 blkid 实测为准）：
/dev/mapper/dmvg-dmdata_lv: LABEL="dmdata" UUID="f41650da-84cf-41d2-8a81-7ea4cd2b094a" TYPE="ext4"
/dev/mapper/dmvg-dmarch_lv: LABEL="dmarch" UUID="f33acaa9-3909-4ceb-9c89-7dc571119607" TYPE="ext4"
/dev/mapper/dmvg-dmbak_lv: LABEL="dmbak" UUID="7967284c-e4a4-4a16-be86-caa38ad98add" TYPE="ext4"
写入 /etc/fstab：
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=f41650da-84cf-41d2-8a81-7ea4cd2b094a /dmdata/data ext4 defaults,noatime,nodiratime 0 2
UUID=f33acaa9-3909-4ceb-9c89-7dc571119607 /dmdata/arch ext4 defaults,noatime,nodiratime 0 2
UUID=7967284c-e4a4-4a16-be86-caa38ad98add /dmdata/dmbak ext4 defaults,noatime,nodiratime 0 2
挂载选项含义：
| 选项 | 作用 |
|---|---|
defaults |
默认挂载属性（rw、suid、dev、exec、auto、nouser、async） |
noatime |
不更新文件访问时间，减少无谓写 I/O |
nodiratime |
不更新目录访问时间，进一步降低 I/O |
必须执行的验证步骤
修改 fstab 后切勿直接重启，应先用mount -a验证语法，否则 fstab 写错会导致系统无法正常启动。
[root]# mount -a # 无报错即语法正确
[root]# df -Th /dmdata/data /dmdata/arch /dmdata/dmbak
[root]# lsblk -o NAME,SIZE,TYPE,MOUNTPOINT /dev/sdd
实测输出（三个卷均已按预期挂载）：
--- mount -a 验证(无报错即语法正确) --- rc=0 --- df -Th --- Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/dmvg-dmdata_lv ext4 59G 53M 56G 1% /dmdata/data /dev/mapper/dmvg-dmarch_lv ext4 40G 49M 38G 1% /dmdata/arch /dev/mapper/dmvg-dmbak_lv ext4 30G 45M 28G 1% /dmdata/dmbak --- lsblk --- NAME SIZE TYPE MOUNTPOINT sdd 140G disk ├─dmvg-dmdata_lv 60G lvm /dmdata/data ├─dmvg-dmarch_lv 40G lvm /dmdata/arch └─dmvg-dmbak_lv 30G lvm /dmdata/dmbak
3.7 后续扩容方法（生产实用）
VG 中尚有剩余空间时，可在线扩容，无需停机：
# 示例：为数据卷扩容 10 GB
[root]# lvextend -L +10G /dev/mapper/dmvg-dmdata_lv
[root]# resize2fs /dev/mapper/dmvg-dmdata_lv # ext4 在线扩容
[root]# df -Th /dmdata/data # 验证
VG 空间用尽时，先添加新磁盘扩展卷组：
[root]# pvcreate /dev/sde
[root]# vgextend dmvg /dev/sde
[root]# lvextend -L +100G /dev/mapper/dmvg-dmdata_lv
[root]# resize2fs /dev/mapper/dmvg-dmdata_lv
xfs扩容用xfs_growfs <挂载点>，且不支持缩小；ext4 两者皆可。规划容量宁大勿小。
第 4 章 创建数据库管理员用户
达梦数据库禁止使用 root 用户安装和运行，必须创建专用操作系统用户。
4.1 创建用户组与用户
官方文档使用固定 UID/GID 2001，生产环境建议不强制指定 ID，由系统自动分配，避免与现有账号冲突：
# 创建用户组
[root]# groupadd dinstall
# 创建用户：指定所属组、创建家目录、指定 shell
[root]# useradd -g dinstall -m -d /home/dmdba -s /bin/bash dmdba
# 设置密码（交互输入两次）
# 本环境实测取 dmdba@2026 —— 仅测试环境示例，生产请按口令复杂度规范另设。
# 该口令用于 su - / SSH 登录；达梦进程本身不以口令启动，故不影响数据库运行。
[root]# passwd dmdba
# 验证
[root]# id dmdba
# 实测输出：uid=1000(dmdba) gid=1000(dinstall) groups=1000(dinstall)
| 参数 | 含义 |
|---|---|
-g dinstall |
指定用户主组 |
-m |
创建用户家目录 |
-d /home/dmdba |
指定家目录路径 |
-s /bin/bash |
指定登录 shell |
若客户环境有统一命名规范（如指定 UID/GID），再用
-u 2001、-g 2001显式指定。
4.2 授权数据目录
[root]# chown -R dmdba:dinstall /dmdata/data
[root]# chown -R dmdba:dinstall /dmdata/arch
[root]# chown -R dmdba:dinstall /dmdata/dmbak
[root]# chmod -R 755 /dmdata/data
[root]# chmod -R 755 /dmdata/arch
[root]# chmod -R 755 /dmdata/dmbak
# 验证
[root]# ls -ld /dmdata/data /dmdata/arch /dmdata/dmbak
# 实测：drwxr-xr-x. 3 dmdba dinstall ... /dmdata/data
实测输出：
--- 验证 id --- uid=1000(dmdba) gid=1000(dinstall) groups=1000(dinstall) ===== 4.2 授权数据目录 ===== drwxr-xr-x 3 dmdba dinstall 4096 Sep 21 08:40 /dmdata/arch drwxr-xr-x 3 dmdba dinstall 4096 Sep 21 08:40 /dmdata/data drwxr-xr-x 3 dmdba dinstall 4096 Sep 21 08:40 /dmdata/dmbak
数据库文件本身会在实例初始化时由达梦自行设为更严格的权限（通常 600），此处仅需保证目录可达。
第 5 章 操作系统资源限制调整
Linux 默认对进程可打开文件数、进程数、内存设有上限。达梦运行中会打开大量数据文件与日志文件，若不解除限制，可能出现连接数上不去、归档写入失败等隐蔽故障。
5.1 永久生效配置
[root]# vi /etc/security/limits.conf
在文件末尾追加（逐项含注释）：
# ---------- DM9 数据库操作系统资源限制 ----------
# 进程调度优先级：允许 dmdba 自行调整 nice 值
dmdba soft nice 0
dmdba hard nice 0
# 进程虚拟地址空间：不限制，数据库需要申请大块连续内存
dmdba soft as unlimited
dmdba hard as unlimited
# 单文件大小：不限制，数据文件与备份集可能超过默认上限
dmdba soft fsize unlimited
dmdba hard fsize unlimited
# 可创建进程/线程数：数据库会为每个连接、每个后台线程分配资源
dmdba soft nproc 65536
dmdba hard nproc 65536
# 可打开文件描述符数：每个数据文件、控制文件、日志文件均占用句柄
dmdba soft nofile 65536
dmdba hard nofile 65536
# 核心转储文件大小：不限制，便于异常时保留 core 文件分析
dmdba soft core unlimited
dmdba hard core unlimited
# 进程数据段大小：不限制，避免大内存场景受限
dmdba soft data unlimited
dmdba hard data unlimited
何为 soft / hard？
soft是当前生效值；hard是绝对上限。两者通常设为相同值，避免程序读取 soft 值后误判可用资源。
5.2 使配置生效
/etc/security/limits.conf 的修改需要重新登录才会生效（重启亦等效）。这是官方强调、但现场极易踩坑的一点。
# 切换到 dmdba 用户（会重新加载 PAM 限制）
[root]# su - dmdba
[dmdba]$ ulimit -a
实测结果（配置已生效）：
open files (-n) 65536
max user processes (-u) 65536
max memory size (-m) unlimited
virtual memory (-v) unlimited
实测输出（在 192.168.3.22 上以 su - dmdba -c 'ulimit -n; ulimit -u' 复核，与配置值一致）：
--- 验证 dmdba 实际生效值 (期望 65536 / 65536) --- 65536 65536
⚠️ 提示：若实测值与上表不一致，请排查多产品覆盖问题，方法见 5.3 节
在混布其他数据库软件的机器上曾观察到：
dmdba的实际ulimit -n / -u为 655360；而/etc/security/limits.conf中该用户的配置行已被清空（仅剩注释文字，赋值行全部消失），真实生效值来自其他软件写入的limits.d/*.conf——它用*通配对所有用户设定了 655360，覆盖了limits.conf中针对dmdba的 65536。这不是命令写错，而是多产品共存环境的典型现象。
常见误区：在 root 会话中执行
su dmdba（不带-）不会重新加载限制，必须用su - dmdba或直接 SSH 登录。若验证不达标，请完全退出会话后重新登录。
5.3 limits 生效顺序与多产品共存冲突（重要）
PAM 的加载顺序决定最终取值。 CentOS 7 的 pam_limits 模块按以下顺序读取配置：
- 先读
/etc/security/limits.conf； - 再按文件名字母序读取
/etc/security/limits.d/*.conf； - 对同一个用户的同一个限制项，后读取的值覆盖先读取的值。
由此产生两个实践中极易踩坑的结论：
| 现象 | 原因 | 处置 |
|---|---|---|
limits.conf 明明配了 65536，ulimit -n 却是别的值 |
同目录其他 limits.d/*.conf 以 * 通配（或同名用户）覆盖了它，且文件名字母序在后 |
用下方"三步定位法"找出真正生效的文件 |
| 同机装了另一款数据库软件后，DM 的限制被改掉 | 该软件的部署脚本可能清空或覆盖了 limits.conf 中的 DM 配置段 |
部署后用 ulimit 实测复核，不要只看配置文件是否写对 |
三步定位法：
# 1) 看当前用户实际生效值（以 dmdba 为例）
[root]# su - dmdba -c 'ulimit -n; ulimit -u'
# 2) 列出所有可能影响该用户的配置文件（含通配 *）
[root]# grep -rn 'dmdba\|^\*' /etc/security/limits.conf /etc/security/limits.d/
# 3) 检查是否存在被清空/备份的痕迹
[root]# tail -20 /etc/security/limits.conf # 若只剩注释、无赋值行，说明配置已被改动过
[root]# ls -l /etc/security/limits.conf*
曾在混布环境复核时观察到的现象（本次部署的 192.168.3.22 为干净服务器，未出现）：DM9 在
limits.conf中的配置段被清空，实际生效值由oceanbase_limits.conf的* 655360提供（比 DM9 所需的 65536 更宽松，功能上无碍）。但这属于被动生效——一旦那款软件被卸载或清理，DM9 的限制会同时消失，届时可能出现"连接数上不去、归档写入失败"等隐蔽故障。稳妥做法：把 DM9 的限制写入优先级更高的专属文件（字母序靠后、且针对具体用户而非
*），例如创建/etc/security/limits.d/zz-dm.conf，内容即 5.1 节的配置项，然后实测复核：[root]# vi /etc/security/limits.d/zz-dm.conf # 粘贴 5.1 节配置 [root]# su - dmdba -c 'ulimit -n; ulimit -u' # 期望：65536 / 65536
5.4 临时调整（仅用于验证）
[dmdba]$ ulimit -n 65536 # 文件描述符
[dmdba]$ ulimit -u 65536 # 进程数
重要：临时设置仅对当前会话有效，会话结束即失效。生产环境务必使用永久方式。
第 6 章 数据库软件安装
6.1 上传安装介质并校验完整性
[root]# ls -lh /root/soft/dm9_20260514_x86_centos7_64.zip
# 实测：986M
[root]# cd /root/soft
[root]# unzip dm9_20260514_x86_centos7_64.zip
# 解压后得到：
# dm9_20260514_x86_centos7_64.iso （1003M，安装镜像）
# dm9_20260514_x86_centos7_64.iso_SHA256.txt （校验文件）
# dm9_20260514_x86_centos7_64_ent_9.1.0.26.README （构建基线说明）
校验 ISO 的 SHA256，与随包提供的校验文件逐字符比对：
[root]# cd /root/soft
[root]# sha256sum dm9_20260514_x86_centos7_64.iso
[root]# cat dm9_20260514_x86_centos7_64.iso_SHA256.txt
本次实测结果：
实际计算值：66e909973ece7b3527b6d78210d2e5a05a1ad45b8c82a66ae03ff1b442acbe47
随包提供值：66e909973ece7b3527b6d78210d2e5a05a1ad45b8c82a66ae03ff1b442acbe47
结论：一致，介质完整
两者不一致说明介质在传输中损坏，禁止继续安装，应重新下载。
6.2 挂载安装镜像
# 创建挂载点
[root]# mkdir -p /mnt/dm9iso
# 以只读方式挂载 ISO
[root]# mount -o loop /root/soft/dm9_20260514_x86_centos7_64.iso /mnt/dm9iso
# 查看内容
[root]# ls -l /mnt/dm9iso/
实测输出：
mount: /dev/loop0 is write-protected, mounting read-only --- 挂载内容 --- total 1026317 -r-xr-xr-x 1 root root 4250937 Apr 3 10:24 DM9-Install Manual.pdf -r-xr-xr-x 1 root root 1046697406 May 14 14:42 DMInstall.bin
ISO 内包含两个文件：
| 文件 | 大小（实测） | 说明 |
|---|---|---|
DMInstall.bin |
999 MB | 数据库安装程序 |
DM9-Install Manual.pdf |
4.1 MB | 安装手册 |
 |
安装结束后需卸载镜像（见 6.5 节）。
6.3 命令行安装软件
DM9 支持两种命令行安装方式。官方文档仅介绍 -i 交互式，本指南同时给出更规范的 -s 静默安装方式。
先查看安装器支持的完整参数（权威依据，建议部署前执行）：
[dmdba]$ cd /mnt/dm9iso
[dmdba]$ ./DMInstall.bin -h
实测输出：
Usage:
./DMInstall.bin [Option]
Options:
--cli,-i Run in command-line mode.
--silent,-s <path> Use specified config file and run in silent mode.
--split Split the current .bin into a .sh and a .tar.gz in the current directory.
--help,-help,-h,help Show this help message.
Environment:
DM_JAVA_HOME Use a Java Home outside the installer; if unset, use the bundled JDK.
DM_INSTALL_TMPDIR Use specified temporary extraction directory; if unset, use the system temp directory.
三个官方支持但文档常被忽略的实用点：
DM_INSTALL_TMPDIR：安装器默认解压到系统/tmp，若根分区空间紧张（/tmp通常很小时），务必显式指定到数据盘，否则会在解压阶段失败且报错不直观：[dmdba]$ DM_INSTALL_TMPDIR=/dmdata/tmp ./DMInstall.bin -i--split：可将.bin拆为.sh+.tar.gz，便于分片传输或在无执行权限环境（如部分共享存储）下解包安装；DM_JAVA_HOME：如需用外部 JDK 替代安装器自带 JDK（约 300 MB），可指定该变量。
方式一：交互式安装（官方方式，适合单次手工部署）
[root]# su - dmdba
[dmdba]$ cd /mnt/dm9iso
[dmdba]$ ./DMInstall.bin -i
DM9 交互式安装的真实流程（实测确认，仅 3 步交互）：
Continue?[Y/n]: ← 步骤0：检测到已有其他 DM 安装时才会出现
Welcome to DM9 Installation Tool
Enter [exit] to exit the program
1) Read
2) Agree and continue
3) Disagree and exit
Please enter an option[2]: ← 步骤1：许可协议
-- Settings --
Select components to install (multiple selection, comma-separated):
1) Server
2) Client Tools
Please enter an option[1,2]: ← 步骤2：选择安装组件
Required Disk Space: 1.48GB
Specify Installation Directory[/home/dmdba/dmdbms]: ← 步骤3：指定安装目录
| 步骤 | 提示内容 | 建议输入 | 说明 |
|---|---|---|---|
| 0 | Continue?[Y/n] |
y |
仅当系统已存在其他 DM 安装时出现，提示继续操作可能影响现有实例 |
| 1 | 许可协议 | 2 |
1=阅读协议，2=同意并继续（默认），3=不同意退出。必须选 2 才能继续 |
| 2 | 选择安装组件 | 1 |
1=Server（服务器）、2=Client Tools（客户端工具），可逗号分隔多选；仅装服务端填 1 |
| 3 | 指定安装目录 | 回车或自定义 | 默认 /home/dmdba/dmdbms；自定义路径必须以 / 开头，且不能含 #、\ 等字符，且当前用户须有写权限 |
⚠️ 与 DM8 的重大流程差异（易踩坑）
DM8 的交互式安装需要依次回答"语言 → Key 文件 → 时区 → 安装类型 → 安装路径"共 5 项，而 DM9 已大幅精简为 3 项（许可协议 → 组件 → 路径），语言与 Key 均改为通过安装包内置或 XML 配置处理。
若沿用 DM8 的操作经验、按旧顺序喂入答案，会在第一步就把 “1” 当成语言选择从而导致协议环节输入非法、安装中断。
安装目录校验规则（实测）：输入非法路径时安装器会明确报错——
The input path is invalid. It must start with '/', and the directory name cannot contain any of the following characters: # \ No write permission, please select a correct path.排错时按此提示逐条核对即可。
方式二：静默安装（本指南推荐，适合批量自动化）
DM9 的安装器支持通过 XML 配置文件静默安装，可完全无人值守。
配置文件的 XML 结构（经实测确认，根元素为 DATABASE）：
[root]# cat > /tmp/dm_silent.xml << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<DATABASE>
<!-- 安装语言：zh_CN 中文 / en 英文 -->
<LANGUAGE>zh_CN</LANGUAGE>
<!-- Key 文件绝对路径；无 License 时留空即可 -->
<KEY></KEY>
<!-- 安装组件：1=Server(服务器)，2=Client Tools(客户端工具)，多个用逗号分隔，如 1,2 -->
<COMPONENTS>1</COMPONENTS>
<!-- 安装目录 -->
<INSTALL_PATH>/home/dmdba/dmdbms</INSTALL_PATH>
</DATABASE>
EOF
chmod 644 /tmp/dm_silent.xml
COMPONENTS取值说明（与交互式安装的选项一一对应，实测确认）：
值 组件 对应交互式菜单 安装后新增内容 1Server（服务器端） 1) Serverbin（dmserver/dminit/disql 等核心程序）2Client Tools（客户端工具） 2) Client Toolstool（manager/dbca/dts 等图形化工具）验证方法：仅选
1时，安装目录下不含tool子目录（本次实测即如此）；若同时需要图形化管理工具，须填1,2。生产服务器通常只装1以减小体积、收敛攻击面。
执行静默安装：
[root]# su - dmdba -c "cd /mnt/dm9iso && ./DMInstall.bin -s /tmp/dm_silent.xml"
安装成功输出（实测）：
Extracting package...
Hardware architecture check passed!
GLIBC VERSION check passed!
欢迎使用 DM9 安装工具
-- 安装小结
产品名称: 达梦数据库V9
安装目录: /home/dmdba/dmdbms
安装内容: 服务器
所需磁盘空间: 1.48GB
可用磁盘空间: 59.09GB
可用内存: 14.75GB
-- 安装中
[*] 正在初始化安装日志...
[✓] 初始化安装日志完成
[*] 正在拷贝文件...
[✓] 拷贝文件完成
[*] 正在修改文件...
[✓] 修改文件完成
[*] 正在修改环境变量...
[✓] 修改环境变量完成
[*] 正在安装服务...
[✓] 安装服务完成
[*] 正在配置...
[✓] 配置完成
-- 安装总结
达梦数据库DM9安装完成
请以root用户执行脚本: /home/dmdba/dmdbms/script/root/root_installer.sh
安装日志位于 /home/dmdba/dmdbms/log/，包含 install.log、install_detail.log，排查安装问题时优先查看。
两种方式对比
-i交互式-s静默适用场景 单次手工部署 批量、自动化、CI/CD 人工干预 需交互 3 项（协议/组件/路径） 零干预 可重复性 易因手误选错 配置即文档，结果确定 键名大小写 — 必须全大写，小写会导致静默失败
6.4 执行 root 配置脚本
安装完成后以 root 执行安装程序提示的脚本，创建达梦辅助服务：
[root]# cd /home/dmdba/dmdbms/script/root
[root]# ./root_installer.sh
实测输出（DM9 与 DM8 的重要差异）：
移动 /home/dmdba/dmdbms/dm_svc.conf 到/etc目录
创建DmAuditMonitorService服务
创建服务(DmAuditMonitorService)完成
创建DmJobMonitorService服务
创建服务(DmJobMonitorService)完成
创建DmInstanceMonitorService服务
创建服务(DmInstanceMonitorService)完成
创建DmAPService服务
Created symlink from /etc/systemd/system/multi-user.target.wants/DmAPService.service to /usr/lib/systemd/system/DmAPService.service.
创建服务(DmAPService)完成
启动DmAPService服务
安装程序额外注册了 3 个监控服务（官方《Linux 服务脚本使用手册》1.1 节把它们归为"第一类服务脚本"——位于
bin/目录、模板名不可修改；1.3.2～1.3.4 节记载了各自的参数）：
服务 二进制 用途 DmInstanceMonitorServicedmimon实例实时监控 DmAuditMonitorServicedmamon实时审计监控 DmJobMonitorServicedmjmon实时作业监控 三者默认已注册、未启用。⚠️ 不要直接
enable --now：官方手册 1.3 节明确写着"用户在使用这些服务脚本前，需要先手动修改服务脚本的参数"，其中审计/作业监控服务必须填USER_ID（数据库连接串）等参数才能启动，否则会以status=1失败（实例监控服务无需配参，故能正常起来）。详见 9.4 节。
验证：
[root]# systemctl status DmAPService --no-pager
# 期望：active (running)，主进程为 dmap
实测输出：
● DmAPService.service - DM Assistant Plug-In Service(DmAPService). Loaded: loaded (/usr/lib/systemd/system/DmAPService.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2026-09-21 09:04:36 CST Process: 22326 ExecStart=/home/dmdba/dmdbms/bin/DmAPService start (code=exited, status=0/SUCCESS) Main PID: 22351 (dmap) CGroup: /system.slice/DmAPService.service └─22351 /home/dmdba/dmdbms/bin/dmap dmap_ini=/home/dmdba/dmdbms/bin/dmap.ini
为何必须执行此脚本？
DmAPService是达梦的辅助进程守护服务，负责备份、还原、归档管理等依赖外部进程的操作。不执行该脚本时，数据库可正常启停与读写，但备份相关功能会异常，属于典型的"功能残缺而不报错"隐患，上线前务必确认该服务已注册。
6.5 卸载安装镜像
[root]# umount /mnt/dm9iso
[root]# ls /mnt/dm9iso # 应为空
第 7 章 环境变量配置
DM9 安装时已自动写入 DM_HOME 与 PATH，但仍建议显式检查并补齐，确保 disql、dminit 等命令可全局调用。
7.1 检查环境变量文件
[root]# grep -E 'DM_HOME|PATH' /home/dmdba/.bash_profile
实测安装后自动写入的内容：
export DM_HOME="/home/dmdba/dmdbms" && export PATH="$PATH:$DM_HOME/bin"
注意：DM9 自动写入的是
$DM_HOME/bin，未包含$DM_HOME/tool。若需使用图形化工具（dbca、manager等），需手动补齐。
7.2 补齐并生效
[root]# vi /home/dmdba/.bash_profile
确保包含（已存在则保留，缺失则补充）：
# ---------- DM9 环境变量 ----------
export DM_HOME=/home/dmdba/dmdbms
# 可执行文件目录（必需）
export PATH=$PATH:$DM_HOME/bin
# 工具目录（使用图形化工具时需要）
export PATH=$PATH:$DM_HOME/tool
# 达梦动态链接库路径
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DM_HOME/bin
[root]# su - dmdba
[dmdba]$ source ~/.bash_profile
[dmdba]$ echo $DM_HOME
[dmdba]$ which dminit disql
实测输出（环境变量已生效，dminit/disql 均可全局调用）：
===== 7.1 当前 .bash_profile 中 DM 相关行 ===== export DM_HOME="/home/dmdba/dmdbms" && export PATH="$PATH:$DM_HOME/bin" ===== 7.2 补齐环境变量 ===== --- 生效并验证 --- DM_HOME=/home/dmdba/dmdbms /home/dmdba/dmdbms/bin/dminit /home/dmdba/dmdbms/bin/disql LD_LIBRARY_PATH=:/home/dmdba/dmdbms/bin
第 8 章 初始化数据库实例
软件安装完成后仅具备可执行程序，必须初始化实例才能创建可用的数据库。
8.1 不可修改参数说明（重中之重）
以下六项参数在实例初始化完成后永久不可修改，任何一项选错都只能删除实例重建：
| 参数 | 含义 | 取值范围 | 本指南取值 | 选错后果 |
|---|---|---|---|---|
PAGE_SIZE |
数据页大小 | 4/8/16/32（KB），默认 8 | 16 | 页越小单行上限越低，大字段场景易报"记录超长" |
EXTENT_SIZE |
簇大小（每次分配连续页数） | 16/32/64（页），默认 16 | 32 | 影响空间分配粒度，大表场景簇太小产生碎片 |
CASE_SENSITIVE |
标识符大小写敏感 | Y/N，默认 Y | Y | 不敏感模式下小写标识符也等价大写，影响迁移兼容 |
CHARSET |
字符集 | 0=GB18030，1=UTF-8，2=EUC-KR，默认 0 | 1（UTF-8） | 字符集不匹配导致中文乱码，且无法转换 |
BLANK_PAD_MODE |
字符串尾部空格填充模式 | 1=兼容，0=不兼容，默认 0 | 1 | 影响定长字符串比较结果，迁移场景须对齐 |
PAGE_CHECK |
页校验模式 | 0=禁用，1=CRC，2=HASH，3=快速CRC，默认 3 | 1（CRC） | 关校验无法在读取时发现页损坏，风险极高 |
选型依据（务必理解，而非照抄）
PAGE_SIZE=16：为支持大字段（CLOB/BLOB）、宽表与大行数据预留空间，生产常用配置。默认 8 KB 在部分业务场景会出现单行超长报错。EXTENT_SIZE=32：与 16 KB 页配合，单簇 512 KB，减少大表空间分配次数；CHARSET=1（UTF-8）：通用性最佳，避免多语言字符集转换问题；PAGE_CHECK=1：开启 CRC 校验，可在读取脏页时第一时间发现存储损坏，生产环境稳妥选择。默认 3（快速 CRC）极端情况下校验强度弱于标准 CRC；BLANK_PAD_MODE=1：采用兼容空格填充语义，使字符串比较行为与主流商业数据库的定长字符串语义一致，便于存量系统迁移。
8.2 兼容模式设置（迁移场景必读）
COMPATIBLE_MODE 控制数据库对其他数据库语法的兼容程度，可在实例初始化后通过 dm.ini 修改，但会改变数据存储与运算行为，生产环境修改须慎重评估。
| 取值 | 兼容的目标语法风格 | dm.ini 中的官方描述 |
|---|---|---|
| 0 | 不兼容（默认） | none |
| 1 | SQL92 标准 | SQL92 |
| 2 | 存量商业数据库语法（迁移常用） | Oracle |
| 3 | 微软 SQL Server 语法 | MS SQL Server |
| 4 | MySQL 语法 | MySQL |
| 5 | DM6 语法 | DM6 |
| 6 | Teradata 语法 | Teradata |
| 7 | PostgreSQL 语法 | PG |
| 8 | DB2 语法 | DB2 |
本指南按兼容模式 2 部署（适用于存量商业数据库向达梦迁移的场景）：
[dmdba]$ vi /dmdata/data/DMDB/dm.ini
COMPATIBLE_MODE = 2
修改后需重启数据库生效。初始化时另一项 BLANK_PAD_MODE=1 与本模式配合使用。
合规提示（重要）
以上兼容目标的官方描述取自dm.ini参数注释。本指南为保持技术中立，在正文中以功能性描述为主；如需取得与具体产品的精确对应关系，请以达梦官方《DM9_dminit 使用手册》为准，切勿凭经验猜测。
8.3 确认实例目录权限
[root]# ls -ld /dmdata/data
# 期望：drwxr-xr-x. N dmdba dinstall ... /dmdata/data
实测输出（并确认全新环境下 DMDB 子目录尚不存在，可安全初始化）：
===== 8.3 实例目录权限 ===== drwxr-xr-x 3 dmdba dinstall 4096 Sep 21 08:40 /dmdata/data --- 确认 DMDB 子目录不存在(全新初始化) --- ls: cannot access /dmdata/data/DMDB: No such file or directory DMDB 不存在，可初始化
8.4 查看 dminit 可用参数
[root]# su - dmdba
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./dminit help
DM9 的 dminit 相对 DM8 新增了若干参数，重点包括：
| 新增参数 | 说明 | 默认值 |
|---|---|---|
AUTO_ADJ_PARA |
是否开启 INI 参数自动调优 | 1（开启） |
AUTO_ADJ_CPUS |
自动调优时指定可用 CPU 核数，0 为使用全部 | 0 |
AUTO_ADJ_MEM |
自动调优时指定可用内存（MB），0 为使用机器 80% 内存 | 0 |
LOG_SIZE |
日志文件大小，范围 256M~8G | 4096（4G） |
PAGE_CHKSUM_POLICY |
是否对每个 4K 数据块生成校验码 | 1 |
重要差异：DM9 的
LOG_SIZE默认值为 4096 MB（4 GB），而 DM8 为 256 MB。实测初始化后生成两个 4 GB 的重做日志文件（共 8 GB）。小容量测试环境务必显式指定更小的LOG_SIZE，否则日志文件会占据可观的磁盘空间。
8.5 执行实例初始化
按 8.1 节参数规划执行（所有参数一次写全，避免遗漏）。
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./dminit PATH=/dmdata/data DB_NAME=DMDB INSTANCE_NAME=DMSERVER PORT_NUM=5236 \
PAGE_SIZE=16 EXTENT_SIZE=32 CASE_SENSITIVE=Y CHARSET=1 BLANK_PAD_MODE=1 PAGE_CHECK=1 \
SYSDBA_PWD='Dm9@SysDba#2026' SYSAUDITOR_PWD='Dm9@Audit#2026'
参数逐项说明：
| 参数 | 作用 |
|---|---|
PATH |
实例文件存放根目录，达梦会在其下创建以 DB_NAME 命名的子目录 |
DB_NAME |
数据库名，长度不超过 16 字符 |
INSTANCE_NAME |
实例名，与数据库名可不同 |
PORT_NUM |
监听端口，默认 5236，多实例部署时需区分 |
SYSDBA_PWD |
内置 DBA 用户 SYSDBA 的密码 |
SYSAUDITOR_PWD |
内置审计员 SYSAUDITOR 的密码 |
口令规范要求
生产环境密码必须满足复杂度要求：长度 9~48 位，且至少包含大写字母、小写字母、数字、特殊字符中的三类（安全版要求四类）。示例密码仅用于测试，切勿在生产环境使用文档示例密码。请通过合规的密码管理系统生成与保管。实务提醒（血泪教训）：当通过脚本、跳板机、多层 shell 传递含特殊字符（
@ # $ ! *）的密码时，极易被 shell 转义改写，导致后续连接报[-2501] 用户名或密码错误。强烈建议把 dminit 命令写入脚本文件后执行，不要让密码经过多层引号传递。
初始化成功输出（实测）：
dminit V9
db version: 0x7000d
file dm.key not found, use default license!
License will expire on 2027-04-17
version: 03151060506-20260417-322930-20218
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
log file path: /dmdata/data/DMDB/DMDB01.log
log file path: /dmdata/data/DMDB/DMDB02.log
write to dir [/dmdata/data/DMDB].
create dm database success. 2026-09-21 09:09:44
8.6 验证实例文件生成
[dmdba]$ ls -l /dmdata/data/DMDB/
实测输出（dminit 生成的第一批文件，时间戳均为 09:09）：
===== 8.6 验证实例文件(dminit 第一批) ===== drwxr-xr-x 2 dmdba dinstall 4096 Sep 21 09:09 bak drwxr-xr-x 2 dmdba dinstall 4096 Sep 21 09:09 ctl_bak -rw-r--r-- 1 dmdba dinstall 5632 Sep 21 09:09 dm.ctl -rw-r--r-- 1 dmdba dinstall 4294967296 Sep 21 09:09 DMDB01.log -rw-r--r-- 1 dmdba dinstall 4294967296 Sep 21 09:09 DMDB02.log -rw-r--r-- 1 dmdba dinstall 92671 Sep 21 09:09 dm.ini -rw-r--r-- 1 dmdba dinstall 633 Sep 21 09:09 dm_service.prikey -rw-r--r-- 1 dmdba dinstall 4096 Sep 21 09:09 HMAIN -rw-r--r-- 1 dmdba dinstall 134217728 Sep 21 09:09 MAIN.DBF -rw-r--r-- 1 dmdba dinstall 134217728 Sep 21 09:09 ROLL.DBF -rw-r--r-- 1 dmdba dinstall 805 Sep 21 09:09 sqllog.ini -rw-r--r-- 1 dmdba dinstall 67108864 Sep 21 09:09 SYSTEM.DBF
关键认知：实例文件分三个时机生成——dminit 只生成第一批，第二批到数据库首次启动时才产生，第三批（SYSAWR.DBF）则要等到实例运行中才创建。 仅执行完 dminit 就去核对文件清单，会误判"缺文件"。本次实测的时间戳可清晰印证这一机制：
| 文件 | 生成时机 | 实测大小 | 说明 |
|---|---|---|---|
dm.ini |
dminit |
91 KB | 实例核心参数文件 |
dm.ctl |
dminit |
5.5 KB | 控制文件，记录物理结构 |
dm_service.prikey |
dminit |
633 B | 服务密钥 |
sqllog.ini |
dminit |
805 B | SQL 日志配置 |
MAIN.DBF |
dminit |
128 MB | 主表空间，存放用户数据 |
ROLL.DBF |
dminit |
128 MB | 回滚表空间 |
SYSTEM.DBF |
dminit（64 MB）→ 首次启动扩至 128 MB → 运行中持续增长 |
192 MB | 系统表空间，存放数据字典；随字典项积累而增长，不是固定值 |
DMDB01.log |
dminit |
4 GB | 重做日志 1（DM9 默认 4G，见 8.4 节提示） |
DMDB02.log |
dminit |
4 GB | 重做日志 2 |
dmtemp.ctl |
首次启动 | 3 KB | 临时控制文件 |
TEMP.DBF |
首次启动 | 64 MB | 临时表空间 |
dm.ini.dmbak |
修改 dm.ini 时 | 91 KB | 参数文件的自动备份（每次改动 dm.ini 自动留存上一版） |
SYSAWR.DBF |
执行 SP_INIT_AWR_SYS(1) 初始化 AWR 时 |
5 GB | SYSAUX 表空间的数据文件（AWR 性能仓库）；dminit 不生成、首次启动也不自动生成，仅在显式初始化 AWR 后出现；容量规划须按是否启用 AWR 分别计算 |
bak/ ctl_bak/ HMAIN/ trace/ |
dminit |
— | 备份、控制文件备份、HUGE 表、跟踪日志目录 |
为什么先核对文件会"缺东西"？ 实测时间线：
dminit完成于13:10:14，此后dmtemp.ctl生成于13:10:51、TEMP.DBF于13:11:20——均晚于初始化，属于首次拉起实例时的运行时产物。因此第 8 章的核对重点是确认第一批文件（dm.ini/dm.ctl/*.DBF/*.log）齐全；dmtemp.ctl、TEMP.DBF留到第 10 章启动数据库后再核对更准确。
SYSAWR.DBF是一份"迟到的文件"，请务必留意它既不在
dminit生成的清单里（dminit日志只打印SYSTEM.DBF/MAIN.DBF/ROLL.DBF），也不是数据库首次启动时出现的。本次实测它由一次 AWR 初始化操作创建——CALL SP_INIT_AWR_SYS(1)（实测SF_CHECK_AWR_SYS返回1，AWR 确已启用），运行日志留下了完整证据链：2026-09-14 14:26:35.796 [INFO] database ... backup control file dm.ctl to .../ctl_bak/dm_20260914142635_796067.ctl succeed 2026-09-14 14:26:35.796 [INFO] database ... ctl_add_table_space_ex_low.lst_table_spaces add, TS_name[SYSAUX]TS_id=5 2026-09-14 14:26:35.797 [INFO] database ... ifun_add_file_low initialize file[0] of ts[5], file_path[/dmdata/data/DMDB/SYSAWR.DBF]!可见达梦在创建该表空间前先自动备份了控制文件，再落盘数据文件——工程做法稳妥。
对容量规划的意义：这 5 GB 不是强制开销。若启用 AWR（生产环境建议启用，便于事后性能回溯），实例基线约 13.5 GB；若不启用 AWR，则约 8.5 GB。请按实际决策计入容量（见第 1 章与附录 D）。
SYSTEM.DBF会持续"长大"：dminit后为 64 MB，首次启动后扩展到 128 MB，本次持续运行 2 天后实测已达 192 MB。这是数据字典正常膨胀所致，不是异常。容量规划建议按"预留 256 MB 以上并纳入增长监控"处理，而不是当作固定 128 MB。
注意表空间初始大小随页大小变化：本次
PAGE_SIZE=16，故 SYSTEM/ROLL/MAIN 的初始稳定大小为 128 MB、TEMP 为 64 MB。如选用 8 KB 页，对应初始大小会减半（SYSTEM/ROLL/MAIN 各 64 MB、TEMP 32 MB）。规划磁盘时请按实际页大小折算（TOTAL_SIZE（页数）×PAGE_SIZE即得字节数）。
第二批文件（数据库首次启动后生成，实测）：
===== 8.6/11 首次启动后实例目录核对 ===== -rw-r--r-- 1 dmdba dinstall 4294967296 Sep 21 09:15 DMDB01.log -rw-r--r-- 1 dmdba dinstall 4294967296 Sep 21 09:15 DMDB02.log -rw-r--r-- 1 dmdba dinstall 3072 Sep 21 09:15 dmtemp.ctl -rw-r--r-- 1 dmdba dinstall 134217728 Sep 21 09:15 SYSTEM.DBF -rw-r--r-- 1 dmdba dinstall 67108864 Sep 21 09:15 TEMP.DBF --- SYSTEM.DBF 大小(期望已扩至128MB=134217728) --- /dmdata/data/DMDB/SYSTEM.DBF 134217728 --- dmtemp.ctl/TEMP.DBF 是否存在(第二批文件) --- -rw-r--r-- 1 dmdba dinstall 3072 Sep 21 09:15 /dmdata/data/DMDB/dmtemp.ctl -rw-r--r-- 1 dmdba dinstall 67108864 Sep 21 09:15 /dmdata/data/DMDB/TEMP.DBF
8.7 核心配置文件内容与参数解读
达梦实例由三个配置文件共同驱动，部署后应逐一核对。掌握这三个文件的内容与参数含义，是后续调优、排障与备份恢复的前提。
8.7.1 dm.ini —— 实例核心参数文件
dm.ini 位于实例目录（/dmdata/data/DMDB/dm.ini），是唯一必须存在的配置文件，实例启动时以其为入口加载全部参数。
格式规范（实测确认）：参数行以两个 Tab 缩进开头，行尾以 # 跟随英文注释——这正是 grep '^PORT_NUM' 匹配不到、必须写 grep -E '^[[:space:]]*PORT_NUM' 的原因。
部署完成后必须核对的关键参数（实测值）：
# ---------- 路径段：所有路径均指向实例目录 ----------
CTL_PATH = /dmdata/data/DMDB/dm.ctl #控制文件路径
CTL_BAK_PATH = /dmdata/data/DMDB/ctl_bak #控制文件备份目录
SYSTEM_PATH = /dmdata/data/DMDB #系统文件路径
CONFIG_PATH = /dmdata/data/DMDB #配置文件路径
TEMP_PATH = /dmdata/data/DMDB #临时文件路径
BAK_PATH = /dmdata/data/DMDB/bak #备份文件路径
BCT_PATH = /dmdata/data/DMDB #BCT 文件路径
# ---------- 实例标识 ----------
INSTANCE_NAME = DMSERVER #实例名
# ---------- 内存段（重点调优对象） ----------
MAX_OS_MEMORY = 100 #达梦可占用的物理内存百分比上限（100=不额外限制）
MEMORY_POOL = 800 #内存池大小（MB）
MEMORY_EXTENT_SIZE = 32 #内存扩展片大小（MB）
BUFFER = 5000 #系统数据缓冲区（MB），最核心的性能参数
BUFFER_POOLS = 17 #缓冲区分区数，建议为 CPU 核数的 4 倍左右
SORT_BUF_SIZE = 10 #排序缓冲区（MB）
HJ_BUF_SIZE = 100 #单次哈希连接缓冲区（MB）
MTAB_MEM_SIZE = 8 #内存表大小（KB）
DICT_BUF_SIZE = 128 #字典缓冲区（MB）
HFS_CACHE_SIZE = 160 #HUGE 表插入/更新/删除缓存（MB）
# ---------- 会话与端口 ----------
MAX_SESSIONS = 200 #最大并发会话数，需与 limits.conf 联动
PORT_NUM = 5236 #监听端口
# ---------- 兼容性（迁移场景重点） ----------
COMPATIBLE_MODE = 2 #兼容模式：0=无 1=SQL92 2=Oracle 3=SQL Server 4=MySQL 8=DB2
CASE_COMPATIBLE_MODE = 1 #大小写兼容：1=Oracle 简单大小写规则
NUMBER_MODE = 0 #NUMBER 类型模式：0=达梦 1=Oracle
# ---------- 归档开关（本步保持 dminit 默认 0；第 12 章 12.2 节改为 1） ----------
ARCH_INI = 0 #是否启用归档配置文件 dmarch.ini
实测核对输出（grep -E '^[[:space:]]*参数名' 逐项比对）：
===== 8.7.1 dm.ini 关键参数核对(文档值比对) ===== CTL_PATH = /dmdata/data/DMDB/dm.ctl CTL_BAK_PATH = /dmdata/data/DMDB/ctl_bak SYSTEM_PATH = /dmdata/data/DMDB CONFIG_PATH = /dmdata/data/DMDB TEMP_PATH = /dmdata/data/DMDB BAK_PATH = /dmdata/data/DMDB/bak INSTANCE_NAME = DMSERVER MAX_OS_MEMORY = 100 MEMORY_POOL = 800 --- 改后核对(期望 2) --- COMPATIBLE_MODE = 2 #0:none, 1:SQL92, 2:Oracle, 3:MS SQL Server, 4:MySQL, 8:DB2
参数分组解读：
| 分组 | 关键参数 | 部署要点 |
|---|---|---|
| 路径 | *_PATH |
由 dminit PATH= 推导得出，默认全部落在实例目录。若需将备份/临时文件分离到独立卷，改此处并把卷权限交给 dmdba |
| 内存 | MAX_OS_MEMORY、BUFFER、MEMORY_POOL |
BUFFER 是命中率与性能的核心，生产建议设为物理内存的 50%~70%；本机 16 GB，BUFFER=5000（约 5 GB）为保守值 |
| 会话 | MAX_SESSIONS |
逐会话占用内存，须与 limits.conf 的 nofile/nproc 匹配；应用连接数上限应按此设防 |
| 兼容 | COMPATIBLE_MODE |
本次设为 2（兼容存量商业数据库语法），这是存量商业数据库迁移场景最常见的选择；注意 COMPATIBLE_MODE 与 dminit 无关，只能在 dm.ini 中设置（详见 8.2 节） |
| 归档 | ARCH_INI |
默认 0（关闭）。不开归档无法在线备份，第 12 章将其置为 1 |
修改 dm.ini 的安全规范：
- 大部分内存类参数需重启实例生效（少数动态参数可在线调整，但重启最稳妥）；
- dm.ini 每次被修改，达梦会自动留存
dm.ini.dmbak（上一版快照），这是官方自带的安全网，误改后可据此回退；- 改前先备份：
cp dm.ini dm.ini.$(date +%Y%m%d)，改动需走变更审批与灰度。
8.7.2 dmarch.ini —— 归档配置文件
dmarch.ini 与 dm.ini 同目录，仅在 dm.ini 中 ARCH_INI=1 时才被加载。它是开启归档、支撑在线备份的开关文件，创建方法与内容见第 12.2 节。完整内容如下：
# ---------- 归档配置 ----------
[ARCHIVE_LOCAL1]
# 归档类型：LOCAL 为本地归档
ARCH_TYPE = LOCAL
# 归档日志存放路径（指向独立的归档卷）
ARCH_DEST = /dmdata/arch
# 单个归档文件大小上限（MB）
ARCH_FILE_SIZE = 1024
# 归档空间上限（MB），0 表示不限制
ARCH_SPACE_LIMIT = 0
| 参数 | 取值 | 说明 |
|---|---|---|
[ARCHIVE_LOCAL1] |
段名 | 本地归档实例名，可定义多个段实现多路归档 |
ARCH_TYPE |
LOCAL |
归档类型，本地归档固定为 LOCAL；远程实时归档用 REALTIME |
ARCH_DEST |
/dmdata/arch |
归档日志落盘路径，指向独立归档卷，避免与数据文件争抢 I/O |
ARCH_FILE_SIZE |
1024 |
单个归档文件大小上限（MB），写满即切换新文件 |
ARCH_SPACE_LIMIT |
0 |
归档目录空间上限（MB），0 为不限制。生产建议显式设值（如 102400 即 100 GB），防止归档撑满磁盘导致数据库挂起 |
文件权限要求：
dmarch.ini由数据库进程读取，属主必须为dmdba:dinstall；权限建议按最小权限原则收窄为600（本次实测644亦可被正常读取并生效，但用 root 身份创建会留下root:root属主，属不规范做法——务必以dmdba身份创建，或事后chown dmdba:dinstall）。
8.7.3 sqllog.ini —— SQL 日志配置文件
sqllog.ini 与 dm.ini 同目录，由 dminit 自动生成，用于定义 SQL 日志的记录规则与滚动策略。默认内容如下：
BUF_TOTAL_SIZE = 10240 #SQL 日志缓冲区总大小（KB），范围 1024~1024000
BUF_SIZE = 1024 #单个 SQL 日志缓冲区大小（KB），范围 50~102400
BUF_KEEP_CNT = 6 #缓冲区保留个数（1~100）
PARAMS_DELAY = 0 #参数数据是否延迟上报（0~2）
[SLOG_ALL] #全部 SQL 日志段
FILE_PATH = ../log #日志文件路径（相对实例目录）
PART_STOR = 0 #是否分区存储
SWITCH_MODE = 2 #日志切换模式：2=按文件大小切换
SWITCH_LIMIT = 128 #切换阈值（MB）
ASYNC_FLUSH = 1 #异步刷盘
FILE_NUM = 5 #日志文件数量
ITEMS = 0 #记录项，0 表示按默认掩码
SQL_TRACE_MASK = 1 #SQL 跟踪掩码：1=全部语句
MIN_EXEC_TIME = 0 #最小记录执行时间（毫秒），0=不限制
USER_MODE = 0 #用户过滤模式
USERS = #指定记录的用户列表（空=不限）
EXECTIME_PREC_FLAG = 0 #执行时间精度标志
[SLOG_ERROR] #错误 SQL 日志段
SQL_TRACE_MASK = 23
FILE_PATH = ../log
[SLOG_DDL] #DDL 语句日志段
SQL_TRACE_MASK = 3
[SLOG_LONG_SQL] #慢 SQL 日志段
SQL_TRACE_MASK = 25
MIN_EXEC_TIME = 60000 #超过 60 秒的语句记入慢 SQL 日志
四个日志段的用途与调优点：
| 段名 | 记录内容 | 生产调优建议 |
|---|---|---|
[SLOG_ALL] |
全部 SQL | 默认开全量，性能敏感场景应关闭或降级（SQL_TRACE_MASK 调整），避免写日志开销拖累业务 |
[SLOG_ERROR] |
报错语句 | 建议保持开启，排障关键 |
[SLOG_DDL] |
结构变更语句 | 建议保持开启，留痕审计 |
[SLOG_LONG_SQL] |
慢 SQL（>60 秒） | 建议开启；MIN_EXEC_TIME 可按业务 SLA 调小（如 5000 即 5 秒），用于抓取性能问题 |
日志落盘位置（实测纠正，重要）
FILE_PATH = ../log的相对基准是$DM_HOME/bin（达梦可执行文件目录），而不是实例目录。因此日志实际写入$DM_HOME/log/（本环境为/home/dmdba/dmdbms/log/）。本次验证采用了受控开关的方法：将
SVR_LOG置 1 后执行若干 SQL，日志文件dmsql_<实例名>_<日期>_<时间>.log立即出现在/home/dmdba/dmdbms/log/；而/dmdata/data/DMDB/log/目录自始至终不存在。文件中记录的正是刚执行的语句（含[SEL]/[ORA]/[CAL]标记与EXECTIME、ROWCOUNT、EXEC_ID），确认无误。易踩坑：不少资料（含本指南早期版本）称该路径"相对实例目录解析"，据此去
/dmdata/data/DMDB/log/找日志会一无所获。若希望 SQL 日志与数据文件分盘存放，请在sqllog.ini中把FILE_PATH写成绝对路径（如/dmdata/arch/sqllog）。
关键前提：仅有
sqllog.ini并不会产生任何 SQL 日志
sqllog.ini只定义"按什么规则记录"，真正决定 SQL 日志开与关的是dm.ini中的SVR_LOG参数。实测本环境SVR_LOG = 0（关闭），因此sqllog.ini虽由dminit完整生成，却一条 SQL 日志也不会落盘——这正是很多用户"配置都在、就是没有日志"的根本原因。开启方式
⚠️ 前置条件：必须在实例启动之后执行。 本小节位于第 8 章，此时实例刚由
dminit创建，尚未注册为服务、也从未启动过，5236 端口没有任何监听。若在此处直接执行下面的 SQL，必然报[-70028] 创建SOCKET连接失败+DISQL-10036: 连接丢失——这不是部署失败，只是实例还没起来。请先完成第 9 章（注册服务）与第 10 章（启动实例），再回来执行（速查手册中的对应步骤编排在 10.4 节）。-- scope 取值：1=仅内存（动态生效，重启失效）；2=内存 + dm.ini（立即生效且持久）；0=仅改 dm.ini（需重启） SP_SET_PARA_VALUE(1, 'SVR_LOG', 1); -- 确认当前值 SELECT PARA_NAME, PARA_VALUE FROM V$DM_INI WHERE PARA_NAME='SVR_LOG';命令行执行提示：若用
disql -e "..."方式执行，SQL 中的$必须转义为\$（如V\$DM_INI），否则会被 Shell 当作变量展开成空串，SQL 变成FROM V而报语法错误。嫌麻烦可改用@sql文件方式。生产建议：全量 SQL 日志有写开销且增长快，不建议长期常开。推荐两种稳妥用法——① 排障窗口期临时开启、事毕即关；② 在
sqllog.ini中把[SLOG_ALL]段关掉，仅保留[SLOG_LONG_SQL]与[SLOG_ERROR]，以最小代价留住"慢 SQL"与"报错语句"。
8.7.4 三个配置文件小结
| 文件 | 是否必需 | 由谁生成 | 核心作用 | 相关章节 |
|---|---|---|---|---|
dm.ini |
必需 | dminit |
实例全部参数入口 | 8.7.1 / 12.3 |
dmarch.ini |
可选（开归档时必需） | 手工创建 | 归档配置，在线备份前置 | 12.2 |
sqllog.ini |
可选（默认自动生成） | dminit |
SQL 日志记录与滚动 | 8.7.3 |
部署收口检查：三个文件均应位于
/dmdata/data/DMDB/下、属主dmdba:dinstall。dm.ini的改动手工做，dmarch.ini手工建，sqllog.ini按需调——这里改动的都是静态配置，必须等实例启动后才谈得上"生效"：dm.ini/dmarch.ini的改动在第 10 章首次启动时被加载，此后的改动则需重启实例；并确认dm.ini.dmbak已生成（改动留痕）。
第 9 章 注册操作系统服务
实例初始化完成后，需将数据库注册为操作系统服务，才能随系统启动并支持标准启停。
9.1 注册数据库服务
使用 root 执行注册脚本：
[root]# cd /home/dmdba/dmdbms/script/root
[root]# ./dm_service_installer.sh -t dmserver -dm_ini /dmdata/data/DMDB/dm.ini -p DMDB
实测输出：
Created symlink from /etc/systemd/system/multi-user.target.wants/DmServiceDMDB.service to /usr/lib/systemd/system/DmServiceDMDB.service.
创建服务(DmServiceDMDB)完成
参数说明：
| 参数 | 含义 |
|---|---|
-t dmserver |
服务类型，dmserver 为数据库实例服务 |
-dm_ini |
该服务对应的实例配置文件 dm.ini 绝对路径 |
-p DMDB |
服务名后缀，最终生成服务名为 DmServiceDMDB |
验证：
[root]# ls -l /home/dmdba/dmdbms/bin/ | grep -i DmService
# 实测：DmServiceDMDB（18512 字节）
[root]# systemctl is-enabled DmServiceDMDB
# 实测：enabled（注册脚本已自动设置开机自启）
实测输出：
Created symlink from /etc/systemd/system/multi-user.target.wants/DmServiceDMDB.service to /usr/lib/systemd/system/DmServiceDMDB.service. 创建服务(DmServiceDMDB)完成 --- 验证 9.1 --- -rwxr-xr-- 1 dmdba dinstall 18512 Sep 21 09:14 DmServiceDMDB is-enabled: enabled
服务命名规则
服务名 = 服务脚本模板名 +-p后缀。多实例部署时-p必须能区分实例（如按实例名区分），否则会互相覆盖。
9.2 -t 支持的完整服务类型
| 服务类型 | 对应组件 |
|---|---|
dmserver |
数据库实例服务 |
dmap |
辅助进程服务（备份依赖） |
dmamon |
实时审计监控（DmAuditMonitorService 对应模板，见 9.4 节） |
dmwatcher |
数据守护（主备）守护进程 |
dmmonitor |
数据守护监视器 |
dmasmsvr / dmasmsvrm |
共享存储集群管理服务 |
dmcss / dmcssm |
集群同步服务及监视器 |
dmwatcher、dmmonitor、dmcss等仅适用于集群部署，单机部署无需使用。
9.3 卸载服务（如需）
[root]# cd /home/dmdba/dmdbms/script/root
[root]# ./dm_service_uninstaller.sh -n DmServiceDMDB
注意：卸载脚本会交互式询问确认（
是否删除服务(DmServiceDMDB)?(Y/y:是 N/n:否)）。在自动化脚本中需通过管道或重定向预先输入y，否则脚本会在此处挂起。
9.4 三个监控服务：保持默认不启用
root_installer.sh 额外注册了三个 DM9 监控服务。它们属于官方手册所说的"第一类服务脚本"——模板位于 bin/ 目录，名称不可修改，且每个 DM 系统只需运行一个。默认状态为已注册、未启用。
| 服务 | 对应二进制 | 用途 | 启动前是否必须手工配参 |
|---|---|---|---|
DmInstanceMonitorService |
dmimon |
实例实时监控 | 不需要（官方原文：“除了 SAVE_PROC_OUT 参数，其他参数不需要修改”） |
DmAuditMonitorService |
dmamon |
实时审计监控 | 必须：INI_PATH(dmamon.ini)、DCR_INI_PATH、USER_ID(连接串)、SSL_PATH / SSL_PWD |
DmJobMonitorService |
dmjmon |
实时作业监控 | 必须：USER_ID(连接串)、SSL_PATH / SSL_PWD |
为什么不能直接启用
官方《Linux 服务脚本使用手册》1.3 节开头有一句关键话：
用户在使用这些服务脚本前，需要先手动修改服务脚本的参数。
也就是说，这三个服务脚本装完只是"半成品"——必填参数（尤其是 USER_ID，格式 username/password@servername:port）默认是空的。直接启用会出现这样一组"看似莫名其妙"的结果：
# ① 先看当前状态（查看无害，可以执行）
[root]# systemctl is-enabled DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
[root]# systemctl is-active DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
# ② ⛔ 反面示例 —— 请勿照着执行
# 下面这行是"错误做法"的演示，用来解释接下来的报错从何而来。
# 正确处置见本节"结论：保持默认关闭"。
# [root]# systemctl enable --now DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
DmInstanceMonitorService：Started ← 起来了
DmAuditMonitorService ：control process exited, code=exited status=1 ← 失败
DmJobMonitorService ：control process exited, code=exited status=1 ← 失败
这个"一好两坏"的结果是必然的，不是装坏了。 实例监控服务不需要配参所以能起来；审计监控与作业监控缺少必填参数，进程启动后无法工作，立即退出。
切勿因看到failed而回头重装数据库——这三个服务与数据库是否能正常运行完全无关。
结论：保持默认关闭
本指南的部署链路不依赖这三个服务，它们面向的是"实时审计"与"定时作业监控"这类增强场景。建议保持默认不启用。
# 情形 A：上面 is-enabled / is-active 显示三个都是 disabled / inactive
# → 本来就没启用过，本节到此结束，直接进第 10 章
# 情形 B：出现 enabled 或 active（含 failed）→ 说明执行过 enable --now，按下面三步回退
[root]# systemctl disable --now DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
[root]# systemctl reset-failed DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
# 复核（期望：3 个 disabled、3 个 inactive）
[root]# systemctl is-enabled DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
[root]# systemctl is-active DmAuditMonitorService DmJobMonitorService DmInstanceMonitorService
[root]# systemctl --failed # 期望：0 loaded units listed
若确实需要启用
必须先补参数、再启动，且实例须已启动（即第 10 章之后）：
# 1) 看模板里要填哪些参数
[root]# grep -nE 'USER_ID|INI_PATH|DCR_INI_PATH|SSL_' /home/dmdba/dmdbms/bin/DmAuditMonitorService
[root]# grep -nE 'USER_ID|SSL_' /home/dmdba/dmdbms/bin/DmJobMonitorService
# 2) 按官方手册 1.3.2 / 1.3.3 节填好参数后，再启动
[root]# systemctl start DmAuditMonitorService
排障：真实报错不在 journalctl 里
journalctl 常把这类输出折叠成 [47B blob data] 之类的乱码。官方 1.5 节说明，服务脚本会把后台进程的标准输出/错误流写到 $DM_HOME/log/：
| 文件 | 内容 |
|---|---|
dmsvc_sh.log |
服务脚本自身在启停过程中产生的日志 |
<服务名>_err.log |
进程标准错误流（SAVE_PROC_ERR 默认 TRUE） |
<服务名>.log |
进程标准输出流（仅当 SAVE_PROC_OUT=TRUE 时才记录） |
# 失败时优先看这两处，而不是 systemctl status 的那一行
[root]# journalctl -u DmAuditMonitorService -n 30 --no-pager -o cat
[root]# tail -30 /home/dmdba/dmdbms/log/DmAuditMonitorService_err.log
第 10 章 数据库启停与状态检查
达梦提供两种启动方式，生产环境必须使用服务方式。
10.1 服务方式（生产环境唯一推荐方式）
[root]# su - dmdba
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./DmServiceDMDB start # 启动
[dmdba]$ ./DmServiceDMDB stop # 停止
[dmdba]$ ./DmServiceDMDB restart # 重启
[dmdba]$ ./DmServiceDMDB status # 查看状态
或直接用系统服务命令（root）：
[root]# systemctl start DmServiceDMDB
[root]# systemctl stop DmServiceDMDB
[root]# systemctl restart DmServiceDMDB
[root]# systemctl status DmServiceDMDB
10.2 前台方式（仅用于调试，禁止用于生产）
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./dmserver /dmdata/data/DMDB/dm.ini
启动成功标志：输出 SYSTEM IS READY。按 Ctrl+C 或输入 exit 退出，数据库随即停止。
为何生产禁用前台方式？
前台方式缺乏进程守护，终端断开（如 SSH 超时）即导致数据库非正常退出，可能引发实例恢复、甚至数据损坏。
10.3 启动状态确认
# 1. 操作系统服务状态
[root]# systemctl status DmServiceDMDB --no-pager
# 期望：active (running)，Main PID 为 dmserver
# 2. 数据库进程
[root]# ps -ef | grep dmserver | grep -v grep
# 3. 端口监听
[root]# ss -lntp | grep 5236
# 期望：LISTEN ... 0.0.0.0:5236 / :::5236
实测输出：
--- 10.1/10.3 服务状态 --- ● DmServiceDMDB.service - DM Instance Service(DmServiceDMDB). Loaded: loaded (/usr/lib/systemd/system/DmServiceDMDB.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2026-09-21 09:15:23 CST Process: 22737 ExecStart=/home/dmdba/dmdbms/bin/DmServiceDMDB start (code=exited, status=0/SUCCESS) Main PID: 22760 (dmserver) --- 数据库进程 --- dmdba 22760 1 18 09:15 ? 00:00:03 /home/dmdba/dmdbms/bin/dmserver path=/dmdata/data/DMDB/dm.ini -noconsole
第 11 章 数据库目录结构说明
11.1 软件安装目录（/home/dmdba/dmdbms）
实测目录清单：
| 子目录 | 存放内容 |
|---|---|
bin |
可执行程序：disql、dminit、dmrman、dmserver、dmap、各 DmService* 脚本 |
tool |
工具：manager（管理工具）、dbca（配置助手）、dts（数据迁移）等 |
doc |
产品手册 |
drivers |
各语言驱动（JDBC、ODBC、OCI 等） |
include |
开发头文件 |
jar |
Java 相关库 |
jdk |
内置 JDK（安装器本身依赖，约 300 MB） |
log |
工具日志与安装日志（install.log、install_detail.log） |
samples |
配置文件示例 |
script/root |
服务注册/注销脚本：dm_service_installer.sh、dm_service_uninstaller.sh、root_installer.sh |
uninstall |
卸载脚本 |
uninstall.sh |
卸载入口 |
license.txt |
许可说明 |
DM9 差异：DM9 的安装目录不含
web与desktop目录（DM8 中存在 DEM 企业管理器 Web 环境与桌面图标），DEM 已改为独立组件部署。
11.2 实例目录（/dmdata/data/DMDB）
| 文件/目录 | 说明 |
|---|---|
dm.ini |
实例主配置，所有实例级参数在此（内存池、兼容模式、归档开关等） |
dm.ini.dmbak |
dm.ini 的自动备份（每次修改主配置时留存上一版） |
dm.ctl |
控制文件，记录物理文件清单与状态，损坏将导致数据库无法启动 |
dmtemp.ctl |
临时控制文件（DM9 新增，首次启动实例时生成） |
dm_service.prikey |
服务密钥文件（DM9 新增） |
SYSTEM.DBF |
系统表空间，存放数据字典、系统对象（dminit 后 64 MB，首次启动扩至 128 MB） |
ROLL.DBF |
回滚表空间，存放未提交事务的旧版本数据 |
TEMP.DBF |
临时表空间，用于排序、临时表等（首次启动实例时生成） |
MAIN.DBF |
主表空间，存放用户业务数据 |
DMDB01.log / DMDB02.log |
重做日志，顺序写，用于崩溃恢复，数据安全的核心保障 |
dmarch.ini |
归档配置（开启归档后生成） |
sqllog.ini |
SQL 日志配置 |
bak/ |
默认备份文件目录 |
ctl_bak/ |
控制文件自动备份目录 |
HMAIN/ |
HUGE 表（列存）主目录 |
trace/ |
跟踪日志目录，用于问题诊断 |
备份必须覆盖的范围：
dm.ini、dm.ctl及全部.DBF数据文件。仅备份数据文件而遗漏控制文件将无法还原。生产环境建议直接使用达梦自带备份工具生成完整备份集。
第 12 章 归档配置（在线备份前置）
本章为官方文档未明确、但生产部署必需的关键环节。
12.1 为何必须开启归档
实测发现：数据库运行状态下执行在线备份，必须先开启归档。未开归档时执行备份会直接报错：
BACKUP DATABASE FULL BACKUPSET '/dmdata/dmbak/bak_test_full';
第1 行附近出现错误[-8003]:缺少本地或者远程归档.
归档的核心作用：
- 支持在线备份——这是最直接、最先碰到的约束；
- 支持时间点恢复——未开归档只能恢复到最近一次全量备份点，中间数据全部丢失；
- 支撑主备同步——数据守护（主备）架构依赖归档日志传输。
结论：只要数据库承载真实业务，归档必须在部署阶段就配置完成，不要等出了问题才补。
12.2 创建归档配置文件
在实例目录下创建 dmarch.ini：
[dmdba]$ vi /dmdata/data/DMDB/dmarch.ini
# ---------- 归档配置 ----------
[ARCHIVE_LOCAL1]
# 归档类型：LOCAL 为本地归档
ARCH_TYPE = LOCAL
# 归档日志存放路径（指向独立的归档卷）
ARCH_DEST = /dmdata/arch
# 单个归档文件大小上限（MB）
ARCH_FILE_SIZE = 1024
# 归档空间上限（MB），0 表示不限制
ARCH_SPACE_LIMIT = 0
12.3 在 dm.ini 中启用归档
[dmdba]$ vi /dmdata/data/DMDB/dm.ini
ARCH_INI = 1 # 启用归档配置文件 dmarch.ini
该参数可在数据库运行状态下修改，但需重启数据库使归档配置文件生效。
[root]# systemctl restart DmServiceDMDB
[root]# systemctl is-active DmServiceDMDB
实测输出（重启后实例正常，5236 端口已重新监听）：
--- 等待启动 --- active --- 端口确认 --- LISTEN 0 128 [::]:5236 [::]:* users:(("dmserver",pid=23057,fd=3))
12.4 切换数据库至归档模式
数据库重启后，以 SYSDBA 登录执行：
-- 将数据库置于 MOUNT 状态（归档模式切换必须在 MOUNT 下进行）
ALTER DATABASE MOUNT;
-- 开启归档模式
ALTER DATABASE ARCHIVELOG;
-- 重新打开数据库对外提供服务
ALTER DATABASE OPEN;
实测输出（三条依次成功执行，归档模式确认为 Y）：
===== 12.4 切换至归档模式 (MOUNT -> ARCHIVELOG -> OPEN) ===== 操作已执行 已用时间: 1.123(毫秒). 操作已执行 已用时间: 5.312(毫秒). 操作已执行 已用时间: 10.006(毫秒). 行号 NAME ARCH_MODE STATUS$ ---------- ---- --------- ----------- 1 DMDB Y 4
注意：
ALTER DATABASE ARCHIVELOG必须在MOUNT状态下执行。若数据库处于OPEN状态直接执行会报[-2007] 语法分析出错。这是实测踩坑点：需先MOUNT再ARCHIVELOG，最后OPEN。
⚠️ 中断兜底：这三步是接力关系，断了库会停在
MOUNT态若在
MOUNT之后、OPEN之前发生中断（网络断开、Ctrl+C、ARCHIVELOG本身报错），数据库会停在挂载状态：
所有客户端都连不上，登录直接报错——现象酷似"数据库挂了"，其实只是没打开，数据完好无损。# 先确认实例进程是否还在 [root]# ps -ef | grep dmserver | grep -v grep # 进程在 —— 直接补 OPEN 即可，不必重做前面两步 [dmdba]$ ./disql -S 'SYSDBA/"密码"@127.0.0.1:5236' -e "ALTER DATABASE OPEN;" # 进程不在 —— 先启服务，再执行上面那条 OPEN [root]# systemctl start DmServiceDMDB判定当前处于哪个阶段：登录成功说明已
OPEN；登录报连接类错误而进程又在，基本就是停在MOUNT。
12.5 验证归档状态
归档配置完成后，必须做三层交叉验证——数据库内部参数、数据库视图、操作系统文件系统。任一层不通过都说明归档未真正生效，此时执行在线备份会直接报 [-8003] 缺少本地或者远程归档。
第一层：数据库内部参数
[dmdba]$ grep -E 'ARCH_INI' /dmdata/data/DMDB/dm.ini
# 期望：ARCH_INI = 1
[dmdba]$ cat /dmdata/data/DMDB/dmarch.ini
# 期望：存在 [ARCHIVE_LOCAL1] 段，且 ARCH_TYPE = LOCAL、ARCH_DEST 指向归档目录
ARCH_INI=1 是开关，dmarch.ini 是配置实体，两者缺一不可：只改 dm.ini 不建 dmarch.ini，数据库启动时会因找不到归档配置文件而忽略归档。
第二层：数据库视图（最权威）
DM9 的重要变化：V$INSTANCE 视图中已不再包含 ARCH_MODE 列，查询归档状态须改用 V$DATABASE：
-- 正确：查询 V$DATABASE.ARCH_MODE，Y 表示已开启归档
SELECT NAME, ARCH_MODE, STATUS$ FROM V$DATABASE;
实测结果：
行号 NAME ARCH_MODE STATUS$
---------- -------- ----------- -----------
1 DMDB Y 4
字段解读：
ARCH_MODE=Y表示归档已开启；V$DATABASE.STATUS$为数值型状态编码（4 表示数据库处于 OPEN 打开状态），不要与V$INSTANCE.STATUS$的字符型OPEN混淆——两者字段名相同但类型与取值完全不同，写监控 SQL 时极易踩坑。后续检查实例状态请统一使用
V$INSTANCE（返回OPEN/MOUNT等可读文本），归档状态使用V$DATABASE.ARCH_MODE。
进一步确认归档日志已实际生成（这是归档真正"跑起来"的证据）：
SELECT SEQUENCE#, NAME FROM V$ARCHIVED_LOG;
实测输出（序号 SEQUENCE# 自增，说明归档在持续生成）：
行号 SEQUENCE# NAME
---------- ----------- ------------------------------------------------------------------
1 1 /dmdata/arch/ARCHIVE_LOCAL1_0x6091A5E8_EP0_2026-09-21_09-18-08.log
2 2 /dmdata/arch/ARCHIVE_LOCAL1_0x6091A5E8_EP0_2026-09-21_09-18-39.log
视图说明：
V$ARCHIVED_LOG中可用列为NAME（含完整路径）、SEQUENCE#、FIRST_TIME、NEXT_TIME，没有DEST列。易踩坑点：
V$ARCHIVE视图在 DM9 中不存在，查询会报[-2106] 无效的表或视图名，请勿沿用旧版本写法。
第三层：操作系统文件系统
[root]# ls -lh /dmdata/arch/
# 实测（本文 2026-09-21 重跑）：
# -rw-r--r-- 1 dmdba dinstall 24K ... ARCHIVE_LOCAL1_0x6091A5E8_EP0_2026-09-21_09-18-08.log
# -rw-r--r-- 1 dmdba dinstall 1.0G ... ARCHIVE_LOCAL1_0x6091A5E8_EP0_2026-09-21_09-18-39.log
[root]# du -sh /dmdata/arch/
# 实测：1.1G /dmdata/arch
归档文件名中的 0x6091A5E8 为实例标识，EP0 为站点号，时间戳为该归档文件的起始时间。
两个实用观察（本次按本文档重新部署时实测）
- 首个归档文件在"切换归档模式"那一刻就产生：执行
ALTER DATABASE ARCHIVELOG成功后，达梦会立即做一次日志切换并落地第一份归档（实测SEQUENCE#=1）。所以第三层验证（看ls输出）通常无需等待即可通过，不必担心"目录是空的"。- 当前正在写入的归档文件会按
ARCH_FILE_SIZE预占磁盘：ARCH_FILE_SIZE = 1024（MB）时，当前活动归档文件固定占用 1 GB（实测ls -ls显示实占 1048580 个块），而历史归档文件只占其真实内容大小（几十 KB ~ 几百 KB）。这正是上例中ls出现一个1.0G大文件、而du -sh总占用约 1.1 GB 的原因。规划归档卷容量时必须把"当前活动文件的 1 GB"计入。容量提示：归档卷紧张时可下调
ARCH_FILE_SIZE（如256），或通过ARCH_SPACE_LIMIT设上限，并配合定期归档清理。
12.6 归档验证结论
| 层级 | 验证对象 | 期望值 | 实测 |
|---|---|---|---|
| 参数层 | dm.ini |
ARCH_INI = 1 |
✅ |
| 参数层 | dmarch.ini |
[ARCHIVE_LOCAL1] 且 ARCH_TYPE=LOCAL |
✅ |
| 视图层 | V$DATABASE.ARCH_MODE |
Y |
✅ |
| 视图层 | V$ARCHIVED_LOG |
有归档记录，且随业务持续递增 | ✅（快照：部署完成时 5 条，二次复核已增至 6 条） |
| 文件层 | /dmdata/arch/ |
存在 ARCHIVE_LOCAL1_*.log |
✅（约 1.1 GB，其中活动文件按 ARCH_FILE_SIZE=1024 MB 预占） |
判据提示（务必看期望值而不是数字）：
V$ARCHIVED_LOG的行数不是一个固定值——只要有事务写入，归档就会不断产生新记录，你照做时看到的可能是 3 条、5 条或 20 条。因此本条验证的正确判据是"能查到记录且序号（SEQUENCE#）连续递增"，而不是"等于 5 条"。同理，/dmdata/arch/的容量也只增不减。
结论：三项验证全部通过，归档已正确开启并生效，数据库具备在线备份与时间点恢复能力，可进入第 13 章备份与恢复演练。
对生产环境的意义：归档已开启意味着——① 可在数据库运行状态下执行在线备份，无需停机；② 可基于"全量备份 + 归档日志"恢复到任意时间点，而非仅能恢复到最近一次备份；③ 为后续搭建数据守护（主备）架构预留了基础。反之，未开归档的生产库，其备份只能恢复到备份那一刻，备份之后的所有事务将全部丢失。
第 13 章 数据库备份与恢复
备份是数据库的生命线。部署阶段的归档配置（第 12 章）是为备份铺路，本章才是真正落地"数据可恢复"的环节。
核心观点："做了备份"和"备份可用"是两件事。只把备份文件生成出来、从不校验、从不演练恢复，等同于没有备份。本章不仅给出备份方法，更完整演练一次异目录恢复并验证数据一致性，用实测证明备份集真实可用。
13.1 备份体系概述
达梦数据库提供两类备份，按数据组织方式划分：
| 类别 | 备份内容 | 工具 | 特点 | 适用场景 |
|---|---|---|---|---|
| 物理备份 | 数据文件、控制文件、日志文件的物理副本（备份集） | SQL BACKUP DATABASE、dmrman |
速度快、可整库恢复、支持增量 | 生产库日常备份、容灾（本指南主线） |
| 逻辑备份 | 库/模式/表级别的 SQL 导出 | dmdump、dexp |
可跨平台、可选择性导出单表 | 数据迁移、小表交换、跨版本搬运 |
本环境的现实约束：本次部署时仅安装 Server 组件（
<COMPONENTS>1</COMPONENTS>），未安装 Client Tools，因此dmdump等逻辑备份工具不存在。生产环境若需要逻辑备份，须在安装时额外勾选 Client Tools 组件。本章主线为物理备份，它也是生产环境最标准的备份方式。
物理备份按数据库是否运行，又分为两类：
| 方式 | 数据库状态 | 命令 | 是否需归档 | 生产推荐度 |
|---|---|---|---|---|
| 在线备份 | 运行中（OPEN） | SQL BACKUP DATABASE ... |
必须先开归档 | ★★★★★ 首选，不停机 |
| 离线备份 | 已停止 | dmrman CTLSTMT="BACKUP DATABASE ..." |
不需要 | ★★☆ 仅用于停机窗口或灾难场景 |
为什么生产环境首选在线备份：在线备份期间数据库正常对外服务，业务无感知；而离线备份必须停库，等于制造一次计划内停机。
13.2 备份策略设计
一套可落地的生产备份策略需要回答四个问题：备什么、多久备一次、留多久、放哪里。
13.2.1 推荐策略（本指南采用）
| 备份类型 | 频率 | 保留份数 | 存放位置 | 说明 |
|---|---|---|---|---|
| 全量备份 | 每周 1 次（周日 02:00） | 4 份 | /dmdata/dmbak |
恢复基线，保留最近一个月 |
| 增量备份 | 每日 1 次（周一至周六 02:00） | 30 份 | /dmdata/dmbak |
只备份自上次备份以来的变化页 |
| 归档日志 | 持续自动生成 | 按空间上限滚动 | /dmdata/arch |
支撑时间点恢复（PITR） |
设计依据：
- 全量 + 增量组合——全量奠定恢复基线，增量降低每日备份窗口与存储占用。实测数据可见（13.5 节）：同环境全量备份集 18~22 MB、耗时约 5 s；增量备份集仅 4.3 MB、耗时约 9 s（首次增量需扫描变化页，后续会更小）。
- 保留份数按恢复窗口倒推——全量保留 4 份意味着最坏情况下可回退到约一个月前的任意一次全量；增量保留 30 份覆盖一个月。
- 备份独立成卷——备份集写满不能反向影响数据卷与归档卷（第 3 章已将三个功能拆分到独立 LV）。
13.2.2 备份三原则
可还原、异地存放、有人看结果。
- 可还原——备份必须定期做恢复演练（本章 13.7 节），不能只"备"不"验"；
- 异地存放——本地备份防不住机房级故障（火灾、断电、整体损坏），核心业务必须将备份集复制到异地或对象存储；
- 有人看结果——备份失败必须告警到人，静默失败的备份与没有备份等价。
13.3 在线备份（推荐方式）
在线备份通过 SQL 直接下发，数据库运行状态下即可执行，是生产环境的唯一首选。
前置条件：归档已开启（第 12 章已完成并通过三层验证）。
13.3.1 全量备份
-- 全量备份到指定目录（目录由数据库自动创建，无需预先 mkdir）
BACKUP DATABASE FULL BACKUPSET '/dmdata/dmbak/full_20260921';
实测输出：
已用时间: 00:00:04.258. 执行号:1101.
注意：SQL 备份只返回"执行号"，不返回进度。备份是否成功要看返回码与文件是否生成（见下）。
备份完成后查看生成的备份集：
[root]# ls -lh /dmdata/dmbak/full_20260921/
-rw-r--r-- 1 dmdba dinstall 54K full_20260921_1.bak
-rw-r--r-- 1 dmdba dinstall 18M full_20260921.bak
-rw-r--r-- 1 dmdba dinstall 122K full_20260921.meta
备份集文件构成：
| 文件 | 作用 | 是否必有 |
|---|---|---|
*.bak |
主备份文件，承载实际数据页，是恢复的核心 | ✅ 必有 |
*_1.bak |
附属备份文件（辅助数据流） | ⚠️ 个数不固定，与备份方式/内容有关，见下方实测 |
*.meta |
元数据文件，记录备份集结构、时间点、文件清单，恢复时用于解析 | ✅ 必有 |
必须整体保留备份集目录，
.meta不可缺移动或复制备份集时必须整目录一起搬。只拷贝
.bak会因缺少.meta而无法恢复——dmrman解析备份集结构、定位时间点全靠它。
实测提醒：备份集文件个数不固定，切勿按个数校验
本指南早期版本先写作"三者缺一不可"，后又改为"增量只有 2 个文件"——两种表述都不严谨。经在 DM9 03151060506-20260417-322930-20218 上实跑，文件个数随备份方式与内容变化：
备份方式 备份类型 实测文件构成 文件数 在线（SQL BACKUP）全量 .bak+_1.bak+.meta3 在线（SQL BACKUP）增量 .bak+.meta（无_1.bak）2 离线（ dmrman）全量 .bak+.meta2 可见同为"全量"，在线方式 3 个文件、离线方式只有 2 个；同为"在线方式"，全量 3 个、增量 2 个。结论：文件个数不能作为备份成功与否的判据。 正确做法是：① 整目录保留；② 用
dmrman CHECK BACKUPSET校验完整性（见 13.6 节）——校验通过才算备份可用。
13.3.2 增量备份
-- 增量备份（相对上一次备份的变化页）
BACKUP DATABASE INCREMENT BACKUPSET '/dmdata/dmbak/incr_20260921';
实测输出：
已用时间: 00:00:08.584. 执行号:1301.
备份完成后查看生成的增量备份集（本环境实测在线增量为 2 个文件）：
[root]# ls -lh /dmdata/dmbak/incr_20260921/
-rw-r--r-- 1 dmdba dinstall 4.1M incr_20260921.bak
-rw-r--r-- 1 dmdba dinstall 114K incr_20260921.meta
增量备份的依赖关系：增量备份必须有一个基线全量备份才有意义。若从未做过全量备份，直接执行增量会失败。恢复时也需要"全量 + 逐级增量"按序应用。
13.4 离线备份（dmrman）
当数据库处于停止状态（如计划内维护、灾难后无法启动）时，使用 dmrman 工具做离线备份。
# 先停库
[root]# systemctl stop DmServiceDMDB
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./dmrman CTLSTMT="BACKUP DATABASE '/dmdata/data/DMDB/dm.ini' FULL BACKUPSET '/dmdata/dmbak/bak_offline'" </dev/null
# 【必做·极易遗漏】备份完成后立即把库启回来
# 本节之后的内容（13.3 在线备份、13.5 脚本、13.7 演练中的建表）全部要求数据库在线。
# 漏掉这一步，后续命令会持续报 [-70028] 创建SOCKET连接失败，且现象与"没装好"一模一样。
[root]# systemctl start DmServiceDMDB
[root]# systemctl is-active DmServiceDMDB # 期望：active
[root]# ss -lntp | grep 5236 # 期望：LISTEN
⚠️ 三个必踩的坑
坑 1 — 数据库必须停止：
dmrman备份要求数据库处于停止状态，运行中调用会报：RMAN[-137]:服务器正在运行或者存在其他进程正在操作同一个库日常运维优先用 13.3 节的 SQL 在线备份，无需停机。
坑 2 — 必须加
</dev/null：dmrman在无输入重定向时，会无限循环输出RMAN>提示符（实测累计输出 666 万字节直至进程被强杀）。所有dmrman调用都应追加</dev/null，必要时再套timeout兜底。# 错误：无限循环输出提示符 ./dmrman CTLSTMT="..." # 正确：重定向标准输入 ./dmrman CTLSTMT="..." </dev/null坑 3 — 停库之后必须启回来：这是最容易被忽略、后果最迷惑人的一个。离线备份是本章唯一需要停库的操作，而它后面的步骤全部是在线操作。漏掉
systemctl start，读者会看到后续命令一路报[-70028] 创建SOCKET连接失败——与"第 10 章还没启动实例"的现象完全一致，极易误判成环境损坏。判定方法很简单：[root]# systemctl is-active DmServiceDMDB # inactive 就说明是这个问题
13.5 自动化备份脚本 dm_backup.sh
手动敲 SQL 只能应急，生产环境必须用脚本 + 定时任务固化流程。本节提供一个经过实测的生产级备份脚本，覆盖"前置检查 → 备份 → 校验 → 保留清理 → 日志"完整闭环。
13.5.1 脚本设计要点
| 设计点 | 做法 | 原因 |
|---|---|---|
| 环境变量显式声明 | 脚本内 export DM_HOME/PATH/LD_LIBRARY_PATH |
crond 不加载用户 profile，缺环境变量会导致找不到命令 |
| 归档前置检查 | 备份前查 V$DATABASE.ARCH_MODE |
未开归档时在线备份必失败，提前拦截并给出可读提示 |
| SQL 写入临时文件 | disql @文件 而非 -e "SQL" |
规避口令与 SQL 经多层 shell 引号转义被改写 |
| 备份后立即校验 | 调用 dmrman CHECK BACKUPSET |
“备份成功"≠"备份可用”，必须体检 |
| 保留策略自动清理 | 按份数删除最旧备份 | 防止备份集撑满备份卷 |
| 全程日志留痕 | tee 到按月日志文件 |
便于事后追溯与告警接入 |
| 失败即终止 | die() 统一退出并记录 |
避免"半成功"状态被误判为成功 |
13.5.2 脚本全文
将以下内容保存为 /home/dmdba/dm_backup.sh，并 chmod 755：
实测部署结果（脚本 7087 字节，语法检查通过）：
===== 已部署 dm_backup.sh ===== -rwxr-xr-x 1 dmdba dinstall 7087 Sep 21 09:28 /home/dmdba/scripts/dm_backup.sh ===== 语法检查 ===== syntax OK
#!/bin/bash
###############################################################################
# 脚本名称：dm_backup.sh
# 功能说明：DM9 数据库自动备份脚本（支持全量/增量、校验、保留策略、日志）
# 适用版本：DM9 企业版 9.1.x（CentOS 7.9 及以上）
# 执行用户：dmdba（必须以数据库运行用户执行，禁止 root）
# 使用方式：
# ./dm_backup.sh full # 执行全量备份
# ./dm_backup.sh incr # 执行增量备份（首次会自动降级为全量）
# ./dm_backup.sh verify <目录> # 仅校验指定备份集
# ./dm_backup.sh list # 列出已有备份集
# 建议配置 crontab（示例）：
# 0 2 * * 0 /home/dmdba/scripts/dm_backup.sh full # 每周日 02:00 全量
# 0 2 * * 1-6 /home/dmdba/scripts/dm_backup.sh incr # 周一至周六 02:00 增量
###############################################################################
# ---------- 环境变量（crond 环境不继承用户 profile，必须显式设置） ----------
export DM_HOME=/home/dmdba/dmdbms
export PATH=$DM_HOME/bin:$PATH
export LD_LIBRARY_PATH=$DM_HOME/bin:$LD_LIBRARY_PATH
# ---------- 可配置参数 ----------
DB_INI="/dmdata/data/DMDB/dm.ini" # 实例配置文件绝对路径
BAK_ROOT="/dmdata/dmbak" # 备份集根目录
DB_USER="SYSDBA" # 备份执行账号（建议专用账号，勿用 SYSDBA 长期承载）
DB_PASS='Dm9@SysDba#2026' # 数据库口令
KEEP_FULL=4 # 全量备份保留份数
KEEP_INCR=30 # 增量备份保留份数
LOG_DIR="/dmdata/dmbak/log" # 脚本运行日志目录
DISQL="$DM_HOME/bin/disql"
DMRMAN="$DM_HOME/bin/dmrman"
# ---------- 内部变量 ----------
MODE="$1" # 备份模式：full / incr / verify / list
TS=$(date +%Y%m%d_%H%M%S) # 时间戳
HOST_PORT="127.0.0.1:5236" # 本地连接地址
mkdir -p "$LOG_DIR" 2>/dev/null
# 日志目录若权限不足（如曾被 root 创建），给出明确提示而非静默失败
if [ ! -w "$LOG_DIR" ]; then
echo "警告：日志目录 $LOG_DIR 不可写，请执行 chown -R dmdba:dinstall $LOG_DIR" >&2
fi
LOG_FILE="$LOG_DIR/dm_backup_$(date +%Y%m).log"
# ---------- 连接串（外单内双，规避 # 被 shell 当注释截断） ----------
CONN="$DB_USER/\"$DB_PASS\"@$HOST_PORT"
# ---------- 日志函数 ----------
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"
}
# ---------- 失败退出（任何关键步骤失败都应终止并告警） ----------
die() {
log "ERROR: $*"
log "===== 备份作业异常终止 ====="
exit 1
}
# ---------- 前置检查 ----------
pre_check() {
[ -f "$DB_INI" ] || die "找不到实例配置文件：$DB_INI"
[ -x "$DISQL" ] || die "找不到 disql：$DISQL"
[ -x "$DMRMAN" ] || die "找不到 dmrman：$DMRMAN"
[ -d "$BAK_ROOT" ] || die "备份根目录不存在：$BAK_ROOT"
# 检查归档是否开启（在线备份的前提）
# 注意：disql 输出形如 "1 Y"（行号+空格+值），不能简单 grep '^Y'
local sql="/tmp/_arch_$$.sql"
printf 'SET PAGESIZE 0\nSELECT ARCH_MODE FROM V$DATABASE;\nEXIT;\n' > "$sql"
chmod 600 "$sql"
local arch
arch=$($DISQL -S "$CONN" @"$sql" </dev/null 2>/dev/null | grep -oE '[YN]' | head -1)
rm -f "$sql"
[ "$arch" = "Y" ] || die "数据库未开启归档（当前 ARCH_MODE=${arch:-未知}），无法执行在线备份，请先完成归档配置"
log "前置检查通过：实例=$DB_INI，归档=已开启"
}
# ---------- 执行备份 ----------
do_backup() {
local type="$1" # FULL / INCREMENT
local bakdir="$BAK_ROOT/${type,,}_$TS"
local sqlfile="/tmp/_dm_bak_$$.sql"
local start=$(date +%s)
log "开始 $type 备份 → $bakdir"
mkdir -p "$bakdir"
# 备份语句写入文件，避免口令与 SQL 经多层 shell 引号转义
echo "BACKUP DATABASE $type BACKUPSET '$bakdir';" > "$sqlfile"
chmod 600 "$sqlfile"
local out
out=$($DISQL -S "$CONN" @"$sqlfile" </dev/null 2>&1)
local rc=$?
rm -f "$sqlfile"
if [ $rc -ne 0 ] || echo "$out" | grep -qE '\[-[0-9]+\]'; then
log "备份失败，输出如下："
echo "$out" | tee -a "$LOG_FILE"
return 1
fi
local cost=$(( $(date +%s) - start ))
local size=$(du -sh "$bakdir" 2>/dev/null | awk '{print $1}')
log "$type 备份完成：耗时 ${cost}s，备份集大小 $size"
# 立即校验备份集完整性（关键：备份不等于可用备份，必须校验）
verify_backupset "$bakdir" || return 1
return 0
}
# ---------- 校验备份集 ----------
verify_backupset() {
local bakdir="$1"
log "校验备份集：$bakdir"
local out
out=$($DMRMAN CTLSTMT="CHECK BACKUPSET '$bakdir';" </dev/null 2>&1 | tr '\r' '\n')
if echo "$out" | grep -qi "check backupset successfully"; then
log "校验通过：$bakdir"
return 0
else
log "校验失败：$bakdir"
echo "$out" | grep -iE "RMAN-|error|fail" | tee -a "$LOG_FILE"
return 1
fi
}
# ---------- 清理过期备份（按份数保留） ----------
cleanup_old() {
local prefix="$1" keep="$2"
local count
count=$(find "$BAK_ROOT" -maxdepth 1 -type d -name "${prefix}_*" | wc -l)
if [ "$count" -le "$keep" ]; then
log "清理检查：$prefix 备份 $count 份，未超保留阈值 $keep，无需清理"
return
fi
# 按时间倒序，删除超出保留份数的旧备份
find "$BAK_ROOT" -maxdepth 1 -type d -name "${prefix}_*" -printf '%T@ %p\n' \
| sort -rn | awk -v k="$keep" 'NR>k {print $2}' \
| while read -r old; do
log "删除过期备份：$old"
rm -rf "$old"
done
}
# ---------- 列出备份集 ----------
list_backups() {
log "===== 现有备份集（按时间倒序） ====="
find "$BAK_ROOT" -maxdepth 1 -type d \( -name "full_*" -o -name "increment_*" \) 2>/dev/null \
| while read -r d; do
printf '%s %8s %s\n' \
"$(date -r "$d" '+%Y-%m-%d %H:%M')" \
"$(du -sh "$d" 2>/dev/null | awk '{print $1}')" \
"$d"
done | sort -r | tee -a "$LOG_FILE"
}
# ---------- 主流程 ----------
case "$MODE" in
full)
pre_check
log "===== 开始全量备份作业 ====="
do_backup "FULL" || die "全量备份失败"
cleanup_old "full" "$KEEP_FULL"
log "===== 全量备份作业结束 ====="
;;
incr)
pre_check
log "===== 开始增量备份作业 ====="
# 增量备份依赖基线全量，若从未做过全量则自动降级
if ! find "$BAK_ROOT" -maxdepth 1 -type d -name "full_*" | grep -q .; then
log "未发现基线全量备份，自动降级为全量备份"
do_backup "FULL" || die "全量备份失败"
cleanup_old "full" "$KEEP_FULL"
else
do_backup "INCREMENT" || die "增量备份失败"
cleanup_old "increment" "$KEEP_INCR"
fi
log "===== 增量备份作业结束 ====="
;;
verify)
[ -n "$2" ] || die "verify 模式需指定备份集目录，如：./dm_backup.sh verify /dmdata/dmbak/full_xxx"
verify_backupset "$2" || die "备份集校验失败"
;;
list)
list_backups
;;
*)
echo "用法：$0 {full|incr|verify <备份集目录>|list}"
echo " full 执行全量备份"
echo " incr 执行增量备份（无基线时自动降级为全量）"
echo " verify <备份集目录> 校验指定备份集完整性"
echo " list 列出已有备份集"
exit 1
;;
esac
exit 0
部署脚本：
# 1) 创建脚本目录并放置脚本
[dmdba]$ mkdir -p /home/dmdba/scripts
[dmdba]$ vi /home/dmdba/scripts/dm_backup.sh # 粘贴上述内容
[dmdba]$ chmod 755 /home/dmdba/scripts/dm_backup.sh
# 2) 确保日志目录属主正确（关键：若曾由 root 创建会 Permission denied）
[root]# mkdir -p /dmdata/dmbak/log
[root]# chown -R dmdba:dinstall /dmdata/dmbak
13.5.3 实测运行效果
全量备份（./dm_backup.sh full）：
[2026-09-21 09:28:37] 前置检查通过：实例=/dmdata/data/DMDB/dm.ini，归档=已开启
[2026-09-21 09:28:37] ===== 开始全量备份作业 =====
[2026-09-21 09:28:37] 开始 FULL 备份 → /dmdata/dmbak/full_20260921_092837
[2026-09-21 09:28:42] FULL 备份完成：耗时 5s，备份集大小 18M
[2026-09-21 09:28:42] 校验备份集：/dmdata/dmbak/full_20260921_092837
[2026-09-21 09:28:42] 校验通过：/dmdata/dmbak/full_20260921_092837
[2026-09-21 09:28:42] 清理检查：full 备份 2 份，未超保留阈值 4，无需清理
[2026-09-21 09:28:42] ===== 全量备份作业结束 =====
增量备份（./dm_backup.sh incr）：
[2026-09-21 09:28:53] 前置检查通过：实例=/dmdata/data/DMDB/dm.ini，归档=已开启
[2026-09-21 09:28:53] ===== 开始增量备份作业 =====
[2026-09-21 09:28:53] 开始 INCREMENT 备份 → /dmdata/dmbak/increment_20260921_092853
[2026-09-21 09:29:02] INCREMENT 备份完成：耗时 9s，备份集大小 4.3M
[2026-09-21 09:29:02] 校验备份集：/dmdata/dmbak/increment_20260921_092853
[2026-09-21 09:29:02] 校验通过：/dmdata/dmbak/increment_20260921_092853
[2026-09-21 09:29:02] 清理检查：increment 备份 1 份，未超保留阈值 30，无需清理
[2026-09-21 09:29:02] ===== 增量备份作业结束 =====
列出备份（./dm_backup.sh list）：
[2026-09-21 09:29:09] ===== 现有备份集（按时间倒序） =====
2026-09-21 09:29 4.3M /dmdata/dmbak/increment_20260921_092853
2026-09-21 09:28 18M /dmdata/dmbak/full_20260921_092837
2026-09-21 09:24 18M /dmdata/dmbak/full_20260921
实测结论：单次全量备份约 4~5 秒、增量约 9 秒，备份 + 校验全流程闭环自动完成。增量备份集仅为全量的约四分之一（4.3 MB vs 22 MB），验证了"全量 + 增量"组合策略对备份窗口与存储的优化效果。
13.5.4 配置定时任务
通过 crontab 将备份固化为周期性作业：
[dmdba]$ crontab -e
# DM9 数据库备份计划
# 每周日 02:00 全量备份
0 2 * * 0 /home/dmdba/scripts/dm_backup.sh full >> /dmdata/dmbak/log/cron.log 2>&1
# 周一至周六 02:00 增量备份
0 2 * * 1-6 /home/dmdba/scripts/dm_backup.sh incr >> /dmdata/dmbak/log/cron.log 2>&1
注意：
- 必须以 dmdba 用户配置 crontab（
crontab -e前先su - dmdba），root 的 crontab 无法正确使用数据库环境；- 脚本内已显式声明环境变量，不依赖 crond 是否加载 profile；
- 建议在 crontab 中保留
>> ... 2>&1重定向，捕获脚本层面的异常输出。
13.6 备份集校验
备份完成后必须校验。达梦提供 dmrman CHECK BACKUPSET 对备份集做完整性检查——它读取备份集的元数据与数据页校验和，能发现文件缺失、损坏、不完整等问题。
关键优势：校验可在数据库运行状态下执行，无需停库。
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./dmrman CTLSTMT="CHECK BACKUPSET '/dmdata/dmbak/full_20260921_092837';" </dev/null
实测输出：
dmrman V9
; DMRMAN ap_port=4236 CHECK BACKUPSET '/dmdata/dmbak/full_20260921_092837'
check backupset successfully.
time used: 177.599(ms)
判读标准：输出中出现
check backupset successfully.即表示备份集完整可用。若出现RMAN[-xxxx]、error、fail等字样，说明备份集有问题，该备份不可用于恢复，须立即重新备份。输出处理提示：
dmrman的输出含\r进度条控制字符，脚本中做文本匹配前建议先tr '\r' '\n'规整（dm_backup.sh已内置该处理）。
也可直接使用脚本的 verify 模式：
[dmdba]$ /home/dmdba/scripts/dm_backup.sh verify /dmdata/dmbak/full_20260921_092837 [2026-09-21 09:29:32] 校验备份集：/dmdata/dmbak/full_20260921_092837 [2026-09-21 09:29:32] 校验通过：/dmdata/dmbak/full_20260921_092837
13.7 恢复演练与备份准确性验证
本节是整章的落脚点——用一次完整的异目录恢复，证明备份集真实可用、数据准确无误。
13.7.1 为什么要在"异目录"演练
生产环境的恢复演练不应直接在原库上操作（会破坏生产数据）。标准做法是：把备份集恢复到另一个目录、另一个端口，启动后比对数据。演练通过，才说明"这个备份真的能救回数据"。
13.7.2 演练设计（数据一致性比对法)
| 步骤 | 动作 | 目的 |
|---|---|---|
| 1 | 建表 T_BAK_DEMO，写入 2 条"备份前"数据 |
建立基线 |
| 2 | 执行全量备份 | 生成待验证的备份集 |
| 3 | 备份后再写入第 3 条数据 | 构造"备份时刻"与"当前时刻"的差异 |
| 4 | 停原库，异目录恢复 + 启动还原库 | 执行恢复 |
| 5 | 还原库应查到 2 条（不含第 3 条） | 证明恢复到的是备份时刻，而非当前时刻 |
这个设计的关键：如果第 3 条数据也出现在还原库里，说明恢复"穿越"到了未来——备份集不可信；只有恰好缺第 3 条，才证明备份集精确冻结了备份那一刻的状态。
13.7.3 恢复三步法
达梦的物理恢复严格分三步，顺序不可颠倒：
RESTORE → RECOVER → RECOVER ... UPDATE DB_MAGIC
（还原文件） （重做日志） （更新数据库魔数）
| 步骤 | 作用 | 关键点 |
|---|---|---|
RESTORE DATABASE |
把备份集中的数据文件还原到指定位置 | 只还原数据文件，不含 dm.ini/dm.ctl |
RECOVER DATABASE |
用归档日志/重做日志把数据文件推进到一致状态 | 必须指定同一备份集 |
RECOVER ... UPDATE DB_MAGIC |
更新还原库的数据库魔数，使其可被独立启动 | 异目录恢复必须执行，否则与原库冲突 |
⚠️ 本指南实测踩坑：
RMAN[-104] INI参数文件错误直接手工
RESTORE到异目录时，若目标目录里没有dm.ini，会反复报：RMAN[-104]:INI参数文件错误根因：备份集内只有数据文件（
SYSTEM.DBF/ROLL.DBF/MAIN.DBF），不含dm.ini与dm.ctl（实测SHOW BACKUPSET已确认）。dmrman需要一个可读的dm.ini来定位实例，因此必须先有一个目标实例的dm.ini。正确做法（本演练采用）：先用
dminit在目标目录建一个同参数的空实例，再基于它的dm.ini做恢复。这样既得到了干净的dm.ini，也避免了手工改 INI 引入非法值（实测手工sed改 INI 导致RMAN[-803] 非法INI配置值）。另一处实测踩坑：
dminit初始化时不接受COMPATIBLE_MODE参数，会报Invalid parameter:COMPATIBLE_MODE.并终止。兼容模式须在实例建好后通过dm.ini修改（或建库时用SF_SET_COMPATIBLE_MODE调整），不能在dminit中直接指定。
13.7.4 完整演练步骤与实测输出
步骤 1：准备基线数据
-- 建验证表并写入 2 条"备份前"数据
CREATE TABLE SYSDBA.T_BAK_DEMO (ID INT PRIMARY KEY, NAME VARCHAR(50), TS TIMESTAMP DEFAULT SYSDATE);
INSERT INTO SYSDBA.T_BAK_DEMO(ID, NAME) VALUES (1, '备份前数据A');
INSERT INTO SYSDBA.T_BAK_DEMO(ID, NAME) VALUES (2, '备份前数据B');
COMMIT;
SELECT COUNT(*) AS CNT FROM SYSDBA.T_BAK_DEMO;
实测：
行号 CNT
---------- --------------------
1 2
步骤 2：执行全量备份
[dmdba]$ /home/dmdba/scripts/dm_backup.sh full [2026-09-21 09:31:53] 开始 FULL 备份 → /dmdata/dmbak/full_20260921_093153 [2026-09-21 09:31:57] FULL 备份完成：耗时 4s，备份集大小 22M [2026-09-21 09:31:58] 校验通过：/dmdata/dmbak/full_20260921_093153
⚠️ 目录名必须替换成你自己的
脚本按时间戳命名备份集，每次执行都不一样。下文步骤 5、6 中出现的/dmdata/dmbak/full_20260921_093153是本次实测值。
你执行时须把它替换成自己脚本实际输出的那一行目录（共 4 处：DUMP、RESTORE、RECOVER，以及CHECK BACKUPSET校验命令）。
照抄本页示例目录名，会一路报"备份集不存在"——这是本演练最高频的失败原因。
步骤 3：写入第 3 条数据（制造"备份后"差异）
INSERT INTO SYSDBA.T_BAK_DEMO(ID, NAME) VALUES (3, '备份后新增数据C');
COMMIT;
SELECT COUNT(*) AS CNT FROM SYSDBA.T_BAK_DEMO;
实测：CNT = 3（此时原库 3 条，备份集内只有 2 条）。
步骤 4：停止原库，在目标目录 dminit 建同参数空实例
[root]# systemctl stop DmServiceDMDB
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ ./dminit PATH=/dmdata/data/DMDB_R DB_NAME=DMDB INSTANCE_NAME=DMSERVER_R PORT_NUM=5237 \
PAGE_SIZE=16 EXTENT_SIZE=32 CASE_SENSITIVE=Y CHARSET=1 BLANK_PAD_MODE=1 PAGE_CHECK=1 \
LOG_SIZE=256 SYSDBA_PWD='Dm9@SysDba#2026' SYSAUDITOR_PWD='Dm9@Audit#2026'
# 实测：create dm database success. 2026-09-21 09:32:29
参数必须与备份源库一致（页大小、簇大小、大小写敏感、字符集等），否则还原会因页结构不匹配而失败。注意不要加
COMPATIBLE_MODE（见 13.7.3 踩坑说明）。
步骤 5：生成映射文件并改写目标路径
# 生成映射文件（DMAP），把备份集内的文件路径"映射"到目标位置
[dmdba]$ ./dmrman CTLSTMT="DUMP BACKUPSET '/dmdata/dmbak/full_20260921_093153' \
DATABASE '/dmdata/data/DMDB_R/DMDB/dm.ini' MAPPED FILE '/tmp/dm_map.txt'" </dev/null
# 实测：dump mapped file successfully.
# 【实测更正】本步骤无需手工改写——早期版本给出的 sed 改写属"多余动作"（无害）
# 原因：DUMP 生成映射文件时，已按 DATABASE 参数把 data_path 直接写成了新实例路径。
# 正确做法是先确认，而不是盲目 sed：
[root]# grep 'data_path' /tmp/dm_map.txt
# 期望：data_path = "/dmdata/data/DMDB_R/DMDB/xxx.DBF" —— 已是新路径，无需再改
映射文件内容形如：
/**=============================================================**/
/*[DMDB_SYSTEM_FIL_0]*/
fil_id = 0
ts_id = 0
ts_name = "SYSTEM"
data_path = "/dmdata/data/DMDB_R/DMDB/SYSTEM.DBF"
mirror_path =
...
/*[DMDB_MAIN_FIL_0]*/
data_path = "/dmdata/data/DMDB_R/DMDB/MAIN.DBF"
只改
data_path，不要改mirror_path——映射文件头部注释已明确：Modify the data_path or mirror_path only in one group。
步骤 6：三步恢复
# ① RESTORE：还原数据文件
[dmdba]$ ./dmrman CTLSTMT="RESTORE DATABASE '/dmdata/data/DMDB_R/DMDB/dm.ini' \
FROM BACKUPSET '/dmdata/dmbak/full_20260921_093153' MAPPED FILE '/tmp/dm_map.txt'" </dev/null
# ② RECOVER：重做日志至一致状态
[dmdba]$ ./dmrman CTLSTMT="RECOVER DATABASE '/dmdata/data/DMDB_R/DMDB/dm.ini' \
FROM BACKUPSET '/dmdata/dmbak/full_20260921_093153'" </dev/null
# ③ RECOVER UPDATE DB_MAGIC：更新数据库魔数（异目录恢复必需）
[dmdba]$ ./dmrman CTLSTMT="RECOVER DATABASE '/dmdata/data/DMDB_R/DMDB/dm.ini' UPDATE DB_MAGIC" </dev/null
实测输出（三步全部成功）：
# ① RESTORE
[Percent:100.00%][Speed:2133.54M/s][Cost:00:00:02][Remaining:00:00:00]
restore successfully.
time used: 00:00:02.467
# ② RECOVER
[Percent:100.00%][Speed:0.00PKG/s][Cost:00:00:00][Remaining:00:00:00]
recover successfully!
time used: 00:00:03.250
# ③ RECOVER UPDATE DB_MAGIC
recover successfully!
time used: 00:00:01.247
步骤 7：启动还原库并验证数据
# 还原库使用独立端口 5237，避免与原库冲突
[dmdba]$ cd /home/dmdba/dmdbms/bin
[dmdba]$ nohup ./dmserver /dmdata/data/DMDB_R/DMDB/dm.ini -noconsole > /tmp/dmdb_r.log 2>&1 &
# 连接还原库查询
[dmdba]$ ./disql -S 'SYSDBA/"Dm9@SysDba#2026"@127.0.0.1:5237' @/tmp/verify.sql
-- verify.sql
SET PAGESIZE 0
SELECT COUNT(*) AS 还原库行数 FROM SYSDBA.T_BAK_DEMO;
SELECT ID, NAME FROM SYSDBA.T_BAK_DEMO ORDER BY ID;
EXIT;
实测结果（决定性证据）：
行号 还原库行数
---------- --------------------
1 2
行号 ID NAME
---------- ----------- ----------
1 1 备份前数据A
2 2 备份前数据B
原库侧核对（演练清理后，原库 5236 保留全部 3 条，与还原库的 2 条形成对照）：
行号 原库行数 ---------- -------------------- 1 3 行号 ID NAME ---------- ----------- ---------------------- 1 1 备份前数据A 2 2 备份前数据B 3 3 备份后新增数据C两库对照才是完整证据链：还原库 2 条（缺 C）证明备份集冻结在备份时刻；原库 3 条（含 C）证明演练未动生产数据。
13.7.5 验证结论
| 对比项 | 原库（备份后） | 还原库（从备份集恢复） | 结论 |
|---|---|---|---|
| 记录数 | 3 条 | 2 条 | ✅ 精确回到备份时刻 |
| 数据内容 | A、B、C | A、B | ✅ 不含备份后写入的 C |
| 服务状态 | 运行中（5236） | 正常启动（5237） | ✅ 备份集可独立启动 |
✅ 备份准确性验证通过
还原库数据为
备份前数据A、备份前数据B两条，恰好缺少备份后写入的备份后新增数据C。这精确证明：
- 备份集完整可用——可成功 RESTORE + RECOVER 并独立启动；
- 备份时间点准确——数据精确冻结在备份执行的那一刻；
- 备份与归档的内容一致——
RESTORE与RECOVER使用同一备份集，恢复结果自洽。至此，本章"编辑脚本备份 + 验证备份准确性"两项要求均已通过实测闭环。
13.7.6 演练后环境清理
演练完成后必须清理测试实例、恢复原库，避免残留实例占用资源或端口：
# 1) 停止还原库进程（按端口查 PID，避免 pkill -f 自匹配导致命令异常终止）
[root]# PID=$(ss -lntp 2>/dev/null | grep ':5237' | grep -oE 'pid=[0-9]+' | head -1 | cut -d= -f2)
[root]# [ -n "$PID" ] && kill $PID
[root]# sleep 5
[root]# ss -lntp | grep 5237 || echo '5237 已停止'
# 2) 删除还原测试目录
[root]# rm -rf /dmdata/data/DMDB_R
[root]# ls -ld /dmdata/data/DMDB_R 2>&1 || echo 'DMDB_R 已删除'
# 3) 启动原库（systemd 方式，恢复服务托管）
[root]# systemctl start DmServiceDMDB
[root]# sleep 6
[root]# systemctl is-active DmServiceDMDB
[root]# ss -lntp | grep 5236
实测输出：
active LISTEN 0 128 [::]:5236 [::]:* users:(("dmserver",pid=25135,fd=3))
⚠️ 实测踩坑：
pkill -f会自匹配早期版本给出的
pkill -f "DMDB_R/DMDB/dm.ini"在远程脚本/管道中执行时，会因为匹配串同时出现在当前 shell 的命令行里而把自己 kill 掉，导致后续rm、systemctl start全部中断。正确做法是通过端口找 PID 再kill（如上），或使用fuser -k 5237/tcp。演练纪律：生产环境的恢复演练必须在独立目录、独立端口进行，绝不可在原库目录就地恢复。演练前务必确认已完成一次可用的全量备份，演练后及时清理。
13.8 备份失败常见问题
| 现象 | 根因 | 解决方式 |
|---|---|---|
[-8003] 缺少本地或者远程归档 |
未开启归档 | 先完成第 12 章归档配置 |
RMAN[-137] 服务器正在运行 |
数据库运行中调用 dmrman |
停库后使用，或改用 SQL 在线备份 |
RMAN[-104] INI参数文件错误 |
异目录恢复时目标目录无 dm.ini |
先用 dminit 建同参数空实例，再基于其 dm.ini 恢复（13.7.3） |
RMAN[-803] 非法INI配置值 |
手工 sed 改 INI 引入非法格式 |
用 dminit 生成干净 dm.ini，不要手工编辑路径参数 |
RMAN[-8287] 映射文件路径无效 |
映射文件未生成或路径错误 | 先执行 DUMP BACKUPSET ... MAPPED FILE 生成映射文件 |
DM[-124] SYSTEM.DBF文件不存在 |
目标目录缺数据文件占位 | 目标实例须由 dminit 初始化（已含数据文件），再 RESTORE |
dminit 报 Invalid parameter:COMPATIBLE_MODE |
dminit 不接受该参数 |
去掉该参数，实例建好后通过 dm.ini 设置 |
脚本报 tee: Permission denied |
日志目录被 root 创建 | chown -R dmdba:dinstall /dmdata/dmbak |
| 脚本报"未开启归档"但实际已开 | grep '^Y' 匹配不到（输出含行号） |
改用 grep -oE '[YN]' | head -1 提取 |
dmrman 无限输出 RMAN> |
未重定向标准输入 | 所有 dmrman 调用追加 </dev/null |
| 备份集撑满备份卷 | 未配置保留策略 | 配置脚本保留份数，并监控备份卷使用率 |
第 14 章 部署后验证
请逐项执行并在附录 E 记录结果，全部通过后方可交付。
14.1 服务与进程验证
[root]# systemctl is-active DmServiceDMDB DmAPService
[root]# ps -ef | grep dmserver | grep -v grep
[root]# netstat -lntp | grep 5236
实测结果：
DmServiceDMDB : active / enabled
DmAPService : active / enabled
dmserver 进程 : dmdba 22760 1 18 09:15 ? 00:00:03 dmserver path=/dmdata/data/DMDB/dm.ini -noconsole
5236 端口 : LISTEN 0 128 [::]:5236 users:(("dmserver",pid=22760,fd=3))
14.2 客户端连接验证
使用达梦命令行客户端 disql 登录（注意引号位置，写法错误会导致登录失败）：
[dmdba]$ cd /home/dmdba/dmdbms/bin
# 正确写法：整个连接串用【单引号】包裹，密码用【双引号】包裹
[dmdba]$ ./disql 'SYSDBA/"Dm9@SysDba#2026"@localhost:5236'
登录成功输出（实测）：
服务器[localhost:5236]:处于普通打开状态
登录使用时间 : 1.806(ms)
disql V9
SQL>
⚠️ 易错写法（实测踩坑，务必避免）
以下两种写法都会直接打出用法帮助、无法登录：
# ✗ 错误1：只在密码外加引号，连接串未整体加引号 ./disql SYSDBA/'Dm9@SysDba#2026'@localhost:5236 # ✗ 错误2：密码不加任何引号，# 会被 shell 当注释截断 ./disql SYSDBA/Dm9@SysDba#2026@localhost:5236原因：
#在 shell 中是注释起始符，@是 disql 连接串的分隔符。只有当整个连接串被单引号包裹、密码被双引号包裹时，shell 才会把这串字符原样交给 disql 解析。记住口诀：外单内双。正确写法要点：
- 外层用单引号
'...'——阻止 shell 解释#；- 密码用双引号
"..."——disql 解析连接串时能正确识别带特殊字符的密码；@只应出现在用户名与地址之间的分隔位置一次（密码内的@由引号保护）。
静默执行 SQL（脚本自动化推荐）：
# -S 隐藏模式；-e 直接执行 SQL（注意是小写 -e，大小写均可但建议统一小写）
[dmdba]$ ./disql -S 'SYSDBA/"Dm9@SysDba#2026"@localhost:5236' -e "SELECT NAME, STATUS$ FROM V\$INSTANCE;"
批量脚本执行的工程化写法（最稳妥）：不要让密码经过多层 shell 引号。将登录串与 SQL 分别写入文件再传参：
# 登录串写入文件，彻底规避 # 被 shell 当注释截断
printf 'SYSDBA/"Dm9@SysDba#2026"@127.0.0.1:5236' > /tmp/_conn.txt
# SQL 写入文件，用 @ 语法交给 disql 执行
printf 'SET PAGESIZE 0\nSELECT NAME, STATUS$ FROM V$INSTANCE;\nEXIT;\n' > /tmp/_q.sql
# 文件读取用双引号包裹命令替换；末尾 </dev/null 防止交互挂起
./disql -S "$(cat /tmp/_conn.txt)" @/tmp/_q.sql </dev/null
该写法已在本次实测中反复验证稳定，推荐作为自动化脚本的标准模板使用。另需注意：
- 交互式直连时若结果过多出现分页等待，执行前先
SET PAGESIZE 0；- 远程批处理务必加
</dev/null与timeout，避免因等待输入而挂起任务。
基础查询验证：
-- 数据库版本
SELECT * FROM V$VERSION;
实测输出：
BANNER
---------------------------------
DM Database Server 64 V9
DB Version: 0x7000d
03151060506-20260417-322930-20218
Msg Version: 3
Gsu level(5) cnt: 102
-- 实例运行状态（STATUS$ 为 OPEN、MODE$ 为 NORMAL 表示正常）
SELECT NAME, STATUS$, MODE$ FROM V$INSTANCE;
实测输出：
NAME STATUS$ MODE$
-------- ------- ------
DMSERVER OPEN NORMAL
-- 数据文件清单
SELECT PATH, STATUS$, TOTAL_SIZE FROM V$DATAFILE ORDER BY PATH;
实测输出（TOTAL_SIZE 单位为数据页数，按本环境 PAGE_SIZE=16 KB 折算）：
PATH STATUS$ TOTAL_SIZE
----------------------------- ----------- --------------------
/dmdata/data/DMDB/MAIN.DBF 1 8192 → 128 MB
/dmdata/data/DMDB/ROLL.DBF 1 8192 → 128 MB
/dmdata/data/DMDB/SYSAWR.DBF 1 327680 → 5 GB（SYSAUX 表空间）
/dmdata/data/DMDB/SYSTEM.DBF 1 12288 → 192 MB（运行中已增长）
/dmdata/data/DMDB/TEMP.DBF 1 4096 → 64 MB
重要：数据文件个数取决于是否启用 AWR——4 个还是 5 个，别漏掉
SYSAWR.DBF早期版本的本指南与部分资料只列出
MAIN/ROLL/SYSTEM/TEMP四个数据文件，遗漏了SYSAWR.DBF。它属于SYSAUX表空间（表空间 ID=5），实测大小为 5120 MB（5 GB），是实例目录中体积最大的单个文件。关于它的来历，本次已用日志与视图双重确证：
dminit初始化日志中只有SYSTEM.DBF/MAIN.DBF/ROLL.DBF，没有SYSAWR.DBF；实例首次启动也不会自动创建它；- 它由一次 AWR 初始化操作创建——
CALL SP_INIT_AWR_SYS(1)（实测SELECT SF_CHECK_AWR_SYS FROM DUAL返回1）。dm_DMSERVER_202609.log留有完整动作链：
ctl_add_table_space_ex_low.lst_table_spaces add, TS_name[SYSAUX]TS_id=5→ifun_add_file_low initialize file[0] of ts[5], file_path[/dmdata/data/DMDB/SYSAWR.DBF]，且创建前先自动备份了dm.ctl。对部署的直接意义：数据文件个数取决于是否启用 AWR——未启用时为 4 个（
SYSTEM/ROLL/MAIN/TEMP），启用后增加SYSAWR.DBF变为 5 个。做容量规划时，实例基线 = 重做日志（LOG_SIZE×2）+ 数据文件；若启用 AWR，须额外计入 SYSAUX 的 5 GB。详见第 1 章与附录 D。
-- 表空间清单（未启用 AWR 为 4 个；执行 SP_INIT_AWR_SYS(1) 后增加 SYSAUX，变为 5 个）
SELECT ID, NAME, TYPE$, STATUS$ FROM V$TABLESPACE ORDER BY ID;
实测输出：
ID NAME TYPE$ STATUS$
----------- ------ ----------- -----------
0 SYSTEM 1 0
1 ROLL 1 0
3 TEMP 2 0
4 MAIN 1 0
5 SYSAUX 1 0
-- 各表空间对应的数据文件与容量（更直观）
SELECT TABLESPACE_NAME, FILE_NAME, BYTES/1024/1024 AS MB FROM DBA_DATA_FILES ORDER BY TABLESPACE_NAME;
实测输出：
TABLESPACE_NAME FILE_NAME MB
--------------- ---------------------------- --------------------
MAIN /dmdata/data/DMDB/MAIN.DBF 128
ROLL /dmdata/data/DMDB/ROLL.DBF 128
SYSAUX /dmdata/data/DMDB/SYSAWR.DBF 5120
SYSTEM /dmdata/data/DMDB/SYSTEM.DBF 192
TEMP /dmdata/data/DMDB/TEMP.DBF 64
不可修改参数的验证方式（重要）
这六项参数不会出现在 V$PARAMETER 视图中，只能通过以下两种方式验证：
方式一：系统函数（推荐，最权威）
SELECT SF_GET_PAGE_SIZE() AS PAGE_SIZE,
SF_GET_EXTENT_SIZE() AS EXTENT_SIZE,
SF_GET_UNICODE_FLAG() AS CHARSET,
SF_GET_CASE_SENSITIVE_FLAG() AS CASE_SENSITIVE
FROM DUAL;
实测输出：
PAGE_SZ EXT_SZ CHARSET CASE_SENS
----------- ----------- ----------- -----------
16384 32 1 1
解读：PAGE_SZ=16384 字节 = 16 KB ✓；EXT_SZ=32 ✓；CHARSET=1（UTF-8）✓；CASE_SENS=1（敏感）✓。
方式二：查看 dminit 初始化日志（最完整，六项全覆盖）
SF_GET_*() 函数只能覆盖 4 项。若要一次拿到全部创建期参数，最权威的依据是 dminit 留下的初始化日志：
[root]# cat /home/dmdba/dmdbms/log/dminit_<数据库名>_<时间戳>.log
实测输出（节选，本环境为 dminit_DMDB_20260914131014.log）：
start init database: V9, 2026-09-14 13:10:14
init params:
db path: /dmdata/data/DMDB
db name: DMDB
page size: 16384 ← PAGE_SIZE = 16 KB
extent size: 32 ← EXTENT_SIZE = 32
string case sensitive: 1 ← CASE_SENSITIVE = 1（大小写敏感）
charset: 1 ← CHARSET = 1（UTF-8）
page check mode: 1 ← PAGE_CHECK = 1（CRC 校验）
blank pad mode: 1 ← BLANK_PAD_MODE = 1（兼容空格填充）
auto_adj_para: 1 ← AUTO_ADJ_PARA = 1（INI 参数自动调优已开启）
...
create dm database success. 2026-09-14 13:10:14
上表仅节选与本指南相关项，实际日志含 23 项初始化参数。建议部署完成后立即归档该日志——它是这六项参数唯一的原始落地记录，日后核对实例规格时会用到。
重要澄清：这六项参数不在
dm.ini中（易踩坑）一个很容易踩的坑：按 DM8 的习惯去
dm.ini里执行
grep -E 'PAGE_SIZE|EXTENT_SIZE|CASE_SENSITIVE|CHARSET|BLANK_PAD_MODE|PAGE_CHECK'，
结果只会返回COMPATIBLE_MODE（而它并不属于这六项）。经本次实测确认：DM9 的dm.ini中完全不存在上述六项参数。原因是 DM9 把参数分成了两类：
- 创建期参数（页大小、簇大小、字符集、大小写敏感、空格填充、页校验）——固化进控制文件
dm.ctl，不参与dm.ini的参数加载；- 可调参数（
BUFFER、MAX_SESSIONS、COMPATIBLE_MODE等）——写入dm.ini供调优。这恰好解释了为什么这六项"永久不可修改"——它们根本不在可编辑的参数文件里。
同理，
V$DM_INI视图中也查不到这六项（实测仅能查到BLANK_PAD_MODE、PAGE_CHKSUM_POLICY两项）。结论：验证创建期参数请用方式一（
SF_GET_*()函数）或方式二（dminit日志），不要用grep dm.ini。
补充说明：
dm.ini的参数行带前导制表符
查询dm.ini中可调参数（如PORT_NUM、COMPATIBLE_MODE）时，需注意参数行以两个 Tab 缩进开头，故grep '^PORT_NUM'匹配不到，应写作grep -E '^[[:space:]]*PORT_NUM'。
14.3 建表与读写功能验证
以 SYSDBA 登录后执行：
-- 创建验证用户
CREATE USER DMVERIFY IDENTIFIED BY "Dm9@Verify#2026";
-- 创建测试表
CREATE TABLE DMVERIFY.T_CHECK (
ID INT PRIMARY KEY,
C_NAME VARCHAR(64),
C_TIME TIMESTAMP DEFAULT SYSDATE
);
-- 插入数据（含中文）
INSERT INTO DMVERIFY.T_CHECK (ID, C_NAME) VALUES (1, '达梦数据库 DM9 部署验证');
INSERT INTO DMVERIFY.T_CHECK (ID, C_NAME) VALUES (2, 'DM9 on CentOS 7.9 单机部署');
INSERT INTO DMVERIFY.T_CHECK (ID, C_NAME) VALUES (3, '中文字符集：数据库-表空间-归档 OK');
COMMIT;
-- 查询验证
SELECT ID, C_NAME FROM DMVERIFY.T_CHECK ORDER BY ID;
SELECT COUNT(*) AS CNT FROM DMVERIFY.T_CHECK;
实测输出：
1 1 达梦数据库 DM9 部署验证
2 2 DM9 on CentOS 7.9 单机部署
3 3 中文字符集：数据库-表空间-归档 OK
1 3
DM9 语法提醒：DM9 不支持
DROP USER IF EXISTS <user> CASCADE语法，会报[-2007] 语法分析出错。清理时请先判断对象是否存在，或直接执行DROP USER <user> CASCADE并容忍"对象不存在"的报错。
14.4 兼容模式与函数验证
-- 兼容模式下的常用函数
SELECT NVL(NULL, 'NVL函数可用') AS NVL_TEST FROM DUAL;
SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS SYS_DATE FROM DUAL;
实测输出：
1 NVL函数可用
1 2026-09-21 09:54:22
UTF-8 字符集验证：
SELECT LENGTH('中文测试') AS CHAR_LEN, LENGTHB('中文测试') AS BYTE_LEN FROM DUAL;
实测输出：
1 4 12
解读：4 个中文字符，占 12 字节（每字 3 字节）——证明字符集为 UTF-8（若为 GB18030 则为 8 字节）。
-- 清理验证对象（注意：必须先删表再删用户；用户下若仍有对象，直接 DROP USER 会报 [-2639] 试图删除被依赖对象）
DROP TABLE DMVERIFY.T_CHECK;
DROP USER DMVERIFY;
更稳妥的清理写法：若不确定用户名下是否还有残留对象，直接加
CASCADE级联删除：DROP USER DMVERIFY CASCADE;注意 DM9 不支持
DROP USER IF EXISTS <user> CASCADE语法（会报[-2007] 语法分析出错），请勿混用。
14.5 服务重启验证
[root]# systemctl restart DmServiceDMDB
[root]# sleep 15
[root]# systemctl is-active DmServiceDMDB
# 实测：active
重启后再次用 disql 登录，确认数据完好、无恢复报错。
14.6 开机自启验证
[root]# systemctl is-enabled DmServiceDMDB DmAPService
# 实测：均为 enabled
实测输出（重启后服务正常、开机自启均为 enabled）：
--- 14.5 重启服务 --- is-active: active --- 14.6 开机自启 --- enabled enabled
14.7 备份功能验证（关键）
这是最容易遗漏、后果最严重的一项。完整方法、脚本与恢复演练见第 13 章，此处仅给出验收所用的最小验证动作。
在线备份（数据库运行中，推荐）——需先完成第 12 章归档配置：
BACKUP DATABASE FULL BACKUPSET '/dmdata/dmbak/bak_full_final';
实测输出（成功创建备份集）：
[root]# ls -lh /dmdata/dmbak/bak_full_final/
total 18M
-rw-r--r-- 1 dmdba dinstall 89K bak_full_final_1.bak
-rw-r--r-- 1 dmdba dinstall 18M bak_full_final.bak
-rw-r--r-- 1 dmdba dinstall 122K bak_full_final.meta
验收要求：备份集整目录保留（
.bak+.meta，全量另有_1.bak），并通过dmrman CHECK BACKUPSET校验（见 13.6 节）。仅生成文件不代表备份可用——校验通过才算数。
14.8 最终验收核对
| 序号 | 检查项 | 期望结果 | 实测 |
|---|---|---|---|
| 1 | 操作系统服务 | DmServiceDMDB 为 running、enabled | ✅ |
| 2 | 辅助进程服务 | DmAPService 为 running | ✅ |
| 3 | 数据库进程 | dmserver 进程存在 | ✅ |
| 4 | 端口监听 | 5236 处于 LISTEN | ✅ |
| 5 | disql 连接 | 可正常登录 | ✅ |
| 6 | 参数核对 | PAGE_SIZE=16K、EXTENT_SIZE=32、CHARSET=UTF-8、CASE_SENSITIVE=Y | ✅ |
| 7 | 建表读写 | DDL/DML 均正常 | ✅ |
| 8 | 中文存储 | 中文与特殊字符无乱码 | ✅ |
| 9 | 兼容模式 | COMPATIBLE_MODE=2 | ✅ |
| 10 | 归档模式 | V$DATABASE.ARCH_MODE = Y | ✅ |
| 11 | 服务重启 | 停止后可正常启动，数据完好 | ✅ |
| 12 | 开机自启 | is-enabled 返回 enabled | ✅ |
| 13 | 在线备份 | BACKUP DATABASE 成功生成备份集 | ✅ |
| 14 | 备份集校验 | dmrman CHECK BACKUPSET 输出 successfully |
✅ |
| 15 | 恢复演练 | 异目录恢复后数据与备份时刻一致 | ✅ |
| 16 | 存储规划 | 三个目录分别挂载独立 LV，类型 ext4 | ✅ |
第 15 章 日常运维要点
15.1 开机自启服务清单
| 服务 | 作用 |
|---|---|
DmServiceDMDB |
数据库实例服务 |
DmAPService |
辅助进程服务（备份依赖） |
[root]# systemctl enable DmServiceDMDB DmAPService
15.2 备份日常管理
备份策略设计、脚本、校验与恢复演练已在第 13 章详述，日常运维阶段重点关注三件事：
- 确认定时任务在跑——检查
crontab -l与备份日志/dmdata/dmbak/log/dm_backup_YYYYMM.log，确保每日有成功记录； - 关注保留策略与空间——备份卷使用率超过 80% 需告警，及时调整
KEEP_FULL/KEEP_INCR； - 定期做恢复演练——至少每季度按 13.7 节方法演练一次，验证备份真实可用。
备份三原则：必须可还原（定期演练）、必须异地存放（防机房级故障）、必须有人看结果（失败要告警）。
15.3 归档日志管理
归档日志会持续增长，需配合 dmarch.ini 中的 ARCH_SPACE_LIMIT 与定期备份清理：
# dmarch.ini 中限制归档空间上限（MB），防止撑满磁盘
ARCH_SPACE_LIMIT = 102400 # 100 GB
归档目录写满是数据库挂起的头号原因之一。务必：
- 归档目录独立成卷（本指南已实现）；
- 配置归档空间上限与自动清理；
- 对归档目录使用率设置 80% 告警。
15.4 监控重点指标
| 类别 | 关键指标 | 告警阈值建议 |
|---|---|---|
| 实例状态 | 实例状态、归档模式 | 非 OPEN / ARCH_MODE 非 Y 即告警 |
| 会话 | 活动会话数、阻塞会话 | 接近连接数上限 80% |
| 空间 | 表空间使用率、归档目录使用率 | 使用率 > 80% |
| 性能 | Buffer 命中率、磁盘 I/O 延迟 | 命中率骤降、延迟突增 |
| 服务 | DmServiceDMDB、DmAPService 状态 | 任一非 running |
| 存储 | LV 使用率、inode 使用率 | 使用率 > 80% |
15.5 数据安全与合规提示
- 密码管理：首次部署后立即修改默认口令，生产密码由密码管理系统统一生成与轮换，禁止明文记录在文档或脚本中；
- 最小权限：应用连接使用独立业务账号，禁止应用直接使用 SYSDBA；
- 审计：安全版需启用 SYSAUDITOR 审计策略，满足等保合规要求；
- 脱敏：生产数据的备份集、导出文件在交付、测试、开发过程中必须脱敏；
- 日志留存：运行日志、审计日志按合规要求留存，不得随意清理。
第 16 章 DM9 数据库干净卸载
部署能力之外，能否干净卸载同样是数据库工程化的基本素养：测试环境反复重装、故障节点重建、下线退役、从测试切正式，都要求"卸载后不留残余"。本章给出经服务器实测验证的完整卸载流程，覆盖"软件卸载 → 服务卸载 → 残留清理 → 资源回收"四个层次，最终把主机还原到"从未装过达梦"的状态。
16.1 卸载前必读（三条铁律）
⚠️ 第一条：卸载不可逆，先备份再动手
卸载会删除实例进程、操作系统服务与软件目录；若连同数据目录一起清理，则数据不可恢复。卸载前必须确认：
- 已有可用且已验证的备份集（按第 13 章做完整备份 +
dmrman CHECK BACKUPSET校验通过）；- 或已确认该库确实无需保留（测试环境）。
⚠️ 第二条：确认无业务连接
卸载前须确认无应用、无调度任务、无外部连接正在使用该实例，否则会造成业务中断。检查方法：V$SESSIONS中除自身外无活动会话，或业务侧已确认停用。
⚠️ 第三条：区分"软件卸载"与"数据清理"
达梦卸载程序只删软件，不删数据。本节把卸载分为两层，按需选择：
- 轻量卸载（保留数据）：仅卸载软件与服务，保留实例目录与数据 → 适用于"重装软件、数据不动"；
- 彻底卸载（清空一切）：在轻量卸载基础上，追加清理数据/LVM/用户 → 适用于"整机交付、测试重建"。
本章按彻底卸载标准演示（测试环境），并在 16.8 节给出生产环境的保留建议。
16.2 卸载流程总览
| 步骤 | 动作 | 执行用户 | 关键命令/文件 | 是否可逆 |
|---|---|---|---|---|
| 1 | 停止数据库服务 | root | systemctl stop |
可逆（可重启） |
| 2 | 卸载操作系统服务 | root | dm_service_uninstaller.sh |
可逆（可重注册） |
| 3 | 卸载数据库软件 | dmdba | uninstall.sh -i |
不可逆 |
| 4 | 清理软件残留 | root | rm 残留目录/文件 |
不可逆 |
| 5 | 清理资源层 | root | 卸载 LV/VG/PV、删用户、清 fstab | 不可逆 |
| 6 | 卸载后验证 | root | 全景核验清单 | — |
顺序不可颠倒：必须先停服、再卸服务，最后卸软件。若直接删软件目录，操作系统服务会残留为"僵尸单元"（
systemctl仍可见但找不到二进制），清理更麻烦。
16.3 第一步：停止数据库服务
卸载前必须让数据库干净停机，避免残留进程占用端口与文件句柄。
# 查看当前服务状态
[root]# systemctl status DmServiceDMDB --no-pager
# 停止实例服务与辅助进程服务
[root]# systemctl stop DmServiceDMDB
[root]# systemctl stop DmAPService
# 验证：应无 dmserver/dmap 进程，端口 5236/4236 已释放
[root]# ps -ef | grep -E 'dmserver|dmap' | grep -v grep
[root]# ss -lntp | grep -E '5236|4236'
实测结果：systemctl stop 退出码为 0，进程与端口全部释放。
多实例场景：若同一主机部署了多个实例（服务名不同），需逐一停止：
systemctl stop DmService<实例名>，可先用systemctl list-unit-files | grep DmService列出全部实例服务。
16.4 第二步：卸载操作系统服务
达梦注册的 systemd 服务不会随软件目录删除而自动消失，必须用专用脚本卸载。
先查看卸载脚本用法：
[root]# /home/dmdba/dmdbms/script/root/dm_service_uninstaller.sh -h
实测输出：
Usage: dm_service_uninstaller.sh [-n service_name] | [-h]
卸载全部达梦服务（逐一卸载）：
[root]# cd /home/dmdba/dmdbms/script/root
# 实例服务
[root]# ./dm_service_uninstaller.sh -n DmServiceDMDB
# 辅助进程服务
[root]# ./dm_service_uninstaller.sh -n DmAPService
# 三个监控服务（DM9 新增，默认 disabled，仍建议一并卸载）
[root]# ./dm_service_uninstaller.sh -n DmAuditMonitorService
[root]# ./dm_service_uninstaller.sh -n DmJobMonitorService
[root]# ./dm_service_uninstaller.sh -n DmInstanceMonitorService
交互确认说明：该脚本会交互式等待确认，非交互环境（脚本、自动化）须预先喂入
y：[root]# echo 'y' | ./dm_service_uninstaller.sh -n DmServiceDMDB
验证服务已卸载：
[root]# systemctl list-unit-files | grep -iE 'DmService|DmAPService|DmAudit|DmJob|DmInstance'
# 期望：无任何达梦服务；systemd 单元文件也应被清除
[root]# ls /usr/lib/systemd/system/Dm*.service 2>/dev/null || echo "✓ 单元文件已清除"
⚠️ 写自动化脚本时的致命正则陷阱（本指南实测踩到）
若用脚本自动发现需要卸载的服务名，下面这个看起来很自然的正则会漏掉实例服务：# ✗ 错误：匹配不到 DmServiceDMDB.service systemctl list-unit-files | awk '{print $1}' | grep -E '^Dm.*Service\.service$'原因：该正则要求
Service与.service紧挨着，而实例服务的实际名字是
DmService+DMDB+.service—— 中间插了实例名，所以永远不匹配。
后果是实例服务既没停也没卸，而脚本输出看起来"一切正常"，直到最后核验才发现。# ✓ 正确：只要求以 Dm 开头、以 .service 结尾 systemctl list-unit-files --type=service | awk '{print $1}' | grep -E '^Dm[^ ]*\.service$'自检习惯：任何"按名字批量操作服务"的脚本，先把匹配结果打印出来看一眼数量，再执行动作。
⚠️ 万一漏卸了实例服务怎么办
顺序颠倒会进入麻烦区：软件目录已被删除，dm_service_uninstaller.sh也没了，无法再按 16.4 节正规卸载。此时按以下方式手工清理残留（效果等价）：[root]# systemctl stop DmServiceDMDB 2>/dev/null [root]# systemctl disable DmServiceDMDB 2>/dev/null [root]# rm -f /etc/systemd/system/multi-user.target.wants/DmServiceDMDB.service # 启动软链 [root]# rm -f /usr/lib/systemd/system/DmServiceDMDB.service # 单元文件 [root]# systemctl daemon-reload && systemctl reset-failed根因：卸载器（
uninstall.sh）只管"安装进去的部件"，不会替你卸注册过的 systemd 服务。
所以 16.3 → 16.4 → 16.5 的顺序不可颠倒——本指南把它列为三条铁律之一，原因就在这里。
⚠️ 切勿误删
dm-event.service/dm-event.socket！
这两个单元属于 Linux 内核的 device-mapper 事件服务（dm是 device-mapper 的缩写），与本产品毫无关系。执行systemctl list-unit-files | grep -i dm时它们会出现，切勿按名字前缀误判为达梦服务而删除，否则会破坏 LVM 事件机制。
16.5 第三步：卸载数据库软件
软件卸载由安装目录下的 uninstall.sh 完成，它是安装程序的"反向操作"，采用与安装一致的程序框架。
[root]# su - dmdba
[dmdba]$ cd /home/dmdba/dmdbms
[dmdba]$ ./uninstall.sh -i
卸载交互流程（实测确认，仅 2 步交互）：
# 步骤1：是否保留 dm_svc.conf 配置文件
保留dm_svc.conf配置文件?[Y/n]:
# 步骤2：确认卸载
确认卸载?[y/n]:
| 步骤 | 提示内容 | 建议输入 | 说明 |
|---|---|---|---|
| 1 | 保留dm_svc.conf配置文件?[Y/n] |
n |
n = 不保留，随软件一并删除；Y = 保留（用于卸载后重装、复用客户端连接配置） |
| 2 | 确认卸载?[y/n] |
y |
确认执行卸载 |
⚠️ 自动化陷阱：卸载器第一个提示不是选项编号，而是"是否保留 dm_svc.conf"。若沿用安装经验的
printf '1\n' |喂入编号，会报"输入非法"。正确的非交互写法是：[root]# su - dmdba -c "cd /home/dmdba/dmdbms && printf 'n\ny\n' | ./uninstall.sh -i"其中
n=不保留 dm_svc.conf，y=确认卸载。
卸载器实际动作序列（实测）：
正在删除服务...
正在删除环境变量...
正在删除组件内容...
正在删除配置...
卸载完成后可明显看到软件目录体积骤降。实测：/home/dmdba/dmdbms 由 1.5 GB → 2.8 MB（仅剩 log/ 目录）。
⚠️ 卸载器的关键行为（最易被误解）
卸载程序会明确提示：“卸载程序将删除系统上已经安装过的功能部件，但不会删除安装后创建的文件夹和文件。”这意味着两件事：
- 卸载器会自动清理：systemd 服务、
/etc/dm*（如dm_svc.conf）、~/.bash_profile中的环境变量——这些无需手工处理；- 卸载器不会清理：安装后新生成的运行期目录（如
dmdbms/log/）与用户自己创建的文件（如家目录下的备份脚本、数据目录）——这些必须手工清理，否则残留会留下"卸载不干净"的假象。
16.6 第四步：清理软件残留
卸载器删除的是"安装进去的部件"，安装之后产生的东西需要人工清理。逐项核对：
# 1) 删除软件目录残留（含卸载后残留的 log 目录）
[root]# rm -rf /home/dmdba/dmdbms
[root]# ls /home/dmdba/dmdbms 2>/dev/null || echo "✓ dmdbms 已删除"
# 2) 清理用户家目录下的自建文件（备份脚本、临时 SQL、连接文件等）
[root]# rm -f /home/dmdba/dm_backup.sh
[root]# rm -rf /home/dmdba/scripts
[root]# rm -f /home/dmdba/*.sql /home/dmdba/conn.txt /home/dmdba/.dm_login
[root]# rm -rf /home/dmdba/.cache
# 3) 清理安装介质与临时解压目录（如需保留安装包则跳过）
[root]# rm -rf /tmp/dmpkg /tmp/dmsplit
[root]# rm -f /tmp/dmjar /tmp/dm_install_out.log /tmp/dm_silent.xml
# 4) 清理 ISO 挂载点（若残留循环挂载）
[root]# mount | grep dm9iso && umount /mnt/dm9iso
[root]# rmdir /mnt/dm9iso 2>/dev/null
[root]# losetup -a | grep -i dm9 || echo "✓ 无残留 loop 设备"
/etc与环境变量无需手工处理：卸载器已自动删除/etc/dm_svc.conf等配置，并清理.bash_profile中的DM_HOME/PATH设置。清理后可用grep -E 'DM_HOME|dmdbms' ~/.bash_profile复核，应无输出。
16.7 第五步：清理资源层（彻底卸载）
若要完全回收主机资源（整机释放、测试重建），需销毁本指南第 3 章创建的所有存储对象，并删除数据库专用用户。此步不可逆，执行前务必确认数据已备份或已确认无需保留。
# 1) 清空数据目录内容（防止误删系统目录，逐卷清理）
[root]# rm -rf /dmdata/data/* /dmdata/arch/* /dmdata/dmbak/*
# 2) 卸载文件系统
[root]# umount /dmdata/data
[root]# umount /dmdata/arch
[root]# umount /dmdata/dmbak
# 3) 从 /etc/fstab 移除数据卷条目（先备份 fstab！）
[root]# cp -a /etc/fstab /etc/fstab.bak.dm9
[root]# sed -i '/dmdata/d' /etc/fstab
[root]# grep -c dmdata /etc/fstab # 期望为 0
# 4) 逐层销毁 LVM：LV → VG → PV
[root]# lvremove -f dmvg/dmdata_lv
[root]# lvremove -f dmvg/dmarch_lv
[root]# lvremove -f dmvg/dmbak_lv
[root]# vgremove -f dmvg
[root]# pvremove -f /dev/sdd
# ⚠️ 追加一步：清除磁盘上残留的文件系统签名，把裸盘真正交还
[root]# wipefs -a /dev/sdd
# 5) 删除挂载点目录
[root]# rmdir /dmdata/data /dmdata/arch /dmdata/dmbak /dmdata
# 6) 清理资源限制配置
[root]# sed -i '/^dmdba /d' /etc/security/limits.conf
# ⚠️ 文件名必须与本指南实际创建的一致（第 2 章建 99-dm.conf，第 5.3 节建 zz-dm.conf）
[root]# rm -f /etc/security/limits.d/zz-dm.conf /etc/security/limits.d/99-dmdb.conf
[root]# rm -f /etc/sysctl.d/99-dm.conf /etc/sysctl.d/99-dmdb.conf
[root]# ls /etc/security/limits.d/ /etc/sysctl.d/ # 复核：已无本指南创建的文件
# 7) 清理开机脚本中的透明大页配置（第 2 章追加的片段）
# ⚠️ 只删本指南追加的那一段！同机其他产品的开机配置必须保留
[root]# cp -a /etc/rc.d/rc.local /etc/rc.d/rc.local.bak.dm9uninstall # 先备份
[root]# grep -n 'transparent_hugepage' /etc/rc.d/rc.local # 先看清有哪几处
[root]# vi /etc/rc.d/rc.local # 手工删掉本指南追加的 if test -f ... fi 区块
[root]# bash -n /etc/rc.d/rc.local && echo "语法 OK"
[root]# ls -l /etc/rc.d/rc.local # 复核：仍为 -rwxr-xr-x（可执行位不能丢）
# 8) 删除数据库专用用户与组（-r 连同家目录一并删除）
[root]# userdel -r dmdba
[root]# groupdel dinstall
为什么必须单独清理
rc.local（本指南实测补充）
第 2 章把"关闭透明大页"的配置追加进了/etc/rc.d/rc.local。这类系统级开机脚本不属于达梦软件，
卸载器不会动它，/etc/dm*通配也扫不到它 —— 不清理的话，主机重启后透明大页仍是关闭状态，
而这台机器已经"没有达梦"了。但绝不能整段删除：
rc.local往往还被同机其他产品（本例中是另一款数据库软件）用来设置
网络中断绑定、时钟源、CPU 调频等。只删本指南追加的那几行，删完必须：
①bash -n校验语法；②ls -l确认可执行位仍在（chmod +x丢失会导致整份脚本不再被执行，
而且不会报错，属静默失效）。同机部署其他产品时的定位技巧：先用
grep -n 'transparent_hugepage' /etc/rc.d/rc.local
看清一共几处。本指南追加的片段有明显的结构特征——被if test -f ...; then ... fi包裹（共 6 行）。
其他产品可能只写了一行裸echo never > ...，那一行不是本指南的，不要删。
实测验证（各步均回显成功）：
Logical volume "dmdata_lv" successfully removed
Logical volume "dmarch_lv" successfully removed
Logical volume "dmbak_lv" successfully removed
Volume group "dmvg" successfully removed
Labels on physical volume "/dev/sdd" successfully wiped.
userdel -r的注意事项：-r会连同家目录/home/dmdba一并删除。若家目录内有需保留的文件，执行前先转移。
fstab处理铁律：fstab写错会导致系统无法启动。改前先cp备份，改后用mount -a验证语法，切勿跳过。
16.8 生产环境的保留策略建议
生产环境通常不做 16.7 的资源层清理，而是采用"轻量卸载 + 数据保留"：
| 场景 | 建议做法 |
|---|---|
| 同机重装软件、数据保留 | 只做 16.3~16.6（停服→卸服务→卸软件→清软件残留），保留 /dmdata 数据目录与 LVM，重装后指向原实例目录即可复用数据 |
| 节点下线退役 | 先做一次完整备份并异地留存，再执行 16.3~16.7 彻底清理；备份集在确认数据可弃前不得删除 |
| 磁盘整块移交 | 执行 16.7 后，从 fstab 清理条目并销毁 LVM，把裸盘交还资源池 |
| 保留审计留痕 | 清理前导出一份 dm.ini、dmarch.ini 及运行日志存档，满足合规要求 |
数据安全红线：任何删除动作前，必须先确认备份可用。 “备份在，才有底气删”——这是数据库工程不可逾越的底线。
16.9 卸载后验证清单
卸载完成后，用以下 13 项清单做全景核验，全部通过方可认定"卸载干净"：
| # | 检查项 | 检查命令 | 期望结果 |
|---|---|---|---|
| 1 | 达梦进程 | ps -ef | grep -E 'dmserver|dmap|dmwatcher' | grep -v grep |
无输出 |
| 2 | 监听端口 | ss -lntp | grep -E '5236|4236' |
无输出 |
| 3 | 系统服务 | systemctl list-unit-files | grep -iE 'DmService|DmAPService' |
无输出（dm-event 属 OS，忽略） |
| 4 | 软件目录 | ls /home/dmdba/dmdbms 2>/dev/null |
不存在 |
| 5 | 数据目录 | ls /dmdata 2>/dev/null |
不存在（或按策略保留） |
| 6 | 用户/组 | id dmdba; getent group dinstall |
均无输出 |
| 7 | 环境变量 | grep -rn 'DM_HOME|dmdbms' /etc/profile /etc/profile.d/ ~/.bash_profile |
无输出 |
| 8 | /etc 配置 |
ls /etc/dm* 2>/dev/null |
不存在 |
| 9 | 资源限制 | grep dmdba /etc/security/limits.conf |
无输出 |
| 10 | 裸盘状态 | lsblk /dev/sdd |
仅 sdd 一行，无子设备 |
| 11 | LVM 卷组 | vgs | grep dmvg; grep -c dmdata /etc/fstab |
无输出 / 计数为 0 |
| 12 | systemd 单元文件 | ls /usr/lib/systemd/system/Dm*.service; ls /etc/systemd/system/multi-user.target.wants/ | grep -i dm |
均无输出（光看 list-unit-files 不够，见 16.4 节正则陷阱） |
| 13 | 开机脚本残留 | grep -c transparent_hugepage /etc/rc.d/rc.local；bash -n /etc/rc.d/rc.local |
仅剩其他产品的行；语法 OK 且仍可执行 |
本次实测核验结果：13 项全部通过。
第 12、13 项是"实测补出"的：本指南最初只列 11 项，按此清单核验时前 11 项全绿，
但服务器上实际仍残留着DmServiceDMDB.service单元文件与rc.local中的透明大页配置。
这说明——清单的完整性本身也需要验证：只跑清单、不质疑清单，会把"清单没覆盖"误判成"已经干净"。
--- A. 进程 --- ✓ 无达梦进程
--- B. 端口 --- ✓ 端口 5236/4236 已释放
--- C. 达梦服务 --- ✓ systemd 无达梦服务
--- D. 关键目录 --- ✓ 无 /home/dmdba ✓ 无 /dmdata ✓ 无 /opt/dmdbms
--- E. 用户/组 --- ✓ dmdba 用户已删除 ✓ dinstall 组已删除
--- F. 资源限制 --- ✓ limits.conf 无 dmdba ✓ 无 zz-dm.conf
--- G. 全局环境变量 --- ✓ 无达梦残留
--- H. 裸盘状态 --- NAME SIZE TYPE sdd 140G disk
--- I. 卷组 --- ✓ dmvg 已删除
--- J. fstab --- ✓ 无 dmdata 条目
--- K. 单元文件 --- ✓ /usr/lib/systemd/system/Dm*.service 已清除
--- L. rc.local --- ✓ 本指南追加的 THP 片段已移除，语法 OK 且可执行位保留
--- M. 未误伤（对本机其他产品）--- ✓ centos VG 完好 ✓ dm-event 仍在 ✓ 其他产品 limits 与 rc.local 行完好
--- N. 根分区空间 --- 7.0G / 69G（已回收）
核验补充说明（实测）：本环境
/dev/sdd上仍留有历史文件系统签名。彻底卸载时
建议追加wipefs -a /dev/sdd（在pvremove之后）——否则下次按第 3 章重建时，
lvcreate可能因检测到残留签名而弹出Wipe it? [y/n]交互提示，在非交互环境下会挂起
（本指南实测曾挂起 31 分钟）。更完整的说明见 3.2 节。
16.10 卸载常见问题
| 现象 | 根因 | 处理方式 |
|---|---|---|
uninstall.sh 报"输入非法"并中断 |
第一个提示是"是否保留 dm_svc.conf"，不是选项编号，喂入编号导致非法 | 按 printf 'n\ny\n' | ./uninstall.sh -i 输入（见 16.5 节） |
dm_service_uninstaller.sh 卡住不返回 |
脚本交互式等待确认 | 用 echo 'y' | 预先喂入确认，或在终端手工输入 y |
卸载后 systemctl 仍能看到达梦服务 |
只删了软件目录，未先卸服务 | 恢复软件目录→按 16.4 节用卸载脚本卸载服务→再卸软件；顺序不可颠倒 |
| 脚本自动发现服务时漏掉实例服务 | 用了 grep -E '^Dm.*Service\.service$ —— 该正则要求 Service 与 .service 相邻，而实际是 DmService+<实例名>+.service |
改用 grep -E '^Dm[^ ]*\.service$'；并先打印匹配结果数量再执行（见 16.4 节） |
| 前 11 项核验全绿，主机上仍有达梦痕迹 | 核验清单未覆盖 systemd 单元文件与 rc.local 开机脚本 |
按 16.9 节13 项清单核验（第 12、13 项为本轮实测补出） |
卸载后 /etc/rc.d/rc.local 里还留着"关闭透明大页" |
该配置由部署时追加到系统开机脚本，不属达梦软件，卸载器与 /etc/dm* 都扫不到 |
按 16.7 节第 7 步只删本指南追加的片段；删后 bash -n 校验语法、确认可执行位仍在 |
重装时 lvcreate 卡在 Wipe it? [y/n] |
/dev/sdd 上残留文件系统签名（彻底卸载未清） |
卸载时追加 wipefs -a /dev/sdd；或重装时按 3.2 节加 wipefs -a + -y |
| 卸载后磁盘空间没释放 | 卸载器不删数据目录与运行期目录 | 按 16.6~16.7 手工清理 /dmdata/*、dmdbms/log、/tmp 安装介质 |
误删 dm-event.service 导致 LVM 异常 |
dm-event 是内核 device-mapper 事件服务，非达梦服务 |
切勿删除；若已删除，用 yum reinstall device-mapper 恢复 |
userdel dmdba 报"用户正在使用" |
仍有进程以 dmdba 身份运行 | 先 pkill -u dmdba 或 /usr/sbin/logout，确认无进程后再删 |
| 卸载后主机名解析仍在 | /etc/hosts 中的主机记录未清理 |
达梦不使用 hosts 做数据库连接，该项可保留（属系统配置，非达梦残留） |
第 17 章 初次试用感受与心得
前面 16 章是"怎么做"，这一章讲讲"做下来是什么感受"。全部结论都来自本次在一台 4 核 / 16 GB 虚拟机上从零到备的完整体验，不做夸大，也不回避问题。
17.1 整体印象：一条"顺"但有"暗礁"的路
如果用一句话概括：主流程足够顺，顺畅程度超出预期；真正的成本不在主流程，而在那些官方文档未标注的行为变化上。
先看客观数据——本次全流程各阶段的实测耗时：
| 阶段 | 实测耗时 | 观察 |
|---|---|---|
| 系统环境准备 | 约 5 分钟 | 全为常规 Linux 操作 |
| 存储规划（LVM + ext4 + 挂载） | 约 5 分钟 | 命令标准，无达梦特有内容 |
| 创建用户与资源限制 | 约 4 分钟 | 常规 |
| 软件静默安装（含解压、校验） | 约 8 分钟 | 解压约占 6 分钟，是耗时最长的一步 |
实例初始化 dminit |
约 2 分钟 | 建库速度令人满意 |
| 服务注册与启动 | 约 3 分钟 | 一条命令注册，一条命令启动 |
| 归档配置（含一次重启） | 约 4 分钟 | 重启约 30 秒 |
| 首次全量备份 | 约 5 秒（18 MB） | 备份速度很快 |
| 首次增量备份 | 约 8 秒（4.2 MB） | 增量体积仅约全量的 1/4 |
合计约 35 分钟即可交付一套已开归档、已备份的可用单机库。
17.2 超出预期的三个点
（1）静默安装做得很扎实。
DM9 的 -s <xml> 静默安装不是"能用但不稳"的附赠功能，而是可以放心用于批量交付的正式能力。只要 XML 键名全大写、根元素正确，安装过程全程无交互、无卡顿，退出码可靠。这一点对需要做标准化交付的团队价值极高——它意味着安装步骤可以完全脚本化、可重放。
（2）dminit 的自动化调优参数很实用。
DM9 新增的 AUTO_ADJ_PARA / AUTO_ADJ_CPUS / AUTO_ADJ_MEM 三个参数，允许 dminit 根据当前机器的 CPU 与内存自动推导 INI 参数。在测试环境验证功能时，可以不必手工精算 BUFFER、MEMORY_POOL 等一串参数，直接用自动值起步，省心且不会因为手抖写错而影响结果。
（3）卸载器比想象中"讲规矩"。
很多软件装起来容易卸起来难，DM9 的 uninstall.sh 会在卸载时自动清理 systemd 服务、/etc/dm* 配置、.bash_profile 中的环境变量，不需要用户逐个手工拔除。卸载行为边界清晰，这一点做得比同类产品规范。
17.3 真正花时间的四个"坎"
必须坦白说：本次部署并非一路顺风。36 个问题中有 4 个卡住过较长时间，全部集中在"DM9 相对 DM8 的行为变化"上——而这些变化，官方文档基本没有专门标注。
| 坎 | 现象 | 卡住原因 | 后来怎么过的 |
|---|---|---|---|
| 坎 1：INI 到底什么时候生成 | dminit 执行成功后，核对文件发现 dmtemp.ctl、TEMP.DBF 不存在，一度怀疑建库失败 |
官方文档把实例文件笼统列为初始化产物，实际是两批生成：控制文件与系统表空间在 dminit 阶段，临时文件在首次启动阶段 |
启动实例后再核对，文件齐全；文档 8.6 节已改为"两批生成"表格并附时间戳实证 |
| 坎 2：备份集里到底有什么 | 异目录恢复时报 INI参数文件错误，反复检查备份命令 |
备份集只含数据文件，不含 dm.ini / dm.ctl。而官方文档未明确这一点 |
先用 dminit 建一个同参数空实例，再基于它的 INI 恢复；见 13.7.3 |
坎 3：RESTORE ... TO 语法不存在 |
按习惯写 RESTORE DATABASE ... TO '/新目录'，报 [-2007] 语法分析出错 |
DM9 的 RESTORE 语句不支持 TO 子句 |
改用 MAPPED FILE 映射文件指定目标路径 |
| 坎 4：归档状态查不到 | 监控脚本沿用 V$INSTANCE.ARCH_MODE，报 [-2111] 无效的列名 |
DM9 已从 V$INSTANCE 移除该列，改为 V$DATABASE.ARCH_MODE |
改查视图；同时注意 STATUS$ 两个视图同名不同型 |
共性启示：这四个坎都不是"难"，而是"不知道"。DM9 作为全新大版本，有大量这样的细节变化。建议后续版本在官方文档中增加一节"由 DM8 升级/迁移的注意事项"，把这些行为差异集中列出——这能替用户省下大量试错时间。本文附录 A 整理的 20 项差异，也是出于这个目的。
17.4 几点给后来者的建议
-
存储一定要分盘。 归档写满会直接挂起数据库，这不是"最佳实践"而是"生存底线"。本次把数据/归档/备份做成三个独立 LV，归档单独占 40 GB，就是避免这个问题。见第 3 章。
-
六项参数上线前定死。 页大小、簇大小、大小写敏感、字符集、空格填充模式、页检查模式——初始化后永久不可修改。改错只能重建实例，代价极大。见第 8 章开头。
-
归档不是可选项，是备份的前置条件。 不开归档，在线备份直接报
[-8003] 缺少本地或者远程归档。生产环境应在上线同时完成归档配置。见第 12 章。 -
把"备份验证"和"备份"当成两件事。 备份成功不等于备份可用。本次每套备份集都用
dmrman CHECK BACKUPSET校验，并做了一次完整的异目录恢复演练——只有恢复成功过的备份才算备份。见 13.6、13.7。 -
先按《快速上手路线图》跑通，再回头读原理。 主流程很短，不要被 17 章的篇幅吓到；把库跑起来之后再回头补原理，理解会快得多。
17.5 小结
DM9 给我的整体感受是：产品成熟度在主流水平之上，安装部署环节的设计明显考虑过自动化与标准化交付；但文档对版本间行为变化的标注仍显不足，这构成了初次上手的主要成本。
对初次尝试者来说，主流程不存在门槛——按本文的《快速上手路线图》9 步执行即可；真正的门槛在遇到报错时能否快速判断"这是版本差异还是操作失误"。希望本文附录 A（20 项差异）与附录 B（40+ 条报错速查）能帮你把这道门槛降下来。
如果这篇文章让你少踩一个坑、少花半小时，那它就有了存在的意义。
第 18 章 DM9 相对 DM8 的能力演进（实测视角）
本章与附录 A 的分工：附录 A 汇总的是"行为差异与坑"（同样的操作在 DM9 上结果不同，容易踩雷）；本章讲的是"能力演进"（DM9 新增或强化的能力，能帮你少做多少事）。两者视角互补，建议对照阅读。
本章所有结论均来自本次在 DM9 企业版 9.1.0.26 上的实测；凡未能验证的内容，一律不写入或以"本文未实测"显式标注。
18.1 安装与初始化：从"交互操作"走向"可编排"
（1）静默安装已可作为正式交付手段
DM9 支持 -s <xml> 静默安装，XML 配置格式经本次实测稳定可用：
[dmdba]$ ./DMInstall.bin -s install.xml
意义不只是"能静默"——它意味着安装步骤可以完全脚本化、可重放、可版本管理。对需要批量交付、标准化部署的团队，这让"安装"从一次性人工操作，变成了可纳入自动化流水线的工程环节。
（2）dminit 新增 INI 参数自动调优
| 参数 | 作用 | 本次实测值 |
|---|---|---|
AUTO_ADJ_PARA |
是否开启 INI 参数自动调优 | 1（开启） |
AUTO_ADJ_CPUS |
自动调优时指定可用 CPU 核数，0=使用全部 | 0 |
AUTO_ADJ_MEM |
自动调优时指定可用内存（MB），0=使用机器 80% | 0 |
dminit 初始化日志中可清晰看到 auto_adj_para: 1（默认即开）。在测试环境、或对参数体系尚不熟悉时，不必手工精算 BUFFER、MEMORY_POOL 这一长串参数，用自动值起步既省心，也避免手写错误导致的偏差。
（3）初始化全过程留档
dminit 会在 $DM_HOME/log/ 下生成 dminit_<库名>_<时间戳>.log，完整记录 23 项初始化参数。由于创建期参数既不在 dm.ini 也不在参数视图中（见 14.2 节），这份日志是它们唯一的原始规格凭证——建议部署完成后立即归档留存。
18.2 存储与性能：内建 AWR 仓库（SYSAUX 表空间）
这是本次实测中"最容易漏算容量、也最容易被误解"的一项。
DM9 实例中存在一个 SYSAUX 表空间（表空间 ID=5），其数据文件为 SYSAWR.DBF，实测大小 5 GB（5120 MB / 327680 页）。需要特别澄清的是：它不会随建库自动出现——只有在**显式初始化 AWR（自动工作负载仓库）**时才会被创建：
-- 初始化 AWR 系统（会创建 SYSAUX 表空间与 SYSAWR.DBF）
CALL SP_INIT_AWR_SYS(1);
-- 查询 AWR 是否已初始化（1 = 已建，0 = 未建）
SELECT SF_CHECK_AWR_SYS FROM DUAL;
关键实测事实（本环境 SF_CHECK_AWR_SYS = 1）：
| 观察项 | 实测结果 |
|---|---|
是否由 dminit 创建 |
否。dminit 日志仅打印 SYSTEM.DBF/MAIN.DBF/ROLL.DBF |
| 是否随实例首次启动自动创建 | 否。需显式调用 SP_INIT_AWR_SYS(1) |
| 本环境创建时点 | 2026-09-14 14:26:35（对应一次 AWR 初始化操作） |
| 创建证据 | dm_DMSERVER 日志：ctl_add_table_space_ex_low ... TS_name[SYSAUX]TS_id=5 → ifun_add_file_low initialize file[0] of ts[5], file_path[.../SYSAWR.DBF] |
| 创建前的动作 | 自动备份 dm.ctl 到 ctl_bak/ 后才落盘数据文件（工程做法稳妥） |
| 初始大小 | 实测初建即为 5 GB（DBA_DATA_FILES.BYTES = 5368709120） |
| 装的是什么 | AWR 系统表：WRM$_SNAPSHOT、WRM$_SNAPSHOT_D、WRM$_GLOBAL_SNAP、WRM$_WR_CONTROL 等（DBA_OBJECTS 实测） |
| 运行痕迹 | SYS.WRM$_SNAPSHOT 实测已有 133 条快照记录，说明采集已按周期运行 |
对部署的三点实际影响：
- 容量规划（关键）：启用 AWR 的实例，数据卷基线约 13.5 GB；不启用 AWR 则约 8.5 GB（省掉 SYSAUX 的 5 GB）。因此这 5 GB 是**"可选的、可控的"开销，而非强制开销**——规划容量前应先确认是否启用 AWR。详见第 1 章。
- 文件核对：若已启用 AWR，核对实例文件时必须把
SYSAWR.DBF计入，否则会误判"多出一个来源不明的文件"。详见 8.6 节。 - 监控能力：DM9 具备 AWR 性能快照能力（
ENABLE_MONITOR实测默认为1）。是否启用由用户决策——生产环境建议启用（便于事后性能回溯与容量趋势分析），但须为其预留磁盘空间并规划快照保留策略。本文未实测：AWR 报告的生成、查看与解读方式不在本指南范围内，请以达梦官方手册为准。
18.3 运维与可观测性：服务与监控增强
（1）系统服务由"1 个"扩展为"5 个"
root_installer.sh 在 DM9 中注册 5 个服务（实测）：
| 服务 | 用途 | 实测默认状态 |
|---|---|---|
DmServiceDMDB |
数据库实例服务 | enabled / active |
DmAPService |
辅助插件服务 | enabled / active |
DmAuditMonitorService |
审计监控服务 | disabled |
DmJobMonitorService |
作业监控服务 | disabled |
DmInstanceMonitorService |
实例监控服务 | disabled |
后三个监控类服务默认 disabled，需要时手工 enable 即可。这体现了 DM9 在可观测性上的投入——把审计、作业、实例三类监控做成标准服务，而不是让用户自行编写脚本实现。
配套注意：服务清单变多，巡检脚本需同步更新；同时务必区分达梦服务与操作系统的
dm-event.service/dm-event.socket（后者属内核 device-mapper 事件机制，误删会导致 LVM 异常，详见附录 B）。
（2）参数文件自带"安全网"
每次修改 dm.ini，达梦会自动留存上一版为 dm.ini.dmbak（实测确认，见 8.6 节）。这意味着误改参数后有官方的回退依据，不必完全依赖人工备份习惯——这是参数治理上一个不起眼但很实用的改进。
18.4 参数治理：创建期参数与可调参数彻底分离
这是 DM9 在架构层面的一项变化，值得单独说明。
| 参数类别 | 存放位置 | 可修改性 | 典型参数 |
|---|---|---|---|
| 创建期参数 | 控制文件 dm.ctl（不写入 dm.ini） |
初始化后永久不可改 | PAGE_SIZE、EXTENT_SIZE、CHARSET、CASE_SENSITIVE、BLANK_PAD_MODE、PAGE_CHECK |
| 可调参数 | dm.ini |
可改（部分需重启） | BUFFER、MAX_SESSIONS、COMPATIBLE_MODE、ARCH_INI 等 |
实测证据：
- 在
dm.ini中检索上述六项创建期参数，除COMPATIBLE_MODE外无任何匹配； dminit日志中可见全部创建期参数；SF_GET_PAGE_SIZE()/SF_GET_EXTENT_SIZE()可在运行时读取。
这个设计的价值：把"一旦选错就无法挽回"的参数，从可编辑文件中彻底移出，从机制上降低了误改风险。以往这些参数混在数百行 dm.ini 中，很容易被误改；DM9 让它们根本不出现在那里。
实践提醒：因此核对这些参数时不要 grep
dm.ini（会一无所获），应使用SF_GET_*()函数或dminit日志，详见 14.2 节。
18.5 小结：DM9 演进的三条主线
综合本次实测，DM9 相对前一代的能力演进可归纳为三条主线：
| 主线 | 具体体现 | 对 DBA 的实际价值 |
|---|---|---|
| 可编排 | 静默安装 XML、dminit 自动调优、初始化日志留档 |
安装部署从"人工操作"变为"可脚本化、可重放"的工程环节 |
| 可观测 | 内建 SYSAUX/AWR 仓库、3 个监控类系统服务 | 性能与审计监控开箱即用，减少自建组件的维护成本 |
| 更稳健 | 创建期参数移出 dm.ini、dm.ini.dmbak 自动留存、建表空间前自动备份控制文件 |
从机制层面降低误操作风险，"防呆"设计更彻底 |
选型提示（中性表述）：若团队重视标准化交付与自动化运维，DM9 在安装编排与可观测性上的改进是明显加分项；同时也应看到，DM9 相对前代有较多行为变化（详见附录 A 的 20 项），存量脚本在迁移前务必经过完整回归测试，不要假设旧脚本可直接复用。
本章未覆盖的内容：DM9 还涉及集中式与分布式一体化、TP+AP 混合负载、多租户隔离、高可用与集群能力、DB+AI 融合等方向。本指南主题为单机部署，未对这些方向做实测，故不作评价；如需了解请以达梦官方资料为准。
附录 A DM9 相对 DM8 的关键行为差异
以下差异均为本次实测确认，官方文档多数未标注，是 DM9 部署中最易踩坑之处：
| 序号 | 差异点 | DM8 行为 | DM9 行为 | 影响 |
|---|---|---|---|---|
| 1 | 安装方式 | 主要 -i 交互式 |
支持 -s <xml> 静默安装 |
可利用静默方式做批量自动化 |
| 2 | 交互式安装流程 | 依次询问：语言 → Key 文件 → 时区 → 安装类型 → 安装路径（5 项） | 精简为：许可协议 → 安装组件 → 安装目录（3 项）；语言与 Key 改由 XML 或内置处理 | 沿用 DM8 操作习惯按旧顺序输入，会在第一步即失败中断 |
| 3 | 安装组件选项 | 区分"典型/服务器/客户端"等安装类型 | 直接列出组件 1) Server、2) Client Tools，支持逗号多选 |
仅装 Server 则无 tool 目录 |
| 4 | -h 帮助/环境变量 |
帮助信息有限 | 明确支持 --cli/-i、--silent/-s、--split、--help；新增 DM_JAVA_HOME、DM_INSTALL_TMPDIR 环境变量 |
可用 DM_INSTALL_TMPDIR 规避 /tmp 空间不足导致解压失败 |
| 5 | root_installer.sh |
仅创建 DmAPService | 额外创建 3 个监控服务：DmAuditMonitorService、DmJobMonitorService、DmInstanceMonitorService | 服务清单变化，巡检脚本需同步更新 |
| 6 | LOG_SIZE 默认值 |
256 MB | 4096 MB（4 GB） | 小容量环境需显式指定小值，否则白占 8 GB 磁盘 |
| 7 | 归档状态视图 | V$INSTANCE.ARCH_MODE |
V$INSTANCE 已无此列，改查 V$DATABASE.ARCH_MODE |
沿用 DM8 的监控 SQL 会报 [-2111] 无效的列名 |
| 8 | V$DATABASE.STATUS$ |
— | 返回数值编码（如 4=OPEN），与 V$INSTANCE.STATUS$ 的字符值 OPEN 同名不同型 |
监控 SQL 混用两视图的同名 STATUS$ 会得到难以理解的结果 |
| 9 | 安装目录 | 含 web（DEM）、desktop |
不含 | DEM 已改为独立组件 |
| 10 | dminit 参数 |
— | 新增 AUTO_ADJ_PARA/AUTO_ADJ_CPUS/AUTO_ADJ_MEM（INI 参数自动调优）、PAGE_CHKSUM_POLICY 等 |
可用于自动化调优 |
| 11 | DROP USER IF EXISTS |
兼容 | 不支持，报 [-2007] |
脚本需改造，改用 DROP USER ... CASCADE |
| 12 | 实例文件生成时机 | — | dmtemp.ctl（临时控制文件）、TEMP.DBF（临时表空间）不在 dminit 阶段生成，而是数据库首次启动时才创建；SYSTEM.DBF 也从 64 MB 扩至 128 MB |
仅执行完 dminit 核对文件会误判"缺文件"，须启动实例后再核对 |
| 13 | 备份集内容范围 | 备份集包含数据文件与元信息 | 备份集内仅含数据文件（SYSTEM.DBF/ROLL.DBF/MAIN.DBF），不含 dm.ini/dm.ctl（SHOW BACKUPSET 实测确认） |
异目录恢复必须自备 dm.ini，见 13.7.3 |
| 14 | RESTORE ... TO 语法 |
— | 不支持 TO 子句，写 TO '目录' 报 [-2007] 语法分析出错 |
异目录恢复须用 MAPPED FILE 映射文件指定目标路径 |
| 15 | dminit 的 COMPATIBLE_MODE |
可作为初始化参数 | 不接受，报 Invalid parameter:COMPATIBLE_MODE. |
去掉该参数，建库后通过 dm.ini 设置 |
| 16 | 归档日志视图 | — | V$ARCHIVE 视图不存在，报 [-2106] 无效的表或视图名 |
改用 V$ARCHIVED_LOG（列为 NAME/SEQUENCE#/FIRST_TIME/NEXT_TIME，无 DEST） |
| 17 | 卸载交互流程 | 交互项较多 | 精简为 2 项：①保留dm_svc.conf配置文件?[Y/n] ②确认卸载?[y/n]；首个提示不是选项编号 |
按编号喂入会报"输入非法"，须按 printf 'n\ny\n' 输入 |
| 18 | 卸载器清理边界 | — | 卸载器自动清理服务、/etc/dm*、.bash_profile 环境变量；不清理安装后新建的目录与文件（如 dmdbms/log/、用户自建脚本） |
卸载"不干净"多因未手工清理运行期目录，见 16.6 节 |
| 19 | dm.ini 自动备份 |
— | 每次修改 dm.ini 会自动留存上一版为 dm.ini.dmbak |
误改参数可据此回退，是官方自带的安全网 |
| 20 | 校验文件格式 | — | .iso_SHA256.txt 含文件名抬头行与 CertUtil: 尾行，直接 awk '{print $1}' 会取到抬头单词 |
校验值须用 grep -oE '[0-9a-fA-F]{64}' 提取，见 6.1 节 |
附录 B 常见问题处理
检索提示：本附录收录 40+ 条报错处置，按"现象 → 根因 → 处理方式"组织。遇到报错时，可用浏览器
Ctrl+F搜索报错编号（如[-8003]）或关键字（如"归档"“权限”）直达。
按场景快速索引：
| 场景 | 典型报错/现象 | 对应条目所在 |
|---|---|---|
| 安装前 | 无法执行二进制文件、Invalid input、The input path is invalid |
本表前 6 行 |
| 安装解压 | 解压失败、报错不直观 | 本表第 4 行 |
| 静默安装 | -s 报"成功"但实际未安装 |
本表第 5 行 |
| 连接登录 | disql 打印用法帮助、无法登录 |
本表第 7 行 |
| 归档配置 | [-8003] 缺少归档、ALTER DATABASE ARCHIVELOG 报 [-2007] |
本表第 9~11 行 |
| 备份 | RMAN[-137] 服务器正在运行 |
本表第 8 行 |
| 恢复 | RMAN[-104]、RMAN[-803]、RMAN[-8287]、[-2007] |
本表第 14~18 行 |
| 用户管理 | [-2639] 被依赖对象、DROP USER IF EXISTS 报 [-2007] |
本表第 12~13 行 |
| 卸载 | 服务残留、空间未释放、误删 dm-event、单元文件与 rc.local 残留 |
见附录 B 表末 9 行 |
| 现象 | 根因 | 处理方式 |
|---|---|---|
| 命令行安装报"无法执行二进制文件" | 安装包与 CPU 架构或操作系统不匹配 | 重新下载匹配平台的安装包 |
交互式安装第一步就提示 Invalid input 并中断 |
沿用 DM8 旧流程（先答语言），与 DM9 实际流程不符 | DM9 第一步是许可协议，须输入 2（同意并继续）；详见 6.3 节 |
安装报 The input path is invalid |
安装路径未以 / 开头，或含 #、\ 等非法字符 |
用绝对路径且不含特殊字符；确认 dmdba 对该目录有写权限 |
| 安装解压阶段失败、报错不直观 | 系统 /tmp 空间不足 |
用 DM_INSTALL_TMPDIR=/dmdata/tmp ./DMInstall.bin -i 指定到大容量分区 |
-s 静默安装"成功"但实际未安装 |
XML 键名用了小写，或根元素名错误 | 键名必须全大写（LANGUAGE/KEY/COMPONENTS/INSTALL_PATH），根元素为 DATABASE |
执行 DMInstall.bin 提示权限不足 |
使用 root 执行 | 必须使用 dmdba 用户 |
disql 直接打印用法帮助、无法登录 |
连接串引号用法错误 | 必须外单内双：./disql 'SYSDBA/"密码"@主机:5236'；详见 14.2 节 |
备份报 RMAN[-137] 服务器正在运行 |
数据库运行中调用 dmrman |
dmrman 需停机使用；在线备份改用 BACKUP DATABASE SQL |
备份报 [-8003] 缺少本地或者远程归档 |
未开启归档 | 先完成第 12 章归档配置 |
ALTER DATABASE ARCHIVELOG 报 [-2007] |
数据库处于 OPEN 状态 | 先 ALTER DATABASE MOUNT 再切换 |
查询 V$INSTANCE.ARCH_MODE 报无效列名 |
DM9 已移除该列 | 改查 V$DATABASE.ARCH_MODE |
DROP USER <user> 报 [-2639] 试图删除被依赖对象 |
用户下仍有表等对象 | 先删对象，或改用 DROP USER <user> CASCADE |
DROP USER IF EXISTS 报 [-2007] |
DM9 不支持 IF EXISTS 子句 |
去掉 IF EXISTS，直接 DROP USER ... CASCADE |
恢复报 RMAN[-104] INI参数文件错误 |
异目录恢复时目标目录无 dm.ini（备份集不含 INI） |
先用 dminit 建同参数空实例，再基于其 dm.ini 恢复（13.7.3） |
恢复报 RMAN[-803] 非法INI配置值 |
手工 sed 改 INI 引入非法格式 |
用 dminit 生成干净 dm.ini，勿手工编辑路径参数 |
恢复报 RMAN[-8287] 映射文件路径无效 |
映射文件未生成 | 先执行 DUMP BACKUPSET ... MAPPED FILE ... 生成 |
恢复报 DM[-124] SYSTEM.DBF文件不存在 |
目标目录缺数据文件 | 目标实例须由 dminit 初始化，再执行 RESTORE |
RESTORE ... TO '目录' 报 [-2007] 语法分析出错 |
DM9 的 RESTORE 无 TO 子句 |
改用 MAPPED FILE 指定异目录目标路径 |
dminit 报 Invalid parameter:COMPATIBLE_MODE. |
dminit 不接受该参数 |
去掉该参数，建库后通过 dm.ini 设置 |
dmrman 无限输出 RMAN> 提示符 |
未重定向标准输入 | 所有 dmrman 调用追加 </dev/null |
备份脚本报 tee: Permission denied |
日志目录被 root 创建 | chown -R dmdba:dinstall /dmdata/dmbak |
| 备份脚本报"未开启归档"但归档已开 | grep '^Y' 匹配不到（disql 输出含行号） |
改用 grep -oE '[YN]' | head -1 |
查询 V$ARCHIVE 报 [-2106] 无效的表或视图名 |
DM9 无该视图 | 改用 V$ARCHIVED_LOG |
disql 报 [-2501] 用户名或密码错误 |
密码含特殊字符被 shell 转义改写 | 连接串外单内双；dminit 密码务必写入脚本文件执行 |
ulimit -n 仍为 1024 |
limits.conf 修改后未重新登录 | 完全退出会话重新登录，或重启服务器 |
| 数据库启动报"共享内存不足" | kernel.shmmax/kernel.shmall 过小 |
按 2.2 节调整并 sysctl -p 生效 |
| 数据库启动后立即退出 | root 安装，或数据目录权限错误 | 确认软件由 dmdba 安装，/dmdata/* 属主为 dmdba:dinstall |
| 中文显示乱码 | 字符集不匹配 | 核对实例 CHARSET；已初始化实例无法改字符集，需重建 |
| 实例初始化报"记录超长" | PAGE_SIZE 过小 |
删除实例，用更大页大小重建 |
dm_service_uninstaller.sh 挂起 |
脚本交互式等待确认 | 预先输入 y：echo 'y' | ./dm_service_uninstaller.sh -n <服务名> |
grep '^PAGE_SIZE' dm.ini 匹配不到 |
dm.ini 参数行带前导制表符 | 用 grep -E '^\s*PAGE_SIZE' 或按关键字匹配 |
| LVM 扩容后目录容量未变 | 仅扩 LV 未扩文件系统 | resize2fs（ext4）或 xfs_growfs（xfs） |
uninstall.sh -i 报"输入非法" |
首个提示是"是否保留 dm_svc.conf"，非选项编号 | 按 printf 'n\ny\n' | 输入（见 16.5 节） |
| 卸载后磁盘空间未释放 | 卸载器不删数据目录与运行期目录 | 手工清理 /dmdata/*、dmdbms/log、/tmp 介质（见 16.6~16.7 节） |
卸载后 systemctl 仍有达梦服务 |
未先卸服务就删了软件目录 | 按 16.4 节用卸载脚本卸载服务，顺序不可颠倒 |
误删 dm-event.service 后 LVM 异常 |
dm-event 属内核 device-mapper，非达梦服务 |
yum reinstall device-mapper 恢复；日常巡检勿误删 |
userdel dmdba 报"用户正在使用" |
仍有进程以 dmdba 身份运行 | pkill -u dmdba 后确认无进程再删 |
lvcreate 长时间无响应、像卡死 |
复用磁盘时检测到残留文件系统签名，弹出 Wipe it? [y/n] 等待终端输入——此时 LV 其实已创建，lsblk 看一切正常 |
① wipefs -a <磁盘> 清残留签名；② 命令加 -y；③ 脚本开头 exec </dev/null（见 3.2/3.4 节） |
按旧写法 sed 改写映射文件却"毫无变化" |
DUMP 生成映射文件时，已按 DATABASE 参数把 data_path 直写为新实例路径 |
属正常，无需改写；先 grep 'data_path' /tmp/dm_map.txt 确认（见 13.7 节） |
归档目录出现 1 GB 大文件，du 也占 1 GB |
ARCH_FILE_SIZE=1024（MB）时，当前正在写入的归档文件按上限预占 1 GB；历史归档文件只占真实内容 |
属正常。规划归档卷容量须计入这 1 GB；紧张时可下调 ARCH_FILE_SIZE（见 12.5 节） |
| 脚本自动卸载服务时漏掉实例服务，且输出看起来"一切正常" | 写了 grep -E '^Dm.*Service\.service$' —— 该正则要求 Service 与 .service 相邻，而实例服务实际是 DmService+<实例名>+.service，永远不匹配 |
改用 grep -E '^Dm[^ ]*\.service$'；执行前先打印匹配结果数量自检（见 16.4 节） |
| 前 11 项核验全绿，但主机上仍能搜到达梦痕迹 | 核验清单本身不完整：未覆盖 systemd 单元文件与 rc.local 开机脚本 |
按 16.9 节 13 项清单核验（第 12、13 项为实测补出）。只跑清单、不质疑清单，会把"清单没覆盖"误判成"已干净" |
卸载后 /etc/rc.d/rc.local 里还留着"关闭透明大页" |
该配置由部署时追加进系统开机脚本，不属达梦软件 → 卸载器不管、/etc/dm* 也扫不到 |
按 16.7 节第 7 步只删本指南追加的片段（被 if test -f ... fi 包裹的 6 行），其他产品的行必须保留；删后 bash -n 验语法、ls -l 确认可执行位仍在 |
DmAuditMonitorService / DmJobMonitorService 启用后启动失败（control process exited, code=exited status=1），而同一个命令下 DmInstanceMonitorService 却起来了 |
这两个服务必须先手工配置参数才能工作（审计监控需 USER_ID 连接串、INI_PATH=dmamon.ini、DCR_INI_PATH 等；作业监控需 USER_ID）。官方手册 1.3 节原文：“用户在使用这些服务脚本前，需要先手动修改服务脚本的参数。” 实例监控服务无需配参，所以只有它能起来 |
保持 disabled（默认即如此，与数据库能否运行无关，非部署必需）。确需启用按 9.4 节补参后再启动。不要因这个 failed 回滚重装 |
journalctl -u <达梦服务> 只显示 [47B blob data] 之类的乱码，看不到真实报错 |
journalctl 对含非文本字节的输出做了折叠（达梦服务脚本的输出流常带控制字符） |
加 -o cat：journalctl -u <服务名> -n 30 --no-pager -o cat；更可靠的是直接看服务自己的日志文件 $DM_HOME/log/<服务名>_err.log（官方 1.5 节） |
附录 C 部署检查清单
按顺序执行，每完成一项打钩。建议正式部署前先通读一遍。
C.1 环境准备阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 1 | 操作系统版本确认 | cat /etc/redhat-release |
☐ |
| 2 | 内核参数优化 | /etc/sysctl.d/99-dm.conf |
☐ |
| 3 | 透明大页关闭 | /sys/kernel/mm/transparent_hugepage/enabled |
☐ |
| 4 | 主机名解析 | /etc/hosts |
☐ |
| 5 | 防火墙端口放通 | firewall-cmd --list-ports |
☐ |
| 6 | 时间同步确认 | timedatectl |
☐ |
C.2 存储规划阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 7 | 目标磁盘确认未使用 | lsblk、pvs |
☐ |
| 8 | 物理卷创建 | pvcreate /dev/sdd |
☐ |
| 9 | 卷组创建 | vgcreate dmvg /dev/sdd |
☐ |
| 10 | 逻辑卷创建 | lvcreate -L 60G/40G/30G |
☐ |
| 11 | 文件系统创建（ext4） | mkfs.ext4 |
☐ |
| 12 | fstab 持久化挂载 | /etc/fstab |
☐ |
| 13 | 挂载验证 | mount -a、df -Th |
☐ |
C.3 用户与资源限制阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 14 | 用户组与用户创建 | groupadd dinstall、useradd dmdba |
☐ |
| 15 | 数据目录授权 | chown -R dmdba:dinstall /dmdata/* |
☐ |
| 16 | 资源限制配置 | /etc/security/limits.conf |
☐ |
| 17 | 限制生效验证 | su - dmdba 后 ulimit -a |
☐ |
C.4 安装与初始化阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 18 | 介质完整性校验 | sha256sum 与校验文件比对 |
☐ |
| 19 | ISO 挂载 | mount -o loop ... /mnt/dm9iso |
☐ |
| 20 | 软件安装（dmdba） | ./DMInstall.bin -s 或 -i |
☐ |
| 21 | root 配置脚本执行 | root_installer.sh |
☐ |
| 22 | 环境变量配置 | /home/dmdba/.bash_profile |
☐ |
| 23 | 实例初始化 | dminit 带全部参数 |
☐ |
| 24 | 实例文件生成确认 | ls /dmdata/data/DMDB |
☐ |
C.5 服务与归档阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 25 | 服务注册 | dm_service_installer.sh -t dmserver |
☐ |
| 26 | 服务启动 | systemctl start DmServiceDMDB |
☐ |
| 27 | 端口监听 | netstat -lntp | grep 5236 |
☐ |
| 28 | 归档配置文件 | /dmdata/data/DMDB/dmarch.ini |
☐ |
| 29 | ARCH_INI=1 设置 |
dm.ini |
☐ |
| 30 | 切换归档模式 | ALTER DATABASE MOUNT/ARCHIVELOG/OPEN |
☐ |
| 31 | 归档状态确认 | V$DATABASE.ARCH_MODE = Y |
☐ |
C.6 验证阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 32 | disql 连接 | ./disql 'SYSDBA/"<密码>"@<地址>:5236' |
☐ |
| 33 | 不可修改参数核对 | SF_GET_PAGE_SIZE() 等系统函数 |
☐ |
| 34 | 建表读写验证 | DDL/DML 测试 | ☐ |
| 35 | 中文存储验证 | LENGTH/LENGTHB 对比 |
☐ |
| 36 | 服务重启验证 | systemctl restart |
☐ |
| 37 | 开机自启设置 | systemctl enable |
☐ |
| 38 | 在线备份验证 | BACKUP DATABASE FULL |
☐ |
C.7 备份与恢复阶段
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 39 | 归档三层验证 | V$DATABASE.ARCH_MODE + V$ARCHIVED_LOG + 归档目录 |
☐ |
| 40 | 备份脚本部署 | /home/dmdba/scripts/dm_backup.sh 且 chmod 755 |
☐ |
| 41 | 日志目录属主 | chown -R dmdba:dinstall /dmdata/dmbak |
☐ |
| 42 | 脚本全量备份 | ./dm_backup.sh full |
☐ |
| 43 | 脚本增量备份 | ./dm_backup.sh incr |
☐ |
| 44 | 备份集校验 | ./dm_backup.sh verify <目录> → successfully |
☐ |
| 45 | 定时任务配置 | crontab -l（dmdba 用户） |
☐ |
| 46 | 恢复演练 | 异目录 RESTORE→RECOVER→UPDATE DB_MAGIC 后比对数据 | ☐ |
| 47 | 演练环境清理 | 删除还原目录、恢复原库 | ☐ |
C.8 卸载阶段（第 16 章）
| 序号 | 检查项 | 命令/位置 | 结果 |
|---|---|---|---|
| 48 | 卸载前备份确认 | 备份集存在且校验通过，或已确认数据可弃 | ☐ |
| 49 | 卸载前无业务连接 | V$SESSIONS 无其他活动会话 |
☐ |
| 50 | 停止数据库服务 | systemctl stop DmServiceDMDB DmAPService |
☐ |
| 51 | 卸载操作系统服务 | dm_service_uninstaller.sh -n <服务名>（5 个） |
☐ |
| 52 | 卸载数据库软件 | printf 'n\ny\n' | ./uninstall.sh -i |
☐ |
| 53 | 清理软件残留 | 删 dmdbms/、家目录自建文件、/tmp 介质 |
☐ |
| 54 | 清理 ISO 挂载 | umount /mnt/dm9iso + 删除 loop 设备 |
☐ |
| 55 | （彻底卸载）销毁 LVM | lvremove → vgremove → pvremove |
☐ |
| 56 | （彻底卸载）清理 fstab | 删除数据卷条目并 mount -a 验证 |
☐ |
| 57 | （彻底卸载）删除用户组 | userdel -r dmdba; groupdel dinstall |
☐ |
| 58 | 卸载后 13 项核验 | 按 16.9 节清单全景核验 | ☐ |
附录 D 生产环境容量规划建议
D.1 数据文件容量
| 业务规模 | 建议初始容量 | 增长预留 |
|---|---|---|
| 小型（< 100 GB） | 500 GB | 3 年增长量 × 1.5 |
| 中型（100 GB ~ 1 TB） | 2 TB | 3 年增长量 × 1.5 |
| 大型（> 1 TB） | 5 TB 起 | 3 年增长量 × 2 |
D.2 归档日志容量
归档日志量 ≈ 每日数据变更量 × 归档保留天数 × 2（膨胀系数）。
- 基础容量：≥ 数据文件容量的 1.5 倍；
- 必须独立于数据卷（归档写满会直接挂起数据库）；
- 配置
ARCH_SPACE_LIMIT与定期清理策略，避免无限增长。
D.3 备份集容量
备份集容量约为数据量的 60%~100%（取决于压缩率）。
- 基础容量：≥ 数据文件容量的 2 倍（保留 2 份全量）；
- 必须独立于数据卷与归档卷；
- 核心业务配置异地备份，防机房级故障。
D.4 内存规划
达梦实例内存主要由 dm.ini 参数控制，实测初始化后的默认值（16 GB 内存机器）：
| 参数 | 含义 | 实测默认值 | 建议值 |
|---|---|---|---|
MEMORY_POOL |
内存池大小 | 800 MB | 500~2000 MB |
MEMORY_EXTENT_SIZE |
内存扩展块大小 | 32 MB | 保持默认 |
BUFFER |
数据缓冲区大小 | 5000 MB | 物理内存的 40%~60% |
MAX_BUFFER |
数据缓冲区上限 | — | BUFFER 的 1.5~2 倍 |
SORT_BUF_SIZE |
排序缓冲区 | — | 10~50 MB |
HJ_BUF_SIZE |
哈希连接缓冲区 | — | 50~200 MB |
DM9 自动化调优：DM9 默认开启
AUTO_ADJ_PARA=1，初始化时已按机器资源自动调整参数（实测BUFFER=5000即为自动调优结果）。如需固定参数以符合交付规范，可显式设置AUTO_ADJ_PARA=0并通过AUTO_ADJ_CPUS/AUTO_ADJ_MEM指定可用资源。内存分配总原则：实例占用 + 操作系统预留 + 其他应用 之和不得超过物理内存。
D.5 I/O 规划
| 存储类型 | 建议用途 |
|---|---|
| SSD / NVMe | 数据文件、重做日志（随机 I/O 敏感） |
| SAS / SATA | 归档日志、备份集（顺序 I/O 为主） |
| 网络存储（NFS 等） | 仅用于备份归档，禁止用于数据文件 |
D.6 文件系统选型速查
| 单卷容量 | 推荐文件系统 | 扩容命令 | 备注 |
|---|---|---|---|
| < 16 TB | ext4 | resize2fs |
支持缩容；元数据开销小 |
| ≥ 16 TB | xfs | xfs_growfs |
不支持缩容；大容量性能更优 |
附录 E 部署作业记录（本次实测）
E.1 部署信息
| 项目 | 内容 |
|---|---|
| 部署日期 | 2026-09-14（历经首装、复核、卸载、全流程重跑四轮） |
| 服务器 IP / 主机名 | 192.168.3.22 / kb-db02 |
| 操作系统 | CentOS Linux release 7.9.2009 (Core) |
| 内核 | 3.10.0-1160.el7.x86_64 |
| 硬件 | 4 vCPU / 16 GB 内存 / 140 GB 数据盘 |
| 数据库版本 | DM9 企业版 9.1.0.26（03151060506-20260417） |
| 部署方式 | 命令行静默安装（-s XML 配置） |
| 部署结果 | 全部验证通过；并完成干净卸载与全流程重跑验证 |
E.2 存储规划实际值
| 项目 | 规划值 | 实际值 |
|---|---|---|
| 物理卷 | /dev/sdd | /dev/sdd（140 GB，LVM2_member） |
| 卷组 | dmvg | dmvg（140 GB，剩余约 10 GB） |
| 数据卷 | 60 GB → /dmdata/data | dmvg-dmdata_lv 60 GB ext4 |
| 归档卷 | 40 GB → /dmdata/arch | dmvg-dmarch_lv 40 GB ext4 |
| 备份卷 | 30 GB → /dmdata/dmbak | dmvg-dmbak_lv 30 GB ext4 |
| 文件系统 | ext4 | ext4 |
E.3 实例参数实际值
| 参数 | 规划值 | 实际值 | 是否一致 |
|---|---|---|---|
| PAGE_SIZE | 16 | 16384 字节（16 KB） | ✅ |
| EXTENT_SIZE | 32 | 32 | ✅ |
| CASE_SENSITIVE | Y | 1（敏感） | ✅ |
| CHARSET | 1（UTF-8） | 1（UTF-8） | ✅ |
| BLANK_PAD_MODE | 1 | 1 | ✅ |
| PAGE_CHECK | 1 | 1 | ✅ |
| COMPATIBLE_MODE | 2 | 2 | ✅ |
| PORT_NUM | 5236 | 5236 | ✅ |
E.4 验证结果汇总
| 序号 | 验证项 | 结果 | 备注 |
|---|---|---|---|
| 1 | 服务状态 | ✅ 通过 | DmServiceDMDB / DmAPService 均 active+enabled |
| 2 | 端口监听 | ✅ 通过 | 5236 LISTEN |
| 3 | disql 连接 | ✅ 通过 | SYSDBA 登录成功 |
| 4 | 参数核对 | ✅ 通过 | 系统函数与 dm.ini 双重确认 |
| 5 | 建表读写 | ✅ 通过 | 3 条记录写入查询正常 |
| 6 | 中文存储 | ✅ 通过 | CHAR_LEN=4 / BYTE_LEN=12，UTF-8 确认 |
| 7 | 兼容模式语法 | ✅ 通过 | NVL / TO_CHAR 正常 |
| 8 | 归档模式 | ✅ 通过 | V$DATABASE.ARCH_MODE = Y |
| 9 | 服务重启 | ✅ 通过 | 重启后连接正常，数据完好 |
| 10 | 开机自启 | ✅ 通过 | 均 enabled |
| 11 | 在线备份 | ✅ 通过 | 生成 18 MB 备份集（.bak/.meta） |
| 12 | 归档日志生成 | ✅ 通过 | /dmdata/arch 下生成 1.0G 归档日志 |
| 13 | 归档三层验证 | ✅ 通过 | 参数层 + V$DATABASE.ARCH_MODE=Y + 归档目录 1.1 GB |
| 14 | 备份脚本全量 | ✅ 通过 | 22 MB，耗时 4 s，自动校验通过 |
| 15 | 备份脚本增量 | ✅ 通过 | 4.3 MB，耗时 9 s（约为全量 1/5） |
| 16 | 备份集校验 | ✅ 通过 | dmrman CHECK BACKUPSET → successfully |
| 17 | 恢复演练 | ✅ 通过 | 异目录恢复成功，数据精确回到备份时刻 |
E.5 实测发现的问题与解决
首次部署中遇到的问题：
| 序号 | 问题 | 根因 | 解决方式 |
|---|---|---|---|
| 1 | -s 静默安装 exit=0 但未安装 |
XML 键名大小写错误 | 键名改为全大写，根元素为 DATABASE |
| 2 | disql 报 [-2501] 用户名或密码错误 |
密码经多层 shell 转义被改写 | 将 dminit 命令写入脚本文件执行 |
| 3 | BACKUP DATABASE 报 [-8003] 缺少归档 |
未配置归档 | 配置 dmarch.ini + ARCH_INI=1 + 切换 ARCHIVELOG |
| 4 | ALTER DATABASE ARCHIVELOG 报 [-2007] |
数据库在 OPEN 状态 | 先 MOUNT 再切换再 OPEN |
| 5 | 查 V$INSTANCE.ARCH_MODE 报无效列名 |
DM9 已移除该列 | 改查 V$DATABASE.ARCH_MODE |
| 6 | dm_service_uninstaller.sh 挂起 |
交互式等待确认 | 预先输入 y |
| 7 | dmrman 备份报 RMAN[-137] |
数据库运行中 | dmrman 需停机；在线备份用 SQL |
