ORA-39084报错导致作业无法分离，远程帮忙修复中

（来源：根据用户提供的报错场景及常见Oracle数据泵问题综合描述）

客户那边突然打来电话,语气非常着急，说他们的数据库迁移作业卡住了，屏幕上显示一个红色的错误代码“ORA-39084”，后面还跟着一串描述，大概意思是“作业正在运行，无法分离”，他们试了几次手动去断开连接，但每次都会弹出这个错误，作业就像黏在了服务器上一样，甩也甩不掉，整个迁移流程因此停滞不前，后续的测试和系统上线计划眼看就要被耽误。

我一边安抚客户情绪,让他别慌，一边立刻通过远程工具连接到了他们的服务器，这种情况我以前处理过几次，知道问题出在哪里，ORA-39084这个错误，说白了，并不是说数据泵导出或导入本身出了什么技术故障，而是一个“状态”问题，想象一下，就像一个工人正在车间里埋头干活，你突然从外面想把门锁上，他肯定会从里面顶住门不让你锁，数据泵作业就是这个工人，而客户尝试的分离操作就是想锁门。

（来源：Oracle官方文档对数据泵交互式模式及ATTACH参数的解释）

数据泵工具设计了一个交互式的模式,当你启动一个数据泵任务（比如叫expdp或impdp）时，这个任务会在数据库内部以后台作业的形式运行，你启动它的那个客户端会话，就相当于一个“控制台”或者“监控面板”，只要这个控制台会话还连着，你就能随时敲入命令，查看进度，甚至暂停、继续它，ORA-39084报错的根本原因，就是这个作为“控制台”的会话因为某种原因异常退出了，或者像客户这样，网络波动、客户端工具崩溃，导致连接非正常中断，但关键在于，后台的作业本身并没有停止，它还在兢兢业业地工作，这时候，你重新打开一个客户端，想用attach参数去重新连接（也就是“分离”前一个失效的连接并接管这个作业），系统就会报错，因为它检测到那个原始的、已经“僵死”的会话在理论上还存在着，它认为“这个作业已经有主了”，所以拒绝你新的连接请求。

修复的核心思路很明确：我们必须先彻底清理掉那个已经失效的、占着茅坑不拉屎的旧会话，然后才能建立新的连接，这需要直接到数据库的内部去操作，而不是在数据泵的命令行层面折腾。

（来源：实际运维中处理僵尸会话的常用SQL语句）

我让客户打开一个能连接到目标数据库的SQL*Plus窗口或者他们常用的数据库图形化管理工具，我告诉他，接下来要执行的命令可能会有点“猛”，但这是解决问题的标准做法，让他放心，我需要找到那个捣乱的“僵尸”会话，我让他输入了一条查询语句，这条语句是去查看数据库里所有当前活跃的会话，并筛选出那些正在执行数据泵相关操作的会话，通过查看程序名或者模块信息，我们很快就锁定了一个或多个状态为“INACTIVE”（非活跃）但确实属于数据泵的会话，记下了它们的SID（会话ID）和SERIAL#（序列号），这些会话就是问题的根源——它们虽然已经不响应任何指令了，但数据库还没有来得及完全回收它们占用的资源，尤其是对数据泵作业的“所有权”。

找到目标后,最关键的一步来了：强制终止这些会话，我指导客户使用ALTER SYSTEM KILL SESSION命令，后面跟上刚才查到的SID和SERIAL#，这个命令就像是数据库管理员的“尚方宝剑”，可以直接告诉数据库：“这个会话已经没用了，立刻清理掉。” 客户小心翼翼地输入命令，按下回车，屏幕上显示“系统已更改”，这意味着清理成功了。

为了确保万无一失,我让他再次运行了之前查找会话的查询语句，果然，刚才那几个碍眼的会话已经消失了，数据库里运行的数据泵作业变成了一个“孤儿”作业——它还在运行，但已经没有哪个客户端会话声称拥有它了。

（来源：数据泵重新附加作业的标准操作流程）

这时,我让客户回到命令行，再次启动数据泵客户端，但这次使用的命令不一样了，不再是重新开始一个作业，而是使用attach参数，后面跟上他们原来那个作业的名字，命令格式大概是：expdp username/password ATTACH=job_name，客户输入命令后，稍微停顿了一下，然后命令行提示符顺利进入了数据泵的交互模式！屏幕上显示出了作业的当前状态：正在运行，已经完成了百分之多少，当前在处理哪个表……一切信息都恢复了正常，这意味着我们成功重新接管了这个作业。

客户看到这里,长长地舒了一口气，连声道谢，我告诉他，现在可以放心地让作业继续运行，也可以通过正常的stop_job命令先暂停一下看看情况，或者直接输入continue_client让它继续，最重要的是，现在控制权已经夺回来了，我还提醒他，为了避免以后再出现类似问题，尤其是在进行长时间作业时，最好让启动数据泵的那个客户端会话保持稳定，不要轻易关闭，如果条件允许，可以考虑使用参数将日志输出到文件，这样即使控制台会话断开，也能通过日志文件了解进度，并且重新连接时会更加从容。

整个远程协助过程大约花了二十多分钟,主要时间花在了解情况、查找会话和确认结果上，问题解决后，客户的迁移作业得以继续，没有造成更大的延误。