0 voti
2.9k visite
quesito posto in SQL e PLSQL da (2.1k punti)
ri-taggati da
Tempo fa mi sono imbatutto in questo errore, la cosa particolare è che questo problema si presentava in fase di INSERT di un record che solitamente non è la causa più frequente nei problemi di lock.

Non poteva trattarsi del tentativo di inserire la stesso id (non ancora committato) della chiave primaria in tabella dato che per ottenere l'id tutti i processi utilizzavano una sequence.

Dato che la transazione utilizzava un dblink il timeout per rilevare il lock era di molto inferiore alla soglia di quello delle sessioni che non sfruttano dblink (il DISTRIBUTED_LOCK_TIMEOUT infatti è impostato di default a 60 secondi).

1 Risposta

0 voti
risposta inviata da (2.1k punti)
Tramite un blocco anonimo in ascolto sulla v$session sono riuscito ad estrarre qualche sessione bloccante che faceva andare la mia transazione in timeout. La cosa particolare di queste sessioni è che avevano valorizzato il campo activity con il valore "enq: TM – contention". Dopo qualche ricerca ho scoperto che questo tipo di problema può essere legato alla mancanza di indici sulle FOREIGN KEY, ed in effetti il motivo era proprio questo. Creando l'indice mancante il problema non si è più presentato.

Domande correlate

0 voti
0 risposte 3.2k visite
0 voti
0 risposte 221 visite
0 voti
0 risposte 117 visite
0 voti
0 risposte 101 visite
0 voti
0 risposte 88 visite
...