ORA-39924错误导致分区索引表空间不在传输集合里，远程帮忙修复思路分享

ORA-39924错误导致分区索引表空间不在传输集合里，远程帮忙修复思路分享

（引用来源：Oracle官方文档《Oracle Database Backup and Recovery User's Guide》中关于可传输表空间及数据泵expdp/impdp的相关章节，以及MOS（My Oracle Support）知识库中关于ORA-39924错误的故障排查笔记。）

最近在处理一个客户的数据库问题时,遇到了一个典型的错误：ORA-39924，这个错误发生在使用Oracle的数据泵工具进行数据迁移的过程中，具体场景是把一个分区表从一个数据库迁移到另一个数据库，客户反馈说，导出过程看起来是顺利的，但是在导入的时候，工具报错了，错误信息明确指出是“分区索引的表空间不在传输集合中”，就是我们准备搬家时，只打包了主表这个“大件家具”所在的房间（表空间），却把这个“大件家具”的一个重要配件——分区索引，给遗忘在另一个没打包的房间（另一个表空间）里了，数据泵工具在目的地组装时，发现找不到这个配件，于是就罢工报错了。

问题是怎么被发现的？

客户是通过数据泵的expdp命令进行导出的,他们指定了要导出的特定表空间（TRANSPORT_TABLESPACES参数），这个表空间里存放着他们需要迁移的核心分区表的数据，导出日志没有报告严重错误，在使用impdp命令导入时，错误ORA-39924就跳了出来，导入进程因此中断，导致目标数据库的表结构不完整，无法正常使用。

为什么会发生这个错误？

这个错误的根源在于对“可传输表空间”技术细节的理解偏差，可传输表空间是一种快速的数据迁移方法，它的核心思想是直接拷贝存储数据的文件（数据文件），而不是像传统导出导入那样一条条地处理数据记录，为了确保拷贝过去的数据文件在目标数据库里能被正确识别和使用，有一个硬性规定：与指定表空间中的表相关的所有分区（或子分区）的索引段，也必须位于同一个要传输的表空间集合里。

在我们的案例中,情况是这样的：

1. 主分区表（比如叫做BIG_TABLE）的数据段确实存放在客户指定的传输表空间（比如TS_DATA）中。
2. 这个BIG_TABLE表上建立了一个本地分区索引,所谓本地分区索引，就是索引的分区结构和表的分区结构是一一对应的。
3. 问题在于,这个本地分区索引的索引段，被有意或无意地创建在了另一个不同的表空间（比如TS_INDEX）中。
4. 客户在导出时,只将TS_DATA加入了传输集合，完全忘记了存放索引的TS_INDEX。
5. 当impdp尝试在目标端创建索引时,它发现索引应该存放在TS_INDEX表空间，但这个表空间并没有随着数据文件一起被传输过来，在目标数据库上也不存在（或者存在但结构不一致），于是果断抛出ORA-39924错误。

（引用来源：MOS文档《ORA-39924 During Transportable Tablespace Import (Doc ID 555565.1)》中对此有明确解释：该错误表明一个或多个分区索引的段位于传输表空间列表之外的表空间中。）

远程协助下的修复思路

由于是远程支持,我们无法直接操作客户的服务器，因此思路主要集中在指导客户进行信息收集和分步操作上。

第一步：确认问题细节

我们让客户在源数据库上执行查询,精确核实问题，关键的查询语句是检查分区表及其索引的表空间分布情况：

-- 查询表的分区所在的表空间
SELECT table_name, partition_name, tablespace_name
FROM user_tab_partitions
WHERE table_name = 'BIG_TABLE'; -- 替换为实际的表名
-- 查询该表上分区索引的索引分区所在的表空间
SELECT i.index_name, ip.partition_name, ip.tablespace_name
FROM user_indexes i
JOIN user_ind_partitions ip ON i.index_name = ip.index_name
WHERE i.table_name = 'BIG_TABLE'; -- 替换为实际的表名

通过对比这两个查询的结果,我们和客户都清晰地看到，表的分区全在TS_DATA中，而索引的分区确实全在TS_INDEX中，这证实了我们的判断。

第二步：制定解决方案

我们提供了两个主要的解决方案供客户选择：

• 方案A：将索引表空间加入传输集合（推荐且彻底） 这是最规范的做法，既然索引是表不可或缺的一部分，就应该将它们作为一个整体来迁移。

  1. 指导客户修改之前的expdp导出命令,在TRANSPORT_TABLESPACES参数中同时包含TS_DATA和TS_INDEX这两个表空间。
  2. 在导入端,同样需要确保impdp命令处理这两个表空间。
  3. 这样做的好处是保持了源端和目的端完全一致的存储结构,避免了后续潜在的管理混乱。

• 方案B：在导入前于目标端重建索引（临时变通） 如果客户出于某种原因（比如TS_INDEX表空间非常大，传输耗时过长）不想传输索引表空间，可以采用此方法。

  1. 在impdp导入时,使用EXCLUDE=INDEX参数，告诉数据泵跳过所有索引的创建。
  2. 导入完成后,主表的数据和结构已经存在于目标数据库的TS_DATA表空间中了。
  3. 指导客户在目标数据库上手动执行一条ALTER INDEX ... REBUILD ... TABLESPACE ...语句（或者如果目标端已有合适的TS_INDEX表空间，也可以指定到那里），重新创建所有缺失的分区索引。 这种方法相当于在目的地重新制作“配件”，虽然能解决问题，但需要额外的索引重建时间，并且要确保目标端有足够的空间和资源。

第三步：执行验证

无论选择哪种方案,在操作完成后，验证是必不可少的，我们让客户在目标数据库上：

1. 再次运行第一步中的查询语句,确认表和索引的分区都正确地分布在了预期的表空间中。
2. 执行一些简单的查询语句,验证索引是否有效，数据是否可以正常访问。

总结与提醒

通过这次远程协助,我们总结出几点经验：

1. 迁移前做好功课：在使用可传输表空间这种高级功能前，一定要彻底搞清楚源对象的存储依赖关系，特别是表和索引的表空间分布。
2. 善用数据字典查询：USER_TAB_PARTITIONS和USER_IND_PARTITIONS等视图是排查这类问题的利器。
3. 理解错误信息的含义：ORA-39924错误信息本身已经非常清晰地指出了问题方向，关键在于如何准确解读并找到具体是哪个索引出了错。
4. 远程协助的核心是清晰的指引：由于无法亲手操作，提供精确、可复制的SQL查询命令和操作步骤至关重要，同时要给出不同方案的利弊，让客户根据自身情况做出选择。

客户选择了方案A,因为他们希望保持环境的一致性，我们指导他们完成了完整的导出和导入流程，整个过程顺利完成，错误不再出现，这次经历也成为了一个很好的知识积累，为以后处理类似问题提供了清晰的范本。