REMAP_SCHEMA仅重写导入语句中的schema名，不修改现有对象owner、不更新数据字典、不处理依赖链；真正转移所有权需重建用户或手动ALTER。
直接用 impdp 的 remap_schema 不能转移对象所有权——它只重定向对象创建语句中的 schema 名，不修改已存在对象的 owner 字段，也不触发权限链路重绑定。真正“转移所有权”必须配合用户重建或显式 alter 操作。
REMAP_SCHEMA 实际干了什么
它在导入时把源 dump 文件中所有 CREATE TABLE scott.emp 类语句，自动改写成 CREATE TABLE hr.emp，再执行。但这个过程完全不碰源库里的 scott 用户本身，也不动目标库中已存在的 hr 用户对象。
- 只影响新导入的对象：表、索引、视图、同义词等结构都会落到目标 schema 下
- 不迁移已有对象：如果目标库
hr已有同名表，impdp默认报错（除非加TABLE_EXISTS_ACTION=REPLACE） - 不改系统字典：
dba_objects.owner字段值由创建时决定，REMAP 不会 retroactively 更新旧对象 - 不处理依赖链：比如
scott.view_a引用了scott.table_b，REMAP 后变成hr.view_a引用hr.table_b—— 但若hr.table_b不存在，视图编译失败，不会自动 fallback 到scott.table_b
为什么导入后还是看到 scott.emp？
常见现象是：impdp ... REMAP_SCHEMA=scott:hr 执行完，查 dba_objects 却发现仍有大量对象 owner 是 scott。这不是 REMAP 失效，而是你导出时没限定范围，dump 文件里混进了其他 schema 的对象（比如 DBA 视图、SYS 对象），或者用了 CONTENT=ALL 导出了整个数据库级元数据。
- 检查导出命令是否带了
schemas=scott：没加就默认导全库，REMAP 只对匹配的 schema 生效 - 确认 dump 文件是否干净：用
impdp ... SQLFILE=check.sql把 DDL 导出为文本，搜CREATE TABLE scott\.看是否还有残留 - 注意
INCLUDE参数干扰：例如INCLUDE=PROCEDURE会把所有 procedure 都拉进来，不管 owner 是谁 - 版本兼容问题：10g 导出的 dump 在 19c 导入时，某些系统对象可能被自动映射到
sys，绕过 REMAP
真正转移所有权的可行路径
如果你的目标是让 hr 成为原 scott 下所有对象的法律 owner（即 dba_objects.owner = 'HR'），只有两条路可走，且都绕不开人工干预：
- 先清空目标用户：
DROP USER hr CASCADE，再用REMAP_SCHEMA=scott:hr导入——这是最干净的方式，所有对象 owner 自然就是hr - 不清空用户，但需手动修正：
ALTER TABLE scott.emp RENAME TO hr.emp不合法；正确做法是CREATE TABLE hr.emp AS SELECT * FROM scott.emp+DROP TABLE scott.emp，再重建索引、约束、授权——适合少量关键表 - 权限不是自动跟着走的：
GRANT SELECT ON scott.emp TO app_user不会因 REMAP 变成GRANT SELECT ON hr.emp TO app_user，必须额外导出并重放GRANT语句（加CONTENT=ALL或INCLUDE=GRANT） - 同义词要单独处理：
CREATE SYNONYM app_emp FOR scott.emp不会被 REMAP，得手动建新同义词或用REMAP_SCHEMA配合INCLUDE=SYNONYM
最容易被忽略的权限静默失效点
REMAP_SCHEMA 导入成功 ≠ 权限生效。日志里出现 ORA-39112: Dependent object type GRANT:"HR" skipped 往往意味着目标对象还没建好，grant 就被跳过，而你根本看不到错误提示。
- 必须确保目标用户
hr已存在且有足够配额：ALTER USER hr QUOTA UNLIMITED ON users - 如果源对象用了自定义类型（如
CREATE TYPE scott.t_list AS TABLE OF NUMBER），REMAP 后类型名仍是scott.t_list，除非显式REMAP_SCHEMA两次（一次类型，一次表）或提前在hr下建好同名类型 - 物化视图日志（
MATERIALIZED VIEW LOG）属于独立对象，owner 不随主表 REMAP，容易漏掉导致刷新失败 - 审计策略（
AUDIT POLICY）、FGA 策略等安全对象不参与 REMAP，需单独导出配置
