Dead Connection Detection

venerdì 26 ottobre 2007 alle 26:42 | Pubblicato su Installation and Configuration | 3 commenti

Da tempo mi affligge un problema sui server Oracle di sviluppo, ovvero sui server su cui si collegano i programmatori durante la fase di sviluppo software. Da quel che ho capito quando gli sviluppatori usano il debugger e chiudono la sessione di debug, le sessioni oracle non vengono chiuse, rimangono li sul server per giorni, si accumulano con le nuove create nei giorni a seguire fino a saturare il server che invece di impedire le nuove connessioni senza tante storie, finisce col piantarsi al punto da necessitare un riavvio del servizio (stiamo parlando 10.2.0.2 su Windoz). L’ultima volta che mi è capitato non c’era verso di entrare neppure come utente SYS.

Una prima idea che mi suggerì un consulente Oracle fu quella di usere i “PROFILES“. Oggi ho avuto modo di verificare che tale idea non funziona. Il fatto è che Oracle, per qualche motivo che mi sfugge, non prevede un metodo per pulire in modo definitivo le sessioni “morte”. Anche killando una sessione con il comando “ALTER SYSTEM KILL SESSION ‘SID,SERIAL#’ IMMEDIATE;”. La sessione rimane li in stato killed fino a quando il client non cercherà di eseguire nuovi comandi su tale sessione. Se il client nel frattempo non esiste più la sessione è destinata a rimanere li fino all’arresto dell’istanza Oracle.

Analogamente, abilitando i profiles e settando ad esempio un tempo massimo di inattività (IDLE_TIME=120), allo scadere del tempo di inattività la sessione verrà marcata come ‘SNIPED’ e rimarrà li fino a quando il client non cercherà di usare tale sessione. La nota metalink 1061189.6 descrive appunto questo problema e propone come soluzione uno script che in ambiente Unix uccide le sessioni dedica a livello di sistema operativo. In Windows la cosa diventa un po’ più complicata. Ho già parlato non molto tempo fa dello strumento “Process Explorer” che in Windows permette di uccidere i singoli thread, ma non so tale operazione è inglobabile in uno script batch analogo a quello descritto nella nota metalink per unix, e francamente in questo momento non ci voglio neppure perdere tempo.

Effettivamente Oracle in teoria fornisce una soluzione al mio problema, si chiama appunto Dead Connection Detection, è una caratteristica attivabile lato server a livello di “Oracle Net” con il parametro SQLNET.EXPIRE_TIME.

La cosa antipatica è che io avevo gia in teoria attivato tale caratteristica tempo fa, ma evidentemente non funziona e, come evidenziato nella nota 151972.1 dalla versione 9.2.0.4 non è più verificabile se non con strumenti esterni. In realtà oggi ho visto che in tempi relativamente recenti è stata introdotta una nuova nota , la 395505.1, che descrive come verificare se DCD è attivo su Oracle 9i/10g.

Il baco!

Mi sembra incredibile, nel giro di dieci giorni ho incontrato tre bachi. In sei anni che lavoro con Oracle, dalla versione 9.2.0.1 me ne saranno capitati cinque o sei. In ogni caso oggi ho verificato di aver incontrato il baco numero 5573896, citato in fondo alla nota che descrive come verificare il funzionamento di DCD su 10g. La nota 5475014 (bug) descrive bene la situazione: se SQLNET.EXPIRE_TIME>1 il problema ricompare al 100%, ho provato e confermo che settando tale parametro ad 1 sulla mia macchina nel trace compare il “probe packet”. Ora vediamo se ho risolto i miei problemi sul server di sviluppo.

P.S.

Degli altri due bachi che ho incontrato negli ultimi giorni di cui ho parlato sopra, uno riguarda la versione 9.2.0.1 e quindi non me ne curo. L’altro invece riguarda la versione 10.2.0.3 e per fortuna pare verificarsi con una certa probabilità solo in ambiente di sviluppo. Si tratta del baco descritto nella nota metalink 418531.1 e che si verifica quando i programmatori tramite il programma client visualizzano la descrizione di una tabella. In questo caso un flush della shared pool risolve il problema (per qualche giorno).

3 commenti »

RSS feed for comments on this post. TrackBack URI

  1. […] descrivo nel mio ultimo post, c’è un inghippo di cui tenere conto, la sessione non viene “eliminata” del […]

  2. […] 2 Novembre 2007 Nel mio ultimo post credevo di aver trovato la soluzione al problema delle sessioni che per diversi motivi possono […]

  3. prova orakill. quello funziona, e su un ambiente di sviluppo te lo puoi permettere


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: