Secondo MSDN:
http://msdn.microsoft.com/en-us/library/ms191242.aspx
Quando le opzioni del database READ COMMITTED SNAPSHOT o CONSENTI ISOLAMENTO SNAPSHOT sono attive, le copie logiche (versioni) vengono mantenute per tutte le modifiche dei dati eseguite nel database. Ogni volta che una riga viene modificata da una transazione specifica, l'istanza di Motore di database memorizza una versione dell'immagine precedentemente sottoposta a commit della riga in tempdb. Ciascuna versione è contrassegnata dal numero di sequenza delle transazioni della transazione che ha apportato la modifica. Le versioni delle righe modificate vengono concatenate utilizzando un elenco di collegamenti. Il valore della riga più recente viene sempre archiviato nel database corrente e concatenato alle righe con versione memorizzate in tempdb.
Per le transazioni a esecuzione breve, l'avversione per una riga modificata può essere memorizzata nella cache nel pool di buffer senza che venga scritta nei file del disco del database tempdb. Se la necessità della riga con versione è di breve durata, verrà semplicemente eliminata dal pool di buffer e potrebbe non comportare necessariamente un sovraccarico di I/O.
Sembra esserci una leggera penalizzazione delle prestazioni per l'overhead aggiuntivo, ma potrebbe essere trascurabile. Dovremmo testare per essere sicuri.
Prova a impostare questa opzione e RIMUOVERE tutti i NOLOCK dalle query di codice a meno che non sia davvero necessario. I NOLOCK o l'utilizzo di metodi globali nel gestore del contesto del database per combattere i livelli di isolamento delle transazioni del database sono cerotti per il problema. NOLOCKS maschererà i problemi fondamentali con il nostro livello dati e probabilmente porterà alla selezione di dati inaffidabili, dove la selezione/aggiornamento automatico delle versioni delle righe sembra essere la soluzione.
ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON
