oracle密码复杂度验证必须使用password_verify_function，它由内核在create/alter user时自动调用；触发器无效，因改密非dml操作。函数须建在sys下、签名固定、返回boolean、绑定profile，查配置表实现动态规则但需注意性能与限制。

触发器不能用于密码复杂度验证

直接在触发器里做密码校验是错的路——PASSWORD_VERIFY_FUNCTION 是 Oracle 唯一认可的密码强度入口，它由数据库内核在 CREATE USER 或 ALTER USER IDENTIFIED BY 时自动调用。触发器只响应 DML（INSERT/UPDATE/DELETE），而改密码不是对表操作，不走任何触发器链。

真正生效的密码校验必须用 verify_function

Oracle 强制要求密码验证函数签名固定：FUNCTION verify_function (username IN VARCHAR2, password IN VARCHAR2, old_password IN VARCHAR2) RETURN BOOLEAN。这个函数必须：

• 存放在 SYS 用户下（或显式授权 EXECUTE 给 SYS）
• 返回 BOOLEAN，不能是 NUMBER 或 VARCHAR2
• 内部用 raise_application_error(-20001, 'xxx') 报错，不能靠 RETURN FALSE 静默失败
• 绑定到 profile 后才起效：ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION my_verify_func

常见翻车点：函数创建成功但没授权给 SYS，或者 profile 绑定的是函数名大小写/拼写错误（比如写成 VERIFY_FUNCTION 而实际是 my_verify_func），结果改密码时只报 ORA-28003 却不提示具体哪条规则失败。

动态规则得靠配置表 + 函数内查表

硬编码规则（比如“必须含大写”）无法满足“不同部门不同强度”的需求。可行做法是建一张配置表：

CREATE TABLE pwd_policy_config (
  dept_code   VARCHAR2(10),
  min_length  NUMBER,
  require_upper CHAR(1),
  require_digit CHAR(1),
  require_punct CHAR(1),
  forbid_usernames CHAR(1)
);

然后在 verify_function 里根据 username 查该表（注意加 SELECT ... INTO，别漏 NO_DATA_FOUND 异常处理），再用 REGEXP_LIKE 和 LENGTH 做判断。关键限制：

• 不能查大表或带聚合的视图，否则每次改密码都卡住
• 避免 UTL_HTTP、DBMS_SCHEDULER 等外部调用，它们在密码校验上下文中被禁用
• 查配置表前加 SELECT /*+ RESULT_CACHE */ ... 可缓存结果，减少重复解析

别把触发器和 verify_function 混在一起用

有人试图在用户表（如 dba_users）上建 AFTER UPDATE 触发器去反向校验密码字段——这完全无效。password 字段在 dba_users 中是加密哈希值，不是明文；且密码修改过程根本不更新该表，而是由 Oracle 内部完成哈希计算与存储。你看到的 ALTER USER ... IDENTIFIED BY 是一个原子操作，不经过任何用户可见的 DML 流程。

真正容易被忽略的点：verify_function 运行在系统级上下文，没有会话状态，不能依赖 USERENV 以外的上下文变量；所有逻辑必须自包含，不能依赖包变量或临时表。