做达梦数据库运维和开发的朋友十有八九都碰到过这么一个问题拿到一个达梦实例的连接串登录进去之后想第一时间摸清楚“当前数据库下到底有哪些模式Schema”。尤其是从 MySQL 或 Oracle 迁移过来的团队对达梦“用户即模式”的这套玩法不熟常常把模式查错成表空间或者满世界找“数据库列表”找不到。我去年接手过一套达梦库的运维交接光是核对模式归属就折腾了大半天后来我把常见的模式查询 SQL 整理成了一个脚本从此再也没为这事发过愁。这篇文章就把这套东西完整分享出来。你不需要有任何达梦基础跟着一步步来就行先搞懂模式在达梦里的准确定义再看四条能查出模式清单的 SQL 写法和适用场景然后我会用真实登录环境演示一遍完整执行过程最后把权限报错、大小写坑、客户端工具看不到模式这些高频问题一次性讲透。看完你至少能在五分钟内回答出“当前实例下有哪些模式、每个模式里有什么对象、我有没有权限看到它们”。1. 模式在达梦里到底是个什么概念1.1 用户和模式一枚硬币的两面很多从 MySQL 转过来的同学第一反应是“模式是不是等于库”这个类比在达梦里不完全成立。达梦的架构里一个实例才是完整的数据库服务实例下面直接挂模式Schema没有 MySQL 那种“数据库”的中间层级。你可以把达梦的实例理解成一栋办公楼模式就是楼里的一个个办公室办公室里摆了各种东西——表、视图、存储过程、索引全都是对象。达梦里模式最特别的地方在于它和用户是强绑定关系。你用CREATE USER创建一个用户时达梦会自动创建一个和用户名同名的模式反过来你用CREATE SCHEMA显式建模式时也必须指定一个归属用户。这意味着查清楚了系统里有哪些用户基本就等于查清楚了有哪些模式二者是一枚硬币的两面。这一点和 Oracle 非常像所以很多 Oracle 的查询习惯在达梦上能直接沿用。但也别照搬得太开心达梦有自己的一些胆识和细节比如初始化参数里配置了用户和模式的关联方式之后行为会有变化后面我会单独说。1.2 默认的同名绑定与特殊情况达梦默认情况下用户和模式一一对应、名称完全一致。你创建APP_USER用户它就自带APP_USER模式你连上数据库之后默认的当前模式就是你登录账号对应的那个模式。但有两类特殊情况必须注意。第一种是显式创建模式并指定归属。你可以执行CREATE SCHEMA TEST_SCHEMA AUTHORIZATION APP_USER;这样就会在APP_USER名下多出一个叫TEST_SCHEMA的模式。此时用户和模式不再是一对一一个用户下可以挂多个模式查询模式清单时如果只盯着用户列表看就会漏掉这种额外模式。第二种是达梦的兼容模式设置。达梦支持 Oracle 兼容、MySQL 兼容、SQL Server 兼容等不同兼容性某些初始化参数会影响系统视图的返回内容比如在 MySQL 兼容模式下“模式”这个概念会更贴近“数据库”的体感。但好消息是无论兼容模式怎么切ALL_USERS、ALL_OBJECTS这类标准视图都能正常查询模式清单的获取思路不受影响。1.3 盘点模式清单的真实业务场景为什么要费劲去查模式清单我列举几个自己在工作中真实遇到的场景。接手环境时做资产盘点。公司让你维护一套新接手的达梦系统你连上去的第一件事肯定不是看 SQL 跑得慢不慢而是先搞清楚这库里到底有哪些业务模式、每个模式有什么表、一共有多少数据量。没有这份清单后面所有排查都像闭眼摸象。数据迁移或同步前检查目标端。从 Oracle 导数据到达梦、或者达梦之间做数据同步模式是否齐全、目标模式是否存在决定了迁移脚本能不能一次性跑通。我见过不止一次因为目标端少建了一个模式导致整批数据装载失败。排查“表找不到”的归属争议。业务方报错说表不存在但表明明就在库里。这种十有八九是表建在了别的模式下面应用账号访问不到。这时候一条模式清单 SQL比翻半天应用配置快得多。权限审计。有些模式是历史遗留创建用户的人早就离职了但你得靠模式清单去发现这些“僵尸账号”然后决定要不要锁定或删除。2. 四条查模式的 SQL按场景挑着用2.1 查 ALL_USERS / DBA_USERS最直接的字典视图法达梦兼容 Oracle 的字典视图所以最常规的写法是查用户。代码很简单-- 查看当前用户可见的用户列表含系统内置用户 SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME;普通用户执行这条语句看到的基本是系统内置账号和自己如果业务上给其他用户授过某些权限可能会多看到几个。想要更完整的字段比如账户状态、默认表空间可以查DBA_USERS但前提是你需要有足够的系统权限-- 需要 DBA 或相应系统权限 SELECT USERNAME, ACCOUNT_STATUS, DEFAULT_TABLESPACE, CREATED FROM DBA_USERS ORDER BY USERNAME;为什么先推查用户因为达梦的默认机制就是用户模式同名ALL_USERS的返回结果能直接当作模式清单用。拿到结果后把SYS、SYSDBA、SYSSSO、SYSAUDITOR这类系统内置账号从清单里剔除剩下的基本就是业务模式。这套方法是四类里最直观、最不容易出错的也是我最推荐新手首先尝试的。2.2 查 ALL_OBJECTS / DBA_OBJECTS按对象归属反推第二种思路不是查用户而是从“对象归属于哪个模式”这个维度去反推。因为模式存在的意义就是承载对象只要把全库所有对象的OWNER字段去重拿到的就是一份“实际有对象的模式清单”-- 普通用户查自己可见的对象 SELECT DISTINCT OWNER FROM ALL_OBJECTS WHERE OWNER NOT IN (SYS, SYSDBA) ORDER BY OWNER; -- DBA 视角查全库对象 SELECT DISTINCT OWNER FROM DBA_OBJECTS WHERE OWNER NOT IN (SYS, SYSDBA) ORDER BY OWNER;这里用到了 SQL 里常见的DISTINCT去重作用就是让同一个模式只出现一次。相对于直接查用户这个方法有一个明显优势它反映的是“真实存在对象”的模式那些建了用户但一张表都没建的空模式不会出现在结果里。对想做数据盘点的朋友来说这反而更贴合业务实际。还可以再进一步统计每个模式下各类型对象的数量SELECT OWNER, OBJECT_TYPE, COUNT(*) FROM DBA_OBJECTS WHERE OWNER NOT IN (SYS, SYSDBA) GROUP BY OWNER, OBJECT_TYPE ORDER BY OWNER, OBJECT_TYPE;这段执行完哪个模式下有几张表、几个视图、几条存储过程一目了然。我给客户做数据库巡检时这条 SQL 是必跑的比单纯查模式清单信息量大得多。2.3 翻 SYSOBJECTS 系统表底层玩法如果你习惯和系统表打交道达梦的核心系统表是SYSOBJECTS里面记录了所有对象的元数据包括模式、表、视图、索引等。直接查它也能拿到模式清单SELECT NAME, ID, PID, TYPE$, CRTDATE FROM SYSOBJECTS WHERE TYPE$ SCH ORDER BY NAME;TYPE$字段表示对象类型常见取值包括SCH模式、TAB表、VEW视图、IDX索引、TRG触发器、PRO存储过程、PKG包等。这是达梦内部最底层的数据字典查询它对权限的要求相对较低有些情况下普通账号也能看到不少元数据信息。不过我要提醒一句系统表的字段含义和版本相关比如TYPE$的取值在不同 DM 版本上可能有细微差异生产环境用之前最好先在你当前的版本上验证一下。日常巡检我个人更推荐先把 2.1 和 2.2 的字典视图方案跑通系统表方案作为补充和交叉验证。2.4 只看当前会话模式最快但范围最小有时候你不需要全库清单只想知道“我现在连的是哪个模式”一条语句就够-- Oracle 兼容写法 SELECT USER FROM DUAL; -- 达梦单独执行也能出结果 SELECT USER; -- 部分版本还支持查看当前 schema SELECT CURRENT_SCHEMA FROM DUAL;需要特别说明的是CURRENT_SCHEMA返回的是当前会话生效的 schema它可能受SET SCHEMA操作影响不一定等于你登录时用的用户名。比如你用SYSDBA登录后执行了SET SCHEMA APP_USER再查CURRENT_SCHEMA得到的可能就不是 SYSDBA。这点排查问题时要留个心眼。2.5 四种方法怎么选方法权限要求优点缺点适用场景ALL_USERS / DBA_USERS全量查询需要较高权限直接简单、字段丰富空模式也会显示日常盘点、权限审计ALL_OBJECTS / DBA_OBJECTS普通用户和 DBA 结果不同贴合实际对象归属查不到空模式对象盘点、迁移前检查SYSOBJECTS 系统表相对较低底层稳定字段含义需查版本文档交叉验证、特殊排查SELECT USER无秒出结果只覆盖当前会话确认当前身份这四种方法不是互斥的实际工作中我经常组合使用先用 ALL_USERS 拿到全量用户列表再用 DBA_OBJECTS 统计对象分布最后用 SYSOBJECTS 交叉验证一下基本就不会出错了。3. 实操全过程从连接到出结果3.1 连接达梦的几种方式达梦的客户端工具有好几套我常用的是这三种。第一种是 disql 命令行。达梦自带的命令行客户端和 Oracle 的 sqlplus 一个定位适合脚本化和快速执行。在 Linux 上安装好达梦后通常可以通过source环境变量文件或者手动设置DM_HOME来使用它export DM_HOME/opt/dmdbms export PATH$DM_HOME/bin:$PATH # 登录示例注意 -p 参数和密码之间不要留空格 disql SYSDBA/\123456\localhost:5236如果数据库跑在 Windows 上disql 一般位于安装目录的bin目录下用法和 Linux 一致。连接端口默认是 5236如果初始化实例时改过端口这里要跟着改。第二种是达梦图形化管理工具。Windows 上一般叫“达梦数据库管理工具”Linux 桌面环境也有对应版本。图形工具适合鼠标点点点能直接查看模式树、对象列表排查问题时比命令行直观。第三种是 DBeaver 这类通用数据库客户端。很多公司统一用 DBeaver连接达梦时需要下载达梦官方 JDBC 驱动URL 只有以下格式jdbc:dm://主机IP:5236连接配置里填用户名和密码即可默认会把你登录的用户名当成当前 schema。如果你的应用是 Java 项目强烈建议先从 JDBC 层面把连接字符串测通再往下游走。3.2 完整执行与结果解读假设我已经用 SYSDBA 登录按顺序跑一遍查询。先查 ALL_USERSSQL SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME; LINEID USERNAME ---------- -------------------------- 1 SYSAUDITOR 2 SYSDBA 3 SYSSSO 4 SYS 5 APP_USER 6 TEST_USER达梦内置账号在不同版本里稍有区别但SYS、SYSDBA、SYSSSO、SYSAUDITOR基本是固定的。剔除这四个系统账号剩下的APP_USER、TEST_USER就是两个业务模式。再用对象归属反推一遍SQL SELECT DISTINCT OWNER FROM ALL_OBJECTS WHERE OWNER NOT IN (SYS,SYSDBA) ORDER BY OWNER; LINEID OWNER ---------- -------------------------- 1 APP_USER 2 TEST_USER两个结果对上了说明这个实例下一共有两个模式而且两个模式都至少有一个对象。如果 ALL_USERS 里有账号、ALL_OBJECTS 里没有它的任何对象那就是一个空模式后续如果应用连到空模式上提示找不到表这个问题就得单独处理了。最后看一眼自己当前在哪个模式SQL SELECT USER FROM DUAL; LINEID USER ---------- ----------------------------- 1 SYSDBA执行过程就这么简单但每一步的输出都要学会看。尤其是 LINEID 这个列达梦命令行输出的每行结果都会给一个序号刚开始可能会被它吓一跳其实它只是行号不影响数据本身。3.3 权限不够时的典型报错与处理普通用户直接查DBA_USERS大概率看到这样的结果SQL SELECT USERNAME FROM DBA_USERS; [-2680]:No enough system privilege for the operation错误码 -2680 表示没有足够的系统权限。解决思路有两条一是让管理员把 DBA 角色授予给你操作简单但权限偏大适合运维岗或临时排查GRANT DBA TO APP_USER;二是精细授权只授予查询特定视图的权限GRANT SELECT ON SYS.DBA_USERS TO APP_USER;生产环境我强烈建议走第二条路别随手丢 DBA 角色出去。DBA 角色能做的事太多一个不小心就可能造成隐患。如果你只是要盘点模式ALL_USERS通常已经够用了先试试它不行再考虑要权限。4. 常见问题排查与避坑心得4.1 为什么普通用户只能看到一部分模式这个问题被问过无数次。普通用户查ALL_USERS默认只会显示系统内置用户和与自己相关的用户别人创建的业务模式如果没有给你授予任何权限你是看不到的。这是达梦权限模型的一部分不是查询语句写错了。遇到这种情况别急着怀疑 SQL先确认自己用的是不是有足够权限的账号。如果只能用普通账号那就联系 DBA 要一个只读权限或者让 DBA 把查询结果导出给你。我遇到过有些刚入行的朋友拿着应用账号去执行全库盘点 SQL查不到东西就以为是环境问题来来回回折腾一整天最后发现是权限没给够。4.2 模式名大小写和引号的坑达梦默认会把不带引号的标识符转成大写存储所有CREATE TABLE test实际建的表名是TEST。同样的规则也适用于模式名。如果你用带引号的写法构建了一个混合大小写的模式CREATE SCHEMA TestSchema AUTHORIZATION APP_USER;那这个模式的名字就是TestSchema之后查表必须加引号SELECT * FROM TestSchema.T_USER;平时最容易踩坑的场景是别人建了一个带引号的模式你用大写去查怎么都查不到对象。遇到这种情况先跑一遍SELECT NAME FROM SYSOBJECTS WHERE TYPE$SCH看清楚准确的名字再决定后面怎么拼 SQL。达梦对大小写敏感的处理和 Oracle 一个路数习惯了就好。4.3 DBeaver/MyBatis-Plus 查不到模式怎么办DBeaver 连达梦时如果驱动配置不对或者左侧树没有刷新会出现“能连上但看不到任何模式/表”的情况。解决办法有三步第一使用达梦官方 JDBC 驱动驱动 jar 版本要和数据库版本兼容。常见的是DmJdbcDriver18.jar不同 DM 版本可能对应不同驱动别混用。第二连接成功后右键数据库连接选择“刷新”或者“重新连接”让客户端重新拉取元数据。第三检查连接设置里的 Schema 选择。DBeaver 里通常会让你选默认 schema选了错误的模式自然看不到别的模式下的表。如果是 MyBatis-Plus 或 Spring Boot 项目配置数据源时也要注意。达梦 JDBC URL 后面可以带 schema 参数但部分版本支持得不稳定最稳妥的做法是让连接用户本身就是目标模式用户因为达梦默认用户和模式同名这样框架层面就不需要额外指定 schema。要是代码里非要写 schema 前缀记得用对了大小写否则又是一顿好查。4.4 养成保留“模式地图”脚本的习惯最后分享一个我自己的实操习惯。我会在本地维护一个固定的达梦盘点脚本里面放三条核心 SQLALL_USERS 拿用户清单、DBA_OBJECTS 统计对象分布、SYSOBJECTS 交叉验证模式列表。每次接手新环境先跑一遍这个脚本把结果导出成 CSV 存档这就是这台实例的“模式地图”。有了这份地图后续再做数据迁移、权限审计、对象排查效率完全是两个量级。我见过太多人每次遇到问题都重新敲一遍查询临时看两眼又关掉下次遇到还是从头来。数据库运维这种事沉淀下来的脚本和文档才是真正值钱的东西。根据我个人经验达梦的模式查询并不复杂核心就是记住“用户模式同名”这个底层逻辑再掌握 ALL_USERS、ALL_OBJECTS 这两个字典视图的用法。真正花时间的永远不是 SQL 本身而是看懂结果、理解权限、避开大小写和兼容模式这些细节。把这篇文章里的四条语句复制到你的 GUI 工具或 disql 里跑一遍对照着检查输出你很快就能把这套流程变成自己的常规操作。
做达梦数据库运维和开发的朋友十有八九都碰到过这么一个问题拿到一个达梦实例的连接串登录进去之后想第一时间摸清楚“当前数据库下到底有哪些模式Schema”。尤其是从 MySQL 或 Oracle 迁移过来的团队对达梦“用户即模式”的这套玩法不熟常常把模式查错成表空间或者满世界找“数据库列表”找不到。我去年接手过一套达梦库的运维交接光是核对模式归属就折腾了大半天后来我把常见的模式查询 SQL 整理成了一个脚本从此再也没为这事发过愁。这篇文章就把这套东西完整分享出来。你不需要有任何达梦基础跟着一步步来就行先搞懂模式在达梦里的准确定义再看四条能查出模式清单的 SQL 写法和适用场景然后我会用真实登录环境演示一遍完整执行过程最后把权限报错、大小写坑、客户端工具看不到模式这些高频问题一次性讲透。看完你至少能在五分钟内回答出“当前实例下有哪些模式、每个模式里有什么对象、我有没有权限看到它们”。1. 模式在达梦里到底是个什么概念1.1 用户和模式一枚硬币的两面很多从 MySQL 转过来的同学第一反应是“模式是不是等于库”这个类比在达梦里不完全成立。达梦的架构里一个实例才是完整的数据库服务实例下面直接挂模式Schema没有 MySQL 那种“数据库”的中间层级。你可以把达梦的实例理解成一栋办公楼模式就是楼里的一个个办公室办公室里摆了各种东西——表、视图、存储过程、索引全都是对象。达梦里模式最特别的地方在于它和用户是强绑定关系。你用CREATE USER创建一个用户时达梦会自动创建一个和用户名同名的模式反过来你用CREATE SCHEMA显式建模式时也必须指定一个归属用户。这意味着查清楚了系统里有哪些用户基本就等于查清楚了有哪些模式二者是一枚硬币的两面。这一点和 Oracle 非常像所以很多 Oracle 的查询习惯在达梦上能直接沿用。但也别照搬得太开心达梦有自己的一些胆识和细节比如初始化参数里配置了用户和模式的关联方式之后行为会有变化后面我会单独说。1.2 默认的同名绑定与特殊情况达梦默认情况下用户和模式一一对应、名称完全一致。你创建APP_USER用户它就自带APP_USER模式你连上数据库之后默认的当前模式就是你登录账号对应的那个模式。但有两类特殊情况必须注意。第一种是显式创建模式并指定归属。你可以执行CREATE SCHEMA TEST_SCHEMA AUTHORIZATION APP_USER;这样就会在APP_USER名下多出一个叫TEST_SCHEMA的模式。此时用户和模式不再是一对一一个用户下可以挂多个模式查询模式清单时如果只盯着用户列表看就会漏掉这种额外模式。第二种是达梦的兼容模式设置。达梦支持 Oracle 兼容、MySQL 兼容、SQL Server 兼容等不同兼容性某些初始化参数会影响系统视图的返回内容比如在 MySQL 兼容模式下“模式”这个概念会更贴近“数据库”的体感。但好消息是无论兼容模式怎么切ALL_USERS、ALL_OBJECTS这类标准视图都能正常查询模式清单的获取思路不受影响。1.3 盘点模式清单的真实业务场景为什么要费劲去查模式清单我列举几个自己在工作中真实遇到的场景。接手环境时做资产盘点。公司让你维护一套新接手的达梦系统你连上去的第一件事肯定不是看 SQL 跑得慢不慢而是先搞清楚这库里到底有哪些业务模式、每个模式有什么表、一共有多少数据量。没有这份清单后面所有排查都像闭眼摸象。数据迁移或同步前检查目标端。从 Oracle 导数据到达梦、或者达梦之间做数据同步模式是否齐全、目标模式是否存在决定了迁移脚本能不能一次性跑通。我见过不止一次因为目标端少建了一个模式导致整批数据装载失败。排查“表找不到”的归属争议。业务方报错说表不存在但表明明就在库里。这种十有八九是表建在了别的模式下面应用账号访问不到。这时候一条模式清单 SQL比翻半天应用配置快得多。权限审计。有些模式是历史遗留创建用户的人早就离职了但你得靠模式清单去发现这些“僵尸账号”然后决定要不要锁定或删除。2. 四条查模式的 SQL按场景挑着用2.1 查 ALL_USERS / DBA_USERS最直接的字典视图法达梦兼容 Oracle 的字典视图所以最常规的写法是查用户。代码很简单-- 查看当前用户可见的用户列表含系统内置用户 SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME;普通用户执行这条语句看到的基本是系统内置账号和自己如果业务上给其他用户授过某些权限可能会多看到几个。想要更完整的字段比如账户状态、默认表空间可以查DBA_USERS但前提是你需要有足够的系统权限-- 需要 DBA 或相应系统权限 SELECT USERNAME, ACCOUNT_STATUS, DEFAULT_TABLESPACE, CREATED FROM DBA_USERS ORDER BY USERNAME;为什么先推查用户因为达梦的默认机制就是用户模式同名ALL_USERS的返回结果能直接当作模式清单用。拿到结果后把SYS、SYSDBA、SYSSSO、SYSAUDITOR这类系统内置账号从清单里剔除剩下的基本就是业务模式。这套方法是四类里最直观、最不容易出错的也是我最推荐新手首先尝试的。2.2 查 ALL_OBJECTS / DBA_OBJECTS按对象归属反推第二种思路不是查用户而是从“对象归属于哪个模式”这个维度去反推。因为模式存在的意义就是承载对象只要把全库所有对象的OWNER字段去重拿到的就是一份“实际有对象的模式清单”-- 普通用户查自己可见的对象 SELECT DISTINCT OWNER FROM ALL_OBJECTS WHERE OWNER NOT IN (SYS, SYSDBA) ORDER BY OWNER; -- DBA 视角查全库对象 SELECT DISTINCT OWNER FROM DBA_OBJECTS WHERE OWNER NOT IN (SYS, SYSDBA) ORDER BY OWNER;这里用到了 SQL 里常见的DISTINCT去重作用就是让同一个模式只出现一次。相对于直接查用户这个方法有一个明显优势它反映的是“真实存在对象”的模式那些建了用户但一张表都没建的空模式不会出现在结果里。对想做数据盘点的朋友来说这反而更贴合业务实际。还可以再进一步统计每个模式下各类型对象的数量SELECT OWNER, OBJECT_TYPE, COUNT(*) FROM DBA_OBJECTS WHERE OWNER NOT IN (SYS, SYSDBA) GROUP BY OWNER, OBJECT_TYPE ORDER BY OWNER, OBJECT_TYPE;这段执行完哪个模式下有几张表、几个视图、几条存储过程一目了然。我给客户做数据库巡检时这条 SQL 是必跑的比单纯查模式清单信息量大得多。2.3 翻 SYSOBJECTS 系统表底层玩法如果你习惯和系统表打交道达梦的核心系统表是SYSOBJECTS里面记录了所有对象的元数据包括模式、表、视图、索引等。直接查它也能拿到模式清单SELECT NAME, ID, PID, TYPE$, CRTDATE FROM SYSOBJECTS WHERE TYPE$ SCH ORDER BY NAME;TYPE$字段表示对象类型常见取值包括SCH模式、TAB表、VEW视图、IDX索引、TRG触发器、PRO存储过程、PKG包等。这是达梦内部最底层的数据字典查询它对权限的要求相对较低有些情况下普通账号也能看到不少元数据信息。不过我要提醒一句系统表的字段含义和版本相关比如TYPE$的取值在不同 DM 版本上可能有细微差异生产环境用之前最好先在你当前的版本上验证一下。日常巡检我个人更推荐先把 2.1 和 2.2 的字典视图方案跑通系统表方案作为补充和交叉验证。2.4 只看当前会话模式最快但范围最小有时候你不需要全库清单只想知道“我现在连的是哪个模式”一条语句就够-- Oracle 兼容写法 SELECT USER FROM DUAL; -- 达梦单独执行也能出结果 SELECT USER; -- 部分版本还支持查看当前 schema SELECT CURRENT_SCHEMA FROM DUAL;需要特别说明的是CURRENT_SCHEMA返回的是当前会话生效的 schema它可能受SET SCHEMA操作影响不一定等于你登录时用的用户名。比如你用SYSDBA登录后执行了SET SCHEMA APP_USER再查CURRENT_SCHEMA得到的可能就不是 SYSDBA。这点排查问题时要留个心眼。2.5 四种方法怎么选方法权限要求优点缺点适用场景ALL_USERS / DBA_USERS全量查询需要较高权限直接简单、字段丰富空模式也会显示日常盘点、权限审计ALL_OBJECTS / DBA_OBJECTS普通用户和 DBA 结果不同贴合实际对象归属查不到空模式对象盘点、迁移前检查SYSOBJECTS 系统表相对较低底层稳定字段含义需查版本文档交叉验证、特殊排查SELECT USER无秒出结果只覆盖当前会话确认当前身份这四种方法不是互斥的实际工作中我经常组合使用先用 ALL_USERS 拿到全量用户列表再用 DBA_OBJECTS 统计对象分布最后用 SYSOBJECTS 交叉验证一下基本就不会出错了。3. 实操全过程从连接到出结果3.1 连接达梦的几种方式达梦的客户端工具有好几套我常用的是这三种。第一种是 disql 命令行。达梦自带的命令行客户端和 Oracle 的 sqlplus 一个定位适合脚本化和快速执行。在 Linux 上安装好达梦后通常可以通过source环境变量文件或者手动设置DM_HOME来使用它export DM_HOME/opt/dmdbms export PATH$DM_HOME/bin:$PATH # 登录示例注意 -p 参数和密码之间不要留空格 disql SYSDBA/\123456\localhost:5236如果数据库跑在 Windows 上disql 一般位于安装目录的bin目录下用法和 Linux 一致。连接端口默认是 5236如果初始化实例时改过端口这里要跟着改。第二种是达梦图形化管理工具。Windows 上一般叫“达梦数据库管理工具”Linux 桌面环境也有对应版本。图形工具适合鼠标点点点能直接查看模式树、对象列表排查问题时比命令行直观。第三种是 DBeaver 这类通用数据库客户端。很多公司统一用 DBeaver连接达梦时需要下载达梦官方 JDBC 驱动URL 只有以下格式jdbc:dm://主机IP:5236连接配置里填用户名和密码即可默认会把你登录的用户名当成当前 schema。如果你的应用是 Java 项目强烈建议先从 JDBC 层面把连接字符串测通再往下游走。3.2 完整执行与结果解读假设我已经用 SYSDBA 登录按顺序跑一遍查询。先查 ALL_USERSSQL SELECT USERNAME FROM ALL_USERS ORDER BY USERNAME; LINEID USERNAME ---------- -------------------------- 1 SYSAUDITOR 2 SYSDBA 3 SYSSSO 4 SYS 5 APP_USER 6 TEST_USER达梦内置账号在不同版本里稍有区别但SYS、SYSDBA、SYSSSO、SYSAUDITOR基本是固定的。剔除这四个系统账号剩下的APP_USER、TEST_USER就是两个业务模式。再用对象归属反推一遍SQL SELECT DISTINCT OWNER FROM ALL_OBJECTS WHERE OWNER NOT IN (SYS,SYSDBA) ORDER BY OWNER; LINEID OWNER ---------- -------------------------- 1 APP_USER 2 TEST_USER两个结果对上了说明这个实例下一共有两个模式而且两个模式都至少有一个对象。如果 ALL_USERS 里有账号、ALL_OBJECTS 里没有它的任何对象那就是一个空模式后续如果应用连到空模式上提示找不到表这个问题就得单独处理了。最后看一眼自己当前在哪个模式SQL SELECT USER FROM DUAL; LINEID USER ---------- ----------------------------- 1 SYSDBA执行过程就这么简单但每一步的输出都要学会看。尤其是 LINEID 这个列达梦命令行输出的每行结果都会给一个序号刚开始可能会被它吓一跳其实它只是行号不影响数据本身。3.3 权限不够时的典型报错与处理普通用户直接查DBA_USERS大概率看到这样的结果SQL SELECT USERNAME FROM DBA_USERS; [-2680]:No enough system privilege for the operation错误码 -2680 表示没有足够的系统权限。解决思路有两条一是让管理员把 DBA 角色授予给你操作简单但权限偏大适合运维岗或临时排查GRANT DBA TO APP_USER;二是精细授权只授予查询特定视图的权限GRANT SELECT ON SYS.DBA_USERS TO APP_USER;生产环境我强烈建议走第二条路别随手丢 DBA 角色出去。DBA 角色能做的事太多一个不小心就可能造成隐患。如果你只是要盘点模式ALL_USERS通常已经够用了先试试它不行再考虑要权限。4. 常见问题排查与避坑心得4.1 为什么普通用户只能看到一部分模式这个问题被问过无数次。普通用户查ALL_USERS默认只会显示系统内置用户和与自己相关的用户别人创建的业务模式如果没有给你授予任何权限你是看不到的。这是达梦权限模型的一部分不是查询语句写错了。遇到这种情况别急着怀疑 SQL先确认自己用的是不是有足够权限的账号。如果只能用普通账号那就联系 DBA 要一个只读权限或者让 DBA 把查询结果导出给你。我遇到过有些刚入行的朋友拿着应用账号去执行全库盘点 SQL查不到东西就以为是环境问题来来回回折腾一整天最后发现是权限没给够。4.2 模式名大小写和引号的坑达梦默认会把不带引号的标识符转成大写存储所有CREATE TABLE test实际建的表名是TEST。同样的规则也适用于模式名。如果你用带引号的写法构建了一个混合大小写的模式CREATE SCHEMA TestSchema AUTHORIZATION APP_USER;那这个模式的名字就是TestSchema之后查表必须加引号SELECT * FROM TestSchema.T_USER;平时最容易踩坑的场景是别人建了一个带引号的模式你用大写去查怎么都查不到对象。遇到这种情况先跑一遍SELECT NAME FROM SYSOBJECTS WHERE TYPE$SCH看清楚准确的名字再决定后面怎么拼 SQL。达梦对大小写敏感的处理和 Oracle 一个路数习惯了就好。4.3 DBeaver/MyBatis-Plus 查不到模式怎么办DBeaver 连达梦时如果驱动配置不对或者左侧树没有刷新会出现“能连上但看不到任何模式/表”的情况。解决办法有三步第一使用达梦官方 JDBC 驱动驱动 jar 版本要和数据库版本兼容。常见的是DmJdbcDriver18.jar不同 DM 版本可能对应不同驱动别混用。第二连接成功后右键数据库连接选择“刷新”或者“重新连接”让客户端重新拉取元数据。第三检查连接设置里的 Schema 选择。DBeaver 里通常会让你选默认 schema选了错误的模式自然看不到别的模式下的表。如果是 MyBatis-Plus 或 Spring Boot 项目配置数据源时也要注意。达梦 JDBC URL 后面可以带 schema 参数但部分版本支持得不稳定最稳妥的做法是让连接用户本身就是目标模式用户因为达梦默认用户和模式同名这样框架层面就不需要额外指定 schema。要是代码里非要写 schema 前缀记得用对了大小写否则又是一顿好查。4.4 养成保留“模式地图”脚本的习惯最后分享一个我自己的实操习惯。我会在本地维护一个固定的达梦盘点脚本里面放三条核心 SQLALL_USERS 拿用户清单、DBA_OBJECTS 统计对象分布、SYSOBJECTS 交叉验证模式列表。每次接手新环境先跑一遍这个脚本把结果导出成 CSV 存档这就是这台实例的“模式地图”。有了这份地图后续再做数据迁移、权限审计、对象排查效率完全是两个量级。我见过太多人每次遇到问题都重新敲一遍查询临时看两眼又关掉下次遇到还是从头来。数据库运维这种事沉淀下来的脚本和文档才是真正值钱的东西。根据我个人经验达梦的模式查询并不复杂核心就是记住“用户模式同名”这个底层逻辑再掌握 ALL_USERS、ALL_OBJECTS 这两个字典视图的用法。真正花时间的永远不是 SQL 本身而是看懂结果、理解权限、避开大小写和兼容模式这些细节。把这篇文章里的四条语句复制到你的 GUI 工具或 disql 里跑一遍对照着检查输出你很快就能把这套流程变成自己的常规操作。
