Quais são os riscos se habilitarmos a leitura instantânea confirmada no sql-server?

Eu li aqui que alguns dados extras serão armazenados por linha, para que possamos ver uma degradação no desempenho, mas que outros riscos existem?

por exemplo. Isso afetará a recuperação do banco de dados? Há mais alguma coisa que precisamos fazer para tirar proveito disso?

Eu pretendo executar estes comandos:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Acredito que isso nos dará algo mais próximo do oracle, onde, se uma transação estiver atualizando outras, ainda será possível ler os dados antigos. Isso está correto?

Estou investigando isso porque estou cansado de problemas de bloqueio no SQL Server 2005. Espero que isso reduza os bloqueios ocasionais que nossos usuários veem, ajude o desempenho geral de nosso aplicativo e incentive nossos desenvolvedores a fazer mais de uma operação por transação sem medo.

Sumário

1. Se você tiver problemas de bloqueio, terá um problema com o seu código: não é o mecanismo do banco de dados
2. Não é uma bala mágica
3. Você pode adicionar mais problemas

Carga

Também aumentará a carga no seu tempdb e CPU . Veja também:

• "Impacto no desempenho: o custo potencial de Read_Committed_Snapshot" (Linchi Shea)

Segurança

Mais importante, os isolamentos de captura instantânea não são seguros em muitos casos por padrão . Leia "Isolamento de instantâneo" (Wikipedia) para obter mais informações sobre anomalias de distorção de gravação. A próxima seção é "Tornando o isolamento do instantâneo serializável" para contornar isso.

Em geral, portanto, o isolamento de instantâneo coloca parte do problema de manter restrições não triviais para o usuário, que pode não apreciar as possíveis armadilhas ou as possíveis soluções. A vantagem dessa transferência é o melhor desempenho.

Veja também:

• "Os perigos potenciais do nível de isolamento de snapshots comprometidos por leitura" (JimMcLeod, disputado nos comentários de Alex Kuznetsov)
• Deadlocked !: "leia o instantâneo confirmado" Explained (Nick Berardi)
• Nível de isolamento serializável vs. instantâneo, o problema do mármore (Craig Freedman)
• As leituras envolvendo UDFs em READ_COMMITTED_SNAPSHOT podem parecer inconsistentes (Alex Kuznetsov)

Eu sei que esse é um tópico antigo, mas eu diria, em grande parte, que o isolamento de instantâneos é uma bala mágica. Isso eliminará todo o seu bloqueio entre leitores e escritores. No entanto, não impedirá que os escritores bloqueiem outros escritores. Não há jeito de contornar isso.

Na minha experiência, a carga adicional no TEMPDB é desprezível e os benefícios do controle de versão de linha na redução de leitores bloqueados são enormes.

Para referência, o controle de versão de linha (isolamento de snapshot) é o método que a Oracle usa há décadas para obter isolamento sem bloquear os leitores e os DBs do Oracle em que trabalhei por quase 20 anos enfrentam muito menos problemas de bloqueio do que o SQL Server. A maioria dos desenvolvedores de SQL hesita em usar o isolamento de instantâneo, porque eles só testaram seu código em bancos de dados que usam a configuração padrão.

Alguns pontos adicionais a serem adicionados às outras respostas:

SET ALLOW_SNAPSHOT_ISOLATION ONsomente ativa o isolamento de captura instantânea em um banco de dados. Para tirar proveito disso, é necessário recodificar e SET TRANSACTION ISOLATION LEVEL SNAPSHOTpara as transações às quais você deseja aplicar. O código de chamada precisará ser alterado para lidar com erros de conflito de atualização.

Depois SET READ_COMMITTED_SNAPSHOT ON, as instruções na leitura confirmada usam o versionamento de linha. Observe que esse é o versionamento de linha no nível da instrução apenas para leitura . Para atualizações, a linha "real" é recuperada e os bloqueios de atualização são aplicados. Consulte a seção Resumo do comportamento em Noções básicas sobre níveis de isolamento baseados em controle de versão de linha

De qualquer forma, sem testes exaustivos, é provável que você introduza um conjunto completamente novo de problemas no sistema.

Acredito que isso nos dará algo mais próximo do oracle, onde, se uma transação estiver atualizando outras, ainda será possível ler os dados antigos. Isso está correto?

Sim, isso está correto .

Vale a pena ler os links na resposta da gbn e acredito que o mesmo se aplica ao MVCC padrão da Oracle e ao SQL Server no modo Isolamento de Instantâneo. Eu acrescentaria que, se você entender as possíveis armadilhas, os benefícios da IMO superam em muito as dificuldades adicionais (falando da perspectiva do Oracle) - e, é claro, alguns problemas de bloqueio desaparecem legitimamente, esse é o ponto do MVCC (há também uma classe de problemas de bloqueio que não desaparecem devido a problemas de código, mas suponho que você entenda isso).

Estamos usando o SNAPSHOT ISOLATION em todos os nossos projetos que usam o SQL Server DB. Não há mais erros 1205 SQL, causados ​​não por causa do código incorreto do aplicativo, mas pelo comportamento padrão de bloqueio de página e bloqueio de linha.

O impacto no desempenho é mínimo e, até agora 7 anos se passaram, centenas de milhões de operações foram processadas em sistemas diferentes, sem problemas com o ISOLAMENTO DO INSTANTÂNEO.

As situações em que vários encadeamentos diferentes estão atualizando informações críticas de negócios em uma única linha em paralelo são extremamente excepcionais, e as chances de SNAPSHOT ISOLATION ser a causa de qualquer problema de inconsistência estão muito próximas de zero.

Se você possui um sistema OLTP, que, por design, atualiza a linha única com base nos dados da linha atual em muitos threads, é claro que os INSTANTÂNEOS não são aceitáveis ​​nesses casos.

nós o tínhamos ativo e uma instrução sql select estranha executando 4 sempre bloqueou o banco de dados inteiro, não importa quantos núcleos e tudo. A desativação do RCSI corrigiu isso. Gostaria de ativá-lo quando você enfrentar outros impasses, não por padrão.