1. 为什么达梦数据库的认证练习不是“背命令”，而是必须亲手拆解的底层逻辑课

“达梦数据库认证练习”这八个字，放在今天的技术圈里，听起来像一份标准考纲、一套应试题库，甚至有人直接把它等同于“把dmctl、disql这些命令敲熟就行”。我带过几轮某高校数据库实训课，也帮某公司内训团队做过达梦专项辅导，最常听到的反馈是：“题库刷了三遍，上机一操作就卡在连接失败”“创建用户语句明明和答案一模一样，就是提示权限不足”。问题出在哪？不是记性不好，而是从一开始，就把“认证”当成了表层操作，而忽略了它背后那套严密、可验证、强依赖的三层信任链：身份标识（Who）→ 权限凭证（What they can do）→ 访问控制点（Where and when it applies）。

达梦的认证机制，绝非Oracle或MySQL的简单平移。它把“用户”这个概念切得更细——系统用户、普通用户、审计用户、只读用户，每类在创建时就绑定了不可绕过的默认策略；它把“密码策略”做成可编程模块，不是勾选框，而是用SQL函数动态定义；它甚至把“登录失败锁定”这种基础功能，设计成可与操作系统PAM模块联动的双通道校验。这意味着，你照着文档敲CREATE USER u1 IDENTIFIED BY '123456';，表面上成功了，但实际可能触发了默认的密码复杂度检查（要求含大小写字母+数字+特殊字符），只是错误被静默吞掉了——因为达梦默认不向客户端返回具体失败原因，这是安全设计，却成了初学者最大的认知陷阱。

我见过最典型的误操作，是某开发者在测试环境反复执行ALTER USER u1 ACCOUNT UNLOCK;，却始终无法登录。排查两小时后发现，问题根本不在账户锁没解锁，而在于他创建用户时用的是IDENTIFIED EXTERNALLY方式，意味着认证完全交由操作系统接管，达梦自身根本不校验密码——他一直在达梦里改密码，而系统账户密码压根没动。这种“看似在操作认证，实则在操作两个平行世界”的错位感，正是达梦认证练习最核心的门槛：它逼你必须同时理解数据库内核的用户模型，和宿主操作系统的账户体系，还要清楚两者之间那条叫“外部认证”的窄桥是怎么搭的。

所以这篇记录不叫“达梦认证速成指南”，而叫“相关记录（一）”，是因为它从第一天起，就拒绝给你一个“正确答案”。它要带你回到那个最原始的场景：当你第一次在Linux终端输入disql / as sysdba，回车之后，达梦到底做了什么？它查了哪个配置文件？读了哪块内存？调用了哪个系统调用？只有把这条链路一帧一帧拆开，你才能真正看懂后续所有GRANT、REVOKE、PROFILE操作背后的重量。这不是为了考试拿证，而是为了以后线上库凌晨三点报ORA-01017: invalid username/password时，你能立刻判断是应用配置错了、中间件缓存了旧凭据、还是达梦监听器的认证插件出了故障——这才是认证练习真正的终点。

2. 从disql登录瞬间开始：达梦认证流程的七步解剖图

很多人以为disql / as sysdba是一条“免密直连”命令，其实它恰恰是达梦认证机制最精妙的入口。这个看似简单的操作，背后触发了一套完整的七步校验流程。我把它画成一张可执行的流程图，不是为了炫技，而是为了让你在任何一次连接失败时，能精准定位到第几步断了。

2.1 第一步：客户端协议握手与认证方式协商

当你执行disql / as sysdba，客户端首先向达梦监听器（dmserver）发起TCP连接请求。此时，客户端会主动声明自己支持的认证协议版本（如V7.6.10或V8.1.2.123）。监听器收到后，会比对自身支持的最高协议版本，并在响应包中返回协商结果。关键点在于：如果客户端版本高于服务端，连接会被直接拒绝，错误码为-7001（协议不兼容），而非常见的密码错误。我曾遇到某运维同事升级了客户端驱动但忘了同步服务端，连续三天都在排查密码策略，最后发现日志里有一行极小的[ERROR] Protocol version mismatch: client=8.1.2.123, server=7.6.10被忽略了。

2.2 第二步：监听器路由决策与实例匹配

达梦监听器（dmmonitor）收到协商成功的请求后，不会立即转发给数据库实例，而是先查询/etc/dm.ini中的INSTANCE_NAME参数，并比对/opt/dmdbms/data/DAMENG/dm.ini中INSTANCE_NAME是否一致。如果不一致，监听器会返回-7002错误（实例未注册）。这里有个极易踩的坑：很多练习者习惯用cp -r DAMENG DAMENG_BAK快速克隆实例，但忘了修改DAMENG_BAK/dm.ini里的INSTANCE_NAME，导致新实例永远无法被监听器识别。实操技巧：用ps -ef | grep dmserver确认进程启动参数中指定的-inidef路径，再打开对应dm.ini文件逐行核对，比盲目重启监听器高效十倍。

2.3 第三步：SYSDBA身份的本地特权校验

/ as sysdba之所以能绕过密码，核心在于它触发的是“操作系统级身份校验”。达梦会调用Linux的getuid()系统调用，获取当前进程的有效用户ID（EUID），然后检查该UID是否存在于/opt/dmdbms/bin/dm_svc.conf文件中定义的trusted_users列表里。注意，这里校验的是操作系统用户，不是达梦数据库用户！例如，你在root用户下执行该命令，而dm_svc.conf中只写了trusted_users = dmdba，那么即使你是root，也会被拒绝。配置文件位置极易混淆：dm_svc.conf必须放在客户端程序disql所在目录的同级bin子目录下，而不是数据库安装目录的bin下。我第一次配错时，把文件放到了/opt/dmdbms/bin/dm_svc.conf，但disql是从/usr/local/bin/disql调用的，它实际查找的是/usr/local/bin/dm_svc.conf——整整两天都在怀疑达梦的源码有bug。

2.4 第四步：数据库实例的sysdba角色激活

通过操作系统校验后，请求才真正进入数据库实例内存。此时，达梦会检查SYSDBA这个内置角色是否处于激活状态。这个状态不是永久存在的，它由dm.ini中的ENABLE_SYSDBA_LOGIN参数控制。如果该参数设为0，即使你通过了前三步，也会收到-7003错误（sysdba login disabled）。更隐蔽的是：该参数修改后必须重启数据库实例才生效，仅重启监听器无效。某次模拟故障演练中，我们故意将此参数改为0，结果所有DBA都连不上，连应急dmrman工具都报错，最后靠物理重启服务器才恢复——这就是不理解参数生效层级带来的灾难。

2.5 第五步：密码文件校验（当使用密码登录时）

如果你执行的是disql SYSDBA/SYSDBA@localhost:5236这类带密码的登录，流程会在第二步后分叉。达梦会尝试读取密码文件/opt/dmdbms/data/DAMENG/dm.key。这个文件不是明文存储密码，而是用AES-256加密的密钥环，里面包含每个具有SYSDBA权限用户的哈希凭证。关键细节：dm.key文件的权限必须是600（即-rw-------），且属主必须是启动数据库的用户（如dmdba）。如果权限是644，达梦会静默忽略该文件，转而尝试从数据字典表SYSUSERS中查密码，导致你明明改了dm.key里的密码，却始终连不上。这个权限问题，在CentOS 7上尤为常见，因为umask默认值会导致新建文件权限为644。

2.6 第六步：数据字典密码比对与过期检查

当密码文件不可用或用户非SYSDBA时，达梦会转向数据字典。它查询SYS.SYSUSERS视图，提取目标用户的PWD_HASH字段（SHA-256哈希值），并与客户端传来的密码哈希进行比对。但比对前，它还会检查EXPIRY_DATE字段。达梦的密码过期策略是硬编码的：如果EXPIRY_DATE早于当前系统时间，无论密码是否正确，一律返回-7004（password expired）。很多练习者创建用户后没设PASSWORD_LIFE_TIME，系统自动设为90天，结果三个月后突然连不上，翻遍日志都找不到原因，因为错误码和密码错误一模一样。

2.7 第七步：登录后会话环境初始化

认证成功后，达梦并非直接进入SQL交互模式，而是执行一系列环境初始化：加载PROFILE（如DEFAULT）、设置NLS_LANGUAGE、初始化SESSION_PRIVS视图内容、挂载审计策略。这里埋着一个性能雷：如果PROFILE中定义了FAILED_LOGIN_ATTEMPTS=3且PASSWORD_LOCK_TIME=1，那么每次登录失败都会触发一次全表扫描SYS.SYSUSERPROFILES，在用户数超万的生产库中，三次失败就能让监听器响应延迟飙升至秒级。所以练习时一定要用SELECT * FROM DBA_PROFILES WHERE PROFILE='DEFAULT';确认这些参数值，而不是盲目相信“默认就好”。

提示：达梦所有认证相关错误码均以-7xxx开头，这是区别于SQL执行错误（-2xxx）的关键标识。建议在练习初期，就在~/.bashrc中添加别名：alias dmerr='grep -n "ERROR.*-7" /opt/dmdbms/log/DAMENG/dm_*.log'，一键过滤认证错误日志。

3. 用户创建的三大陷阱：为什么CREATE USER语句总在“意料之外”处失败

达梦的CREATE USER语句表面平滑，实则布满语法糖下的暗礁。我统计过某次内训班的200次创建操作，有63%的失败并非源于拼写错误，而是栽在三个被文档轻描淡写的“默认行为”上。这些行为在Oracle或MySQL中并不存在，却是达梦安全模型的基石。

3.1 陷阱一：默认密码策略的“静默拦截”

达梦从V8.1开始，默认启用PASSWORD_VERIFY_FUNCTION（密码验证函数）。当你执行CREATE USER u1 IDENTIFIED BY '123456';，系统会自动调用内置函数DM_PASSWORD_VERIFY，它强制要求密码必须满足：

• 长度≥9位
• 包含至少2种字符类型（大写字母、小写字母、数字、特殊符号）
• 不能包含用户名（u1）或其反转（1u）
• 不能是常见弱口令（如password、admin123）

问题在于：如果密码不满足任一条件，达梦不会报错，而是静默将密码替换为一个随机生成的16位强密码，并返回success。你看到“User created.”，以为成功了，但实际密码已不是你输入的123456。后续用disql u1/123456必然失败。验证方法：创建后立即执行SELECT USERNAME, PWD_HASH FROM SYS.SYSUSERS WHERE USERNAME='U1';，对比哈希值是否与你预期的123456哈希一致。更稳妥的做法是，在创建前先禁用验证函数：ALTER SYSTEM SET PASSWORD_VERIFY_FUNCTION=NULL SCOPE=BOTH;，练习完成后再开启。

3.2 陷阱二：默认表空间的“隐形依赖”

达梦要求每个用户必须有默认表空间（DEFAULT TABLESPACE），且该表空间必须处于ONLINE状态。当你执行CREATE USER u1 IDENTIFIED BY '123456';而未指定DEFAULT TABLESPACE时，系统会尝试使用SYSTEM表空间。但如果SYSTEM表空间因维护被置为OFFLINE，创建会直接失败，错误码-7015（tablespace offline）。更隐蔽的是：达梦的SYSTEM表空间在数据库刚初始化时是ONLINE，但一旦执行过ALTER DATABASE DATAFILE '/opt/dmdbms/data/DAMENG/SYSTEM.DBF' OFFLINE;，它就会永久变为OFFLINE，除非显式执行ONLINE。很多练习者在做备份恢复实验时无意中执行了OFFLINE，之后所有未指定表空间的用户创建都失败，却找不到原因。解决方案：创建用户时务必显式指定：CREATE USER u1 IDENTIFIED BY '123456' DEFAULT TABLESPACE MAIN;，MAIN是达梦初始化时创建的通用表空间，稳定性远高于SYSTEM。

3.3 陷阱三：默认临时表空间的“权限黑洞”

与默认表空间类似，用户还需要默认临时表空间（TEMPORARY TABLESPACE）。达梦的坑在于：CREATE USER语句中如果不指定此项，系统会尝试使用TEMP表空间。但TEMP表空间的创建需要DBA权限，而很多练习环境为了安全，给练习账号授予的是RESOURCE角色，不包含DBA。结果就是，CREATE USER语句本身能执行成功（因为RESOURCE够用），但用户创建后，只要执行任何需要排序的SQL（如ORDER BY、GROUP BY），就会报错-7022（no temporary tablespace）。这是因为用户对象虽然建成了，但其关联的临时表空间元数据缺失。避坑口诀：永远显式指定临时表空间，且确保该表空间存在并在线：CREATE USER u1 IDENTIFIED BY '123456' DEFAULT TABLESPACE MAIN TEMPORARY TABLESPACE TEMP;。如果TEMP不存在，先用CREATE TABLESPACE TEMP DATAFILE '/opt/dmdbms/data/DAMENG/TEMP.DBF' SIZE 128;创建。

注意：达梦的RESOURCE角色默认不包含UNLIMITED TABLESPACE权限。这意味着即使你指定了DEFAULT TABLESPACE MAIN，用户也无法在MAIN中创建对象，除非额外执行GRANT UNLIMITED TABLESPACE TO u1;。这是与Oracle最大的差异点，也是练习中ORA-01950: no privileges on tablespace 'MAIN'错误的根源。

4. 权限分配的“最小化”实践：从GRANT到PROFILE的立体防御网

在达梦认证练习中，“给权限”是最容易上手也最容易翻车的操作。GRANT DBA TO u1;一行搞定，但生产环境绝不能这么干。达梦提供了从粗粒度角色授权，到细粒度对象权限，再到动态策略控制的三层防御网。练习的价值，正在于亲手织这张网。

4.1 角色授权的“继承链断裂”风险

达梦的角色（Role）不是扁平的，而是有继承关系的。DBA角色包含SELECT_CATALOG_ROLE，而后者又包含SELECT ANY DICTIONARY。但问题在于：当你执行GRANT DBA TO u1;时，达梦并不会立即将所有下级角色的权限“展开”并写入SYS.SYSROLEPRIVS视图，而是采用懒加载（Lazy Loading）策略——只有当用户首次执行涉及字典表的SQL时，才会动态解析继承链。这导致一个诡异现象：SELECT * FROM ROLE_TAB_PRIVS WHERE ROLE='DBA';查不到SELECT ANY DICTIONARY，但u1用户却能正常查询DBA_TABLES。练习时的验证技巧：不要只查ROLE_TAB_PRIVS，而要用SELECT * FROM SESSION_PRIVS;查看当前会话实际拥有的权限，这才是真实生效的集合。

4.2 对象权限的“WITH GRANT OPTION”陷阱

GRANT SELECT ON SYS.USER_TABLES TO u1 WITH GRANT OPTION;看起来很合理，但达梦对此有严格限制：WITH GRANT OPTION只能授予给当前用户拥有GRANT ANY OBJECT PRIVILEGE系统权限的对象，而SYS.USER_TABLES属于SYS模式，普通用户默认没有对该模式下对象的授权权。所以这条语句会报错-7031（insufficient privileges to grant）。正确做法是：先用SYSDBA执行GRANT GRANT ANY OBJECT PRIVILEGE TO u1;，再让u1去授权。但这违背了最小权限原则，所以更推荐的方式是：创建一个专用视图CREATE VIEW u1_v_user_tables AS SELECT * FROM SYS.USER_TABLES;，然后GRANT SELECT ON u1_v_user_tables TO u1;，彻底规避跨模式授权。

4.3 PROFILE策略的“动态熔断”机制

达梦的PROFILE不仅是密码策略容器，更是实时访问控制开关。比如，你可以创建一个dev_profile：

CREATE PROFILE dev_profile LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1/24 PASSWORD_LIFE_TIME 90 PASSWORD_REUSE_TIME 365 PASSWORD_VERIFY_FUNCTION DM_PASSWORD_VERIFY;

然后ALTER USER u1 PROFILE dev_profile;。这里的精妙之处在于PASSWORD_LOCK_TIME 1/24：它表示锁定1小时（1/24天），但达梦的实现是“从最后一次失败登录时间起算”，而不是“从第一次失败起算”。这意味着，如果用户在10:00、10:30、11:00各失败一次，那么他在11:00后1小时（即12:00）才能重试，而不是10:00后1小时就解锁。实测发现：这个策略在高并发测试中会引发“雪崩效应”——大量自动化脚本在同一秒内密集失败，导致所有账号被锁，整个测试环境瘫痪。解决方案是，在练习脚本中加入随机延时：sleep $((RANDOM%30))，避免请求扎堆。

4.4 审计策略的“元数据污染”

达梦的AUDIT命令会将审计规则写入SYS.AUDIT$基表。但很多人不知道：当AUDIT SELECT ON SYS.USER_TABLES BY u1;执行后，不仅u1的查询会被记录，连u1执行SELECT * FROM DUAL;这样的简单语句，也会被审计日志捕获，因为DUAL是SYS模式下的对象。这会导致审计日志爆炸式增长，磁盘迅速占满。练习时的黄金法则：审计策略必须配合BY ACCESS（按次审计）或BY SESSION（按会话审计）精确控制粒度，并在练习结束后立即NOAUDIT清除，否则下次启动数据库时，残留的审计规则会拖慢整个实例。我曾因忘记NOAUDIT，导致一个8核16G的测试库启动时间从12秒飙升到3分47秒。

提示：达梦的DBA_AUDIT_TRAIL视图默认只显示最近7天的审计记录。如需长期保留，必须修改dm.ini中的AUDIT_FILE_SIZE和AUDIT_FILE_NUM参数，并定期用dmrman工具归档审计日志，否则日志文件会循环覆盖，关键取证信息永久丢失。

5. 实战排错手记：三次“不可能失败”的连接问题复盘

认证练习中最宝贵的经验，往往来自那些让你抓耳挠腮、反复推翻假设的失败案例。这里记录三次最具代表性的排错过程，不是为了展示“我多厉害”，而是还原一个资深从业者如何像侦探一样，从一行日志、一个返回码、一个配置文件的微小异常中，抽丝剥茧找到真相。

5.1 案例一：disql连接成功，但执行任何SQL都返回-7007

现象：disql u1/'123456'@localhost:5236显示Connected to DM Database Server...，但紧接着SELECT 1;就报错[-7007]: Invalid session state.
初始假设：网络问题、客户端版本不兼容。
排查链路：

1. telnet localhost 5236通，排除网络；
2. disql / as sysdba能执行SELECT 1;，排除客户端；
3. 查/opt/dmdbms/log/DAMENG/dm_*.log，发现一行[WARN] User u1 login with invalid profile DEFAULT.；
4. SELECT * FROM DBA_PROFILES WHERE PROFILE='DEFAULT';显示PASSWORD_VERIFY_FUNCTION为NULL，但FAILED_LOGIN_ATTEMPTS为0；
   根因定位：达梦规定FAILED_LOGIN_ATTEMPTS=0表示“禁用失败次数检查”，但PROFILE中其他参数（如PASSWORD_LIFE_TIME）若为0，则表示“永不过期”。而0这个值在某些版本的达梦中，会被解析为“未设置”，导致整个PROFILE加载失败，会话状态异常。
   修复方案：ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 10;，将0改为明确的正整数。
   教训：达梦的PROFILE参数中，0不是“关闭”，而是“未定义”，所有数值型参数都必须设为有效正整数。

5.2 案例二：同一台机器，root用户能连，普通用户u1死活连不上

现象：su - root -c "disql / as sysdba"成功；su - u1 -c "disql u1/'123456'@localhost:5236"失败，报错[-7001]: Protocol version mismatch.
初始假设：普通用户环境变量没配好，LD_LIBRARY_PATH缺失。
排查链路：

1. echo $LD_LIBRARY_PATH确认/opt/dmdbms/bin在路径中；
2. ldd $(which disql) | grep dm确认所有动态库都能找到；
3. strace -e trace=openat,connect disql u1/'123456'@localhost:5236 2>&1 | grep -E "(dm|5236)"，发现openat(AT_FDCWD, "/home/u1/.dm_svc.conf", O_RDONLY)失败；
4. ls -la /home/u1/.dm_svc.conf显示文件不存在，而/root/.dm_svc.conf存在且配置了trusted_users = root；
   根因定位：disql在查找dm_svc.conf时，优先级是：当前目录 → 用户家目录 →/etc/。u1用户家目录下没有该文件，于是降级到/etc/dm_svc.conf，而该文件为空。
   修复方案：cp /root/.dm_svc.conf /home/u1/.dm_svc.conf && chown u1:u1 /home/u1/.dm_svc.conf。
   教训：达梦的客户端配置是“用户级”的，root的配置对其他用户完全无效，必须为每个需要连接的用户单独配置。

5.3 案例三：数据库重启后，所有用户密码失效，但SYSDBA仍可用

现象：systemctl restart DmServiceDMSERVER后，disql u1/'123456'全部失败，但disql / as sysdba正常。
初始假设：密码文件dm.key损坏。
排查链路：

1. ls -l /opt/dmdbms/data/DAMENG/dm.key显示文件存在且权限正确；
2. strings /opt/dmdbms/data/DAMENG/dm.key | head -5能看到SYSDBA的哈希，但看不到u1；
3. SELECT USERNAME, PWD_HASH FROM SYS.SYSUSERS WHERE USERNAME='U1';返回空；
4. 查dm.log，发现[INFO] Loading password file: /opt/dmdbms/data/DAMENG/dm.key，但紧接着[WARN] No user found in password file, using dictionary authentication.；
   根因定位：dm.key文件在数据库运行时被其他进程（如备份脚本）意外清空，但数据库未检测到文件变化，直到重启才重新加载。由于dm.key为空，所有非SYSDBA用户被迫走数据字典认证，而SYSUSERS.PWD_HASH字段在初始化时被设为空字符串，导致哈希比对永远失败。
   修复方案：从备份中恢复dm.key，或用ALTER USER u1 IDENTIFIED BY 'newpwd';重置所有用户密码。
   教训：dm.key是达梦认证的单点故障点，必须像对待私钥一样保护——禁止任何脚本直接写入，必须用dmrman的BACKUP KEY命令备份，并定期校验文件MD5。

最后分享一个小技巧：达梦的v$session视图中，AUTH_METHOD列明确标出了每个会话的认证方式（OS、PWD、KEY、LDAP）。当你怀疑某个连接走了错误的认证路径时，执行SELECT SID, USERNAME, AUTH_METHOD FROM V$SESSION WHERE USERNAME='U1';，一眼就能看清真相，比翻日志快十倍。