ORA-31442锁等待超时了，数据库卡住了咋整远程帮你解决

ORA-31442锁等待超时了，数据库卡住了咋整远程帮你解决 来源：根据多位DBA的实战经验总结和Oracle官方支持文档中的故障排查思路，结合常见的锁等待场景编写）

碰到ORA-31442错误，弹出来说锁等待超时了，整个数据库操作都卡住不动了，这种感觉确实很让人头疼，别慌，这个问题虽然听起来专业，但我们可以用一些相对直接的方法来尝试解决，就算你是远程连接过去处理，也能一步步来，下面我就把常见的排查和解决思路给你捋一捋，咱们不用那些绕口的专业术语，就用人话讲清楚。

你得明白这个错误是啥意思,简单说，就是你想去操作某个数据（比如改一条记录），但那个数据已经被另一个会话（可以理解成另一个用户或者另一个程序连接）给“锁”住了，就像一扇门被别人从里面反锁了，你在外面干等着，等了好久（超过了数据库设定的超时时间）还没轮到你，数据库就不耐烦了，抛出这个错误告诉你“别等了，等不到了”，核心问题就是找到“谁”锁住了资源，以及“为什么”它迟迟不释放。

第一步：先别急着动手，看看现场情况

当错误发生,应用卡住的时候，千万别第一时间想着去重启数据库或者杀掉会话，那相当于出了问题就直接拉闸断电，可能会丢数据，是最不得已的办法，我们应该先像侦探一样，收集一下现场的“线索”。

1. 搞清楚是哪个操作卡住了： 问问操作的同事或者自己回忆一下，是在执行什么样的SQL语句时报错的？是在修改某张特定的表，还是在进行一个复杂的业务操作？这能帮你缩小排查范围。
2. 登录数据库服务器： 通过SQL*Plus或者其他图形化工具（比如PL/SQL Developer）用有足够权限的账号（比如SYSTEM或者SYS）连上数据库。

第二步：找出“罪魁祸首”——那个占着茅坑不拉屎的会话

现在我们要在数据库内部找找看,到底是哪个会话持有锁，并且导致了阻塞，Oracle提供了一些动态性能视图（可以理解成数据库的“监控大屏”）来帮我们。

一个非常常用的查询是这样的（来源：Oracle DBA常用的故障排查脚本）：

SELECT l1.sid AS blocking_sid, s1.username AS blocking_user, s1.program AS blocking_program, s1.machine AS blocking_machine, l2.sid AS waiting_sid, s2.username AS waiting_user, s2.program AS waiting_program FROM v$lock l1, v$lock l2, v$session s1, v$session s2 WHERE l1.block = 1 AND l2.request > 0 AND l1.id1 = l2.id1 AND l1.id2 = l2.id2 AND l1.sid = s1.sid AND l2.sid = s2.sid;

这个查询的意思是从锁视图v$lock和会话视图v$session里，找出那些正在阻塞别人（l1.block = 1）的会话信息，以及被它阻塞的正在等待的会话信息（l2.request > 0），你运行一下，它会返回几列关键信息：

• blocking_sid, blocking_user, blocking_program, blocking_machine：这告诉你“肇事者”的会话ID、用户名、是哪个程序（比如一个Java应用服务器名）、是从哪台机器连过来的，这是最关键的信息！
• waiting_sid, waiting_user：这告诉你“受害者”是谁，通常报错的就是这个会话。

第三步：分析原因，区别对待

找到阻塞的会话后,不要立马就把它“杀掉”，先看看它到底在干嘛，为什么长时间不提交或回滚事务。

1. 查看阻塞会话在执行什么SQL： 用上一步查到的blocking_sid，执行下面的查询： SELECT sql_text FROM v$sqlarea a, v$session s WHERE s.sql_address = a.address AND s.sql_hash_value = a.hash_value AND s.sid = &blocking_sid; （把&blocking_sid换成实际的ID） 这能让你看到这个会话最后执行的一条SQL语句是什么，也许它正在做一个需要很长时间的更新操作，或者它本身就是一个没写好的慢查询。

   

2. 常见原因和应对：

   • 场景A：正常的长时间操作。 比如这个阻塞会话确实是在处理一个大批量的数据更新，需要运行几分钟甚至更久，这是合理的，这时候你需要做的就是等待，或者与应用团队沟通，看能否在业务低峰期执行这类操作，你还可以尝试联系持有锁的会话的用户，请他尽快完成操作并提交事务。
   • 场景B：异常挂起的会话。 这是最常见的情况，比如应用程序代码有BUG，开启了事务（比如UPDATE了数据）但没有正确提交（COMMIT）或回滚（ROLLBACK），导致锁一直占着，或者程序突然崩溃，网络断开，导致会话“僵死”在那里。这种情况下，这个会话通常已经不会做任何有用的事情了，是清理的主要目标。
   • 场景C：锁升级或设计缺陷。 有可能是因为业务逻辑设计有问题，导致多个会话以错误的顺序请求锁，形成了“死锁”或者长时间的锁等待，Oracle通常能自动检测并解决死锁，但复杂的锁等待链可能不会，这就需要对应用程序逻辑进行优化。

第四步：采取行动——温柔的沟通还是强制的清除

根据上一步的分析,我们来决定怎么做。

• 如果是场景A（正常操作）： 耐心等待或协调时间，你可以尝试让被阻塞的会话先取消当前操作（如果可能的话），等高峰期过后再试。
• 如果是场景B或C（异常会话）： 通常需要终止阻塞的会话。
  1. 先尝试温和的方式： 给那个会话的用户发个消息（如果用户还在线的话），在Oracle里可以这样做： EXEC DBMS_SYSTEM.KSDWRT(2, 'Hey, your session SID='||&blocking_sid||' is blocking others, please commit or rollback!'); 这会在服务器的日志和那个用户的客户端（如果使用SQL*Plus等工具）显示一条消息，也许用户看到了就会处理。
  2. 如果温和无效或用户已离线： 那就只能强制杀掉了，分两步：
     • 先查出阻塞会话的SERIAL#： SELECT sid, serial# FROM v$session WHERE sid = &blocking_sid;
     • 然后使用ALTER SYSTEM命令杀掉它： ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE; （把sid,serial#换成刚才查到的值） 注意： 杀掉会话会强制回滚该会话未提交的事务，如果它修改了大量数据，回滚过程可能会花费一些时间，并可能产生大量的redo日志，在此期间，锁可能仍然不会立即释放，需要稍等片刻。IMMEDIATE选项会让它更快一些。

第五步：事后反思与预防

问题解决后,别忘了想想怎么避免下次再发生。

• 优化应用程序： 这是根本，督促开发人员确保事务要尽可能短小精悍，操作完数据后立刻提交或回滚，避免在循环里做更新操作而不提交，检查是否有不必要的SELECT ... FOR UPDATE这样的悲观锁。
• 设置合理的超时时间： 在某些场景下，可以通过Oracle的参数或应用框架设置合理的锁等待超时时间，让应用在等待一段时间后自动放弃并重试，而不是一直傻等。
• 监控与告警： 可以部署一些监控脚本，定期检查数据库中是否存在长时间的锁等待，一旦发现就提前告警，防患于未然。

处理ORA-31442的核心流程就是：保持冷静 -> 登录系统 -> 查找阻塞源 -> 分析原因 -> 区别处理（沟通或清除）-> 总结预防，远程处理时，关键是能准确地获取到阻塞会话的信息，并谨慎地执行操作，希望这个流程能帮到你。