Início / dba / Perguntas / 5014
Accepted
Adam Butler
Asked: 2011-08-25 20:45:31 +0800 CST

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

  • 772

Eu li aqui que alguns dados extras serão armazenados por linha para que possamos ver uma degradação de 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 transações ainda poderão ler os dados antigos. Isso está correto?

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

sql-server sql-server-2005

5 respostas

  1. Best Answer

    Resumo

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

    Carregar

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

    Segurança

    Mais importante, os isolamentos de instantâneos 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 de 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 no usuário, que pode não apreciar as armadilhas potenciais ou as soluções possíveis. A vantagem dessa transferência é um melhor desempenho.

    Veja também:

    • 56

  2. Eu sei que este é um tópico antigo, mas eu diria que, em grande parte, o isolamento de instantâneo é 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 é insignificante 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 instantâneo) é o método que a Oracle usa há décadas para obter isolamento sem bloquear leitores e os bancos de dados Oracle em que trabalhei por quase 20 anos apresentam 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 só testaram seu código em bancos de dados que usam a configuração padrão.

    • 42

  3. Alguns pontos adicionais para adicionar às outras respostas:

    SET ALLOW_SNAPSHOT_ISOLATION ONsó habilita o isolamento de instantâneo em um banco de dados. Para aproveitá-lo, você precisa recodificar e SET TRANSACTION ISOLATION LEVEL SNAPSHOTpara as transações que deseja aplicar. O código de chamada precisará ser alterado para lidar com erros de conflito de atualização.

    Depois SET READ_COMMITTED_SNAPSHOT ONde , as instruções em read confirmadas usam o controle de versão de linha. Observe que este é o controle de versão de linha no nível de instrução somente 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 versão de linha

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

    • 27

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

    Sim, isso está correto .

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

    • 20

  5. Estamos usando SNAPSHOT ISOLATION em todos os nossos projetos que usam SQL Server DB. Não há mais 1205 erros de SQL, que são causados ​​não por causa de código de aplicativo errado, mas do bloqueio de página padrão e comportamento de 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 diferentes sistemas, sem problemas em relação ao SNAPSHOT ISOLATION.

    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 que o SNAPSHOT ISOLATION seja a causa de qualquer problema de inconsistência são muito próximas de zero.

    Se você tiver um sistema OLTP que, por design, atualiza uma única linha com base nos dados de linha atuais em muitos encadeamentos, é claro que INSTANTÂNEOS não são aceitáveis ​​nesses casos.

    • 12

relate perguntas