ORA-00037报错搞不定？服务器组切换问题远程帮你快速解决

ORA-00037这个错误，说实话，我第一次遇到的时候也懵了，那是在一个深夜，客户的财务系统突然卡死，应用日志里全是这个报错，用户急得团团转，电话一个接一个，屏幕上冰冷的“ORA-00037: session switched to another kill session, cannot switch back”字样，背后是可能无法按时完成的月度结算，我当时想，这玩意儿听起来就很拗口，什么“会话切换到另一个终止会话”,简直像绕口令。

（根据Oracle官方文档和大量DBA实践经验）这个错误的本质，就是一场“套娃”式的误杀，想象一下，你是一个系统管理员（会话A），你发现有一个用户会话（会话B）像疯了一样占用大量资源，把数据库拖慢了，你的第一反应可能就是“干掉它”！于是你发出了终止会话B的命令，但问题在于，会话B可能也不是“善茬”，它自己当时可能也正在执行一个操作，比如它也在尝试终止另一个有问题的会话（会话C）。

这下就乱套了，数据库内核在处理你的命令时发现：哎？你要杀掉的这个会话B，它自己就是个“杀手”（持有'enqueue'锁），如果直接让你（会话A）把杀手B干掉了，那杀手B原本要杀的那个目标C怎么办？这个“杀人”的上下文就丢失了，可能会留下烂摊子，为了保护数据库的一致性，Oracle系统做了一个决定：它临时把“处决”会话B的权力从你（会话A）手里，转移给了另一个专门处理这种复杂情况的系统内部会话（我们称之为SYS内部会话）。

这个时候，你就失去了对会话B的控制权，如果你不死心，再次对同一个会话B发出杀死命令，数据库就会毫不客气地给你抛出ORA-00037错误，它的潜台词是：“兄弟，这个犯人已经移交上级处理了，你别再插手了，等着就行。”

关键就在于“等着就行”，大多数情况下，那个接手的SYS内部会话会很快完成清理工作，包括终止会话B以及它可能锁住的资源，这个过程可能需要几秒到几分钟，你需要做的就是耐心等待那个内部会话完成它的任务，而不是反复重试KILL SESSION命令，那只会看到更多的ORA-00037。

（根据一些资深Oracle ACE的博客分享）具体怎么等？等的时候干什么？

立刻停止所有尝试杀死该会话的操作，你越杀,错误越多。

去查看数据库的警报日志（alert log），这是Oracle的“黑匣子”，它会记录最核心的系统事件，当发生会话移交和终止时，警报日志里通常会有更详细的跟踪信息，告诉你内部会话正在做什么，通过看警报日志,你能确认清理是否真的在进行中。

你可以查询动态性能视图，比如V$SESSION，看看那个该死的会话B的状态是不是变成了KILLED、MARKED FOR KILL，或者干脆已经消失了，如果它还在，但状态是KILLED却迟迟不释放资源，这可能意味着遇到了更棘手的问题，比如事务回滚缓慢或者存在网络I/O等待。

如果等待了很长时间（比如超过十分钟）问题依旧，会话B像僵尸一样僵在那里，那就需要进一步排查了。（参考Oracle Support官方知识库文档）这时候，可能就不是简单的KILL SESSION能解决的了，在某些极端情况下，可能需要重启数据库实例才能强制释放所有资源，但这绝对是最后的手段,因为重启意味着服务中断。

后来，在那个深夜的故障处理中，我就是这么做的，我安抚了客户的情绪，告诉他们需要等待系统自动清理，然后我盯着警报日志，大概过了两三分钟，日志里出现了目标会话被成功清除的记录，再查询V$SESSION，那个捣乱的会话果然不见了，应用连接自动恢复，系统速度回归正常，一个看似复杂的报错，其实解决方法的核心就是“耐心”和“正确的观察”，下次再碰到ORA-00037，别慌，先别急着反复操作，给它一点时间,也给你自己一点时间去看清问题的全貌。