ORA-00054: resurse ocupat și de a dobândi cu NOWAIT specificate sau de expirare a expirat

De ce primesc aceasta eroare baza de date atunci când am actualiza un tabel?

EROARE la linia 1: ORA-00054: resurse ocupat și de a dobândi cu NOWAIT specificate sau de expirare a expirat

Josep
Întrebarea editată 6 august 2013 в 12:24
Programare
oracle ora-00054
30 ianuarie 2011 в 11:59
11 vizualizări
Comentarii la întrebare (1)
Soluția

Masa este deja blocat de unele interogare. De exemplu, poate fi executat "selectați pentru a actualiza" și nu au comis/rollbacked și a tras-o altă interogare de selectare. Face un commit/rollback înainte de a executa interogarea.

Paweł Obrok
Răspuns editat 14 noiembrie 2018 в 3:22
Comentarii (4)

de aici https://stackoverflow.com/questions/3075738/ora-00054-resource-busy-and-acquire-with-nowait-specified

De asemenea, puteți căuta sql,nume de utilizator,o mașină,un port de informații și de a ajunge la proces real care deține o conexiune

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;
Community
Răspuns editat 23 mai 2017 в 12:10
Comentarii (5)

Vă Rugăm Să Omoare Oracle Sesiune

Folosesc de mai jos interogare pentru a verifica sesiune activă info

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;

ucide ca

alter system kill session 'SID,SERIAL#';

(De exemplu, modifice sistemul de omor sesiune '13,36543';)

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

user128216
Răspuns editat 26 octombrie 2015 в 5:10
Comentarii (4)

Acolo este un foarte ușor de lucru în jurul valorii de această problemă.

Dacă tu a alerga un 10046 urme pe sesiune (google asta... e prea mult de explicat). Veți vedea că, înainte de orice DDL operare Oracle face următoarele:

MASĂ DE BLOCARE 'TABLE_NAME' NU AȘTEPTAȚI

Deci, dacă o altă sesiune a deschis o tranzacție obține o eroare. Deci fix este... tobele va rog. Problema propria dvs. de blocare înainte de DDL și lăsa 'NU AȘTEPTAȚI'.

Notă Specială:

dacă faci divizare/cădere partiții oracle doar blochează partiție. ... deci yo pot bloca doar partiția subpartition.

Deci... Următorii pași rezolva problema.

  1. MASĂ de BLOCARE 'NUMELE'; - va 'stai' (dezvoltatorii numesc acest suspendate). până la sesiune cu tranzacție deschise, angajează. Aceasta este o listă de așteptare. deci, pot exista mai multe sesiuni de față. dar NU vei eroare.
  2. Executa DDL. DDL va rula apoi un sistem de blocare cu NICI o așteptare. Cu toate acestea, ședința a achizitionat de blocare. Deci sunt bune.
  3. DDL auto-angajează. Aceasta eliberează încuietori.

DML declarații va 'stai' sau ca dezvoltatorii numesc 'stea' în timp ce tabelul este blocat.

Eu folosesc acest lucru în codul care se execută la un loc de muncă să scadă partiții. Acesta funcționează bine. Acesta este într-o bază de date care este în mod constant introducerea la o rată de câteva sute de insertii/secundă. Fără erori.

dacă vă întrebați. Face acest lucru în 11g. Am făcut acest lucru într-10g înainte la fel de bine în trecut.

Comentarii (7)

Această eroare se produce atunci când resursa este ocupată. Verificați dacă aveți orice constrângeri referențiale în interogare. Sau chiar tabele pe care le-am menționat în interogare poate fi ocupat. Acestea ar putea fi angajat cu un alt loc de muncă, care va fi cu siguranță enumerate în următorul rezultatele interogării:

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

Găsi SID, 

SELECT * FROM V$OPEN_CURSOR WHERE SID = --the id
Arunchunaivendan
Răspuns editat 20 octombrie 2017 в 6:54
Comentarii (3)

În cazul meu, am fost destul de sigur că a fost unul dintre mea sesiuni care a fost blocarea. Prin urmare, este sigur să faceți următoarele:

  • Am găsit ofensatoare sesiune cu:

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

Sesiunea a fost inactiv, dar nu a avut loc încă de blocare într-un fel. Rețineți că poate fi necesar să utilizați o altă UNDE condiție în cazul dumneavoastră (de exemplu, încercați să "numele de UTILIZATOR" sau "MAȘINĂ" câmpuri).

  • Ucis de sesiune folosind ID-ul " și " SERIE# dobândite de mai sus:

modifice sistemul de omor sesiune de &#39;<id>, <serial#>&#39;;

Editat de @thermz: Dacă niciuna din precedentele deschide-sesiune de întrebări munca încercați această unul. Această interogare poate ajuta pentru a evita erori de sintaxă în timp ce uciderea sesiuni:

  • SELECTA &#39;să MODIFICE SISTEMUL de OMOR SESIUNE &#39;&#39;&#39;||SID||&#39;,&#39;||SERIAL#||&#39;&#39;&#39; imediate;&#39; DE la V$SESSION UNDE OSUSER=&#39;my_local_username_on_OS&#39;
wrygiel
Răspuns editat 15 februarie 2019 в 7:28
Comentarii (1)

Acest lucru se întâmplă atunci când o sesiune alta decât cea utilizată pentru a modifica un tabel deține un sistem de blocare probabil din cauza unei DML (update/delete/insert). Dacă sunteți în curs de dezvoltare un nou sistem, este probabil ca tu sau cineva din echipa ta probleme declarația de actualizare și te-ar putea ucide sesiune fără prea mult consecință. Sau ai putea comite din acea sesiune odată ce știi cine a sesiunii deschise.

Dacă aveți acces la un SQL admin sistemul folosi pentru a găsi ofensatoare sesiune. Și poate ucide.

Ai putea folosi v$session și v$de blocare și altele, dar vă sugerez google cum de a găsi acea sesiune și apoi cum să-l omoare.

Într-un sistem de producție, depinde. Pentru oracle 10g și mai în vârstă, ai putea executa 

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

Într-o sesiune separată, dar avea următoarele gata în cazul în care este nevoie de prea mult timp.

alter system kill session '....

Depinde de ce sistem ai, sistemele mai vechi, sunt mult mai probabil pentru a nu comite de fiecare dată. Asta este o problemă, deoarece nu poate fi de lungă durată încuietori. Deci, de blocare ar împiedica orice nouă încuietori și așteptați pentru un sistem de blocare care cine știe când va fi lansat. Care este de ce aveți altă declarație gata. Sau ai putea să te uiți pentru UNIX script-uri de acolo, care fac lucruri similare în mod automat.

În versiunea 11g există o nouă variabilă de mediu, care stabilește o perioadă de așteptare. Cred că a face ceva similar cu ceea ce am descris. Tine minte ca de blocare probleme don't să dispară.

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

În cele din urmă că ar fi mai bine să așteptați până când sunt puțini utilizatori în sistem pentru a face acest tip de întreținere.

Comentarii (2)

Doar verifica pentru procesul care deține sesiune și să-l Ucidă. Își reveni la normal.

Mai jos SQL va găsi procesul

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;

Apoi l omoare 

ALTER SYSTEM KILL SESSION 'sid,serial#'

SAU

un exemplu l-am găsit online pare să aibă nevoie de la id de instanță, precum și modifica sistemul de omor sesiune '130,620,@1';

Comentarii (0)

Problema ta se pare ca se amesteca DML & DDL operațiuni. A se vedea această adresă URL care explică această problemă:

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

Comentarii (0)

Am reusit sa lovit de aceasta eroare, atunci când pur și simplu a crea un tabel! Acolo a fost, evident, nici un conflict problemă pe o masă care nu't există încă. `CREAȚI TABELUL declarația conținea o CONSTRÂNGERE fk_name CHEIE EXTERNĂ clauza de referire la o bine-populate de masă. Am avut de a:

  • Scoateți CHEIA EXTERNĂ clauza din declarația create TABLE
  • A crea un INDEX pe coloana FK
  • Crea FK
Comentarii (2)

Am avut această eroare se întâmplă atunci când am avut 2 script-uri am fost difuzate. Am avut:

  • Un SQL*Plus sesiune conectat direct, folosind o schemă cont de utilizator (contul #1)
  • Un alt SQL*Plus sesiune conectat folosind un alt model de cont de utilizator (contul #2), dar conectarea pe o bază de date link-ul ca primul cont

Am făcut o masă picătură, apoi crearea de masă ca contul #1. Am dat un tabel de actualizare pe contul #2's-a sesiune. Nu a comis-o schimbă. Re-ran tabel drop/crearea script ca contul #1. Am eroare pe drop table x comanda.

Am rezolvat-o prin rularea `a COMIS; în SQL*Plus a sesiune a cont #2.

Comentarii (2)
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#';
Comentarii (0)

Eu confruntă, de asemenea Problemă similară. Nimic programator trebuie să facă pentru a rezolva această eroare. Am informat-o pe a mea oracle DBA echipa. Ei ucid sesiunii și a lucrat ca un farmec.

Comentarii (3)

Soluția dată de Shashi's link-ul este cel mai bun... nu are nevoie să contactați dba sau altcineva

face o copie de rezervă

create table xxxx_backup as select * from xxxx;

șterge toate rândurile

delete from xxxx;
commit;

introduce-ți rezervă.

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