ORA-39919报错，表空间对象没在传输集里，远程修复思路分享

ORA-39919这个错误，就是你想把一个表空间从一个数据库“搬”到另一个数据库（这个过程叫表空间传输），但是在打包准备搬运的“物品清单”（也就是传输集）里，数据库系统发现缺少了某个关键的东西，导致它没法安全、完整地完成这次搬运，系统为了不出错，就抛出这个错误，告诉你：“喂，先别搬，清单和实物对不上，有东西没在清单里！”

这个错误通常发生在你执行TRANSPORT TABLESPACE操作，使用DBMS_STREAMS_TABLESPACE_ADM包或者数据泵（Data Pump）的传输表空间功能时，错误信息通常会明确告诉你哪个对象（比如一张表、一个索引）没有被包含在内。

为什么会发生这种情况？

根据Oracle官方文档和一些技术社区的实践经验（比如Oracle Support的文档ID 555565.1和类似的问题讨论），核心原因就是这个“遗漏的对象”通常是某个表的“依赖对象”，什么叫依赖对象？举个例子你就明白了：

1. 索引不在表空间里： 这是最常见的原因，你有一个表叫员工表，它存放在你想传输的用户数据表空间里，你为这个员工表创建了一个索引叫员工姓名索引，但这个索引却被你或者之前的开发人员不小心创建在了另一个表空间，比如叫索引表空间里，你想只传输用户数据表空间，数据库系统在检查时发现：“等等，员工表是要搬走的，但它有个孩子——员工姓名索引——没在搬家名单上啊！如果把表搬走了，索引还留在老数据库，那新数据库里的表不就找不到索引了吗？这肯定要出乱子。” 它就抛出ORA-39919错误，阻止你继续操作。
2. 分区表的部分分区在其他表空间： 如果一个表是分区表，并且它的不同分区存放在不同的表空间里，你只选择了其中一部分分区所在的表空间进行传输，那么其他分区的“魂”还在源数据库，这也是不允许的。
3. LOB字段存储在单独的表空间： 如果一张表里有存放大对象（比如图片、文档）的LOB字段，并且这个LOB字段被指定存储在一个独立的表空间里，你只传输了主表所在的表空间，但没有传输LOB字段的表空间，同样会触发这个错误。
4. 其他依赖关系： 比如物化视图、某些类型的约束等，如果它们没有和基表放在同一个要传输的表空间内，也可能导致问题。

远程修复思路分享（核心部分）

既然知道了原因,修复的思路就很清晰了：把那个“掉队”的依赖对象，要么请回我们要传输的表空间里，要么把它也加入到传输集中。 由于是“远程”修复，我们主要通过SQL命令在数据库服务器上操作。

第一步：精准定位“失踪”对象

你不能瞎猜是哪个对象出了问题,Oracle的错误信息通常会告诉你对象名和类型，请仔细阅读错误信息，如果信息不够明确，你可以通过查询数据字典来定位，在源数据库上，执行类似下面的查询（你需要替换你的表空间名和操作条件）：

-- 查询传输集中缺失的索引
SELECT i.owner, i.index_name, i.tablespace_name
FROM dba_indexes i
WHERE i.tablespace_name != '你的源表空间名' -- 索引不在要传输的表空间
AND i.table_name IN (
    SELECT table_name FROM dba_tables
    WHERE tablespace_name = '你的源表空间名' -- 但表在要传输的表空间
);
-- 查询分区表的情况
SELECT table_owner, table_name, partition_name, tablespace_name
FROM dba_tab_partitions
WHERE tablespace_name != '你的源表空间名'
AND table_name IN (
    SELECT table_name FROM dba_tables
    WHERE tablespace_name = '你的源表空间名'
);
-- 查询LOB字段的情况
SELECT l.owner, l.table_name, l.column_name, l.tablespace_name
FROM dba_lobs l
WHERE l.tablespace_name != '你的源表空间名'
AND l.table_name IN (
    SELECT table_name FROM dba_tables
    WHERE tablespace_name = '你的源表空间名'
);

通过这些查询,你就能准确地找到是哪些“调皮鬼”没有待在它该待的队伍里。

第二步：制定修复方案并执行

找到对象后,你有两种主要的修复选择：

方案A：移动对象（推荐且彻底）

这个方案的思想是：把这个依赖对象物理地移动到你要传输的表空间里，这样，当你传输这个表空间时，所有相关的东西就都在一起了，一锅端走，最是干净利落。

• 移动索引：

  ALTER INDEX 索引拥有者.索引名 REBUILD TABLESPACE 你的源表空间名;

  这条命令会把索引在指定的表空间里重建,相当于把它搬了过去。

• 移动LOB字段：

  ALTER TABLE 表拥有者.表名 MOVE LOB(LOB字段名) STORE AS (TABLESPACE 你的源表空间名);

  这条命令专门用于移动LOB字段的存储位置。

• 移动表分区： 移动分区稍微复杂点，可能需要使用ALTER TABLE ... MOVE PARTITION命令。

方案B：扩展传输集（折中方案）

如果你的业务场景允许,或者移动对象成本太高（比如索引非常大，重建耗时很长），你可以选择把依赖对象所在的另一个表空间也加入到本次传输集中，也就是说，本来你只打算搬一个表空间（比如用户数据表空间），现在你把存放索引的那个索引表空间也一起搬走。

这个方案的具体操作取决于你使用的工具：

• 如果使用数据泵,在expdp导出时，在TRANSPORT_TABLESPACES参数里同时列出这两个表空间的名字。
• 如果使用DBMS_STREAMS_TABLESPACE_ADM包，也需要在过程中指定多个表空间。

注意： 方案B意味着目标数据库也会接收这个额外的表空间，你需要确保目标数据库的环境能够接受这一点。

第三步：重新验证和测试

在执行完修复操作（比如移动了索引）后，强烈建议你再次运行第一步的查询，确认那些“失踪”对象现在已经正确地出现在了传输表空间中，重新执行一次传输表空间的预检查或者直接再次尝试传输操作，确认ORA-39919错误已经消失。

无论采用哪种方案,在将表空间成功传输到目标数据库后，都要在目标端进行充分的应用测试，确保表可以正常访问、查询性能符合预期，特别是如果你移动或改变了索引，更要检查查询速度是否正常。

处理ORA-39919就是一个“找孩子”和“让孩子归队”的过程，核心在于利用SQL查询精准定位问题根源，然后根据实际情况选择是“移动对象”还是“扩大运输队伍”，最终实现表空间的平稳迁移。