impdp 默认不导入任何 GRANT 权限，需导出时显式指定 CONTENT=ALL 或 INCLUDE=GRANT，并确保目标库已预先创建用户、角色及表空间，否则权限将静默跳过。
直接用 impdp 导入用户数据，默认不带权限——连 grant select on scott.emp to hr 这种基础授权都会静默跳过，查表时报 ora-00942 却以为是表没导过去。
impdp 默认不导入任何 GRANT 语句
导出时若只写 expdp ... SCHEMAS=scott，哪怕加了 CONTENT=DATA_ONLY 或默认行为，生成的 dump 文件里也只含对象定义和数据，不含任何显式授权。导入时 impdp 不会重建用户、不创建角色、也不执行 GRANT。日志里只会有一行轻描淡写的 ORA-39112: Dependent object type GRANT:"HR" skipped，根本不会报错中断。
- 必须在导出端显式要求包含权限：加
CONTENT=ALL（最稳妥）或INCLUDE=GRANT -
CONTENT=ALL会导出表、索引、约束、视图、同义词、触发器 + 所有 GRANT，适合完整迁移 -
INCLUDE=GRANT只导“被授予方”视角的授权（如GRANT SELECT ON scott.emp TO hr），不导WITH GRANT OPTION链路，也不能还原“谁授的权” - 别信
GRANTS=YES参数——这是 impdp 的默认值，但对缺失基础结构的场景毫无作用
目标库必须提前建好用户和角色
impdp 不会帮你执行 CREATE USER 或 CREATE ROLE。如果目标库没有 hr 用户，那所有 GRANT ... TO hr 都会失败并跳过；如果用了自定义角色 my_app_role，而目标库没建，GRANT my_app_role TO hr 同样失效。
- 先查源库用户密码哈希：
SELECT username, password FROM dba_users WHERE username = 'HR'; - 在目标库执行：
CREATE USER hr IDENTIFIED BY VALUES 'xxx' DEFAULT TABLESPACE users;（用查到的password值，避免重置密码） - 如有自定义角色，提前运行
CREATE ROLE my_app_role; - 至少赋予
CONNECT和RESOURCE，否则用户连不上或建不了对象
REMAP_SCHEMA 不改 GRANT 里的对象名
加 REMAP_SCHEMA=scott:hr 只影响表、索引等对象的属主，不影响 GRANT 语句中硬编码的 schema 名。比如导出语句是 GRANT SELECT ON scott.emp TO hr，导入时仍按 scott.emp 解析——如果目标库没 scott 用户或该表不在 scott 下，权限就挂了。
- 要么在导出前确保源库
scott.emp已存在且可访问（用于权限校验） - 要么改用
INCLUDE=GRANT+ 手动修正 dump 中的 GRANT 语句（不推荐） - 更可靠的做法：导出时用
SCHEMAS=scott+CONTENT=ALL，导入时用REMAP_SCHEMA=scott:hr，同时确保目标库已建好hr用户和对应表空间 - 注意
REMAP_TABLESPACE要配齐，否则表能导过去，索引/LOB 可能因表空间不存在而失败
字符集与版本兼容性容易被忽略
Oracle 11g 导出的数据，导入到 12c/19c/21c 时，若没指定 VERSION，可能因内部元数据格式差异导致 GRANT 解析失败，尤其涉及系统权限（如 SELECT ANY DICTIONARY）。
- 导出时加上
VERSION=11.2.0（对应源库版本），保证元数据向下兼容 - 检查两端字符集是否一致：
SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET'); - 若目标库字符集是
AL32UTF8，源库是ZHS16GBK，GRANT 中的中文注释可能乱码，但权限本身通常不受影响 -
NLS_LANG环境变量要设对，否则日志文件里的报错信息可能显示为问号，掩盖真实问题
权限不是导进去就完事的——它依赖用户存在、角色存在、被授权对象存在、表空间存在、字符集兼容。漏掉任一环，impdp 都不会提醒你，只会默默跳过。
