达梦数据库实践（一）：SSH 隧道连接、systemctl 服务管理与 DTS 迁移问题排查

达梦数据库典型问题排查实践

1.SSH 隧道连接：Windows 无法直连远程库

问题描述：
在 Windows 上通过 DM 管理工具（Manager）连接远程数据库时，报错 错误号: 6001，错误消息: 网络通信异常。经过排查，Windows 主机无法直接 ping 通远程服务器 10.36.41.11，但 SSH 端口（5223）可以正常连接。原因是公司内网对数据库端口（5223）做了访问限制，仅开放了 SSH 端口。

排查过程：

执行 ping 10.36.41.11，请求超时，说明网络层不通。
执行 ssh -p 5223 root@10.36.41.11，可以正常登录，说明 SSH 端口可用。
结论：Windows 与远程服务器之间只有 SSH 端口是连通的，数据库端口被隔离。

解决方案：
利用 SSH 的本地端口转发（Local Port Forwarding）功能，将远程服务器的数据库端口映射到本地：

ssh -p 5223 -L 5223:127.0.0.1:5223 root@10.36.41.11

原理说明：
该命令在本地和远程服务器之间建立一条加密的 SSH 隧道，把远程服务器的 5223 端口“搬”到本地的 127.0.0.1:5223。之后所有 Windows 客户端工具（Manager、DTS、Console）只需连接 127.0.0.1:5223，即可通过 SSH 隧道安全地访问远程数据库。

注意事项：

SSH 隧道窗口必须保持打开状态，关闭后隧道即断开。
每次使用前需重新执行该命令。

2. systemctl 启动失败：旧进程占用端口

问题描述：
使用 dm_service_installer.sh 成功注册达梦系统服务后，执行 systemctl start DmServiceDAMENG 报错：

Job for DmServiceDAMENG.service failed because the control process exited with error code.

查看服务状态 systemctl status DmServiceDAMENG，显示 Active: failed，但使用 ps -ef | grep dmserver 发现数据库进程依然存在。

原因分析：

此前使用 nohup 手动启动的数据库进程（PID 15294）仍在后台运行。
达梦服务脚本 DmServiceDAMENG 在启动时会检查端口 5223 是否被占用。
由于旧进程已占用该端口，服务脚本检测到端口被占用后返回非 0 状态码，导致 systemd 认为启动失败。
systemd 记录的失败状态未自动清除，导致 systemctl status 一直显示失败。

解决方案：

步骤一：停止旧进程

#先通过服务名正常停止旧进程
systemctl stop DmServiceDAMENG
#万不得已使用kill，（进程彻底卡死时）
kill -9 PID
ps -ef | grep dmserver   # 确认进程已退出

步骤二：用 systemctl 启动服务

systemctl start DmServiceDAMENG
systemctl status DmServiceDAMENG

步骤三：清除 systemd 失败记录（如有必要）

systemctl reset-failed DmServiceDAMENG

操作结果：

Active: active (running) since Wed 2026-07-15 14:09:43 CST; 32s ago
Main PID: 22654 (dmserver)

服务状态变为 active (running)，systemd 成功接管数据库进程。

<h3 style=“color: red;”>3. DTS 迁移唯一约束冲突：远程库存在残留表结构</h3>

问题描述：
使用 DTS 将本地库的 LOCAL_TABLE 表迁移到远程库时，报错：

错误号: -6602
错误消息: 违反表[LOCAL_TABLE]唯一性约束条件[CONS134218860]
INSERT INTO "SYSDBA"."LOCAL_TABLE"("ID","NAME","CREATE_TIME") VALUES(?,?,?)

但在远程库执行 SELECT * FROM USER_TABLES WHERE TABLE_NAME = 'LOCALTABLE'; 却显示 “未选定行”，表并不存在。

原因分析：
远程库曾有一次失败的迁移尝试，DTS 在目标端创建了部分对象（如主键约束），但表创建未完全成功。这些残留的约束信息仍存在于系统表中，导致 DTS 在重新迁移时认为表已存在，尝试直接插入数据，从而触发唯一性约束冲突。

解决方案：

按照导师的指导，采用清理目标端的正规方案，而非修改源端。

在 DTS 迁移任务配置中，通过迁移策略设置，让 DTS 在迁移前自动删除目标端已存在的同名表，确保迁移从头开始。迁移工具支持目标端已存在表时自动删除重建。
若 DTS 不支持清空，可在目标端手动执行：
```
DROP TABLE IF EXISTS LOCAL_TABLE;
```
注意：数据库运维中，“清空”通常指 TRUNCATE TABLE（只清理数据，保留表结构），而此处需要的是 DROP TABLE（删除表结构），两者不同。
清理完成后，重新执行 DTS 迁移任务，DTS 会正常创建表并迁移数据。

经验总结：

迁移失败后，目标端可能残留部分对象，导致后续重试失败。
迁移工具只操作目标端，不允许修改源端任何数据（数据源只读，避免影响业务）。
DTS 内置的 “迁移前清空目标端” 策略是处理残留对象的正规手段，应优先使用。
如果确实需要手动处理，也只在目标端操作，绝不能修改源端的表名或数据。