不能一步到位，必须分四类调用：SYSTEM_GRANT、ROLE_GRANT、DEFAULT_ROLE、OBJECT_GRANT；漏任何一类或用户名非大写均导致脚本不完整或为空；还需设置LONG等参数并校验对象存在性、用户状态、角色及表空间配额。
直接用 DBMS_METADATA.GET_GRANTED_DDL 能不能一步到位？
不能，必须分四类调用且全部执行。只跑 dbms_metadata.get_granted_ddl('object_grant', 'old_user') 会漏掉系统权限、角色、默认角色——新用户可能连 create session 都没有，根本登不进库。
必须依次执行这四条（OLD_USER 必须全大写）：
SELECT DBMS_METADATA.GET_GRANTED_DDL('SYSTEM_GRANT', 'OLD_USER') FROM DUAL;SELECT DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT', 'OLD_USER') FROM DUAL;SELECT DBMS_METADATA.GET_GRANTED_DDL('DEFAULT_ROLE', 'OLD_USER') FROM DUAL;SELECT DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT', 'OLD_USER') FROM DUAL;
漏掉任何一类，生成的脚本就不完整；用户名若用小写或带引号，函数返回空 CLOB，不是报错，极易误判为“没权限”。
SET LONG 不够大会导致 GRANT 语句被截断
DBMS_METADATA.GET_GRANTED_DDL 返回的是 CLOB，SQL*Plus 默认 LONG 只有 80 字符，远不够容纳多条授权语句。一旦截断，脚本里 GRANT SELECT ON ... 缺后半截，执行时直接报 ORA-00922: missing or invalid option。
执行前必须显式设置：
SET LONG 100000-
SET PAGESIZE 0（避免页眉页脚混入） -
SET FEEDBACK OFF（防止输出1 row selected污染脚本） SET TRIMSPOOL ON
验证是否生效：看输出第一行是不是完整的 GRANT 语句，而不是以 GRANT SELECT ON 开头、后面跟着省略号。
动态 SQL 执行 GRANT 时为什么总报 ORA-01917 或 ORA-01950？
这类错误不是语法问题，而是依赖未就绪：ORA-01917 说明目标用户或角色还没建好；ORA-01950 说明新用户没配表空间配额，对象权限本身不触发它，但后续操作会崩。
执行前必须确认：
- 目标用户已存在，且状态为
OPEN（查DBA_USERS） - 所有涉及的角色（包括自定义角色）已在目标库创建
- 执行
ALTER USER NEW_USER QUOTA UNLIMITED ON USERS或对应表空间 - 若权限语句含同义词（如
GRANT SELECT ON MY_EMP TO NEW_USER），确保该同义词指向的真实对象存在且可访问
不要指望脚本自动建用户或角色——impdp 和 DBMS_METADATA 都不干这事，得你手动铺路。
为什么不能直接用 EXPDP/IMPDP 导出权限？
因为 EXPDP 默认不导权限；即使加了 CONTENT=ALL，导入时也会静默跳过所有 GRANT，日志里只有一行 ORA-39112: Dependent object type GRANT:"NEW_USER" skipped，你根本看不到失败。
更麻烦的是，它不区分“直接授予”和“继承获得”，会把通过角色间接拿到的权限也打包进去，结果新用户拿到一堆无效授权（比如指向已被删表的 GRANT SELECT ON SCOTT.EMP），甚至触发 ORA-01927: cannot revoke privileges you did not grant。
真正需要的是最小集精确克隆：只取 OLD_USER 显式拥有的权限，不带继承、不带冗余、不带失效对象。
复杂点不在怎么生成语句，而在每条 GRANT 背后都藏着对象存在性、用户状态、角色激活、表空间配额四个校验点——少盯住一个，脚本就跑不通。
