Respuestas:
Su tabla ya está bloqueada por alguna consulta. Por ejemplo, puede haber ejecutado "seleccionar para actualizar" y aún no haber confirmado / revertido y disparado otra consulta de selección. Haga un commit / rollback antes de ejecutar su consulta.
desde aquí ORA-00054: recurso ocupado y adquirir con NOWAIT especificado
También puede buscar la información de sql, nombre de usuario, máquina, puerto y acceder al proceso real que mantiene 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 la sesión de Oracle
Use la consulta a continuación 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
CONNECTy RESOURCE, pero no lo que sea que esto necesite, con la cuenta que tengo, y dice ORA-00942: table or view does not exist. No todos los que lean este hilo tendrán la SYScuenta.
alter system kill session '13,36543'se agota el tiempo de espera y la sesión no morirá. En ese caso, consulte: stackoverflow.com/a/24306610/587365
connection objecten pythonTengo algunos errores. Luego python scriptse cierra sin cerrar correctamente el connection object. Ahora recibo el error "LOCKWAIT" cuando intento dejar la tabla en otra sesión. Cuando lo intento kill sessionno tengo suficiente privilegio. ¿Qué más se puede hacer para deshacerse de esto?
Hay una solución muy fácil para este problema.
Si ejecuta una traza 10046 en su sesión (google esto ... demasiado para explicar). Verá que antes de cualquier operación DDL, Oracle hace lo siguiente:
LOCK TABLE 'TABLE_NAME' SIN ESPERA
Entonces, si otra sesión tiene una transacción abierta, obtendrá un error. Entonces la solución es ... tambor por favor. Emita su propio bloqueo antes del DDL y omita el 'NO ESPERE'.
Nota especial:
si está haciendo partición / caída de particiones, Oracle simplemente bloquea la partición. - para que puedas bloquear la subpartición de partición.
Entonces ... Los siguientes pasos solucionan el problema.
Las declaraciones DML 'esperarán' o como los desarrolladores lo llaman 'colgar' mientras la tabla está bloqueada.
Lo uso en el 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 preguntas Haciendo esto en 11g. He hecho esto en 10 g antes también en el pasado.
KILL SESSIONes la respuesta correcta para estas personas.
set_ddl_timeouty cuál debería ser?
ALTER SYSTEM SET ddl_lock_timeout=20;ver documentos
Este error ocurre cuando el recurso está ocupado. Compruebe si tiene alguna restricción referencial en la consulta. O incluso las tablas que ha mencionado en la consulta pueden estar ocupadas. Es posible que se comprometan 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 idORA-00942: table or view does not exist.
Esto sucede cuando una sesión distinta a la utilizada para alterar una tabla mantiene un bloqueo probablemente debido a un DML (actualizar / eliminar / insertar). Si está desarrollando un nuevo sistema, es probable que usted o alguien de su equipo emita la declaración de actualización y podría matar la sesión sin muchas consecuencias. O puede comprometerse 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, úselo para encontrar la sesión ofensiva. Y tal vez matarlo.
Puede usar v $ session y v $ lock y otros, pero le sugiero que busque en Google cómo encontrar esa sesión y luego cómo matarla.
En un sistema de producción, realmente depende. Para Oracle 10g y 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 tarde demasiado.
alter system kill session '....Depende de qué sistema tenga, es más probable que los sistemas más antiguos no se comprometan cada vez. Eso es un problema ya que puede haber bloqueos de larga data. Por lo tanto, su bloqueo evitará cualquier bloqueo nuevo y esperará un bloqueo que quién sabe cuándo se liberará. Es por eso que tiene lista la otra declaración. 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 haga 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 pocos usuarios en el sistema para realizar este tipo de mantenimiento.
alter system kill session '....si no tiene acceso a las vistas de administración?
En mi caso, estaba bastante seguro de que era una de mis 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 aún mantenía el bloqueo de alguna manera. Tenga en cuenta que es posible que necesite usar alguna otra condición WHERE en su caso (por ejemplo, try USERNAMEo MACHINEfields).
Eliminó la sesión usando IDy SERIAL#adquirió lo anterior:
alter system kill session '<id>, <serial#>';
Editado por @thermz: si ninguna de las consultas anteriores de sesión abierta funciona, prueba esta. Esta consulta puede ayudarlo a evitar errores de sintaxis al matar sesiones:
SELECT 'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||''' immediate;' FROM V$SESSION WHERE OSUSER='my_local_username_on_OS'Simplemente verifique el proceso de celebración de la sesión y elimínelo. Ha vuelto a la normalidad.
Debajo de 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
algún ejemplo que encontré en línea parece necesitar la identificación de la instancia, así como alterar la sesión de muerte del sistema '130,620, @ 1';
Parece que su problema está mezclando operaciones DML y DDL. Consulte esta URL que explica este problema:
select
c.owner,
c.object_name,
c.object_type,
b.sid,
b.serial#,
b.status,
b.osuser,
b.machine
from
v$locked_object a,
v$session b,
dba_objects c
where
b.sid = a.session_id
and
a.object_id = c.object_id;
ALTER SYSTEM KILL SESSION 'sid,serial#';¡Me las arreglé para dar con este error cuando simplemente creé una tabla! Obviamente, no había ningún problema de contención en una tabla que aún no existía. La CREATE TABLEdeclaración contenía una CONSTRAINT fk_name FOREIGN KEYcláusula que hacía referencia a una tabla bien poblada. Tuve que:
novalidatecláusula al alter table add constraint. Esto de alguna manera lo deja correr, pero se bloquea. Luego miré los bloqueos de sesión para averiguar en qué sesión se bloquea. Y luego maté esa sesión.
Tuve este error cuando tuve 2 scripts que estaba ejecutando. Yo tenía:
Ejecuté una caída de la tabla, luego la creación de la tabla como cuenta # 1. Ejecuté una actualización de la tabla en la sesión de la cuenta # 2. No cometió cambios. Se volvió a ejecutar el script de creación / caída de la tabla como cuenta n. ° 1. Tengo un error en el drop table xcomando.
Lo resolví ejecutando COMMIT;en la sesión SQL * Plus de la cuenta # 2.
COMMIT;. Si ni siquiera puede soltar una tabla, no tiene los permisos para alterar nada que lo lleve a este problema en primer lugar.
También me enfrento al problema similar. Nada programador tiene que hacer para resolver este error. Informé a mi equipo Oracle DBA. Matan la sesión y funcionan como un encanto.
La solución dada por el enlace de Shashi es la mejor ... no es necesario contactar a dba u otra persona
hacer una copia de seguridad
create table xxxx_backup as select * from xxxx;eliminar todas las filas
delete from xxxx;
commit;inserte su copia de seguridad.
insert into xxxx (select * from xxxx_backup);
commit;