解决锁的问题—-ORA-00054: resource busy and acquire with NOWAIT specified

 

天开发人员在做同步时,出现如下错误:

Fri Feb 15 23:57:15 2011
Errors in file /ora10/admin/crmiba/bdump/crmiba_j003_19872.trc:
ORA-00054: resource busy and acquire with NOWAIT specified

”资源正忙,需指定nowait"

出现这个问题的原因是正在执行的操作请求的资源正被其他事务锁定。

nowait:立即执行,如果另有会话正在修改该记录会立即报告错误:ORA-00054: 资源正忙,要求指定 NOWAIT;如果不选择nowait选项则会一直处理等待状态。
wait [n]:等待n秒,如果另有会话正在修改该记录会报告错误:ORA-30006: 资源已被占用; 执行操作时出现 WAIT 超时
=>另外,还有一个skip locked。
skip locked:跳过已被别的会话锁定的记录。

例如:

SELECT … FOR UPDATE [OF ...][NOWAIT | WAIT integer]

NOWAIT指在执行"SELECT … FOR UPDATE"时其他事务修改了该查寻的结果但还没有提交,此时将立即返回如下结果:
ORA-00054: resource busy and acquire with NOWAIT specified
如果不使用NOWAIT等项,默认为等待(WAIT)其他事务提交后在返回结果。

WAIT integer,与NOWAIT的功能相似,但可以等待用户指定的秒数。如:"WAIT 3"等待3秒后,其他事务还没有提交将返回如下结果:
ORA-30006: resource busy; acquire with WAIT timeout expired 。

出现这种问题后查V$LOCKED_OBJECT,要么等事务结束后再做,要么杀掉持有锁的会话(如果不是关键会话):

1.通过上句查找出已被锁定的数据库表及相关的sid、serial#及spid
select object_name as 对象名称,s.sid,s.serial#,p.spid as 系统进程号
from v$locked_object l , dba_objects o , v$session s , v$process p
where l.object_id=o.object_id and l.session_id=s.sid and s.paddr=p.addr;

2.在数据库中灭掉相关session
alter system kill session 'sid,serial#';–sid及serial#为第一步查出来的数据。

用如下的语句也可以:

1、用dba权限的用户查看数据库都有哪些锁

select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;

如:testuser 339 13545 2009-3-5 17:40:05
知道被锁的用户testuser,sid为339,serial#为13545

2、根据sid查看具体的sql语句,如果sql不重要,可以kill

select sql_text from v$session a,v$sqltext_with_newlines b
  where DECODE(a.sql_hash_value, 0, prev_hash_value, sql_hash_value)=b.hash_value
  and a.sid=&sid order by piece;

查出来的sql,如: begin :id := sys.dbms_transaction.local_transaction_id; end;

3、kill该事务
alter system kill session '339,13545';

### ORA-00054 错误解决方案 #### 1. **错误核心原因** ORA-00054 错误的根本原因是目标资源(如表、索引等)当前正在被其他会话占用,而尝试对该资源执行的操作指定了 `NOWAIT` 参数或默认行为不允许等待资源解[^4]。这意味着当一个事务持有时,另一个事务无法立即访问同一资源并触发此错误。 #### 2. **影响因素分析** 以下是可能导致该问题的具体场景: - 创建索引时会对底层数据施加共享,阻止某些类型的并发操作[^3]。 - DML 操作(如 INSERT、UPDATE 或 DELETE)可能会引发行级或表级定,从而阻碍后续的 DDL 请求。 - 如果在创建索引的过程中加入了 ONLINE 关键字,则仍可能存在特定条件下的定冲突。 #### 3. **解决策略** ##### 方案一:等待资源释放 最简单的方法之一就是让受影响的任务稍作延迟再试运行命令。这适用于那些短暂性的定情况——即一旦前序工作完成就会自动解除限制的情况[^4]。 ##### 方案二:查找并终止阻塞会话 通过查询系统视图定位具体哪个会话造成了干扰之后可以直接结束它以快速解决问题: ```sql -- 查询定对象的相关信息 SELECT t2.username, t2.sid, t2.serial#, t2.logon_time FROM v$locked_object t1, v$session t2 WHERE t1.session_id = t2.sid ORDER BY t2.logon_time; -- 获取指定 SID 的详细资料 SELECT sid, serial#, username, osuser, terminal, program, action, prev_exec_start FROM v$session WHERE sid = <your_blocked_session_sid>; -- 杀死有问题的会话 ALTER SYSTEM KILL SESSION '<sid>,<serial#>'; ``` 需要注意的是,在极端情况下即使已经发出杀死信号但仍看到残留状态标记为 "KILLED" 的进程未能及时清理干净的话,还可以进一步深入操作系统层面强制关闭相应后台线程[^2]。 ##### 方案三:调整应用逻辑规避竞争状况 长期来看更稳健的做法是从程序设计角度出发尽量减少不必要的争用现象发生几率。比如合理安排任务调度顺序;充分利用乐观机制代替悲观等等措施都可以显著改善此类异常发生的频率[^4]。 --- ### 总结 综上所述,面对 ORA-00054 这样的挑战可以从多个维度入手加以克服。无论是耐心等候自然解封还是主动干预消除障碍物乃至从根本上优化业务流程都能有效地缓解甚至杜绝同类事件再次上演的机会。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值