Volgens MSDN:
http://msdn.microsoft.com/en-us/library/ms191242.aspx
Als de database-opties LEES COMMITTED SNAPSHOT of MOMENTOP ISOLATIE TOESTAAN zijn AAN, worden logische kopieën (versies) onderhouden voor alle gegevensmodificaties die in de database worden uitgevoerd. Elke keer dat een rij wordt gewijzigd door een specifieke transactie, slaat de instantie van de Database Engine een versie op van de eerder vastgelegde afbeelding van de rij in tempdb. Elke versie is gemarkeerd met het transactievolgnummer van de transactie die de wijziging heeft aangebracht. De versies van gewijzigde rijen zijn geketend met behulp van een linklijst. De nieuwste rijwaarde wordt altijd opgeslagen in de huidige database en gekoppeld aan de rijen met versiebeheer die zijn opgeslagen in tempdb.
Voor kortlopende transacties kan de afkeer van een gewijzigde rij in de bufferpool worden gecached zonder dat deze naar de schijfbestanden van de tempdb-database wordt geschreven. Als de behoefte aan de rij met versiebeheer van korte duur is, wordt deze eenvoudig uit de bufferpool verwijderd en hoeft dit niet noodzakelijk I/O-overhead met zich mee te brengen.
Er lijkt een lichte prestatiestraf te zijn voor de extra overhead, maar deze kan verwaarloosbaar zijn. We moeten testen om er zeker van te zijn.
Probeer deze optie in te stellen en VERWIJDER alle NOLOCKs uit codequery's, tenzij het echt nodig is. NOLOCK's of het gebruik van globale methoden in de databasecontext-handler om isolatieniveaus van databasetransacties te bestrijden, zijn pleisters voor het probleem. NOLOCKS zal fundamentele problemen met onze gegevenslaag maskeren en mogelijk leiden tot het selecteren van onbetrouwbare gegevens, waarbij automatisch selecteren / updaten van rijversies de oplossing lijkt te zijn.
ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON