必须执行四类dbms_metadata.get_granted_ddl调用（system_grant、role_grant、default_role、object_grant），且用户名全大写；需配置set long 100000等sql*plus参数；生成脚本中to后必须加双引号并严格匹配目标用户名大小写；动态权限语句须人工验证对象存在性。
DBMS_METADATA.GET_GRANTED_DDL 四类调用必须全执行
只跑一次 DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT', 'OLD_USER') 不够——新用户可能连登录都失败。系统权限（如 CREATE SESSION）、角色授权（如 GRANT CONNECT TO OLD_USER）、默认角色设置（ALTER USER ... DEFAULT ROLE）和对象权限缺一不可。
必须分别执行这四条语句，且用户名必须全大写：
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;
漏掉 DEFAULT_ROLE 会导致目标用户连接后角色不自动激活；漏掉 SYSTEM_GRANT 可能直接卡在登录环节。
SET LONG 和 SQL*Plus 环境配置不能省略
输出是 CLOB，SQL*Plus 默认 LONG 是 80 字符，截断后脚本会少半句 GRANT，执行时报 ORA-00922: missing or invalid option。
执行前必须设好这四行：
SET LONG 100000SET PAGESIZE 0SET FEEDBACK OFFSET TRIMSPOOL ON
不关 FEEDBACK 会在脚本里混入 1 row selected；不设 PAGESIZE 0 会插入页眉页脚；TRIMSPOOL 不开会导致每行末尾多空格，某些权限语句因此失效。
替换 TO 用户名时双引号和大小写要严格匹配
生成的脚本里所有 TO OLD_USER 必须替换成 TO "NEW_USER"，注意双引号——哪怕 NEW_USER 是全大写也得加引号。
原因：Oracle 解析时，没引号的标识符强制转大写，但若目标用户是小写创建（如 CREATE USER "app_dev" IDENTIFIED BY ...），不加引号就变成 TO APP_DEV，报 ORA-01917: user or role 'APP_DEV' does not exist。
替换时还要注意：
- 原输出中对象名（如表、视图）若带双引号（
"MyTable"），不能去掉，否则GRANT SELECT ON MyTable TO ...会报ORA-00942 - 角色名不用引号，但必须全大写：
GRANT RESOURCE TO "new_user"错，GRANT RESOURCE TO "new_user"也错，正确是GRANT RESOURCE TO "NEW_USER"
动态 SQL 执行前必须人工验证对象存在性
DBMS_METADATA.GET_GRANTED_DDL 不解析同义词或已删除对象。比如输出里有 GRANT SELECT ON MY_EMP TO OLD_USER，但 MY_EMP 可能是同义词，真实对象早已被删，或指向另一个 schema 的无效表。
这类权限无法“一键克隆”，必须：
- 查
SELECT * FROM DBA_SYNONYMS WHERE SYNONYM_NAME = 'MY_EMP'确认指向 - 用
SELECT COUNT(1) FROM DBA_OBJECTS WHERE OWNER = 'SCOTT' AND OBJECT_NAME = 'EMP'验证基表是否存在 - 若对象不存在，这条
GRANT就得删掉，否则执行时报ORA-00942并中断后续语句
真正麻烦的不是生成脚本，而是确认每一条 ON owner.object 在目标库是否真实可达——这点没法自动化，必须人眼核对。
