Oracle 锁等待一旦扩散，业务请求会很快排队。
用户看到的是请求变慢，开发看到的是 SQL 不返回，DBA 需要判断谁持有锁、谁在等待、事务持续了多久，以及当前能不能处理。
锁问题处理错对象，等待会继续扩大。
先别只看等待，先看它会不会继续扩散
Oracle 锁等待一旦扩散，业务请求会很快排队。
用户看到的是请求变慢，开发看到的是 SQL 不返回，DBA 需要判断谁持有锁、谁在等待、事务持续了多久，以及当前能不能处理。
锁问题处理错对象，等待还会继续扩大。真正要做的，不是只盯着排队的请求，而是先把阻塞链路看清楚。
锁等待背后是一条链路
一次 Oracle 锁等待通常涉及持锁会话和等待会话。
持锁会话先执行了更新或事务操作，拿到了目标资源；等待会话随后访问同一资源，被迫等待锁释放。
如果持锁事务迟迟不提交或回滚，等待会话会继续增加，业务影响也会扩大。
先找阻塞源，不要先处理等待会话
处理 Oracle 锁等待时，关键是先确认阻塞源。
终止等待会话通常只能释放一个排队者，后续请求仍可能继续等待；处理阻塞源可以释放锁，但也可能中断关键业务事务。
正确动作需要结合事务内容、持续时间、业务来源和影响范围判断。
真到操作时，可以这样问 ChatDBA
先登录 NineData 控制台。
在页面上方单击 ChatDBA。
选择出现锁等待的 Oracle 数据源，可以选中深度研究，让 ChatDBA 更充分地分析阻塞链路。
在对话框中输入锁诊断需求，并发送。
示例问题可以这样写：请诊断当前 Oracle 是否存在锁等待或死锁风险，找出阻塞源、被阻塞会话、涉及 SQL，并给出应急处理建议。
最后一句
Oracle 锁等待的风险在于扩散速度快。
ChatDBA 可以帮助团队找到阻塞源，判断影响范围，并把应急处理和长期治理建议放在同一条排障路径里。