Enligt MSDN:
http://msdn.microsoft.com/en-us/library/ms191242.aspx
När antingen databasalternativen READ COMMITTED SNAPSHOT eller ALLOW SNAPSHOT ISOLATION är PÅ, bibehålls logiska kopior (versioner) för alla datamodifieringar som utförs i databasen. Varje gång en rad modifieras av en specifik transaktion, lagrar instansen av Database Engine en version av den tidigare överlåtna bilden av raden i tempdb. Varje version är märkt med transaktionssekvensnumret för transaktionen som gjorde ändringen. Versioner av modifierade rader är kedjade med hjälp av en länklista. Det senaste radvärdet lagras alltid i den aktuella databasen och kopplas till de versionerade raderna lagrade i tempdb.
För korta transaktioner kan aversion av en modifierad rad cachelagras i buffertpoolen utan att skrivas in i diskfilerna i tempdb-databasen. Om behovet av den versionerade raden är kortvarigt kommer den helt enkelt att släppas från buffertpoolen och behöver inte nödvändigtvis medföra I/O-overhead.
Det verkar finnas ett litet prestationsstraff för extra overhead, men det kan vara försumbart. Vi bör testa för att vara säkra.
Försök att ställa in det här alternativet och TA BORT alla NOLOCKs från kodfrågor om det inte verkligen är nödvändigt. NOLOCKs eller att använda globala metoder i databasens kontexthanterare för att bekämpa databastransaktionsisoleringsnivåer är plåster för problemet. NOLOCKS kommer att maskera grundläggande problem med vårt datalager och eventuellt leda till val av opålitlig data, där automatisk val/uppdatering av radversioner verkar vara lösningen.
ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON