Oracle Isolation Levels

mercoledì 23 maggio 2007 alle 23:47 | Pubblicato su Diario, SQL | Lascia un commento

Thomas Kyte nel suo libro dimostra di sapere abbastanza sull’argomento e ne descrive molto bene tutti gli aspetti, soprattutto spiega come si comporta Oracle al riguardo.

Mi preme però spiegare come si comporta Oracle in quanto tempo addietro un programmatore, analizzando un problema sulla nostra applicazione presso un cliente scrisse:

… due task facevano inserimenti nella tabella A mentre uno faceva la select dalla stessa tabella, cosa di per se non bloccante con l’isolation level utilizzato, …

Si può dire che l’isolation level in questo caso è stato citato a sproposito. Nel mio post di ieri ho spiegato brevemente cosa sono gli isolation level come definiti nello standard ANSI SQL-92. Oracle fornisce due isolation level: Read committed, quello di default e serializable. Questo significa, con l’isolation level usato per default in Oracle che:

  • non sono possibili dirty reads, cioè una sessione non vedrà mai dati modificati da un’altra e non committati.
  • Sono possibili non-repeatable reads, cioè interrogando due volte la stessa tabella una sessione può vedere dati diversi (questo non accade con l’isolation level serializable)
  • Sono possibili phantom reads, cioè facendo due interrogazioni uguali una sessione può vedere un insieme di record diversi nelle due interrogazioni

L’isolation level non c’entra un tubo con le politiche di locking

Ovvero, oracle grazie a sofisticate tecnologie riesce ad ottenere l’isolation level read committed riducendo al minimo i locking necessari, aumentando quindi la concorrenza e la scalabilità. Per garantire l’assenza del fenomeno “dirty read” un database potrebbe bloccare le letture su una tabella mentre essa viene modificata da una sessione, fino a quando tale sessione non committi. Oracle usa l’UNDO e non blocca mai i lettori, solo gli scrittori che vogliono modificare lo stesso dato. Più di così è difficile poter fare qualcosa. L’unico problema che si può verificare è il deadlock ma Oracle è in grado di accorgersene, in tal caso una delle due sessioni coinvolte riceve la segnalazione dell’errore.

Lascia un commento »

RSS feed for comments on this post. TrackBack URI

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: