ORA-00054: recurso ocupado y adquirir con NOWAIT especificado o tiempo de espera expirado

Desde aquí ORA-00054: recurso ocupado y adquirir con NOWAIT especificado

También puede buscar la información sql,nombre de usuario,máquina, puerto y llegar al proceso real que contiene la conexión

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;

Por favor, Mata a Oracle Session

Use la siguiente consulta para verificar la información de la sesión activa

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;

Matar como

alter system kill session 'SID,SERIAL#';

(Por ejemplo, alter system kill session '13,36543';)

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

Hay un trabajo muy fácil para este problema.

Si ejecuta un seguimiento 10046 en su sesión (busque en Google esto... demasiado para explicar). Verá que antes de cualquier operación DDL Oracle hace lo siguiente:

BLOQUEAR LA TABLA 'NOMBRE_DE_TABLA' SIN ESPERAR

Entonces, si otra sesión tiene una transacción abierta, se obtiene un error. Así que la solución es... redoble de tambores por favor. Emitir su propio bloqueo antes de la DDL y dejar de lado el 'NO ESPERAR'.

Nota especial:

Si usted está haciendo dividir / soltar particiones oracle solo bloquea la partición. -- así que puedes bloquear la subpartición de la partición.

So... Los siguientes pasos solucionan el problema.

1. LOCK TABLE 'TABLE NAME'; will 'wait' (los desarrolladores llaman a esto colgando). hasta la sesión con la transacción abierta, commits. Esto es una cola. así que puede haber varias sesiones por delante de usted. pero no te equivocarás.
2. Ejecutar DDL. Su DDL ejecutará un bloqueo con el NO WAIT. Sin embargo, su session ha adquirido la cerradura. Así que eres bueno.
3. Auto-commits DDL. Esto libera las cerraduras.

Las instrucciones DML 'wait' o como lo llaman los desarrolladores 'hang' mientras la tabla está bloqueada.

Uso esto en código que se ejecuta desde un trabajo para soltar particiones. Funciona bien. Está en una base de datos que se inserta constantemente a una velocidad de varios cientos de inserciones / segundo. Sin errores.

Si te lo estás preguntando. Haciendo esto en 11g. He hecho esto en 10g antes también en el pasado.

Este error ocurre cuando el recurso está ocupado. Compruebe si tiene restricciones referenciales en la consulta. O incluso las tablas que ha mencionado en la consulta pueden estar ocupadas. Podrían estar comprometidos con algún otro trabajo que se enumerará definitivamente en los siguientes resultados de la consulta:

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

Encuentra el SID,

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

Esto sucede cuando una sesión distinta a la utilizada para alterar una tabla mantiene un bloqueo probablemente debido a un DML (update/delete/insert). Si está desarrollando un nuevo sistema, es probable que usted o alguien en su equipo emita la declaración de actualización y podría matar la sesión sin muchas consecuencias. O puede confirmar desde esa sesión una vez que sepa quién tiene la sesión abierta.

Si tiene acceso a un sistema de administración SQL, utilícelo para encontrar la sesión infractora. Y tal vez matar se.

Podría usar v session session y v lock lock y otros, pero le sugiero que busque en Google cómo encontrar esa sesión y luego cómo eliminarla.

En un sistema de producción, realmente depende. Para oracle 10g y versiones anteriores, puede ejecutar

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

En una sesión separada, pero tenga listo lo siguiente en caso de que tome demasiado tiempo.

alter system kill session '....

Depende de qué sistema tenga, los sistemas más antiguos son más propensos a no comprometerse cada vez. Eso es un problema ya que puede haber mucho tiempo cerraduras de pie. Por lo tanto, su cerradura evitaría cualquier cerradura nueva y esperaría una cerradura que quién sabe cuándo se liberará. Es por eso que tiene la otra declaración lista. O podría buscar scripts PLSQL que hagan cosas similares automáticamente.

En la versión 11g hay una nueva variable de entorno que establece un tiempo de espera. Creo que probablemente hace algo similar a lo que describí. Tenga en cuenta que los problemas de bloqueo no desaparecen.

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

Finalmente puede ser mejor esperar hasta que haya son pocos los usuarios en el sistema para hacer este tipo de mantenimiento.

Su problema parece que está mezclando operaciones DML y DDL. Vea esta URL que explica este problema:

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

Simplemente verifique si el proceso está sosteniendo la sesión y elimínelo. Ha vuelto a la normalidad.

A continuación SQL encontrará su proceso

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;

Entonces mátalo

ALTER SYSTEM KILL SESSION 'sid,serial#'

O

Un ejemplo que encontré en línea parece necesitar el id de instancia también alter system kill session '130,620,@1';

En mi caso, estaba bastante seguro de que era una de mis propias sesiones que estaba bloqueando. Por lo tanto, era seguro hacer lo siguiente:

• Encontré la sesión ofensiva con:

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

  La sesión estaba inactiva, pero todavía mantenía el bloqueo de alguna manera. Tenga en cuenta que es posible que necesite usar algún otro DONDE condición en su caso (por ejemplo, try USERNAME o MACHINE campos).

• Mató la sesión usando el ID y SERIAL# adquirido arriba:

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

Me las arreglé para golpear este error al crear simplemente una tabla! Obviamente no había ningún problema de contención en una mesa que aún no existía. La instrucción CREATE TABLE contenía una cláusula CONSTRAINT fk_name FOREIGN KEY que hacía referencia a una tabla bien poblada. Tuve que:

• Elimine la cláusula FOREIGN KEY de la instrucción CREATE TABLE
• Crear un ÍNDICE en la columna FK
• Crear el FK

Este error ocurrió cuando tenía 2 scripts que estaba ejecutando. Tenía:

• Una sesión SQL * Plus conectada directamente mediante una cuenta de usuario de esquema (cuenta #1)
• Otra sesión SQL*Plus conectada usando una cuenta de usuario de esquema diferente (cuenta #2), pero conectándose a través de un enlace de base de datos como la primera cuenta

Ejecuté una caída de tabla, luego la creación de la tabla como cuenta #1. Corrí una actualización de la tabla en la sesión de la cuenta # 2. No cometió cambios. Volver a ejecutar tabla de caída / creación script como cuenta # 1. Error en el comando drop table x.

Lo resolví ejecutando COMMIT; en la sesión SQL*Plus de la cuenta #2.

También me enfrento a un problema similar. Nada programador tiene que hacer para resolver este error. Informé a mi equipo de Oracle DBA. Matan la sesión y trabajaron como un encanto.

La solución dada por el enlace de Shashi es la mejor... no es necesario ponerse en contacto con dba o alguien más

Hacer una copia de seguridad

create table xxxx_backup as select * from xxxx;

Suprimir todas las filas

delete from xxxx;
commit;

Inserte su copia de seguridad.

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