最近因为项目国产化改造，我把一套跑了多年的业务系统整体迁到了达梦数据库（DM8），从安装、初始化、客户端连接、数据迁移到高可用方案选型，前前后后踩了不少坑。网上关于达梦的资源不少，但大多零散，要么是官方文档的搬运，要么只讲某一步就没了下文。这篇我就把这一轮“达梦数据库全流程操作指南”的实操过程完整梳理一遍，从零开始讲清楚环境准备、实例初始化、Navicat连接、DW/DSC选型、迁移工具使用和编码处理这些关键环节，给正在做数据库国产化替代、准备上手达梦的同学一份可以直接照着操作的参考。
1. 安装部署：从零搭一套能用的达梦环境
1.1 安装前先想清楚这三件事
很多人拿到达梦安装包就直接下一步下一步，装完才发现字符集不对、大小写敏感设置不合理，只能推倒重来。我建议动手之前先确认三件事。
第一，CPU架构和操作系统版本。达梦支持x86、ARM（鲲鹏、飞腾）等主流架构，操作系统常见的有麒麟、统信UOS、CentOS、Ubuntu等。不同架构要下对应的安装包，下错了装不上。可以先执行uname -m、cat /etc/os-release确认。
第二，授权许可。达梦提供开发版和试用版，从官网申请授权文件（key文件）就行，试用期足够把全套流程跑通。生产环境就找原厂购买正式授权。没有License，数据库也能启动，但有限制，比如实例最大使用时间或者连接数受限。
第三，规划好关键参数。这一步最重要，尤其是字符集和标识符大小写敏感。达梦初始化实例时字符集支持GB18030、UTF-8等，如果后续要从MySQL、PostgreSQL迁数据过来，源库是UTF-8，那建议初始化直接选UTF-8，不然后面导入导出全是编码报错。大小写敏感这个参数，决定了SQL里表名不带双引号时是否区分大小写，对迁移兼容性影响非常大，后面第4部分我会专门展开。
1.2 静默安装与初始化实例
Linux环境下推荐用静默安装，比图形界面稳定，也方便在服务器上操作。先把安装包解压，然后用非root用户执行安装。
达梦官方要求用专门的系统用户来安装，一般约定是dmdba。创建用户和目录：
groupadd dinstall useradd -g dinstall -m dmdba passwd dmdba mkdir -p /opt/dmdbms chown -R dmdba:dinstall /opt/dmdbms把授权文件放到安装目录下，然后执行静默安装：
chmod +x DMInstall.bin ./DMInstall.bin -q -l /path/to/dm.key -p /opt/dmdbms-q表示静默安装，-l指定授权文件，-p指定安装路径。装完之后，用dmdba用户执行初始化实例工具dminit：
su - dmdba cd /opt/dmdbms/bin ./dminit PATH=/opt/dmdbms/data DB_NAME=DAMENG INSTANCE_NAME=DMSERVER \ PORT_NUM=5236 CHARSET=1 PAGE_SIZE=32 CASE_SENSITIVE=1这里几个参数值得多说一句。PORT_NUM默认就是5236，达梦的服务端口；CHARSET=1表示UTF-8，0表示GB18030，这个必须和业务数据编码对齐；PAGE_SIZE单位是KB，可选4、8、16、32，一般OLTP系统选16或32，页大小确定后很难改，建库前就要想好；CASE_SENSITIVE=1表示标识符大小写敏感，这个是达梦为了兼容Oracle的默认行为，但从MySQL迁过来的业务如果之前习惯了小写表名，这里建议直接设成0，否则后面写SQL到处都要加双引号，能把人逼疯。
1.3 服务注册、启停与基本状态检查
实例初始化完成后，需要注册成系统服务，才能用systemctl管理。用root用户执行达梦自带的注册脚本：
cd /opt/dmdbms/script/root ./dm_service_installer.sh -t dmserver -dm_ini /opt/dmdbms/data/DAMENG/dm.ini -p DMSERVER启动服务：
systemctl start DmServiceDMSERVER systemctl status DmServiceDMSERVER服务名是DmServiceDMSERVER，中间的DMSERVER对应实例名。也可以直接手动启动：
su - dmdba -c "/opt/dmdbms/bin/dmserver /opt/dmdbms/data/DAMENG/dm.ini"启动后验证是否正常，用达梦自带的命令行客户端disql连接：
cd /opt/dmdbms/bin ./disql SYSDBA/SYSDBA@localhost:5236连接成功后会进入SQL提示符，可以执行：
select * from v$version; select name, status$ from v$instance;看到数据库状态是OPEN就说明环境没问题了。这里有个经验：刚上手别急着用图形工具，先在disql里把查询跑通，后面排查问题会快很多。
2. 客户端工具连接：Navicat 连接达梦的完整姿势
2.1 Navicat 连接达梦的配置方法
很多同学装好达梦后，习惯性地打开Navicat去连，结果发现连接类型下拉框里找不到达梦，或者连上了报驱动错误。其实新版本的Navicat Premium（16.0以上）已经原生支持达梦数据库，连接类型直接选择Dameng就可以。
新建连接时填这几项：
| 配置项 | 填写内容 |
|---|---|
| 连接名 | 自定义，比如 DM8_test |
| 主机 | 数据库服务器IP |
| 端口 | 5236 |
| 用户名 | SYSDBA |
| 密码 | 安装时设置的SYSDBA密码 |
如果Navicat版本较旧，或者下拉列表里确实没有Dameng选项，那就走ODBC通用连接。先去达梦官网下载对应操作系统的ODBC驱动，装在客户端机器上，配置好数据源后，Navicat里选择ODBC连接类型，再选对应的DSN。Linux客户端还需要装unixODBC，配置odbc.ini和odbcinst.ini，步骤稍微繁琐，但一次配好就能长期用。
2.2 连接失败的常见原因排查
我实际踩过和帮别人排查过的连接问题，主要集中在三个点。
端口不通。很多服务器有防火墙策略，5236端口默认没放行。排查时先确认服务监听正常：
netstat -anp | grep 5236再从客户端机器测一下端口：
telnet 192.168.x.x 5236连不上就先放行防火墙，再继续排查。
驱动缺失或版本不匹配。如果错误提示是“Cannot load JDBC driver”或者ODBC相关报错，基本就是驱动问题。Navicat原生连接达梦一般会自动带驱动，但有些精简版没有，需要手动指定达梦JDBC驱动包。达梦安装目录的drivers/jdbc下有DmJdbcDriver18.jar，把路径配置到Navicat的驱动管理里就行。
密码和用户名。达梦有个特殊点：默认安装完，SYSDBA的密码是初始化时指定的，如果长时间没用或者安装时没注意，可能会被安全策略锁定。真遇到这种情况，重置SYSDBA密码的方法是用操作系统用户加白名单模式登录，或者用disql以本地认证方式连接后执行：
alter user SYSDBA identified by "新密码";2.3 连接成功后建议先做这些设置
连接成功后，我强烈建议先在Navicat里做两件事。
第一，把默认模式改对。达梦里用户和模式是绑定的，比如SYSDBA用户对应SYSDBA模式。业务表一般建在独立用户下，新建连接后默认显示的是SYSDBA模式下的对象。如果发现看不到业务表，检查一下连接属性的“模式”选项。
第二，确认字符集显示正常。如果表数据里中文显示乱码，多半是客户端编码和服务端编码不一致。可以在连接的高级设置里找到编码选项，手动改成和服务端一致的UTF-8。服务端字符集可以通过SQL查看：
select sf_get_unicode_flag();返回值0代表GB18030，1代表UTF-8。客户端设置越早对齐，后面迁移和日常使用越省心。
3. 高可用方案选型：DW 和 DSC 到底怎么选
3.1 DW 数据守护的工作原理与适用场景
达梦的DW（Data Watch），中文叫数据守护，是一主多备的高可用方案，原理和Oracle Data Guard非常像。主库产生归档日志，通过网络实时或异步发送到备库，备库持续应用日志，保持和主库的数据同步。主库故障时，通过守护进程和监视器可以自动或手动将备库切换为主库，业务连续性得到保障。
我在生产环境部署过一套DW，结构是一台主库加一台备库，备库开启只读模式，平时还能分担一部分查询压力。配置DW需要关注几个关键文件：dm.ini里要有ARCH_INI=1，然后配置dmarch.ini指定归档类型和归档目录，再配置dmmal.ini做MAL通信环境，最后是dmwatcher.ini守护进程配置。这套东西第一次配置会有点绕，但配好后就非常稳。
DW适合的场景非常明确：同城容灾、两地三中心、读写分离。它不需要共享存储，主备各用各的磁盘，硬件成本低，部署和运维复杂度也相对可控。对绝大多数业务系统来说，DW是第一优先级考虑的高可用方案。
3.2 DSC 共享存储集群的工作原理与适用场景
DSC的全称是DM Shared Cluster，也就是达梦的共享存储集群，架构上对标的是Oracle RAC。多台数据库实例共享一份数据库文件，这些文件放在SAN存储或分布式存储上，每个实例有自己的内存和日志，通过内部通信机制保证集群一致性。
DSC能实现实例级的故障容错，一个节点宕机，其他节点继续提供服务，应用基本无感知。同时多个节点可以并行处理请求，比DW的读写分离更进一步，真正做到了负载均衡。
但DSC的适用门槛明显更高。首先必须有可靠的共享存储设备，其次至少两台服务器，网络要求也高。我见过不少客户在集采方案里硬上DSC，但底层存储其实撑不住，结果性能反而不如单机。如果业务量没有大到单实例撑不住，或者容灾等级没有高到要求秒级自动切换，DSC大概率是过度设计。
3.3 DW 和 DSC 的对比与选型建议
| 对比维度 | DW 数据守护 | DSC 共享存储集群 |
|---|---|---|
| 架构模式 | 一主多备，备库只读 | 多实例共享数据文件 |
| 存储要求 | 节点独立存储 | 必须共享存储 |
| 数据同步 | 日志实时/异步传送 | 共享存储直接访问 |
| 故障切换 | 主备切换，有短暂中断 | 实例级切换，应用无感知 |
| 扩展方向 | 加备库 | 加节点 |
| 部署复杂度 | 中等 | 高 |
| 典型场景 | 容灾、读写分离 | 高并发、高可用 |
选型我个人的经验是：先问业务对RTO（恢复时间目标）和RPO（恢复点目标）的要求是多少。如果RTO允许分钟级、RPO允许秒级甚至分钟级，选DW完全够用，运维成本还低；如果业务要求故障后几十秒内恢复、数据零丢失，那只能上DSC。绝大多数内部管理系统、OA、ERP，DW就够稳了，没必要为了“更高级”去扛DSC的复杂度和存储成本。
还有一种做法是先上DW，跑一段时间观察负载，如果主库压力确实大，再把备库升级成DSC节点——当然这个改造过程也不轻松，所以前期架构评审时最好就把目标和预算一起定下来。
4. 数据迁移实操：编码问题、迁移工具和“先删后插入”策略
4.1 达梦迁移工具 DTS 的正确打开方式
达梦自带的迁移工具叫DTS（Data Transformation Service），图形界面的程序在安装目录的tool下，Windows直接双击启动脚本，Linux下执行./dts。DTS支持从Oracle、MySQL、SQL Server、PostgreSQL、DB2等主流数据库迁移到达梦，也支持从通用ODBC数据源迁移。
用DTS迁移的流程是：新建工程，新建迁移任务，选择源库类型和连接信息，选择目标库（达梦）连接信息，然后勾选需要迁移的对象——表、视图、序列、存储过程、函数都可以迁移，再设置迁移选项，最后执行并查看日志。
这里我强烈建议：能用DTS就尽量用DTS，别自己手工导出SQL再导入。DTS在底层做了大量类型映射和编码转换工作，手工导入很容易踩类型不兼容和编码不匹配的坑。尤其从PostgreSQL迁过来的时候，很多人用pg_dump导出再导入，报错率非常高。
4.2 编码报错“本地编码pg_gbk，导入文件编码pg_utf8”的解决思路
使用外部SQL文件导入达梦时，很多人会碰到一个很典型的报错提示：本地编码pg_gbk、导入文件编码pg_utf8，两边对不上，导入直接中断或者出现乱码。这个问题的根源是目标库会话的客户端编码用了GBK（GB18030），而导入文件本身是UTF-8编码，或者说反过来了。
解决思路有三种，按推荐程度排序。
思路一，直接用DTS从源库迁移，不要在中间导出SQL文件，让DTS自动做编码转换。这是最省心、最不容易出问题的方案。
思路二，如果确实需要文件导入，先把文件编码转一致。比如把UTF-8的文件转成GBK再执行：
iconv -f UTF-8 -t GBK source.sql -o target.sql反过来转则把-f和-t对调。转换之前备份好原文件，iconv偶尔会在遇到无法映射的字符时中断。
思路三，调整客户端连接编码。如果连接时能指定编码参数，就把客户端编码改到和文件一致。达梦的JDBC连接可以在URL里加encoding=UTF-8，disql也可以用环境变量控制客户端编码。重点是让本地会话编码、导入文件编码、数据库服务端编码三方统一，这个原则搞清楚了，乱码问题基本都能定位。
4.3 迁移表设置“先删后插入”到底在什么场景用
DTS里有一个迁移选项叫“先删后插入”，字面意思就是数据写入目标表之前先执行DELETE，把表清空再插入新数据。这个选项默认可能是关闭的，但在特定场景下必须打开。
什么场景呢？迁移任务重复执行时。比如第一次迁移跑到一半失败了，目标表里已经插了一部分数据，修复问题后重新执行迁移，如果不先删，数据重复插入，唯一索引冲突直接报错，或者数据翻倍。打开“先删后插入”，每次迁移都是幂等的，重跑多少次结果都一样。
还有一种场景是目标表已经存在，且里面有一些旧的测试数据或脏数据，需要被正式数据覆盖。这时“先删后插入”就相当于自动清场。
但要注意，这个选项是把双刃剑。如果目标表里存着不想丢的数据，又没有备份，勾选这个选项后数据直接没了。我在测试环境就干过一回这种事，好在只是测试表，正式环境大家千万要谨慎。建议的习惯是：无论勾不勾选，迁移前先做一次目标库的备份，哪怕只是导出表结构加数据，也就几分钟的事。
4.4 迁移过程中常见的坑与排查实录
迁移过程中我遇到最多的问题，列成一张速查表：
| 问题现象 | 常见原因 | 处理建议 |
|---|---|---|
| 建表失败，提示标识符过长 | 源库表名或字段名超过了达梦限制 | 调整标识符长度，或迁移前做映射 |
| 找不到表或视图 | 大小写敏感设置导致表名带引号 | 建库时设 CASE_SENSITIVE=0 |
| 数据类型不兼容 | Oracle NUMBER不加精度、MySQL TEXT等 | 在DTS的类型映射里手动调整 |
| 中文乱码 | 源库、文件、目标库编码不一致 | 按4.2节的思路统一编码 |
| 大表迁移极慢 | 默认批量提交行数太小 | DTS里调大批次大小，例如每次5000行 |
| 自增列数据不一致 | 序列没有迁移或序列值不对 | 迁移后手工调整序列值到表最大值 |
列表里的第一条和第二条特别典型。有一个项目从MySQL迁到达梦，MySQL的表名都是小写，达梦初始化时CASE_SENSITIVE=1，迁移完应用一跑全都是“表不存在”。最后查下来是大小写敏感的问题，业务SQL里写的是小写表名，数据库里存的是大写。解决办法是根本源头改：重建实例把大小写敏感设为0。所以我在第1部分就反复强调，建库前的参数评估真的不是走过场。
自增列那个坑也很隐蔽。表数据迁过去了，看起来没问题，但应用一插入新记录就报主键冲突，原因就是序列的当前值没有同步到迁移后的表最大值。DTS迁序列时有时候不会自动维护这个关系，需要手工设置。达梦里可以这样重置序列：
alter sequence 序列名 restart with 新起始值;新起始值一般是表当前最大ID加1。
迁移完成之后，我建议做一轮数据对比验证：对比源库和目标库的行数，抽样比对关键字段，再跑一遍应用核心流程。行数不一致常见于LOB字段或特殊字符导致插入失败被工具跳过，DTS日志里会有警告，但默认不会中止任务，不看日志根本发现不了。
5. 全流程走完后的几点个人体会
这一套流程走下来，我的体会是达梦数据库并没有想象中那么“小众不好用”。它的很多设计确实能看到成熟商业数据库的影子，安装、初始化、高可用、迁移都有对应的工具链，只是资料分散，中文搜索结果里还夹杂着大量过时内容，导致上手门槛被人为拉高了。
如果让我给正在做数据库国产化替代的同学一句实在建议，那就是：前期参数规划比后期操作更重要。字符集、大小写敏感、页大小这三个参数，想清楚再动手，后面能省掉一大半麻烦。迁移环节不要图省事手工导数据，把DTS用熟，把“先删后插入”的语义吃透，比任何投机取巧都可靠。
最后再分享一个小技巧：达梦安装目录下有大量示例脚本和文档，路径一般在/opt/dmdbms/doc和/opt/dmdbms/samples，很多网上搜半天的问题，直接翻本地文档就能找到答案。数据库这个领域，踏实读文档永远比碎片化搜索更有效率。
