Cosa può causare errori intermittenti ORA-12519 (TNS: non è stato trovato alcun gestore appropriato)

Question

Stiamo eseguendo la nostra suite di test Junit 4 su Weblogic 9 di fronte a un database Oracle 10 (utilizzando Hudson come server di integrazione continua) e occasionalmente si verificherà un arresto anomalo di ORA-12519 durante lo smontaggio dello script. Tuttavia, l'errore è molto intermittente:

• Di solito succede per la stessa classe Test
• Non succede sempre per gli stessi casi di test (a volte passano)
• Non succede per lo stesso numero di casi di test (ovunque 3-9)
• A volte non succede affatto, tutto passa

Anche se non posso garantire che ciò non accada localmente (quando si esegue sullo stesso database, ovviamente), ho eseguito la stessa suite di classe più volte senza problemi.

Qualche idea?

Answer 1

Non so se questa sarà la risposta di tutti, ma dopo un po 'di ricerche, ecco cosa ci è venuto in mente.

L'errore è ovviamente causato dal fatto che l'ascoltatore non stava accettando le connessioni, ma perché dovremmo ottenere quell'errore quando altri test potrebbero connettersi bene (potremmo anche connettere nessun problema tramite sqlplus)? La chiave del problema non era che non potevamo connetterci, ma che era intermittente

Dopo alcune indagini, abbiamo scoperto che c'erano alcuni dati statici creati durante l'installazione della classe che avrebbero mantenuto connessioni aperte per tutta la durata della classe di test, creandone di nuove man mano che procedevano. Ora, anche se tutte le risorse sono state correttamente rilasciate quando questa classe è uscita dal campo di applicazione (tramite un blocco finalmente {}, ovviamente), ci sono stati alcuni casi durante l'esecuzione in cui questa classe avrebbe inghiottito tutte le connessioni disponibili (ok, male avviso di pratica: si trattava di un codice di test unit che si collegava direttamente anziché utilizzare un pool, quindi lo stesso problema non poteva verificarsi in produzione).

La correzione non consisteva nel rendere statica quella classe ed eseguirla nell'impostazione della classe, ma invece nell'usarla nei metodi setUp e tearDown per metodo.

Quindi, se ricevi questo errore nelle tue app, dai uno schiaffo a un profiler su quel cattivo ragazzo e vedi se potresti avere una perdita di connessione. Spero che sia d'aiuto.

Answer 2

Un'altra soluzione che ho riscontrato per un errore simile, ma lo stesso messaggio di errore è aumentare il numero di gestori di servizi trovati. (La mia istanza di questo errore è stata causata da troppe connessioni nei pool di connessioni del portale Weblogic.)

• Esegui SQL * Plus e accedi come SYSTEM . Dovresti sapere quale password hai usato durante l'installazione di Oracle DB XE.
• Esegui il comando alter system set processi = 150 scope = spfile; in SQL * Plus
• MOLTO IMPORTANTE: riavviare il database.

Da qui:

  

http: // www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

Answer 3

Ho anche avuto lo stesso problema, ho cercato le risposte in molti posti. Ho ricevuto molte risposte simili per modificare il numero di gestori di processi / servizi. Ma ho pensato, e se avessi dimenticato di ripristinarlo?

Quindi ho provato a usare il metodo Thread.sleep () dopo ognuno dei miei connection.close (); .

Non so come, ma funziona almeno per me.

Se qualcuno vuole provarlo e capire come funziona, per favore vai avanti. Mi piacerebbe anche saperlo perché sono un principiante nel mondo della programmazione.

Answer 4

Ho avuto il problema simile. È successo ogni volta che eseguo un pacchetto di test del database (Spring JDBC) con SpringJUnit4ClassRunner , quindi ho risolto il problema inserendo l'annotazione @DirtiesContext per ogni test per ripulire il contesto dell'applicazione e rilasciare tutte le risorse in modo che ogni test possa essere eseguito con una nuova inizializzazione del contesto dell'applicazione.

Answer 5

Ho avuto questo problema in un unit test che ha aperto molte connessioni al DB tramite un pool di connessioni e poi "fermato" il pool di connessioni (attualmente ManagedDataSource) per rilasciare le connessioni alla fine di ogni test. Ho sempre finito le connessioni a un certo punto nella suite di test.

Aggiunto un Thread.sleep (500) nel teardown () dei miei test e questo ha risolto il problema. Penso che ciò che stava accadendo fosse che il pool di connessioni stop () rilascia le connessioni attive in un altro thread in modo che se il thread principale continua a funzionare, i thread di cleanup sono così indietro che il server Oracle ha esaurito le connessioni. L'aggiunta della sospensione consente ai thread in background di rilasciare le connessioni in pool.

Questo è molto meno un problema nel mondo reale perché i server DB sono molto più grandi e c'è una buona combinazione di operazioni (non solo infinite operazioni di connessione / disconnessione di DB).