ORA-13665报错怎么回事，执行名顺序乱了导致的远程修复思路分享

ORA-13665报错怎么回事，执行名顺序乱了导致的远程修复思路分享

ORA-13665这个错误，根据甲骨文官方支持文档（Oracle Support Doc ID 13665.1）的标题“EXPDP Fails With ORA-13665”，可以知道它主要发生在使用数据泵导出工具（EXPDP）的时候，这个错误的直接原因是“执行名顺序乱了”，更具体地讲，是你发出的数据泵操作指令中，某个对象的操作顺序存在依赖性问题,导致系统不知道该怎么执行了。

想象一下一个简单的场景：你要先建好一个房子（表）的框架，才能往里搬家具（数据），但如果你给工人的指令是“先把家具搬进去，然后再盖房子”，这显然就乱套了，会无法执行，ORA-13665就是类似的情况，数据库在准备执行导出任务时，发现任务队列里的步骤顺序不对，可能先要处理一个依赖于其他对象才能存在的对象，而它所依赖的那个对象却排在后面处理,这就产生了矛盾。

为什么会出现“执行名顺序乱了”这种情况呢？根据一些技术社区（如Oracle官方论坛、ITPUB等）用户的经验分享,常见的原因包括以下几种：

1. 元数据不一致：这是最根本的原因之一，数据库的数据字典（记录所有数据库对象信息的地方）可能因为某些原因（比如不完全恢复、手动修改、Bug等）出现了不一致，一个外键约束所引用的父表信息在数据字典中丢失或损坏了，导致数据泵在分析依赖关系时无法正确识别出“应该先导出父表，再导出子表”的正确顺序。
2. 复杂的数据信对象：当数据库中包含非常复杂的对象关系时，比如深层次的视图依赖（视图A基于视图B，视图B又基于表C和视图D……）、复杂的类型继承关系、或者大量的跨Schema同义词等，数据泵的依赖关系分析算法可能会在某些特定情况下“算晕了”，从而排错顺序，这种情况虽然不常见,但在极其复杂的系统中有可能发生。
3. Oracle数据库版本的Bug：在某些特定的Oracle数据库版本中，数据泵工具本身可能存在未被发现的缺陷（Bug），这些缺陷可能导致其在处理特定类型的对象或特定场景下的依赖关系分析时出错,生成错误的作业队列顺序。

当你通过远程连接的方式管理数据库，并遇到EXPDP导出因ORA-13665失败时，修复思路需要循序渐进，避免盲目操作,以下是一些可以尝试的远程修复思路：

尝试最直接的修复命令

可以尝试使用Oracle提供的内置过程来修复数据字典的元数据，这个方法相对安全，通常是DBA的首选尝试方案，通过远程会话（比如SQL*Plus或SQL Developer）连接到目标数据库,以SYSDBA权限执行以下命令：

EXECUTE DBMS_UTILITY.COMPILE_SCHEMA('YOUR_SCHEMA_NAME');

以及

EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;

第一条命令COMPILE_SCHEMA会重新编译指定模式下的所有对象（过程、函数、包、视图等），这个过程会重新解析对象的依赖关系，有时可以顺带修复一些轻微的元数据不一致，第二条命令GATHER_DICTIONARY_STATS是重新收集数据字典的统计信息，确保优化器（以及像数据泵这样的工具）对系统表有最新的信息用于分析，执行完这两个步骤后，再次尝试运行之前失败的EXPDP命令,看问题是否解决。

简化导出任务，定位问题对象

如果上述方法无效，说明问题可能比较具体，接下来可以尝试“缩小包围圈”，找到导致报错的具体对象，不要一次性导出整个模式或数据库,而是尝试分批导出。

• 方法A：使用EXCLUDE参数排除：在EXPDP命令中，使用EXCLUDE参数逐步排除掉你认为可能不重要的对象类型，先尝试排除所有约束、索引、触发器，只导出表和数据：EXCLUDE=CONSTRAINT,INDEX,TRIGGER，如果这样能成功，说明问题出在排除掉的这些对象类型中，然后再逐步将排除的对象加回来，比如先加回索引试试,通过这种二分法定位到具体的对象类型乃至具体对象。
• 方法B：使用INCLUDE参数包含：与排除法相反，如果你只需要导出一部分重要表，可以使用INCLUDE参数，只包含少数几个表进行导出测试，先从一个你认为最简单的表开始，成功后再逐渐添加其他表，直到添加某个表时错误复现，那么这个表（或它与之前已包含表的关系）就很可能是问题的根源。

通过这种方法，你可以将问题范围从“整个模式”缩小到“某一类对象”甚至“某一个特定对象”。

查询数据字典，手动分析依赖关系

如果通过思路二定位到了可疑的对象（比如某个视图或某个表），可以进一步手动查询数据字典来分析其依赖关系，查询DBA_DEPENDENCIES视图，查看这个对象到底依赖于哪些其他对象，检查这些被依赖的对象是否都存在、状态是否有效，有时，你会发现某个底层表已经被删除，但依赖它的视图却依然存在（状态变为INVALID），这就可能引发顺序混乱，根据查询结果，你可能需要重建无效的视图,或者修复缺失的依赖关系。

作为最后手段——使用传统EXP工具或SQL脚本

如果以上方法都失败了，而导出数据又非常紧急,可以考虑以下备选方案：

• 尝试使用老版的传统导出工具EXP，虽然EXP功能不如EXPDP强大，但它的逻辑相对简单，有时能绕过EXPDP遇到的复杂依赖问题,这取决于你的Oracle版本是否还支持EXP。
• 放弃使用数据泵，转而使用SQL脚本方式，即，通过查询数据字典，手动生成创建表结构、索引、约束等的DDL语句，然后使用SQL*Plus的SPOOL功能将表数据生成INSERT语句，这是一个非常耗时费力的过程,通常只用于对象数量不多或者作为万不得已的补救措施。

处理ORA-13665错误的关键在于理解其核心是“依赖顺序混乱”，远程修复时，应从最简单、风险最低的操作开始（如编译Schema和收集统计信息），逐步过渡到更具体的排查（通过排除法/包含法定位问题对象），最后再考虑手动分析或替代方案，在整个过程中,耐心和有条理的排查比任何单一的高深技巧都更重要。