ORA-39025报错，字符串类型任务不能重启，远程帮忙修复故障问题

ORA-39025报错是Oracle数据库在使用Data Pump工具（即expdp和impdp命令）进行数据导入或导出时可能遇到的一个特定错误，根据Oracle官方文档和常见的故障处理经验，这个错误的根本原因在于尝试重新启动（使用START_JOB参数）一个被归类为“字符串类型”的Data Pump任务。

要理解这个错误，首先需要知道Data Pump有一个非常实用的功能叫“重启”，意思是，如果一个数据导出或导入任务因为各种原因（比如空间不足、网络中断）中途失败了，只要不是致命错误，你可以修复问题后，使用START_JOB=YES参数从断点继续任务，而不用从头开始,这能节省大量时间。

并不是所有任务都支持重启，根据Oracle的设定，ORA-39025报错明确指出：你正在尝试重启的任务是一个“字符串类型”的任务，这里的“字符串类型”并不是指数据库里的VARCHAR2字段，而是指这个Data Pump任务本身的性质，当你的expdp导出命令或impdp导入命令中包含了PARALLEL参数，并且同时使用了NETWORK_LINK参数进行跨数据库的操作时，这个任务就会被标记为“字符串类型”。

为什么这种组合会导致不能重启呢？原因在于任务执行方式的不同，当使用NETWORK_LINK时，数据并不是先导出到磁盘文件再传输，而是通过数据库链接（Database Link）直接在两个数据库之间流动，这是一种“流式”的处理方式。PARALLEL参数会启用多个并行进程来加速这个流式传输，这种模式下，Data Pump无法在本地磁盘上为每个并行进程创建稳定的、可用于恢复的检查点文件，因为没有这些中间状态文件，所以当任务中断后，系统无法知道每个并行进程具体进行到哪一步了,自然也就无法实现精确的重启。

当你遇到ORA-39025报错时，屏幕上通常会显示类似这样的信息：“ORA-39025: String data type job restart is not supported.” 这其实是Oracle在明确告诉你：你这个任务的工作方式决定了它无法被重启。

遇到这个问题应该如何修复呢？既然根本原因是PARALLEL和NETWORK_LINK的组合，解决方案就需要从调整参数入手,以下是基于故障排除实践的具体步骤：

1. 放弃重启，重新运行任务（最直接的方法）：既然重启功能不可用，最稳妥的办法就是放弃当前失败的任务，然后重新启动一个全新的任务，在重新运行之前，务必先解决导致任务最初失败的根本问题（确保目标数据库有足够的表空间，网络连接稳定等），使用相同的参数文件重新执行impdp或expdp命令，缺点是如果数据量巨大,这会耗费和第一次相同的时间。

2. 移除非法的参数组合（根本的解决方法）：如果你希望未来的任务具备可重启的能力，就应该避免在使用了NETWORK_LINK参数的场景下同时使用PARALLEL参数，修改你的参数文件（parfile），将PARALLEL参数移除，或者将其值设为1，这样，Data Pump会以单进程模式通过数据库链接传输数据，虽然速度可能会变慢，但Oracle此时可以为这个单一线程的任务创建检查点，从而使任务在中断后能够被重启，这是一个在“速度”和“可恢复性”之间的权衡。

3. 改变操作模式（替代方案）：如果既需要并行处理的速度，又希望任务可重启，可以考虑改变操作流程,一个可行的办法是将操作拆分成两步：

   • 第一步：在不使用NETWORK_LINK的情况下，先用expdp命令（可以启用PARALLEL）将源数据库的数据高速导出到磁盘上的转储文件（dump file）中，因为数据落地到了文件,这个导出任务是支持重启的。
   • 第二步：再使用impdp命令（同样可以启用PARALLEL）将磁盘上的转储文件导入到目标数据库，这个导入任务也是支持重启的。 这种方法虽然多了一个步骤，并且需要额外的磁盘空间来存放转储文件，但它结合了并行处理的高效和Data Pump任务的可重启性,是处理大数据量迁移时的一个可靠策略。

ORA-39025不是一个需要“修复”的底层故障，而是一个由不支持的参数用法引发的“提醒”，解决它的关键不在于高深的数据库调试，而在于正确理解Data Pump各种参数之间的依赖和限制，并根据你的实际需求（是追求速度还是追求可恢复性）来选择合适的操作参数或操作流程，当这个错误出现时，你最应该做的就是检查你的命令行或参数文件，看是否同时包含了PARALLEL和NETWORK_LINK,然后从上述的解决方案中选择最适合当前情况的一种来执行。