De acordo com o MSDN:
http://msdn.microsoft.com/en-us/library/ms191242.aspx
Quando as opções de banco de dados READ COMMITTED SNAPSHOT ou ALLOW SNAPSHOT ISOLATION estiverem ATIVADAS, as cópias lógicas (versões) são mantidas para todas as modificações de dados executadas no banco de dados. Toda vez que uma linha é modificada por uma transação específica, a instância do Mecanismo de Banco de Dados armazena uma versão da imagem da linha confirmada anteriormente no tempdb. Cada versão é marcada com o número de sequência da transação que fez a alteração. As versões de linhas modificadas são encadeadas usando uma lista de links. O valor de linha mais recente é sempre armazenado no banco de dados atual e encadeado às linhas com versão armazenadas em tempdb.
Para transações de execução curta, aversão de uma linha modificada pode ser armazenada em cache no conjunto de buffers sem ser gravada nos arquivos de disco do banco de dados tempdb. Se a necessidade da linha versionada for de curta duração, ela simplesmente será descartada do pool de buffers e pode não necessariamente incorrer em sobrecarga de E/S.
Parece haver uma pequena penalidade de desempenho para a sobrecarga extra, mas pode ser insignificante. Devemos testar para ter certeza.
Tente definir esta opção e REMOVER todos os NOLOCKs das consultas de código, a menos que seja realmente necessário. NOLOCKs ou o uso de métodos globais no manipulador de contexto do banco de dados para combater os níveis de isolamento de transações do banco de dados são band-aids para o problema. O NOLOCKS mascarará problemas fundamentais com nossa camada de dados e possivelmente levará à seleção de dados não confiáveis, onde o controle automático de versão de linha de seleção/atualização parece ser a solução.
ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON
