ORA-00054：资源正忙并且正在使用指定的NOWAIT进行获取，或者超时已过期

为什么更新表时出现此数据库错误？

第1行发生错误：ORA-00054：资源繁忙，并且指定了NOWAIT进行获取或超时已过期

您的表已被某些查询锁定。例如，您可能已执行“选择更新”，但尚未提交/回滚并触发了另一个选择查询。在执行查询之前执行提交/回滚。

从这里 ORA-00054：资源繁忙，并且使用NOWAIT指定获取

您还可以查找sql​​，用户名，机器，端口信息，并获得包含连接的实际进程

SELECT O.OBJECT_NAME, S.SID, S.SERIAL#, P.SPID, S.PROGRAM,S.USERNAME,
S.MACHINE,S.PORT , S.LOGON_TIME,SQ.SQL_FULLTEXT 
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;

请杀死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

有一个非常容易的解决此问题的方法。

如果您在会话上运行10046跟踪（对此进行了Google搜索...太多无法解释）。您将看到，在执行任何DDL操作之前，Oracle会执行以下操作：

锁定表“ TABLE_NAME”无需等待

因此，如果另一个会话具有未完成的事务，则会出现错误。所以解决方法是...请打鼓。在DDL之前发出自己的锁，并忽略“ NO WAIT”。

特别说明：

如果您要分割/删除分区，oracle只会锁定分区。-这样您就可以锁定分区子分区了。

所以...以下步骤解决了该问题。

1. 锁定表“表名”；-您将“等待”（开发人员称此为挂起）。直到与未完成交易的会话提交。这是一个队列。因此，您可能要提前几个会议。但您不会出错。
2. 执行DDL。然后，您的DDL将使用NO WAIT进行锁定。但是，您的会话已获取锁定。所以你很好。
3. DDL自动提交。这将释放锁。

当表被锁定时，DML语句将“等待”或被开发人员称为“挂起”。

我在从作业运行以删除分区的代码中使用此代码。它工作正常。它在一个数据库中，它以每秒几百次插入的速度不断插入。没有错误。

如果您想知道。用11g做。我以前也曾在10g中做到这一点。

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

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

找到SID，

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

当除用于更改表的会话以外的其他会话可能由于DML（更新/删除/插入）而持有锁时，会发生这种情况。如果您正在开发新系统，则您或团队中的某人可能会发布更新声明，并且您可能会在没有太大后果的情况下终止会话。或者，一旦知道谁打开了会话，就可以从该会话中提交。

如果您有权访问SQL管理系统，请使用它来查找有问题的会话。也许杀死它。

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

在生产系统中，这确实取决于。对于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);

最后，最好等到系统中的用户很少进行此类维护。

就我而言，我非常确定这是我自己的会话中的一个被阻塞。因此，执行以下操作是安全的：

• 我发现有以下问题：

  SELECT * FROM V$SESSION WHERE OSUSER='my_local_username';

  该会话处于非活动状态，但仍以某种方式锁定了该锁。请注意，您可能需要根据情况使用其他WHERE条件（例如try USERNAME或MACHINEfield）。

• 使用ID和杀死SERIAL#了上面的会话：

  alter system kill session '<id>, <serial#>';

@thermz编辑：如果以前的打开会话查询均不起作用，请尝试执行此操作。此查询可以帮助您避免在终止会话时避免语法错误：

• SELECT 'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||''' immediate;' FROM V$SESSION WHERE OSUSER='my_local_username_on_OS'

只需检查举行会议的进程并杀死它即可。它恢复正常。

下面的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#'

要么

我在网上发现的一些示例似乎还需要实例ID以及更改系统终止会话“ 130,620，@ 1”；

您的问题看起来像是在混合DML和DDL操作。请参阅解释此问题的URL：

http://www.orafaq.com/forum/t/54714/2/

仅创建表时，我设法解决了该错误！显然，在尚不存在的表上没有争用问题。该CREATE TABLE语句包含一个CONSTRAINT fk_name FOREIGN KEY引用填充良好的表的子句。我不得不：

• 从CREATE TABLE语句中删除FOREIGN KEY子句
• 在FK列上创建一个INDEX
• 创建FK

当我运行2个脚本时，发生了此错误。我有：

• 使用模式用户帐户（帐户1）直接连接的SQL * Plus会话
• 另一个SQL * Plus会话使用不同的架构用户帐户（帐户2）连接，但通过数据库链接作为第一个帐户进行连接

我放了一张桌子，然后以帐户＃1的身份创建了表格。我在帐户＃2的会话上进行了表更新。没有提交更改。以帐户＃1重新运行表删除/创建脚本。在drop table x命令上出错。

我通过COMMIT;在帐户＃2的SQL * Plus会话中运行来解决此问题。

我也面临类似的问题。程序员无需执行任何操作即可解决此错误。我通知了我的Oracle DBA团队。他们扼杀了会议并像魅力一样工作。

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

进行备份

create table xxxx_backup as select * from xxxx;

删除所有行

delete from xxxx;
commit;

插入您的备份。

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