准确提取用户对象权限需联合查询dba_tab_privs（加where grantee='目标用户'且排除sys等系统用户）、dba_col_privs（列级权限）、dba_role_privs（角色权限含admin_option/default_role）、dba_sys_privs（系统权限），并按依赖顺序生成grant语句，避免依赖未就绪导致ora错误。
怎么从 dba_tab_privs 里准确提取用户对象权限
直接查 dba_tab_privs 容易漏掉列级权限、带 with grant option 的授权，甚至把系统视图误当成普通表。关键不是“能不能查”，而是“查全不全”。
- 必须加
WHERE GRANTEE = '目标用户名' AND OWNER NOT IN ('SYS', 'SYSTEM', 'ORDSYS')过滤掉系统对象和内置账号 - 列级权限藏在
DBA_COL_PRIVS里，不能只查DBA_TAB_PRIVS；如果目标用户有列授权，脚本里就得补上GRANT ... ON table(col1, col2) TO ... -
GRANTABLE字段为'YES'才要加WITH GRANT OPTION，否则生成的语句会多出不该有的权限传递能力 - 注意
TABLE_NAME可能是同义词（SYS.ALL_SYNONYMS），得先解析真实对象名，否则生成的GRANT会报ORA-00942: table or view does not exist
如何处理角色权限（ROLE）和系统权限（SYSTEM PRIV）
用户权限分三层：对象权限、角色权限、系统权限。只克隆对象权限，等于只做了三分之一。角色里可能嵌套角色，系统权限如 CREATE SESSION 不写出来，新用户连登录都做不到。
- 角色权限查
DBA_ROLE_PRIVS，但要注意ADMIN_OPTION和DEFAULT_ROLE字段：前者决定能否再授出该角色，后者影响连接后是否自动激活 - 系统权限查
DBA_SYS_PRIVS，特别留意ADMIN_OPTION = 'YES'的权限（比如GRANT ANY PRIVILEGE），这类权限极敏感，不能无条件照搬 - 避免用
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'U1'就完事——它不递归展开角色所含的权限，必须结合ROLE_ROLE_PRIVS或提前用DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT', 'U1')获取完整授权链
生成 GRANT 语句时怎么避开 ORA-01917 和 ORA-01950
常见错误是脚本生成了 GRANT SELECT ON SCOTT.EMP TO NEWUSER，但 SCOTT 用户没被解锁，或 NEWUSER 没有对应表空间配额，导致执行失败。问题不在语法，而在依赖未就绪。
-
ORA-01917（用户或角色不存在）：说明GRANTEE或OWNER对应的用户还没建好，脚本里得前置检查DBA_USERS和DBA_ROLES -
ORA-01950（对表空间无权限）：对象权限本身不触发这个错，但用户若没默认表空间或配额，后续建对象会崩；生成脚本前建议顺手加一句ALTER USER NEWUSER QUOTA UNLIMITED ON USERS - 所有
GRANT语句必须按依赖顺序排列：先建用户 → 再赋系统权限 → 接着授角色 → 最后给对象权限；顺序错一个，ORA-01917就跟着来
为什么不能直接用 DBMS_METADATA.GET_GRANTED_DDL
这个函数看着省事，但它输出的是“授予动作”的 DDL，不是“当前生效权限”的快照。一旦原用户被 revoke 过某些权限，GET_GRANTED_DDL 仍可能返回已失效的旧授权语句。
- 它不区分
GRANT来源：是直接授的？还是通过角色继承的？脚本里混在一起，后期维护难定位 - 对
WITH ADMIN OPTION和WITH DELEGATE OPTION处理不一致，Oracle 12c+ 后者才支持，老版本用这个函数反而生成非法语法 - 更麻烦的是，它不会过滤掉已被
REVOKE的权限 —— 元数据视图（如DBA_SYS_PRIVS）反映的是当前状态，而GET_GRANTED_DDL回溯的是历史 DDL 记录
真正稳妥的做法，是老老实实扫一遍 DBA_SYS_PRIVS、DBA_ROLE_PRIVS、DBA_TAB_PRIVS、DBA_COL_PRIVS 四张表，逐条判断有效性，再拼字符串。快不快不重要，权限不丢、不错、不越权，才是关键。
