说实话以前用Navicat连达梦数据库有种“有劲没处使”的感觉。Navicat长期自带主流的MySQL、PostgreSQL、Oracle、SQL Server但国产的达梦DM直到Premium 17版本才开始原生支持。实际操作过才知道光“能连上”只算敲门砖——达梦的元数据体系、用户与模式绑定机制、数据字典的生成方式都跟MySQL那套底子不太一样。我这个技术指引系列就是想把“Navicat x 达梦”这条线走完整从凭什么选它到连接配置再到系统表分析、数据字典自动化生成最后附上真实踩坑记录。适用对象很明确准备做国产化适配的Java后端、接手达梦运维的DBA以及那些被要求“顺便把数据字典文档导出来”的开发同学。1. 为什么是“Navicat 达梦”以及达梦的几个关键认知1.1 Navicat对达梦的兼容情况先解决“能不能连”的问题。Navicat Premium 17发布之后数据库类型列表里正式出现了“达梦”DM这意味着你终于不用绕道ODBC折腾半天的驱动映射了。连接窗口原生支持达梦的端口、用户、模式这些概念查询、建模、数据同步、导出导入也都拿得出手。对于16及更早版本的用户倒也不是完全没办法——走ODBC驱动也能连但体验上会差不少特别是元数据读取、模型生成这类功能经常抽风。所以我的建议很直接真要跟达梦长期打交道优先上Premium 17。但“兼容”不等于“一马平川”。达梦的很多设计思路和Oracle接近跟MySQL相差较大。如果你只熟悉MySQL连上之后第一个感觉可能是“这界面怎么这么多模式”。这就引出了下一个必须搞懂的概念。1.2 达梦的“用户模式”机制必须先搞懂MySQL里“数据库”这个概念很直接CREATE DATABASE xxx然后USE xxx。达梦不一样它沿用Oracle的体系一个用户可以对应一个默认的模式SCHEMA表和对象都归属在模式下面。你执行CREATE USER dm_user IDENTIFIED BY xxx之后系统会自动生成一个名为dm_user的模式你在dm_user下建的表全名其实是dm_user.表名。这一点直接影响你后续的数据字典查询和SQL拼接。很多首次迁移的人会问“为什么我在达梦里找不到mysql下的表”答案往往就是你还没把数据导到对应模式下面或者你查系统表时没有按模式去过滤。达梦还支持兼容模式建库时可以选择兼容Oracle、MySQL还是PostgreSQL语法。我实际测试下来如果团队是从Oracle迁过来基本零成本如果是从MySQL转建议建库时直接选兼容MySQL模式能省掉不少字符串函数、分页语法上的麻烦。1.3 达梦与Oracle/MySQL的差异速览这张表对DBA和开发都有参考价值对比项达梦 DM8MySQLOracle默认端口523633061521用户/模式用户关联模式数据库实例用户关联模式类型风格Oracle兼容为主自有风格NUMBER/VARCHAR2分页ROWNUM/LIMIT兼容LIMIT OFFSETROWNUM/ROW_NUMBER()自增列IDENTITY/AUTO_INCREMENTAUTO_INCREMENTIDENTITY/SEQUENCE触发器从上面的对比能看到达梦的“体质”更接近Oracle。如果你以前是MySQL用户第一次接触达梦时别急着套用MySQL的经验先花半天把它的元数据视图、系统函数过一遍后面会顺很多。2. 环境准备与连接实操从装驱动到建立连接2.1 达梦数据库的安装与初始化Docker方式开发环境里最省事的安装方式就是用Docker。达梦官方有镜像dameng/dameng8拉下来就能跑docker pull dameng/dameng8 docker run -d -p 5236:5236 \ -e LD_LIBRARY_PATH/opt/dmdbms/bin \ --name dm8 dameng/dameng8启动后默认的初始化库是DM8实例端口走5236。第一次登录建议直接用安装时配置的管理员账号比如SYSDBA。这里有个需要留意的点不同发行版对默认密码的要求不一样有的是安装时强制改有的是给了一个初始密码。如果你拿不准可以先看容器日志或者官方初始化文档别猜密码猜半天。如果是在生产环境用还需要配置数据目录、初始化参数、字符集这些建议参考达梦官方安装文档一步步来这里不展开。镜像起来后可以先在宿主机用disql验证一下服务是不是正常docker exec -it dm8 /opt/dmdbms/bin/disql SYSDBA/你的密码localhost:5236能进disql会话说明服务没问题接下来再用Navicat连就能把问题范围缩小到Navicat配置这一侧。2.2 Navicat连接达梦图形化配置步骤打开Navicat Premium 17点击左上角“连接”在下拉菜单里找到“达梦”如果版本不支持可能需要检查你的授权或者升级到17以上。填几个关键项连接名随便起比如 dm8-dev主机127.0.0.1 或远程主机IP端口5236用户名SYSDBA或者是你在达梦中创建的业务用户密码对应用户的密码填完后建议先点“测试连接”确认网络、端口、账号三方都通畅再保存。测试成功后连接树里会出现“模式”节点展开就能看到当前用户能访问的所有模式。默认管理员SYSDBA能看到SYS、SYSDBA、PUBLIC等一堆模式业务用户通常只看到自己的模式和PUBLIC。2.3 连接参数与初始化脚本说明几个容易被忽略的配置项编码达梦默认字符集跟初始化库时的配置有关。如果连接后中文乱码优先确认达梦实例的字符集UTF-8是最常用的Navicat这边不用特别设它通常会自适应。SSL内网开发环境一般不开生产环境如果开了SSLNavicat连接设置里记得勾选对应的SSL配置。高级设置Navicat的“高级”选项卡里可以设置连接超时、维持连接时长保持活跃间隔对长查询场景比较重要。连接配置这块最后补一句在Navicat里建议把常用的达梦连接分组管理比如开发、测试、生产分成不同分组配色也换一下可以有效防止“手滑连错库”的惨剧。这真的不是小事我见过不止一次因为连接名相近把测试数据写到生产的情况。3. 数据字典的核心用SQL把元数据“捞”出来3.1 数据字典是什么、能做什么数据字典说白了一句话数据库的“说明文档”。它描述库里有哪些表、每张表有哪些字段、什么类型、是否可空、默认值是多少、有哪些索引和约束。有人会觉得“表结构不就在Navicat里点开就能看吗为什么还要专门做数据字典”原因很简单开发文档、系统设计文档、汇报材料总不能截图一张张贴吧产出一份结构化的数据字典文档才是能交付、可复用的东西。尤其在做系统重构和影响分析的时候数据字典的价值会放大。你要评估“改一个字段长度会影响哪些表”靠人工去翻几十张表是不现实的直接用SQL扫系统表结果又快又准。在Navicat里数据字典还承担了一个角色让新同学快速上手业务表结构。新人入职看代码经常一头雾水给他一份按模块分好的数据字典再加上流程图上手速度快很多。3.2 达梦系统表速查SYSOBJECTS / SYSCOLUMNS 等达梦把元数据存在系统模式SYS下最核心的几张表SYS.SYSOBJECTS数据库对象主表包含表、视图、索引、约束、存储过程、序列等对象的基本信息对象ID、名称、类型、子类型、所属用户等。SYS.SYSCOLUMNS列定义表记录每张表的每个字段包含字段名、字段序号、类型信息、默认值、可空性等。SYS.SYSCONSTRAINTS约束表主键、唯一约束、检查约束等。SYS.SYSINDEXES索引表记录索引名称、所属对象ID、索引列顺序等。光看表名还不行最重要的是能灵活过滤。比如SYSOBJECTS的TYPE$字段不同数值代表不同类型0表示表1表示视图2表示索引3表示触发器以此类推。实际查询时想只要普通用户表就加上TYPE$ 0和OWNER过滤。不过对于大多数应用开发场景我更推荐直接使用达梦提供的兼容视图Oracle风格比如ALL_TABLES / USER_TABLES表清单ALL_TAB_COLUMNS / USER_TAB_COLUMNS字段清单ALL_CONSTRAINTS / USER_CONSTRAINTS约束清单ALL_INDEXES / USER_INDEXES索引清单这些视图在达梦中是存在的从Oracle转过来的DBA几乎零学习成本。3.3 实操生成数据字典的查询示例假设我们要生成某业务用户的数据字典第一步列出所有表SELECT owner, table_name, tablespace_name, status FROM all_tables WHERE owner DM_USER ORDER BY table_name;第二步为了生成每个表的详细字段说明可以连查询字段信息SELECT table_name AS 表名, column_id AS 序号, column_name AS 字段名, data_type AS 类型, data_length AS 长度, nullable AS 可空, data_default AS 默认值 FROM all_tab_columns WHERE owner DM_USER ORDER BY table_name, column_id;第三步加上主键、索引和注释就能生成比较完整的数据字典文档。实际项目中我一般分几步执行先跑表清单再跑字段清单然后跑约束清单最后在Excel里用VLOOKUP把几张表的数据合并成一张大表也就是“一表一Sheet”的字典。如果建表时写了COMMENT还能把业务说明也拉进来字段说明会比裸字段名友好得多SELECT c.table_name AS 表名, c.column_name AS 字段名, e.comments AS 字段说明 FROM all_tab_columns c LEFT JOIN all_col_comments e ON c.owner e.owner AND c.table_name e.table_name AND c.column_name e.column_name WHERE c.owner DM_USER ORDER BY c.table_name, c.column_id;这里有个小技巧如果团队建表时没有规范写注释数据字典的质量会大打折扣。所以我给团队定的规矩是建表必须带COMMENT后续改字段也必须同步改COMMENT。这不是为了好看是为了让数据字典真正成为“活文档”。3.4 在Navicat中把SQL变成可复用的字典模板查数据字典的SQL不需要每次手工敲。Navicat里有“查询”功能把上面那些SQL保存成查询文件下次双击就能跑。更方便的是结合Navicat的“报表”功能把查询结果直接生成PDF或Excel报表给业务方展示或者归档都用得上。我个人的习惯是在Navicat里建一个“字典模板”文件夹里面放几套固定查询表清单、字段明细、约束与索引、对象依赖。这次需要什么跑哪套几分钟就能出一份像样的字典文档。相比用PL/SQL Developer或者手工写SQL脚本Navicat在图和文档两个维度上的整合确实更省心。4. 日常运维与数据迁移实操4.1 MySQL迁移到达梦的要点信创改造里最典型的场景就是MySQL迁达梦。我踩过不少坑先说结论小表直接Navicat复制数据大表建议用达梦自带的DTS迁移工具。原因在于Navicat的数据传输走的是逐条INSERT遇到大表或者特殊类型就会有性能瓶颈。迁移前先做类型对照MySQL类型达梦建议VARCHAR(n)VARCHAR(n) 或 VARCHAR2(n)DATETIMETIMESTAMP 或 DATETEXT/JSONCLOB 或 TEXTDECIMAL(p,s)NUMBER(p,s) 或 DECIMAL(p,s)TINYINTSMALLINT 或 NUMBER(3)语法差异上以下几个是高频坑字符串拼接MySQL用CONCAT_WS达梦兼容Oracle的||也支持CONCAT但多参数CONCAT在达梦里可能行为不一致需要测。分页MySQL是LIMIT offset, count达梦兼容MySQL模式下支持LIMIT如果建库时选了Oracle模式要用ROWNUM或者FETCH FIRST。自增MySQL的AUTO_INCREMENT在达梦里可以用IDENTITY函数也支持用IDENTITY()或者自带的序列。迁移步骤上我比较推荐先用Navicat的“数据传输”功能做一次全量结构同步选好源库和目标库勾选你要迁移的表Navicat会自动生成对应的建表语句。结构同步完成后再导数据。导完数据记得做三件事第一用SELECT COUNT(*)做行数比对第二抽查几个关键表的数据内容别只比对数量第三跑一遍应用的核心查询SQL确认没有语法不兼容的地方。4.2 在Navicat中管理和查看模式/权限/空间连接上达梦后Navicat的左侧树可以浏览模式下的所有表、视图、函数、存储过程、序列等对象。想改表结构右键“设计表”即可可视化界面能直接改字段、默认值、注释。要注意的是达梦对DDL的很多操作是隐式提交的——改完保存就执行了不像MySQL里有些操作还能回滚所以生产环境改表前一定备份。查看权限和空间通过Navicat的“用户”节点可以查看当前连接用户权限但达梦底层管理更多还是得靠SQL。常用的几个视图DBA_USERS用户、DBA_TABLESPACE_USAGE表空间使用、DBA_TABLES表清单。这些视图在达梦的Oracle兼容视图体系里都有。表空间管理是运维重点。达梦默认有MAIN、ROLL、SYSTEM等表空间业务表放MAIN即可但如果数据量增长快最好提前给业务单独建表空间避免和系统表空间混在一起。我在一个项目里就吃过亏刚开始图省事业务表全丢在MAIN表空间里后来发现系统表空间跟着膨胀备份恢复都变慢。后来专门给核心业务拆了一个独立表空间管理起来清爽很多。5. 常见问题与排查技巧实录5.1 连接报错 -2501用户名或密码错误这是Navicat连达梦时最经典的报错[hy000] 用户名或密码错误 (-2501)。第一次看到这条错误时我下意识以为是密码问题换了三次密码都不对最后发现是用户名的大小写问题。达梦对用户名是分大小写的如果你创建时用了大写的DM_USER连接时写dm_user就会报这个错。排查顺序建议先用disql在服务器上验证同账号是否能登录排除账号本身问题。确认Navicat填的用户名大小写与创建时完全一致。确认密码有没有被密码策略强制改过比如首次登录必须改密。确认网络端口是否能通用telnet ip 5236测一下。查看达梦日志路径一般在/opt/dmdbms/log报错会留下具体原因。5.2 模式错误对象找不到另一个高频问题是“表或视图不存在”或者“模式错误”。这在达梦里一般就两种情况表在别的模式下当前用户没有权限或者没有加模式前缀。你在SQL中写的是SELECT * FROM tablename而达梦默认搜索当前用户的模式查不到就报错。解决方法是SQL里显式加上模式名SELECT * FROM DM_USER.tablename。在Navicat的模型视图里它也允许你指定涉及的模式生成ER图之前先确认选了正确的模式否则图会缺一大堆表。另外注意如果你执行的是CREATE TABLE表建出来可能在当前用户的默认模式下。如果中途切了模式再操作后面的引用就全乱了。我的习惯是在每次连接会话初期就确认当前模式或者干脆在表名前面带上模式前缀。5.3 驱动与版本匹配问题如果你用的是Navicat 16或更早版本走ODBC连接时驱动版本不匹配的问题会比较常见。达梦官网提供DM ODBC驱动安装完在Navicat选择数据源时要指定对应当是32位还是64位——Navicat本身是64位如果装了32位ODBC驱动怎么连都报“找不到数据源”。判断驱动架构的方式在Windows的ODBC数据源管理工具里看是“32位还是64位”入口下的驱动。如果升级到Navicat 17原生支持达梦后就不用操心ODBC了这也再次说明为什么我建议直接用17。不过有些老项目里的Navicat 16还承担着日常运维任务业务紧急的时候我们也不去升级而是保留两套环境16连MySQL和旧库17连达梦新库避免来回切换。这里还要注意一个点达梦的JDBC驱动和ODBC驱动有时候版本也不一样如果你是在Java项目里用JDBC直连达梦驱动包版本要跟达梦服务端版本匹配不然也会出现一些莫名其妙的问题比如字符集乱码、建链失败。5.4 字符集与乱码最后是中文乱码。达梦的字符集在初始化实例时就定下来了常见有UTF-8、GB18030、GBK。如果应用写入的是UTF-8而达梦实例字符集是GB18030Navicat里看中文就会变成乱码。这种乱码基本无解只能在初始化时统一字符集或者用数据迁移工具做一次字符集转换。Navicat侧能做的事是连接属性里确认“编码”没有被手工改成奇怪的值不然就算实例字符集没问题显示层面也会乱。查询时也可以临时用UNICODE()、CONVERT()这类函数做调试但治标不治本。如果你要在新环境里搭达梦我的建议是直接上UTF-8这套标准在跨平台、跨应用时最省心。GB18030虽然对中文支持也不错但遇到接口对接、报表导出这些场景编码不一致的坑能让人查到怀疑人生。结尾最后聊点个人实战体会。达梦这套东西只要理解了“用户-模式-对象”的层级关系再用Navicat做可视化入口绝大多数工作是能顺手推进的。我第一次用Navicat连达梦时也遇到过-2501、模式不对这些问题但当你把错误当成信息去读——它告诉你是用户、密码、模式哪个环节出问题了——排错速度会快很多。另外一个实用建议在项目初期就建立数据字典查询模板并且把COMMENT写规范。等到做测试数据核对、系统上线评审的时候你会感谢当时的自己。后面我还会继续分享达梦与DBeaver、JDBC驱动版本、数据字典自动化生成工具链等内容欢迎持续关注。
说实话以前用Navicat连达梦数据库有种“有劲没处使”的感觉。Navicat长期自带主流的MySQL、PostgreSQL、Oracle、SQL Server但国产的达梦DM直到Premium 17版本才开始原生支持。实际操作过才知道光“能连上”只算敲门砖——达梦的元数据体系、用户与模式绑定机制、数据字典的生成方式都跟MySQL那套底子不太一样。我这个技术指引系列就是想把“Navicat x 达梦”这条线走完整从凭什么选它到连接配置再到系统表分析、数据字典自动化生成最后附上真实踩坑记录。适用对象很明确准备做国产化适配的Java后端、接手达梦运维的DBA以及那些被要求“顺便把数据字典文档导出来”的开发同学。1. 为什么是“Navicat 达梦”以及达梦的几个关键认知1.1 Navicat对达梦的兼容情况先解决“能不能连”的问题。Navicat Premium 17发布之后数据库类型列表里正式出现了“达梦”DM这意味着你终于不用绕道ODBC折腾半天的驱动映射了。连接窗口原生支持达梦的端口、用户、模式这些概念查询、建模、数据同步、导出导入也都拿得出手。对于16及更早版本的用户倒也不是完全没办法——走ODBC驱动也能连但体验上会差不少特别是元数据读取、模型生成这类功能经常抽风。所以我的建议很直接真要跟达梦长期打交道优先上Premium 17。但“兼容”不等于“一马平川”。达梦的很多设计思路和Oracle接近跟MySQL相差较大。如果你只熟悉MySQL连上之后第一个感觉可能是“这界面怎么这么多模式”。这就引出了下一个必须搞懂的概念。1.2 达梦的“用户模式”机制必须先搞懂MySQL里“数据库”这个概念很直接CREATE DATABASE xxx然后USE xxx。达梦不一样它沿用Oracle的体系一个用户可以对应一个默认的模式SCHEMA表和对象都归属在模式下面。你执行CREATE USER dm_user IDENTIFIED BY xxx之后系统会自动生成一个名为dm_user的模式你在dm_user下建的表全名其实是dm_user.表名。这一点直接影响你后续的数据字典查询和SQL拼接。很多首次迁移的人会问“为什么我在达梦里找不到mysql下的表”答案往往就是你还没把数据导到对应模式下面或者你查系统表时没有按模式去过滤。达梦还支持兼容模式建库时可以选择兼容Oracle、MySQL还是PostgreSQL语法。我实际测试下来如果团队是从Oracle迁过来基本零成本如果是从MySQL转建议建库时直接选兼容MySQL模式能省掉不少字符串函数、分页语法上的麻烦。1.3 达梦与Oracle/MySQL的差异速览这张表对DBA和开发都有参考价值对比项达梦 DM8MySQLOracle默认端口523633061521用户/模式用户关联模式数据库实例用户关联模式类型风格Oracle兼容为主自有风格NUMBER/VARCHAR2分页ROWNUM/LIMIT兼容LIMIT OFFSETROWNUM/ROW_NUMBER()自增列IDENTITY/AUTO_INCREMENTAUTO_INCREMENTIDENTITY/SEQUENCE触发器从上面的对比能看到达梦的“体质”更接近Oracle。如果你以前是MySQL用户第一次接触达梦时别急着套用MySQL的经验先花半天把它的元数据视图、系统函数过一遍后面会顺很多。2. 环境准备与连接实操从装驱动到建立连接2.1 达梦数据库的安装与初始化Docker方式开发环境里最省事的安装方式就是用Docker。达梦官方有镜像dameng/dameng8拉下来就能跑docker pull dameng/dameng8 docker run -d -p 5236:5236 \ -e LD_LIBRARY_PATH/opt/dmdbms/bin \ --name dm8 dameng/dameng8启动后默认的初始化库是DM8实例端口走5236。第一次登录建议直接用安装时配置的管理员账号比如SYSDBA。这里有个需要留意的点不同发行版对默认密码的要求不一样有的是安装时强制改有的是给了一个初始密码。如果你拿不准可以先看容器日志或者官方初始化文档别猜密码猜半天。如果是在生产环境用还需要配置数据目录、初始化参数、字符集这些建议参考达梦官方安装文档一步步来这里不展开。镜像起来后可以先在宿主机用disql验证一下服务是不是正常docker exec -it dm8 /opt/dmdbms/bin/disql SYSDBA/你的密码localhost:5236能进disql会话说明服务没问题接下来再用Navicat连就能把问题范围缩小到Navicat配置这一侧。2.2 Navicat连接达梦图形化配置步骤打开Navicat Premium 17点击左上角“连接”在下拉菜单里找到“达梦”如果版本不支持可能需要检查你的授权或者升级到17以上。填几个关键项连接名随便起比如 dm8-dev主机127.0.0.1 或远程主机IP端口5236用户名SYSDBA或者是你在达梦中创建的业务用户密码对应用户的密码填完后建议先点“测试连接”确认网络、端口、账号三方都通畅再保存。测试成功后连接树里会出现“模式”节点展开就能看到当前用户能访问的所有模式。默认管理员SYSDBA能看到SYS、SYSDBA、PUBLIC等一堆模式业务用户通常只看到自己的模式和PUBLIC。2.3 连接参数与初始化脚本说明几个容易被忽略的配置项编码达梦默认字符集跟初始化库时的配置有关。如果连接后中文乱码优先确认达梦实例的字符集UTF-8是最常用的Navicat这边不用特别设它通常会自适应。SSL内网开发环境一般不开生产环境如果开了SSLNavicat连接设置里记得勾选对应的SSL配置。高级设置Navicat的“高级”选项卡里可以设置连接超时、维持连接时长保持活跃间隔对长查询场景比较重要。连接配置这块最后补一句在Navicat里建议把常用的达梦连接分组管理比如开发、测试、生产分成不同分组配色也换一下可以有效防止“手滑连错库”的惨剧。这真的不是小事我见过不止一次因为连接名相近把测试数据写到生产的情况。3. 数据字典的核心用SQL把元数据“捞”出来3.1 数据字典是什么、能做什么数据字典说白了一句话数据库的“说明文档”。它描述库里有哪些表、每张表有哪些字段、什么类型、是否可空、默认值是多少、有哪些索引和约束。有人会觉得“表结构不就在Navicat里点开就能看吗为什么还要专门做数据字典”原因很简单开发文档、系统设计文档、汇报材料总不能截图一张张贴吧产出一份结构化的数据字典文档才是能交付、可复用的东西。尤其在做系统重构和影响分析的时候数据字典的价值会放大。你要评估“改一个字段长度会影响哪些表”靠人工去翻几十张表是不现实的直接用SQL扫系统表结果又快又准。在Navicat里数据字典还承担了一个角色让新同学快速上手业务表结构。新人入职看代码经常一头雾水给他一份按模块分好的数据字典再加上流程图上手速度快很多。3.2 达梦系统表速查SYSOBJECTS / SYSCOLUMNS 等达梦把元数据存在系统模式SYS下最核心的几张表SYS.SYSOBJECTS数据库对象主表包含表、视图、索引、约束、存储过程、序列等对象的基本信息对象ID、名称、类型、子类型、所属用户等。SYS.SYSCOLUMNS列定义表记录每张表的每个字段包含字段名、字段序号、类型信息、默认值、可空性等。SYS.SYSCONSTRAINTS约束表主键、唯一约束、检查约束等。SYS.SYSINDEXES索引表记录索引名称、所属对象ID、索引列顺序等。光看表名还不行最重要的是能灵活过滤。比如SYSOBJECTS的TYPE$字段不同数值代表不同类型0表示表1表示视图2表示索引3表示触发器以此类推。实际查询时想只要普通用户表就加上TYPE$ 0和OWNER过滤。不过对于大多数应用开发场景我更推荐直接使用达梦提供的兼容视图Oracle风格比如ALL_TABLES / USER_TABLES表清单ALL_TAB_COLUMNS / USER_TAB_COLUMNS字段清单ALL_CONSTRAINTS / USER_CONSTRAINTS约束清单ALL_INDEXES / USER_INDEXES索引清单这些视图在达梦中是存在的从Oracle转过来的DBA几乎零学习成本。3.3 实操生成数据字典的查询示例假设我们要生成某业务用户的数据字典第一步列出所有表SELECT owner, table_name, tablespace_name, status FROM all_tables WHERE owner DM_USER ORDER BY table_name;第二步为了生成每个表的详细字段说明可以连查询字段信息SELECT table_name AS 表名, column_id AS 序号, column_name AS 字段名, data_type AS 类型, data_length AS 长度, nullable AS 可空, data_default AS 默认值 FROM all_tab_columns WHERE owner DM_USER ORDER BY table_name, column_id;第三步加上主键、索引和注释就能生成比较完整的数据字典文档。实际项目中我一般分几步执行先跑表清单再跑字段清单然后跑约束清单最后在Excel里用VLOOKUP把几张表的数据合并成一张大表也就是“一表一Sheet”的字典。如果建表时写了COMMENT还能把业务说明也拉进来字段说明会比裸字段名友好得多SELECT c.table_name AS 表名, c.column_name AS 字段名, e.comments AS 字段说明 FROM all_tab_columns c LEFT JOIN all_col_comments e ON c.owner e.owner AND c.table_name e.table_name AND c.column_name e.column_name WHERE c.owner DM_USER ORDER BY c.table_name, c.column_id;这里有个小技巧如果团队建表时没有规范写注释数据字典的质量会大打折扣。所以我给团队定的规矩是建表必须带COMMENT后续改字段也必须同步改COMMENT。这不是为了好看是为了让数据字典真正成为“活文档”。3.4 在Navicat中把SQL变成可复用的字典模板查数据字典的SQL不需要每次手工敲。Navicat里有“查询”功能把上面那些SQL保存成查询文件下次双击就能跑。更方便的是结合Navicat的“报表”功能把查询结果直接生成PDF或Excel报表给业务方展示或者归档都用得上。我个人的习惯是在Navicat里建一个“字典模板”文件夹里面放几套固定查询表清单、字段明细、约束与索引、对象依赖。这次需要什么跑哪套几分钟就能出一份像样的字典文档。相比用PL/SQL Developer或者手工写SQL脚本Navicat在图和文档两个维度上的整合确实更省心。4. 日常运维与数据迁移实操4.1 MySQL迁移到达梦的要点信创改造里最典型的场景就是MySQL迁达梦。我踩过不少坑先说结论小表直接Navicat复制数据大表建议用达梦自带的DTS迁移工具。原因在于Navicat的数据传输走的是逐条INSERT遇到大表或者特殊类型就会有性能瓶颈。迁移前先做类型对照MySQL类型达梦建议VARCHAR(n)VARCHAR(n) 或 VARCHAR2(n)DATETIMETIMESTAMP 或 DATETEXT/JSONCLOB 或 TEXTDECIMAL(p,s)NUMBER(p,s) 或 DECIMAL(p,s)TINYINTSMALLINT 或 NUMBER(3)语法差异上以下几个是高频坑字符串拼接MySQL用CONCAT_WS达梦兼容Oracle的||也支持CONCAT但多参数CONCAT在达梦里可能行为不一致需要测。分页MySQL是LIMIT offset, count达梦兼容MySQL模式下支持LIMIT如果建库时选了Oracle模式要用ROWNUM或者FETCH FIRST。自增MySQL的AUTO_INCREMENT在达梦里可以用IDENTITY函数也支持用IDENTITY()或者自带的序列。迁移步骤上我比较推荐先用Navicat的“数据传输”功能做一次全量结构同步选好源库和目标库勾选你要迁移的表Navicat会自动生成对应的建表语句。结构同步完成后再导数据。导完数据记得做三件事第一用SELECT COUNT(*)做行数比对第二抽查几个关键表的数据内容别只比对数量第三跑一遍应用的核心查询SQL确认没有语法不兼容的地方。4.2 在Navicat中管理和查看模式/权限/空间连接上达梦后Navicat的左侧树可以浏览模式下的所有表、视图、函数、存储过程、序列等对象。想改表结构右键“设计表”即可可视化界面能直接改字段、默认值、注释。要注意的是达梦对DDL的很多操作是隐式提交的——改完保存就执行了不像MySQL里有些操作还能回滚所以生产环境改表前一定备份。查看权限和空间通过Navicat的“用户”节点可以查看当前连接用户权限但达梦底层管理更多还是得靠SQL。常用的几个视图DBA_USERS用户、DBA_TABLESPACE_USAGE表空间使用、DBA_TABLES表清单。这些视图在达梦的Oracle兼容视图体系里都有。表空间管理是运维重点。达梦默认有MAIN、ROLL、SYSTEM等表空间业务表放MAIN即可但如果数据量增长快最好提前给业务单独建表空间避免和系统表空间混在一起。我在一个项目里就吃过亏刚开始图省事业务表全丢在MAIN表空间里后来发现系统表空间跟着膨胀备份恢复都变慢。后来专门给核心业务拆了一个独立表空间管理起来清爽很多。5. 常见问题与排查技巧实录5.1 连接报错 -2501用户名或密码错误这是Navicat连达梦时最经典的报错[hy000] 用户名或密码错误 (-2501)。第一次看到这条错误时我下意识以为是密码问题换了三次密码都不对最后发现是用户名的大小写问题。达梦对用户名是分大小写的如果你创建时用了大写的DM_USER连接时写dm_user就会报这个错。排查顺序建议先用disql在服务器上验证同账号是否能登录排除账号本身问题。确认Navicat填的用户名大小写与创建时完全一致。确认密码有没有被密码策略强制改过比如首次登录必须改密。确认网络端口是否能通用telnet ip 5236测一下。查看达梦日志路径一般在/opt/dmdbms/log报错会留下具体原因。5.2 模式错误对象找不到另一个高频问题是“表或视图不存在”或者“模式错误”。这在达梦里一般就两种情况表在别的模式下当前用户没有权限或者没有加模式前缀。你在SQL中写的是SELECT * FROM tablename而达梦默认搜索当前用户的模式查不到就报错。解决方法是SQL里显式加上模式名SELECT * FROM DM_USER.tablename。在Navicat的模型视图里它也允许你指定涉及的模式生成ER图之前先确认选了正确的模式否则图会缺一大堆表。另外注意如果你执行的是CREATE TABLE表建出来可能在当前用户的默认模式下。如果中途切了模式再操作后面的引用就全乱了。我的习惯是在每次连接会话初期就确认当前模式或者干脆在表名前面带上模式前缀。5.3 驱动与版本匹配问题如果你用的是Navicat 16或更早版本走ODBC连接时驱动版本不匹配的问题会比较常见。达梦官网提供DM ODBC驱动安装完在Navicat选择数据源时要指定对应当是32位还是64位——Navicat本身是64位如果装了32位ODBC驱动怎么连都报“找不到数据源”。判断驱动架构的方式在Windows的ODBC数据源管理工具里看是“32位还是64位”入口下的驱动。如果升级到Navicat 17原生支持达梦后就不用操心ODBC了这也再次说明为什么我建议直接用17。不过有些老项目里的Navicat 16还承担着日常运维任务业务紧急的时候我们也不去升级而是保留两套环境16连MySQL和旧库17连达梦新库避免来回切换。这里还要注意一个点达梦的JDBC驱动和ODBC驱动有时候版本也不一样如果你是在Java项目里用JDBC直连达梦驱动包版本要跟达梦服务端版本匹配不然也会出现一些莫名其妙的问题比如字符集乱码、建链失败。5.4 字符集与乱码最后是中文乱码。达梦的字符集在初始化实例时就定下来了常见有UTF-8、GB18030、GBK。如果应用写入的是UTF-8而达梦实例字符集是GB18030Navicat里看中文就会变成乱码。这种乱码基本无解只能在初始化时统一字符集或者用数据迁移工具做一次字符集转换。Navicat侧能做的事是连接属性里确认“编码”没有被手工改成奇怪的值不然就算实例字符集没问题显示层面也会乱。查询时也可以临时用UNICODE()、CONVERT()这类函数做调试但治标不治本。如果你要在新环境里搭达梦我的建议是直接上UTF-8这套标准在跨平台、跨应用时最省心。GB18030虽然对中文支持也不错但遇到接口对接、报表导出这些场景编码不一致的坑能让人查到怀疑人生。结尾最后聊点个人实战体会。达梦这套东西只要理解了“用户-模式-对象”的层级关系再用Navicat做可视化入口绝大多数工作是能顺手推进的。我第一次用Navicat连达梦时也遇到过-2501、模式不对这些问题但当你把错误当成信息去读——它告诉你是用户、密码、模式哪个环节出问题了——排错速度会快很多。另外一个实用建议在项目初期就建立数据字典查询模板并且把COMMENT写规范。等到做测试数据核对、系统上线评审的时候你会感谢当时的自己。后面我还会继续分享达梦与DBeaver、JDBC驱动版本、数据字典自动化生成工具链等内容欢迎持续关注。
