接手达梦数据库项目的朋友十有八九都会撞上同一个头疼问题业务账号建好了数据也有可登录进去就是查不到表、看不到数据一查发现所有对象都堆在别的模式下面甚至全部跑到了SYSDBA名下。标题里说的“达梦数据库调整非默认模式所属数据库用户”就是解决这类归属错配问题的实操核心。所谓非默认模式是指那些不是用户同名自动创建、而是通过CREATE SCHEMA或第三方工具额外冒出来的模式调整归属本质上就是把模式的所有者从当前用户改到真正该管它的数据库用户身上。这篇文章我会把模式与用户的关系、查询归属的方法、调整归属的三条路径和权限配套以及我踩过的坑一次性讲透适合刚上手达梦的运维、开发还有正在做项目移交的人参考。1. 达梦中模式与用户的关系搞清了才能动手1.1 模式不是用户用户也不等于模式很多新手会搞混模式SCHEMA和用户USER这在达梦里尤其容易出问题。拿现实生活类比数据库用户相当于一张门禁卡门禁卡决定了你能进哪栋楼、能刷开哪些门模式则相当于楼里的房间房间里放着表、视图、函数、存储过程这些实际的数据对象。一个用户可以持有多个房间的钥匙但每个房间必须有一个明确的产权人也就是Owner。达梦在语法上兼容了Oracle的部分习惯建用户时有很强的“自动绑定”特性执行CREATE USER创建用户时系统会顺手创建一个和用户名同名的模式这个模式就是该用户的默认模式。比如我建一个APP_USER用户数据库自动就有一个APP_USER模式存在之后APP_USER连接数据库默认工作空间就是APP_USER模式不加前缀直接写表名系统会优先在这个模式里找对应表。但注意默认模式只是用户默认使用的模式不代表该用户只有这一个模式。达梦允许一个数据库用户拥有多个模式也允许多个用户按权限访问同一个模式。所以实际生产环境里经常出现这样的情况模式名叫UAT_TESTOwner却不是名为UAT_TEST的用户或者模式Owner是SYSDBA但业务对象需要归给应用账号APP_UAT。这种“模式归属”和“业务期望”不一致的状态就是标题说的非默认模式所有权问题。1.2 非默认模式到底是怎么冒出来的非默认模式听起来神秘其实就是不按“同名自动创建”来的模式。我在项目里见过的产生途径主要有三种。第一种是有人显式执行了CREATE SCHEMA语句。达梦里可以单独创建模式比如CREATE SCHEMA V1 AUTHORIZATION APP_USER这种模式就没有跟用户名天然绑定Owner是谁完全看语句里怎么写。如果写成了CREATE SCHEMA V1没指定AUTHORIZATION那就按当前会话用户作为Owner很多时候执行者是DBA或者SYSDBAOwner就变成了DBA/SYSDBA后面业务用户想用V1模式里的表就发现权限和归属一团乱。第二种是数据迁移工具和导入导出带来的。从Oracle、MySQL或者其他环境往达梦导数据时工具往往直接把原始库的Schema名原样带过来。比如Oracle里有个模式REPORT迁移到达梦后也创建了REPORT模式但这个REPORT模式和达梦里的哪个用户对齐工具通常不会自动判断经常是导完以后Owner指向SYSDBA或者指向导入时使用的账号。这其实就是“非默认模式所属数据库用户”问题最典型的来源。第三种属于运维习惯问题也是我最常被问到的开发人员图省事一直用SYSDBA账号连接数据库建表建视图结果所有对象都落在SYSDBA模式里。业务账号登录后默认模式是它自己的同名模式当然查不到数据。等要交维、要上线的时候才发现对象归属不对必须在不动数据的情况下把模式和对象重新归位。1.3 归属不一致会导致哪些现实问题模式Owner不对看起来只是一个元数据字段的事但实际影响范围相当大。首先是权限管理失效。达梦的对象权限SELECT、INSERT、UPDATE、DELETE等都是基于“某个模式下的某个对象”来授权的。对象在SYSDBA模式下业务用户就算有RESOURCE角色也未必能访问。更麻烦的是有些运维平台、监控工具、报表系统会按Owner去扫描模式资源Owner不对扫描出来的数据全乱。其次是备份恢复容易出偏差。用达梦的备份工具做逻辑备份时通常会按模式或用户来选择导出对象。如果模式和用户的匹配关系混乱导出的脚本里对象归属就会错位恢复到一个新环境时表和数据的归属跟你预期的完全不一样需要手工再改一遍。再一个是应用连接配置的问题。Java应用通过JDBC连达梦DataSource里一般会配用户名对象在哪个模式应用访问时要么写模式名前缀要么在会话里SET SCHEMA切换。如果模式Owner跟应用用户对不上应用起来以后各种“表或视图不存在”的报错就来了排查半天最后发现不是SQL写错是模式归属错了。所以调整非默认模式的所有者不单是为了“看着顺眼”而是为了权限可管、备份可恢复、应用可运行。2. 调整前先摸底把模式的Owner和对象分布查清楚2.1 查询全库模式及其Owner调整之前最重要的一步是把当前所有模式的所有者关系查清楚千万不要凭印象直接跑ALTER SCHEMA。达梦的系统表里模式和用户都注册在SYSOBJECTS中模式记录通过PID指向用户记录。我用下面这条SQL查过很多次能列出所有模式和对应的Owner名SELECT B.NAME AS SCHEMA_NAME, A.NAME AS OWNER_NAME, B.ID AS SCHEMA_ID FROM SYSOBJECTS A, SYSOBJECTS B WHERE A.SUBTYPE$ USER AND B.SUBTYPE$ SCH AND A.ID B.PID ORDER BY B.NAME;这段SQL可以这么理解从SYSOBJECTS里取所有用户记录再取所有模式记录然后靠PID把模式挂到它的Owner用户上。需要说明的是不同达梦版本的系统视图字段名略有差异有些版本里SUBTYPE$取值大小写有区别如果执行报错可以先查一下当前版本的字典描述再微调。如果不想写系统表SQL达梦也提供了更友好的视图。用DBA账号登录后可以查询ALL_USERS和DBA_USERS来确认用户列表而模式的Owner关系用上面这条SQL通常最直接。查询结果里重点关注哪些模式的Owner不是你预期用户的把这些模式名记录下来列一张待调整清单。2.2 统计每个模式下有多少对象只查模式和Owner还不够还要知道待调整模式下到底有多少表、视图、存储过程、函数、序列。这能直接决定你用哪种方式调整。如果模式里只有几十个对象直接改Owner或者手动迁移都能接受如果模式里有几千张表那必须做好批量处理和影响评估。可以使用ALL_OBJECTS视图统计各模式对象数量SELECT OWNER, OBJECT_TYPE, COUNT(*) FROM ALL_OBJECTS WHERE OWNER IN (UAT_TEST, V1, REPORT) GROUP BY OWNER, OBJECT_TYPE ORDER BY OWNER, OBJECT_TYPE;同时建议把模式下所有表的清单导出来备份一份方便后面核对。我习惯把查询结果直接导出成Excel或CSV作为调整前的基线数据。后面无论操作成功还是出问题需要回滚都能拿这份清单对比。2.3 依赖对象和跨模式引用要提前评估这是很多人容易忽略的一步。模式归属调整不是把Owner字段改一下就完事模式里的视图、存储过程、函数、同义词、触发器都可能引用了其他模式的对象反过来其他模式的对象也可能引用了待调整模式里的表。一旦Owner变了部分对象的解析路径会受影响轻则权限报错重则编译失效。我建议调整前必须查两类依赖第一类是待调整模式里对象引用了谁。比如UAT_TEST模式里有个视图SELECT语句里写的是SYSDBA.T_ORDER那改完Owner后这个视图如果还想访问SYSDBA.T_ORDER就需要新Owner对SYSDBA.T_ORDER有相应权限。查询这类依赖可以去查DBA_DEPENDENCIES视图达梦对常用Oracle查询兼容得不错。第二类是谁引用了待调整模式里的对象。比如另外一个模式APP_V2里有个存储过程内部调用UAT_TEST.P_GET_DATA或者别的用户建了公共同义词指向UAT_TEST下的表。调整所有制后需要确认新的Owner能正常访问这些对象以及引用方是否还需要额外授权。在这一步把依赖清单列出来后面操作就踏实了。3. 核心实操调整非默认模式所属数据库用户的前三种方式3.1 最直接的ALTER SCHEMA改Owner如果目标只是把某个模式的Owner改成另一个用户首选达梦提供的ALTER SCHEMA语句。语法很简洁ALTER SCHEMA UAT_TEST OWNER TO APP_UAT;执行这行SQL前要确认几个前置条件。第一执行账号要有修改模式的权限通常DBA或者SYSDBA可以直接做第二目标用户必须已经存在如果APP_UAT还没建要先补建用户第三最好在业务低峰期操作虽然ALTER SCHEMA本身很快但如果模式下面有大量对象或者有会话正在占用数据库需要处理元数据锁极端情况下可能阻塞较长时间。执行完毕后可以用最开始那条SYSOBJECTS查询验证一下看UAT_TEST的OWNER_NAME是否已经变成APP_UAT。实际上ALTER SCHEMA修改的不仅是模式Owner也会把模式下面所有对象的Owner概念在字典层面整体联动不需要逐表去改这也是它最省事的地方。3.2 当模式需要整体搬迁到用户默认模式下怎么办ALTER SCHEMA能解决Owner归属但解决不了对象所在的模式名和用户默认模式名不一致的问题。比如业务用户叫APP_UAT默认模式是APP_UAT但对象全部放在UAT_TEST模式下用户登录后还是得SET SCHEMA UAT_TEST才能看到表。如果希望用户登录后不切模式就直接能用本质上要把对象从UAT_TEST模式搬到APP_UAT模式。这类整体搬迁我建议用“新建目标模式对象复制/移动”的方式来做。大概思路是先在目标用户下确认同名模式存在然后用CTASCREATE TABLE AS SELECT把数据从旧模式复制到新模式再重建索引、触发器、视图和存储过程最后校验数据量确认无误后再删除旧模式下的表。需要注意CTAS不会自动带过来约束、索引、默认值这些元数据需要单独用脚本生成所以大批量搬迁时不要指望一步到位。如果数据量很大比如一张表几千万行CTAS会非常慢此时可以用达梦自带的逻辑导入导出工具比如dmfldr或者DM管理工具里的导出导入功能把数据按模式导出再导入到正确的用户模式下。过程中要注意字符集、表空间和大字段类型的兼容性建议先在测试环境跑通一遍再动生产库。3.3 用DM管理工具图形化调整适合不常写SQL的场景不是所有人都习惯命令行达梦自带的DM管理工具一般在安装目录的tool目录下Windows上叫Manager提供了图形化修改的方式。操作路径大致是用有权限的账号连接数据库在左侧对象树里展开“模式”找到目标模式右键选择“修改”或“属性”在弹出的界面里可以看到当前所有者和相关设置把所有者改成目标用户保存即可。图形化操作的优点是一目了然不容易写错对象名缺点是实际执行的底层SQL被工具封装了操作日志不如命令行直观而且如果有些版本工具的“修改模式”入口只允许改注释、默认表空间等属性不提供Owner变更选项那还是要回到ALTER SCHEMA。所以我的建议是图形化适合你正好开着工具、且版本支持的情况生产环境强烈的变更老老实实用SQL并保留执行记录出了问题好回溯。3.4 配套权限调整别只改Owner忘了授权模式调给新用户之后权限配套是必须做的第二步。新Owner只能管理这个模式本身以及该模式下对象的结构并不意味着业务用户可以随便读写。常见的做法是给用户授权限授权分两个层面。第一个层面是给用户授予通用角色。业务账号通常需要RESOURCE角色才有权限创建表、视图、存储过程等对象GRANT RESOURCE TO APP_UAT;第二个层面是对象级授权。如果只是让用户查询可以只授SELECT如果需要增删改就加上INSERT、UPDATE、DELETEGRANT SELECT, INSERT, UPDATE, DELETE ON UAT_TEST.T_ORDER TO APP_UAT;对象多的时候逐条手写授权不现实可以先用SQL生成授权剧本再执行。SELECT GRANT SELECT, INSERT, UPDATE, DELETE ON UAT_TEST. || TABLE_NAME || TO APP_UAT; FROM ALL_TABLES WHERE OWNER UAT_TEST;把查询结果复制出来执行即可。如果应用账号还需要执行存储过程或调用函数还要继续授EXECUTE权限别漏掉。4. 实战全程一次把UAT_TEST模式从SYSDBA名下调整到业务用户4.1 场景原貌表全在SYSDBA模式下业务用户一脸懵有一次做项目交付客户的环境里有一个模式UAT_TEST里面放了几十张UAT阶段的业务表但整个模式的Owner是SYSDBA业务账号APP_UAT登录后默认模式是它自己的APP_UAT什么都查不到。每次开发连数据库都得写全限定名SYSDBA.UAT_TEST甚至要先切换模式搞得团队怨声载道。客户的需求很明确把UAT_TEST这个非默认模式的归属改到APP_UAT名下以后APP_UAT登录就直接能用对象不用挪动位置。这个场景用ALTER SCHEMA最合适因为对象不需要跨模式搬迁只要把整个UAT_TEST模式的所有者从SYSDBA变成APP_UAT即可。4.2 分步执行记录第一步先确认APP_UAT用户存在。如果不存在先创建用户并且给默认表空间CREATE USER APP_UAT IDENTIFIED BY 此处填密码; GRANT RESOURCE TO APP_UAT;第二步用SYSDBA登录核对待调整模式下对象清单。这里我把UAT_TEST下的表导出来做了基线记录包含表名、行数、是否有自增列和主键等信息后面验证要用。第三步执行调整Owner的语句ALTER SCHEMA UAT_TEST OWNER TO APP_UAT;这条语句执行很快一般情况下秒级返回。执行期间我特意让一个会话任务停了一下避免元数据锁冲突。如果库里有长事务正在跑ALTER SCHEMA可能会等锁等多久取决于事务结束时间所以建议低峰期操作。第四步验证Owner变更结果。重新跑SYSOBJECTS关联查询看到UAT_TEST的OWNER_NAME已经变成APP_UAT心里就踏实了一半。第五步授权。我给APP_UAT用户额外执行了下面这类授权让它能读写UAT_TEST模式下现有的表GRANT SELECT, INSERT, UPDATE, DELETE ON UAT_TEST.T_ORDER TO APP_UAT;第六步让开发用APP_UAT账号重新连接执行一次简单的SELECT验证。4.3 验证结果和实际体验调整后APP_UAT用户登录执行SELECT USER FROM DUAL;返回是APP_UAT。然后在不写模式前缀的情况下直接查询SELECT COUNT(*) FROM T_ORDER;如果还是报“表或视图不存在”请检查当前会话默认模式是否真在UAT_TEST下面。达梦用户登录后的默认模式是“用户名同名模式”APP_UAT登录后默认是APP_UAT不是UAT_TEST。所以这里要给APP_UAT设置默认模式或者确认应用连接后是否会自动SET SCHEMA。最稳妥的方法是给用户执行ALTER USER APP_UAT SET DEFAULT SCHEMA UAT_TEST;注意达梦某些版本里修改用户默认模式的语法是ALTER USER ... SET SCHEMA ...还是需要直接修改用户的DEFAULT_SCHEMA不同版本有差异。如果版本不支持可以改在应用连接时执行SET SCHEMA UAT_TEST;Java连接池里一般也可以在初始化SQL中带上。这是这个场景里最容易忽视的一环我在这里吃过亏建议你验证时千万别漏掉。实际上调整完Owner以后APP_UAT如果直接从管理工具登录并选择UAT_TEST模式也能看到全部表。验证数据完整性方面我抽查了几张核心表的行数和变更前基线记录完全一致数据没有任何影响。整个过程大概10分钟其中大部分时间花在确认依赖和基线记录上真正的DDL执行几乎一瞬间。5. 常见报错与避坑实录5.1 ALTER SCHEMA执行失败权限不足或对象占用如果执行ALTER SCHEMA时提示权限不足基本可以确定当前账号不是DBA或者SYSDBA换有权限的账号执行。如果提示模式正在使用或对象占用通常是有会话正在访问该模式下的对象或者存在依赖于这个模式的锁。解决办法是先查一下活动会话看看能不能等待会话结束或者选择低峰期执行。不要频繁重试否则锁等待可能越积越深。如果是批量改动多个模式建议按模式逐个处理每次改完验证一遍不要一股脑把所有ALTER SCHEMA拼到一个脚本里跑。万一中间某个模式名写错后续定位问题会非常痛苦。5.2 改了Owner后视图和同义词全失效这类问题我在实际项目中碰到过不止一次。模式Owner变更以后原来基于旧Owner权限创建的视图可能失效因为视图内部引用的对象路径变了或者视图定义里的模式前缀解析权限失效。同义词也一样特别是私有同义词绑定关系不会自动跟随对象Owner变化。处理方式不复杂把失效的视图重新编译同义词重新创建或替换。达梦中重新编译视图可以使用ALTER VIEW 视图名 COMPILE;如果编译失败就查看具体报错一般是要给新Owner补查询权限。同义词方面建议优先使用公共同义词PUBLIC SYNONYM这样能减少模式和用户变更对应用的影响。5.3 序列、触发器等独立对象没有迁移模式和用户调整后最容易被忽略的就是序列和触发器。序列是独立于表存储的数据库对象它不属于哪个表只归属某个模式。如果业务表搬到了新模式而序列还留在旧模式应用新增数据时调NEXTVAL可能就会报序列不存在。触发器类似它的定义里可能引用了新模式的表结构但触发器本身还挂靠在旧模式下导致触发不生效或者编译失败。处理方案很直接迁移前把模式下的序列清单导出来归属调整后重新生成序列或者把序列本身移到新模式下如果达梦版本支持序列转移。触发器也建议先在测试环境把新旧模式对象都建好然后编译一遍确认没有错误再切换流量。5.4 验证阶段推荐多维度核对调整完成后至少从四个维度做一次完整验证别只看一条查询能过就收工表数量核对新旧模式下所有对象数量一致权限核对新Owner能否正常INSERT/UPDATE/DELETE依赖校验视图、存储过程、函数编译是否通过业务冒烟让应用实际跑通一条增删改查链路。我把这四个维度整理过一张速查表每次变更后按表逐项勾选基本没有漏过问题。验证维度检查方式常见失败原因对象数量对比调整前后ALL_OBJECTS统计重名对象被忽略迁移遗漏对象权限新用户执行增删改查只改了Owner忘了GRANT依赖编译查询DBA_DEPENDENCIES编译视图过程跨模式引用权限不足业务链路应用真实业务操作默认模式未设置连接串没切Schema收个尾说说我自己的操作习惯处理这类模式归属问题我现在的固定套路是先导出SYSOBJECTS基线再查依赖然后挑业务影响最小的窗口执行最后按四维表格验证。这套流程虽然看起来保守但从没出过差错。反倒是早期图省事跳过依赖检查结果改完Owner后半个应用接口报错被拉去加班排查从那以后彻底老实了。最后分享一个小技巧如果你手头环境里一下子有一堆模式归属要调整建议先只改一个模式完整走一遍验证流程确认这套方法在当前达梦版本下没问题再批量操作。模式归属这种事慢就是快。
