应该很多同学都碰到过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 2 3 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 2 3 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 2 3 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 2 3 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 2 3 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之