最近因为项目国产化改造我把一套跑了多年的业务系统整体迁到了达梦数据库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用户执行初始化实例工具dminitsu - dmdba cd /opt/dmdbms/bin ./dminit PATH/opt/dmdbms/data DB_NAMEDAMENG INSTANCE_NAMEDMSERVER \ PORT_NUM5236 CHARSET1 PAGE_SIZE32 CASE_SENSITIVE1这里几个参数值得多说一句。PORT_NUM默认就是5236达梦的服务端口CHARSET1表示UTF-80表示GB18030这个必须和业务数据编码对齐PAGE_SIZE单位是KB可选4、8、16、32一般OLTP系统选16或32页大小确定后很难改建库前就要想好CASE_SENSITIVE1表示标识符大小写敏感这个是达梦为了兼容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/SYSDBAlocalhost:5236连接成功后会进入SQL提示符可以执行select * from v$version; select name, status$ from v$instance;看到数据库状态是OPEN就说明环境没问题了。这里有个经验刚上手别急着用图形工具先在disql里把查询跑通后面排查问题会快很多。2. 客户端工具连接Navicat 连接达梦的完整姿势2.1 Navicat 连接达梦的配置方法很多同学装好达梦后习惯性地打开Navicat去连结果发现连接类型下拉框里找不到达梦或者连上了报驱动错误。其实新版本的Navicat Premium16.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代表GB180301代表UTF-8。客户端设置越早对齐后面迁移和日常使用越省心。3. 高可用方案选型DW 和 DSC 到底怎么选3.1 DW 数据守护的工作原理与适用场景达梦的DWData Watch中文叫数据守护是一主多备的高可用方案原理和Oracle Data Guard非常像。主库产生归档日志通过网络实时或异步发送到备库备库持续应用日志保持和主库的数据同步。主库故障时通过守护进程和监视器可以自动或手动将备库切换为主库业务连续性得到保障。我在生产环境部署过一套DW结构是一台主库加一台备库备库开启只读模式平时还能分担一部分查询压力。配置DW需要关注几个关键文件dm.ini里要有ARCH_INI1然后配置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、ERPDW就够稳了没必要为了“更高级”去扛DSC的复杂度和存储成本。还有一种做法是先上DW跑一段时间观察负载如果主库压力确实大再把备库升级成DSC节点——当然这个改造过程也不轻松所以前期架构评审时最好就把目标和预算一起定下来。4. 数据迁移实操编码问题、迁移工具和“先删后插入”策略4.1 达梦迁移工具 DTS 的正确打开方式达梦自带的迁移工具叫DTSData 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两边对不上导入直接中断或者出现乱码。这个问题的根源是目标库会话的客户端编码用了GBKGB18030而导入文件本身是UTF-8编码或者说反过来了。解决思路有三种按推荐程度排序。思路一直接用DTS从源库迁移不要在中间导出SQL文件让DTS自动做编码转换。这是最省心、最不容易出问题的方案。思路二如果确实需要文件导入先把文件编码转一致。比如把UTF-8的文件转成GBK再执行iconv -f UTF-8 -t GBK source.sql -o target.sql反过来转则把-f和-t对调。转换之前备份好原文件iconv偶尔会在遇到无法映射的字符时中断。思路三调整客户端连接编码。如果连接时能指定编码参数就把客户端编码改到和文件一致。达梦的JDBC连接可以在URL里加encodingUTF-8disql也可以用环境变量控制客户端编码。重点是让本地会话编码、导入文件编码、数据库服务端编码三方统一这个原则搞清楚了乱码问题基本都能定位。4.3 迁移表设置“先删后插入”到底在什么场景用DTS里有一个迁移选项叫“先删后插入”字面意思就是数据写入目标表之前先执行DELETE把表清空再插入新数据。这个选项默认可能是关闭的但在特定场景下必须打开。什么场景呢迁移任务重复执行时。比如第一次迁移跑到一半失败了目标表里已经插了一部分数据修复问题后重新执行迁移如果不先删数据重复插入唯一索引冲突直接报错或者数据翻倍。打开“先删后插入”每次迁移都是幂等的重跑多少次结果都一样。还有一种场景是目标表已经存在且里面有一些旧的测试数据或脏数据需要被正式数据覆盖。这时“先删后插入”就相当于自动清场。但要注意这个选项是把双刃剑。如果目标表里存着不想丢的数据又没有备份勾选这个选项后数据直接没了。我在测试环境就干过一回这种事好在只是测试表正式环境大家千万要谨慎。建议的习惯是无论勾不勾选迁移前先做一次目标库的备份哪怕只是导出表结构加数据也就几分钟的事。4.4 迁移过程中常见的坑与排查实录迁移过程中我遇到最多的问题列成一张速查表问题现象常见原因处理建议建表失败提示标识符过长源库表名或字段名超过了达梦限制调整标识符长度或迁移前做映射找不到表或视图大小写敏感设置导致表名带引号建库时设 CASE_SENSITIVE0数据类型不兼容Oracle NUMBER不加精度、MySQL TEXT等在DTS的类型映射里手动调整中文乱码源库、文件、目标库编码不一致按4.2节的思路统一编码大表迁移极慢默认批量提交行数太小DTS里调大批次大小例如每次5000行自增列数据不一致序列没有迁移或序列值不对迁移后手工调整序列值到表最大值列表里的第一条和第二条特别典型。有一个项目从MySQL迁到达梦MySQL的表名都是小写达梦初始化时CASE_SENSITIVE1迁移完应用一跑全都是“表不存在”。最后查下来是大小写敏感的问题业务SQL里写的是小写表名数据库里存的是大写。解决办法是根本源头改重建实例把大小写敏感设为0。所以我在第1部分就反复强调建库前的参数评估真的不是走过场。自增列那个坑也很隐蔽。表数据迁过去了看起来没问题但应用一插入新记录就报主键冲突原因就是序列的当前值没有同步到迁移后的表最大值。DTS迁序列时有时候不会自动维护这个关系需要手工设置。达梦里可以这样重置序列alter sequence 序列名 restart with 新起始值;新起始值一般是表当前最大ID加1。迁移完成之后我建议做一轮数据对比验证对比源库和目标库的行数抽样比对关键字段再跑一遍应用核心流程。行数不一致常见于LOB字段或特殊字符导致插入失败被工具跳过DTS日志里会有警告但默认不会中止任务不看日志根本发现不了。5. 全流程走完后的几点个人体会这一套流程走下来我的体会是达梦数据库并没有想象中那么“小众不好用”。它的很多设计确实能看到成熟商业数据库的影子安装、初始化、高可用、迁移都有对应的工具链只是资料分散中文搜索结果里还夹杂着大量过时内容导致上手门槛被人为拉高了。如果让我给正在做数据库国产化替代的同学一句实在建议那就是前期参数规划比后期操作更重要。字符集、大小写敏感、页大小这三个参数想清楚再动手后面能省掉一大半麻烦。迁移环节不要图省事手工导数据把DTS用熟把“先删后插入”的语义吃透比任何投机取巧都可靠。最后再分享一个小技巧达梦安装目录下有大量示例脚本和文档路径一般在/opt/dmdbms/doc和/opt/dmdbms/samples很多网上搜半天的问题直接翻本地文档就能找到答案。数据库这个领域踏实读文档永远比碎片化搜索更有效率。