Selon MSDN :
http://msdn.microsoft.com/en-us/library/ms191242.aspx
Lorsque les options de base de données READ COMMITTED SNAPSHOT ou ALLOW SNAPSHOT ISOLATION sont activées, des copies logiques (versions) sont conservées pour toutes les modifications de données effectuées dans la base de données. Chaque fois qu'une ligne est modifiée par une transaction spécifique, l'instance du moteur de base de données stocke une version de l'image précédemment validée de la ligne dans tempdb. Chaque version est marquée avec le numéro de séquence de la transaction qui a effectué la modification. Les versions des lignes modifiées sont chaînées à l'aide d'une liste de liens. La valeur de ligne la plus récente est toujours stockée dans la base de données actuelle et liée aux lignes versionnées stockées dans tempdb.
Pour les transactions de courte durée, une version d'une ligne modifiée peut être mise en cache dans le pool de mémoire tampon sans être écrite dans les fichiers disque de la base de données tempdb. Si le besoin de la ligne versionnée est de courte durée, elle sera simplement supprimée du pool de tampons et n'entraînera pas nécessairement de surcharge d'E/S.
Il semble y avoir une légère pénalité de performance pour la surcharge supplémentaire, mais elle peut être négligeable. Nous devrions tester pour nous en assurer.
Essayez de définir cette option et SUPPRIMEZ tous les NOLOCKs des requêtes de code, sauf si cela est vraiment nécessaire. Les NOLOCKs ou l'utilisation de méthodes globales dans le gestionnaire de contexte de base de données pour lutter contre les niveaux d'isolement des transactions de base de données sont des pansements au problème. NOLOCKS masquera les problèmes fondamentaux avec notre couche de données et conduira peut-être à la sélection de données non fiables, où la sélection/mise à jour automatique des versions de lignes semble être la solution.
ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON
