SQL Server 2005 permette di isolare le transazioni (come richiede la proprietà "I" dell'acronimo ACID, ossia Isolation) non solo tramite l'utilizzo della tecnica conosciuta come locking ma anche tramite il row versioning.
Cosa significa questo? Che, utilizzando il nuovo livello di isolamento snapshot, è possibile far si che le scritture non siano bloccanti per le letture e viceversa. Questa è un'ottima cosa per limitare i problemi dovuti ai lock, ma, come al solito, ha un prezzo.
Prima di passare al costo, però, è bene chiarire, all'atto pratico, cosa permette di ottenre tale livello di isolamento. Nella fattispecie mi limito a descrivere il livello di isolamento definito come read committed snapshot isolation che è il più semplice da utilizzare e da comprendere. Supponiamo di avere due transazioni attive; la prima modifica il dato in modo da portare il valore della colonna "Nome" da "Davide" a "Mario"; la seconda cerca di leggere la stessa riga modificata dalla transazione uno.
Bene, con la tecnica del locking la seconda transazione sarebbe messa in attesa fino al completamento della prima (supponendo di essere in livello di isolamento Read Commited), mentre usando il versioning la seconda vede il dato nello stato in cui era prima dell'inzio della prima transazione, ossia vedere il valore "Davide".
Questo avviene grazie al version chaining che permette a Sql Server di conoscere i valori precendenti di una determinata colonna per una determinata riga. La tecnica con la quale il motore di Sql Server va a scovare la versione corretta si chiama version traversing.
Niente male vero? Tutti i problemi di concorrenza si annullano in un attimo, e cosi - diciamola tutta - anche database scritti in modo non troppo corretto (per esser gentili) smetteranno di mostrare apparenti colli di bottiglia dovuti al locking.
E' bene quindi ricordare che il prezzo da pagare è fissato in termini di byte, in particolare di 14 byte per ogni riga di cui SQL Server deve effettuare il versioning. Detto questo significa che lo spazio occupato dai metadati aumenta sensibilmente, mentre lo spazio disponibile rimane sempre quello ossia 8060 byte. Questo significa dati più frammentati (anche fisicamente) e quindi un maggior numero di operazioni di I/O richieste e quindi delle prestazioni non ottimali.
Detto ciò il nuovo livello di isolamente è davvero straordinario, ma è bene tenere a mente che nulla viene regalato e quindi l'utilizzo di tale funzionalità o meno (che tra l'altro fa _abbondante_ uso del tempdb che pertanto deve essere ottimizzato e gestito a dovere) deve essere ben ponderato, e non deve assolutamente essere utilizzato per sopperire alle mancanze di un disegno errato del database.