ORA-00060是Oracle检测到循环等待型死锁后主动回滚牺牲者事务的错误，非锁等待超时；需通过trace文件分析Deadlock graph定位行级锁冲突，而非查v$locked_object，因锁已在报错瞬间释放。
ora-00060 是 oracle 检测到死锁后主动回滚其中一个事务的错误，不是锁等待超时，也不是普通阻塞——它意味着两个或多个会话互相持有对方需要的资源，且都在等对方释放，系统无法靠等待解决，只能强制中断一个。
ORA-00060 为什么不是“锁没释放”而是“互相卡住”
很多人看到 ORA-00060 就去查 v$locked_object，结果发现“没几个锁”，误以为是监控遗漏。其实 ORA-00060 触发时，死锁已解除（被 Oracle 自动处理），相关锁在报错瞬间就被释放了。真正该看的是 trace 文件（默认在 user_dump_dest 目录下），里面会明确记录：谁持有什么锁、请求什么锁、另一个会话又持有什么锁、请求什么锁。
- 死锁必须满足四个条件：互斥、占有并等待、不可剥夺、循环等待；Oracle 只检测最后一条（循环等待）
-
DBA_WAITERS视图在死锁发生后通常为空，因为 Oracle 已清理现场；v$session_wait中对应会话状态可能为enq: TX - row lock contention，但这是锁争用，不等于死锁 - 应用层捕获到 ORA-00060 后，应重试事务，而不是试图“kill session”——此时 session 已回滚退出
哪些 DML 操作最容易触发 ORA-00060
死锁高发场景集中在“非主键/非索引列更新 + 多表关联顺序不一致”上。Oracle 行级锁本身不保证加锁顺序，实际加锁顺序取决于执行计划访问数据块的物理顺序。
- UPDATE 涉及未索引外键列：比如
UPDATE orders SET status = 'S' WHERE cust_id = 123，而cust_id无索引，Oracle 可能全表扫描并按块顺序加锁；另一会话执行UPDATE customers SET name = 'X' WHERE id = 123，再更新关联的orders，就可能形成反向加锁链 - 同一事务中 UPDATE 多张表，但不同会话对表的更新顺序不同：会话 A 先
UPDATE t1再UPDATE t2，会话 B 反过来，极易死锁 - 使用
SELECT ... FOR UPDATE但未按主键/唯一键顺序排序：例如SELECT * FROM accounts WHERE balance ，返回行序不确定，两个会话锁定的行物理顺序可能交叉
如何用行级锁机制规避 ORA-00060 而不是硬扛
关键不是“怎么锁得更细”，而是“让所有会话以相同逻辑顺序获取锁”。Oracle 的行级锁粒度已经足够细，问题出在无序竞争。
- 对外键列强制建立索引：不只是性能考虑，更是避免子表全表扫描式加锁，
CREATE INDEX idx_orders_custid ON orders(cust_id) - UPDATE / DELETE 语句必须带确定性排序：例如
SELECT ROWID FROM accounts WHERE ... ORDER BY id FOR UPDATE，再按此 ROWID 顺序更新，确保所有会话加锁顺序一致 - 批量操作拆分为小事务：避免单个事务跨多张表长时间持锁；用
FOR UPDATE SKIP LOCKED处理队列类场景，跳过已被锁的行而非等待 - 应用层统一加锁顺序：定义业务规则，如“所有涉及订单和客户的操作，先锁客户，再锁订单”，并在代码中强制执行
别依赖 ALTER SYSTEM KILL SESSION 解 ORA-00060
ORA-00060 报错后，出问题的会话已经终止，v$session 中对应 SID 状态通常是 INACTIVE 或已消失。此时执行 ALTER SYSTEM KILL SESSION 不仅无效，还可能误杀其他正常会话。
- 真正该做的是：检查 alert.log 找到 trace 文件名，打开它确认死锁路径；然后回溯应用日志，定位哪两个业务操作并发执行时路径冲突
- 如果频繁出现 ORA-00060，说明业务逻辑存在固有竞争，必须重构加锁策略，而不是调大
deadlock_timeout（Oracle 没这参数）或增加重试次数 - 注意：
v$lock中的TYPE='TX'是事务锁，不是死锁标志；死锁信息只存在于 trace 和 alert.log 中
最常被忽略的一点：ORA-00060 的根因几乎从不在数据库配置或硬件层面，而在应用发起的 SQL 顺序、索引缺失、事务边界设计这三者交叉处。查 trace 文件比翻监控视图快十倍，而修复一个外键索引，往往比写十个重试逻辑更治本。
