不能用GRANT转移对象所有权，因GRANT仅授访问权而非所有权；必须通过expdp/impdp重映射或手动重建实现OWNER字段变更，否则PUBLIC同义词、DBLINK、FGA策略等残留将导致应用异常。
不能直接用 GRANT 或 ALTER USER 转移对象所有权；必须逐个执行 ALTER TABLE、ALTER VIEW 等 DDL，或用 Data Pump 重映射——否则原用户对象仍归原主，新用户只有访问权，不是所有者。
为什么不能用 GRANT 把所有权“给”别人
很多人误以为 GRANT SELECT ON user1.t1 TO user2 是转移所有权，其实只是授出查询权限。user2 依然不能 DROP、ALTER 或 COMMENT ON 这张表——它连 user2.t1 都不存在，只是能查 user1.t1。真正改变所有者，意味着该对象在数据字典里 OWNER 字段要从 USER1 变成 USER2，这只能靠重建或迁移实现。
安全转移的两种可靠方式
生产环境推荐以下任一路径，避免锁表、权限断裂或元数据不一致：
- 用
expdp+impdp重映射：导出时指定REMAP_SCHEMA=user1:user2，导入时对象自动归属 user2，且约束、索引、注释全保留；但要求 user2 已存在且有CREATE TABLE等基础权限 - 手动重建（适合少量关键对象）：以 user2 身份执行
CREATE TABLE t1 AS SELECT * FROM user1.t1，再迁移约束/索引/触发器；注意SEQUENCE和DBLINK不会自动复制，需单独处理
别用 ALTER SCHEMA ——Oracle 根本没有这个语法；也别依赖第三方工具自动改 OBJ$ 表，那是破坏数据字典，实例可能无法启动。
容易被忽略的三类残留对象
即使表和视图成功迁走，以下对象常被遗漏，导致应用报错：
-
PUBLIC同义词：比如SELECT * FROM emp能跑，是因为dba_synonyms里有OWNER = 'PUBLIC'指向SCOTT.EMP；迁移后若没重建，就会报ORA-00942: table or view does not exist - 数据库链接（
DBLINK）：dba_db_links中OWNER != 'USER1'的链接不会随 schema 迁移，user2 查询远程库会失败 - 细粒度审计策略（FGA）：策略绑定在原 owner 的对象上，迁移后策略仍在但失效，需用
DBMS_FGA.DROP_POLICY+ 重新创建
真正完成所有权转移，不只是让新用户“能用”，而是让它成为数据字典里那个对象的唯一合法 OWNER——这意味着所有依赖关系、审计上下文、回收站条目都得同步刷新，漏掉任何一类，后续维护就埋了雷。
