ORA-00054: resource busy and acquire with NOWAIT specified

本地有错误如下：

SQL> select * from sss for update nowait;

select * from sss for update nowait

ORA-00054: resource busy and acquire with NOWAIT specified

SQL>

看了一下，是另有人打开没有关。kill

参考几个url如下：

http://space.itpub.net/12778571/viewspace-561543

当某个数据库[/u]用户在数据库中插入、更新、删除一个表的数据，或者增加一个表的主键时或者表的索引时，常常会出现ora-00054:resource
busy and acquire with nowait specified这样的错误。
主要是因为有事务正在执行（或者事务已经被锁），所有导致执行不成功。
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查看具体的[b]sql[/u]语句，如果sql不重要，可以kill[/b]
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';
4、这样就可以执行其他的事务sql语句了
如增加表的主键：

alter table test

add constraint PK_test primary key (test_NO)；

http://ysping.itpub.net/post/40024/489114

今天在做同步时，出现如下错误：
ORA-00054 resource busy and acquire with NOWAIT specified

”资源正忙，需指定nowait"

出现这个问题的原因是正在执行的操作请求的资源正被其他事务锁定。
nowait：立即执行，如果另有会话正在修改该记录会立即报告错误：ORA-00054: 资源正忙，要求指定 NOWAIT；如果不选择nowait选项则会一直处理等待状态。

wait
：等待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#为第一步查出来的数据。

http://www.dbasky.com/oracle/ora-00054-resource-busy-and-acquire-with-nowait-specified.html

深度解析ORA-00054: resource
busy and acquire with NOWAIT specified

应该很多同学都碰到过ora-0054 error, 但你认真研究过它吗？很多同学会想当然的认为，要访问的资源（表或者索引或者其他）被锁了呗，这有什么好研究的？也不能说你错，但是具体情况你都了然了么？

先来研究下这个错误的字面意思

ORA-00054: resource busy and acquire with NOWAIT specified

资源忙需要指定NOWAIT??那你在你报错的语句后加上NOWAIT成功了吗? 恐怕不能
首先来看什么情况下会报这个错误：

第一个可能的原因是在lock table 和select for update 的句子中有nowait关键字导致报错。nowait关键字的意思是当你要锁定某一资源时，如果该资源正被别的用户锁定则直接返回错误信息，而不是等待别的用户解锁。来个例子

session 1 update test table without commit or rollback;

1 2	SQL> update test set a=3 where a=2; 1 row updated.

session 2 执行select * from test for update 那么session 2这个时候会hang住等待session 1 释放行上的排他锁

而如果你执行select * from test for update nowait;那么这个时候会直接报错退出而不是等待session1 释放排他锁

1 23 4 5

SQL> select * from test for update nowait; select * from test for update nowait * ERROR at line 1: ORA-00054: resource busy and acquire with NOWAIT specified

第二个原因是你执行了ddl语句并且这个ddl 无法获得需要的锁

继续上面的例子，session 1 执行了update 语句。你在session 2 想要truncate 这个table

1 23 4 5

SQL> truncate table test; truncate table test * ERROR at line 1: ORA-00054: resource busy and acquire with NOWAIT specified

这个时候的错误提示有点歧义，因为对于ddl 来说你不可能显式的指定nowait 关键字，ddl的nowait是隐式的（直到10g,11g不太清楚行不行）。

那么碰到这个错误该怎么处理呢？

一般来说不需要特别处理。不过下面一些思路或许对你有用

对于11g,有一个新特性可能会有助于解决这个问题.就是使用ddl_lock_timeout这个参数来指定你愿意等待的时间

1 23 4

SQL> alter session set ddl_lock_timeout = 600; Session altered. SQL> alter table test add (b varchar2(10)); Table altered.

对于10g和之前的版本,你可以尝试使用Jonathan Lewis提供的一段脚本，我没有用过，不知道效果怎么样

1 23 4 5 6 7 8 9 10 11

begin while true loop begin execute immediate m_sql; exit; exception when in_use then null; end; dbms_lock.sleep(0.01); end loop; end;

对于9i之后的版本可以考虑使用在线重定义dbms_redefinition package

oracle在note: 18245.1 中也给出了一些参考思路

1 23 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

- None normally required unless this is occurring when not expected. - Check v$lock for locks being held. - For DDL repeat the command. If the DDL is issued under DBMS_SQL it is possible to cause this error if the DDL touches an object related to the current PL/SQL block by some dependency. - For SELECT FOR UPDATE issue the same statement without the NOWAIT clause to see if the statement blocks (assuming the problem is reproducible). If it blocks check there is a blocker in v$lock, Eg: select * from v$lock where request!=0; -- To find the blocked process. select * from v$lock where type='TX' and id1='&1' and id2='&2' -- where &1 and &2 are the ID for the lock we are waiting on from above. Is this Oracle7 version prior to 7.1.6? If so are the foreign key columns indexed or not? (If not, DML on child table will take out table locks on parent, preventing DML on parent.) If this is Oracle7 V7.1.6+, are locks being taken out on a child table when doing deletes on the parent? If so, indexing the foreign key column on the child table will stop this happening. Is there a select ... for update, joining two tables together? If so this will lock both parent and child rows. If you only wish to lock e.g. child rows, specify: for update OF COLUMN_ON_CHILD_TABLE

基本来说，如果你的优先级比较高，并且其他影响你的session可以被干掉，那么就好办了。查出那些影响你的session然后kill之