ora-00054是ddl操作因等待对象排他锁超时而报错，并非死锁；需通过v$lock与v$session定位持锁会话及sql，检查未提交事务，优先联系业务方处理，必要时用immediate强制终止。
ORA-00054 是锁等待超时，不是死锁
ORA-00054 报错本质是 ALTER TABLE、DROP INDEX、TRUNCATE 等 DDL 操作在获取对象排他锁（X 锁）时，等待时间超过 ddl_lock_timeout（默认 0，即不等待），或显式设置了超时但未等到锁释放。它和死锁（ORA-00060）完全不同——这里没有循环等待，只有“别人占着资源，我等不及了”。
排查重点不是找谁“卡死了”，而是定位：谁正在持有目标对象的锁？它在执行什么 SQL？是否长时间未提交？
查谁在持锁：用 v$lock + v$session 定位阻塞源头
运行以下查询，把 OBJECT_NAME 替换为你 DDL 失败时操作的对象名（比如 'EMPLOYEES'）：
SELECT s.sid, s.serial#, s.username, s.osuser, s.machine, s.program,
l.type, l.lmode, l.request, o.object_name, s.sql_id
FROM v$lock l
JOIN v$session s ON l.sid = s.sid
LEFT JOIN dba_objects o ON l.id1 = o.object_id
WHERE l.type IN ('TM', 'TX')
AND o.object_name = 'EMPLOYEES';
关键看字段：
-
lmode > 0表示已持有锁；常见 TM 锁的lmode=6即排他锁（X），说明该会话正对表做 DML 或未提交事务 -
request > 0表示当前正在申请锁但被阻塞（这是你的会话） -
s.sql_id可关联v$sql查原始语句：SELECT sql_text FROM v$sql WHERE sql_id = 'xxx'
查事务状态：确认是不是没提交的 UPDATE/DELETE
持有 TM 锁却长期不释放，90% 是因为事务未提交。用下面语句快速筛查活跃事务：
SELECT s.sid, s.serial#, s.username, t.start_time, t.used_ublk, s.sql_id FROM v$transaction t JOIN v$session s ON t.ses_addr = s.saddr;
重点关注：
-
start_time很早（比如几小时以前）→ 极可能遗忘COMMIT或ROLLBACK -
used_ublk > 100→ 修改量大，更需谨慎处理 - 若
s.sql_id对应的是UPDATE或DELETE，基本可锁定问题
注意：不要直接 ALTER SYSTEM KILL SESSION，先尝试联系业务方确认能否提交/回滚；如确需强制结束，加上 IMMEDIATE 参数：ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE。
避免重复踩坑：DDL 前加锁检查 + 超时控制
生产环境执行 DDL 前，建议养成两个习惯：
- 用上面的
v$lock查询确认目标对象无活跃 TM 锁（尤其lmode=6） - 显式设置锁等待上限，避免无限挂起：
ALTER SESSION SET ddl_lock_timeout = 30;（单位秒） - 对大表
TRUNCATE或ADD COLUMN ... DEFAULT，优先考虑分批操作或业务低峰期执行
真正棘手的情况往往不是锁本身，而是持有锁的会话早已断连（比如应用异常退出但连接未释放），此时 v$session.status = 'INACTIVE' 且 sql_id 为空——这种会话只能靠 DBA 主动清理，别指望它自己释放。
