ORA-00054: risorse occupate e acquisite con NOWAIT specificato o timeout scaduto

Perché visualizzo questo errore del database quando aggiorno una tabella?

ERRORE alla riga 1: ORA-00054: risorse occupate e acquisite con NOWAIT specificato o timeout scaduto

La tua tabella è già bloccata da qualche query. Ad esempio, potresti aver eseguito "seleziona per aggiornamento" e non hai ancora eseguito il commit / rollback e attivato un'altra query di selezione. Effettuare un commit / rollback prima di eseguire la query.

da qui ORA-00054: risorse occupate e acquisite con NOWAIT specificato

È inoltre possibile cercare sql, nome utente, macchina, informazioni sulla porta e accedere al processo effettivo che contiene la connessione

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;

Si prega di uccidere Oracle Session

Utilizzare la query seguente per controllare le informazioni sulla sessione attiva

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;

uccidi come

alter system kill session 'SID,SERIAL#';

(Ad esempio alter system kill session '13,36543',;)

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

C'è un modo molto semplice per ovviare a questo problema.

Se esegui una traccia 10046 sulla tua sessione (google questo ... troppo per spiegare). Vedrai che prima di qualsiasi operazione DDL Oracle esegue le seguenti operazioni:

BLOCCO TABELLA 'TABLE_NAME' NO ATTENDERE

Pertanto, se un'altra sessione ha una transazione aperta, viene visualizzato un errore. Quindi la soluzione è ... rullo di tamburi per favore. Rilascia il tuo lucchetto prima del DDL ed escludi "NO WAIT".

Nota speciale:

se stai facendo dividere / rilasciare le partizioni oracle blocca semplicemente la partizione. - Quindi puoi semplicemente bloccare la sottopartizione della partizione.

Quindi ... I seguenti passaggi risolvono il problema.

1. LOCK TABLE 'NOME TABELLA'; - "Aspetterai" (gli sviluppatori chiamano questo impiccagione). fino alla sessione con la transazione aperta, si impegna. Questa è una coda. quindi potrebbero esserci diverse sessioni davanti a te. ma NON sbaglierai.
2. Eseguire DDL. Il DDL eseguirà quindi un blocco con NO WAIT. Tuttavia, la sessione ha acquisito il blocco. Quindi sei bravo.
3. Auto-commit DDL. Questo libera le serrature.

Le istruzioni DML "attenderanno" o come gli sviluppatori chiamano "blocco" mentre la tabella è bloccata.

Lo uso nel codice che viene eseguito da un lavoro per eliminare le partizioni. Funziona bene È in un database che si inserisce costantemente ad una velocità di diverse centinaia di inserti / secondo. Nessun errore

se ti stai chiedendo. In questo modo in 11g. L'ho già fatto in 10g prima e in passato.

Questo errore si verifica quando la risorsa è occupata. Controlla se ci sono vincoli referenziali nella query. O anche le tabelle menzionate nella query potrebbero essere occupate. Potrebbero essere coinvolti in qualche altro lavoro che sarà sicuramente elencato nei seguenti risultati della query:

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

Trova il SID,

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

Ciò accade quando una sessione diversa da quella utilizzata per modificare una tabella è in possesso di un blocco probabilmente a causa di un DML (aggiornamento / eliminazione / inserimento). Se stai sviluppando un nuovo sistema, è probabile che tu o qualcuno del tuo team rilasci la dichiarazione di aggiornamento e che sia possibile interrompere la sessione senza molte conseguenze. Oppure puoi impegnarti da quella sessione una volta che sai chi ha la sessione aperta.

Se hai accesso a un sistema di amministrazione SQL, utilizzalo per trovare la sessione offensiva. E forse ucciderlo.

Potresti usare v $ session e v $ lock e altri, ma ti suggerisco di google come trovare quella sessione e come ucciderla.

In un sistema di produzione, dipende davvero. Per Oracle 10g e oltre, potresti eseguire

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

In una sessione separata, ma tieni pronto quanto segue nel caso in cui impieghi troppo tempo.

alter system kill session '....

Dipende dal sistema che hai, è più probabile che i sistemi più vecchi non si impegnino ogni volta. Questo è un problema poiché potrebbero esserci blocchi di vecchia data. Quindi il tuo blocco impedirebbe qualsiasi nuovo blocco e aspetterebbe un blocco che sa quando verrà rilasciato. Ecco perché hai l'altra affermazione pronta. Oppure potresti cercare script PLSQL là fuori che fanno automaticamente cose simili.

Nella versione 11g è presente una nuova variabile d'ambiente che imposta un tempo di attesa. Penso che probabilmente faccia qualcosa di simile a quello che ho descritto. Intendiamoci che i problemi di blocco non vanno via.

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

Infine, potrebbe essere meglio attendere fino a quando non ci sono pochi utenti nel sistema per eseguire questo tipo di manutenzione.

Nel mio caso, ero abbastanza sicuro che fosse una delle mie sessioni a bloccare. Pertanto, è stato sicuro eseguire le seguenti operazioni:

• Ho trovato la sessione offensiva con:

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

  La sessione era inattiva , ma in qualche modo manteneva il blocco. Tieni presente che potrebbe essere necessario utilizzare alcune altre condizioni WHERE nel tuo caso (ad es. Try USERNAMEo MACHINEfields).

• Ha ucciso la sessione usando il IDe SERIAL#acquisito sopra:

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

A cura di @thermz: se nessuna delle precedenti query a sessione aperta funziona, prova questa. Questa query può aiutarti a evitare errori di sintassi durante l'uccisione delle sessioni:

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

Basta controllare il processo che tiene la sessione e ucciderlo. È tornato alla normalità.

Sotto SQL troverai il tuo processo

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;

Quindi uccidilo

ALTER SYSTEM KILL SESSION 'sid,serial#'

O

alcuni esempi che ho trovato online sembrano aver bisogno dell'ID dell'istanza e di modificare la sessione di interruzione del sistema '130.620, @ 1';

Il tuo problema sembra che stai mescolando le operazioni DML e DDL. Vedi questo URL che spiega questo problema:

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

Sono riuscito a colpire questo errore semplicemente creando una tabella! Non c'era ovviamente alcun problema di contesa su un tavolo che non esisteva ancora. L' CREATE TABLEistruzione conteneva una CONSTRAINT fk_name FOREIGN KEYclausola che faceva riferimento a una tabella ben popolata. Dovevo:

• Rimuovere la clausola FOREIGN KEY dall'istruzione CREATE TABLE
• Crea un INDICE nella colonna FK
• Crea l'FK

Ho avuto questo errore accadere quando avevo 2 script che stavo eseguendo. Avevo:

• Una sessione SQL * Plus connessa direttamente tramite un account utente dello schema (account n. 1)
• Un'altra sessione SQL * Plus si è connessa utilizzando un altro account utente dello schema (account n. 2), ma si è collegata attraverso un collegamento al database come primo account

Ho eseguito un drop della tabella, quindi la creazione della tabella come account n. 1. Ho eseguito un aggiornamento della tabella nella sessione dell'account n. 2. Non è stato eseguito il commit delle modifiche. Rieseguito script di eliminazione / creazione della tabella come account n. 1. Errore nel drop table xcomando.

L'ho risolto eseguendo COMMIT;nella sessione SQL * Plus dell'account n. 2.

Devo anche affrontare il problema simile. Niente programmatore deve fare per risolvere questo errore. Ho informato il mio team DBA di Oracle. Uccidono la sessione e hanno funzionato come un fascino.

La soluzione fornita dal link di Shashi è la migliore ... non c'è bisogno di contattare dba o qualcun altro

fare un backup

create table xxxx_backup as select * from xxxx;

elimina tutte le righe

delete from xxxx;
commit;

inserisci il tuo backup.

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