当资源繁忙时发生此错误。检查查询中是否有任何引用约束。甚至您在查询中提到的表也可能处于繁忙状态。他们可能正在从事其他工作，这些工作肯定会在以下查询结果中列出:

SELECT * FROM V$SESSION WHERE STATUS = 'ACTIVE'

找到SID，

SELECT * FROM V$OPEN_CURSOR WHERE SID = --the id

当用于修改表的会话以外的会话持有锁时，就会发生这种情况，可能是因为DML(更新/删除/插入)。如果您正在开发一个新系统，您或您的团队中的某个人很可能会发出更新语句，您可能会在没有太大后果的情况下终止会话。或者，一旦知道谁打开了会话，就可以从该会话提交。

如果您可以访问SQL管理系统，请使用它来查找违规会话。也许还会杀死它。

你可以使用v$session和v$lock等，但我建议你谷歌如何找到该会话，然后如何杀死它。

在生产系统中，这确实取决于情况。对于oracle 10g或更老的版本，您可以执行

LOCK TABLE mytable in exclusive mode;
alter table mytable modify mycolumn varchar2(5);

在一个单独的会议，但准备好以下，以防太长时间。

alter system kill session '....

这取决于你使用的是什么系统，旧的系统更有可能每次都不提交。这是一个问题，因为可能会有长时间的锁。因此，您的锁将阻止任何新的锁，并等待一个不知道何时释放的锁。这就是为什么你准备了另一个声明。或者你也可以寻找可以自动完成类似任务的PLSQL脚本。

在版本11g中，有一个新的环境变量用于设置等待时间。我认为它可能与我所描述的类似。请注意，锁定问题不会消失。

ALTER SYSTEM SET ddl_lock_timeout=20;
alter table mytable modify mycolumn varchar2(5);

最后，最好等到系统中用户较少时再进行这种维护。

Shashi的链接给出的解决方案是最好的…不需要联系dba或其他人

备份

create table xxxx_backup as select * from xxxx;

删除所有行

delete from xxxx;
commit;

插入备份。

insert into xxxx (select * from xxxx_backup);
commit;

我也面临着类似的问题。程序员不需要做任何事情来解决这个错误。我通知了我的oracle DBA团队。他们扼杀了会议，并像一个魅力。

只需检查持有会话的进程并杀死它。一切恢复正常。

在SQL下面可以找到您的流程

SELECT s.inst_id,
   s.sid,
   s.serial#,
   p.spid,
   s.username,
   s.program FROM   gv$session s
   JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id;

然后杀死它

ALTER SYSTEM KILL SESSION 'sid,serial#'

OR

我在网上找到的一些例子似乎也需要实例id 删除系统会话:

请关闭Oracle会话

使用下面的查询来检查活动会话信息

SELECT
    O.OBJECT_NAME,
    S.SID,
    S.SERIAL#,
    P.SPID,
    S.PROGRAM,
    SQ.SQL_FULLTEXT,
    S.LOGON_TIME
FROM
    V$LOCKED_OBJECT L,
    DBA_OBJECTS O,
    V$SESSION S,
    V$PROCESS P,
    V$SQL SQ
WHERE
    L.OBJECT_ID = O.OBJECT_ID
    AND L.SESSION_ID = S.SID
    AND S.PADDR = P.ADDR
    AND S.SQL_ADDRESS = SQ.ADDRESS;

杀死像

alter system kill session 'SID,SERIAL#';

(例如，alter system kill session '13,36543';)

参考 http://abeytom.blogspot.com/2012/08/finding-and-fixing-ora-00054-resource.html