Quando a detecção de página rasgada e a soma de verificação foram introduzidas no SQL Server e quais são os comportamentos de atualização?

15

Existem duas opções diferentes no SQL Server moderno para verificação de página; sendo rasgado detecção de página e soma de verificação . Nenhuma também é, obviamente, uma opção.

Acredito que o Checksum foi introduzido no SQL Server 2005 e que a atualização ou restauração de um banco de dados de uma versão anterior manteria seu método de verificação de página anterior. ou seja, não houve atualização implícita.

O problema envolvido é que temos um banco de dados de produção que entrou em produção usando o SQL Server 2000 e que foi transferido para um servidor SQL Server 2008 R2. A Verificação de página está definida como Nenhum quando eu esperava que fosse Detecção de página rasgada . Voltando a essa quantidade de tempo, parece que o banco de dados foi originalmente desenvolvido no SQL Server 7.0 e depois migrado para o SQL Server 2000, o que pode explicar o resultado observado.

Fiquei pensando quando a detecção de página rasgada e a soma de verificação se tornaram um recurso do SQL Server e como elas se comportaram quando migradas ou atualizadas para versões mais recentes.

Edit: Resumindo algumas das respostas:

Há um pouco de discrepância em algumas datas de quando a Detecção de página rasgada entrou no SQL Server.
Link 1: http://support.microsoft.com/kb/230785
Link 2: http://technet.microsoft.com/en-us/library/aa337525(v=sql.90).aspx

O primeiro link indica o SQL 7.0 e o segundo SQL2000. Costumo confiar na sugestão do SQL7.0 e esse link dois ficou confuso por estar desativado por padrão no SQL7.0 e ativado por padrão no SQL2000.

Paulo
fonte
2
foi introduzido quando o código foi confirmado.
swasheck 18/09/13
Por que isso Importa? Qual é o problema que está sendo resolvido aqui?
Marian
@swasheck - desculpe, eu não entendo o seu comentário.
Paul
11
@Paul votou na reabertura
swasheck 18/09/13
11
@ Paul Adicionei informações da página dbcc para verificar se há página rasgada ou bits de soma de verificação na minha resposta.
Kin Shah

Respostas:

15

No SQL Server 2000, se você deseja identificar páginas corrompidas, a opção do banco de dados TORN_PAGE_DETECTION deve ser definida como TRUE.

Porém, no SQL 2005 e posteriores, uma nova configuração PAGE_VERIFY substituiu a antiga TORN_PAGE_DETECTION, que permite escolher entre dois tipos diferentes de verificação de página: TORN_PAGE_DETECTION e CHECKSUM.

Agora vem a pergunta qual definir - TORN_PAGE_DETECTION ou CHECKSUM?

TORN_PAGE_DETECTION - grava um bit para cada 512 bytes em uma página, permitindo detectar quando uma página não foi gravada com sucesso no disco. O problema é que ele não informa se os dados armazenados nesses 512 bytes estão realmente corretos ou não, devido ao fato de que alguns bytes podem ter sido gravados incorretamente.

CHECKSUM - calculará uma soma de verificação da página quando uma página for escrita e quando uma página for lida, assumindo que ela tenha soma de verificação.

O SQL Server calcula a soma de verificação com base no padrão de bits da página, armazena-a no cabeçalho da página e emite uma E / S para gravar a página. Quando o SQL Server lê a página, recalcula a soma de verificação usando a mesma lógica e a compara com o valor disponível no cabeçalho da página. Se o valor da soma de verificação corresponder, será assumido que a página não foi corrompida durante o ciclo de gravação / leitura.

Como o custo de computação da soma de verificação é incorrido em cada página de leitura e gravação, ela pode aumentar a sobrecarga da CPU e, possivelmente, afetar a taxa de transferência de sua carga de trabalho. Outro aspecto a ter em mente é que a soma de verificação não é exclusiva para um padrão de bits específico na página. Duas páginas podem mapear para o mesmo valor de soma de verificação. Portanto, existe a possibilidade remota de que a corrupção da página não seja detectada.

Referência: soma de verificação no SQL2005

Para responder especificamente às suas perguntas:

Acredito que o Checksum foi introduzido no SQL2005 e que a atualização ou restauração de um banco de dados de uma versão anterior manteria seu método de verificação de página anterior. ou seja, não houve atualização implícita.

Sim, o CHECKSUM foi introduzido no SQL Server 2005 e é o PADRÃO . Ao atualizar de 2000 para 2005, é necessário alterar explicitamente a opção de verificação de página do banco de dados para usar CHECKSUM.

Se você restaurar o banco de dados já criado no sql 2005 para outro servidor executando o sql 2005, não será necessário configurá-lo. Ele persistirá para o que você definiu como opção de verificação da página.

Não consegui pesquisar quando a Detecção de página rasgada chegou

De: http://support.microsoft.com/kb/230785

Versões do SQL Server anteriores à 7.0

As versões do SQL Server anteriores à 7.0 não forneciam paridade de log ou recursos de detecção de bits rasgados. De fato, essas versões podem gravar a mesma página de log várias vezes até que os registros preencham a página de log de 2 KB. Isso pode expor transações que foram confirmadas com êxito. Se a página de log estiver sendo reescrita durante uma falha, um setor com a transação confirmada pode não ser reescrito corretamente.

Portanto, TORN_PAGE_DETECTION existe desde o SQL Server 7.0. Mesmo assim, o padrão era que não estava ativado (mesmo link) .

Nota A detecção de página rasgada não está habilitada por padrão no SQL Server 7.0. Veja sp_dboption para saber como habilitar a detecção em seu sistema.

Portanto, se o banco de dados fosse desenvolvido em uma instância 7.0 e posteriormente atualizado, ele teria atualizado a opção PAGE VERIFY existente de NONE (como @ThomasStringer observou em sua resposta).


Edição: 24/09/2013 Para melhorar a resposta:

Referindo-me às minhas anotações internas do SQL Server do SQLSkills, descobri que, usando um despejo de página, é possível verificar se a detecção de bits rasgados - TORN_PAGE_DETECTION ou CHECKSUM foi ativada ou não:

use database_name -- change here for your database !!
checkpoint
go 
dbcc traceon (3604)   -- send output to screen
go
dbcc page (dbaalert, 1,1,0)
dbcc traceoff (3604)  -- turn off the trace flag
go

m_tornBits : mantém a soma de verificação da página ou os bits que foram deslocados pelos bits de proteção de página rasgada - dependendo de qual forma de proteção de página está ativada para o banco de dados.

Nota : Não tenho versões mais antigas do servidor sql em execução. Abaixo está confirmado a partir do sql server 2000 e superior . Se você tem um 7.0 ou 6.5 rodando, também pode confirmá-lo :-)

insira a descrição da imagem aqui

Kin Shah
fonte
@Kin sim, eu sei que também existia no SQL2000, gostaria de saber quando foi introduzido pela primeira vez. pela frase "migrando para versões anteriores", vamos fazer de conta que o TPD foi introduzido no SQL2000; em seguida, migrar do SQL7 para o SQL2000 passaria entre as versões anteriores ao SQL2005. Estou interessado em saber se o TPD foi ativado durante essas migrações. Eu espero totalmente que não seria, mas não foi capaz de verificar isso.
Paul
@ Paulo I excluído-los porque eu senti que a minha edição abrangeu a comentários
swasheck
@Kin Eu tentei o seu código DBCC no SQL2008R2 e obtive um valor m_tornbits de 1711843878 .. então é uma medida, e não um booleano, você diria?
Paul
@Paul significa que a página checksum ou torm está ativada. A partir de 2005, você deve ir apenas para CHECKSUM. Querendo saber se você tem algum 7.0 por aí para testar?
Kin Shah
6

Veja a referência da BOL :

Quando um banco de dados do usuário ou do sistema é atualizado para o SQL Server 2005 ou uma versão posterior, o valor PAGE_VERIFY (NONE ou TORN_PAGE_DETECTION) é mantido. Recomendamos que você use CHECKSUM

Isso determina que, antes do SQL Server 2005, a opção TORN_PAGE_DETECTIONexistia, mas não CHECKSUM.

E para responder seu segundo ponto:

... e que atualizar ou restaurar um banco de dados de uma versão anterior manteria seu método de verificação de página anterior.

Sim, está correto. Você precisaria definir explicitamente o banco de dados para utilizar o CHECKSUMmétodo de verificação da página.

Thomas Stringer
fonte
Obrigado pela referência @Thomas, mas isso não responde quando TORN PAGE DETECTION ficou disponível pela primeira vez no SQL Server.
Paul
2
@Paul Isso responde que a detecção de página rasgada existia antes do SQL Server 2005. Você está procurando qual versão do SQL Server essa verificação de página entrou em jogo? Além de uma lição de história, não sei ao certo o que você deseja obter lá. Que problema exatamente você está tentando resolver?
22813 Thomas Stringer
Eu estava procurando saber quando ele surgiu e como se comportou durante as migrações. Espero entender como alguns de nossos DBs muito antigos passaram a ter as configurações que eles fazem em alguns de nossos servidores modernos (ish, SQL2008R2).
Paul
Se os seus bancos de dados tiverem TORN_PAGE_DETECTION, isso certamente poderá resultar em uma atualização do pré-SQL Server 2005 e a opção de verificação da página persistirá.
22613 Thomas Stringer
eles não têm o TPD ativado, essa foi a parte desconcertante. Outras respostas têm proporcionado a solução para a questão agora (SQL7.0 teve TPD, mas não habilitado por padrão e esta foi a versão originalmente desenvolvido contra)
Paul
3

Existem duas opções diferentes no SQL Server moderno para verificação de página

Existem três como você declarou: TORN_PAGE_DETECTION, CHECKSUM e NONE.

Acredito que CHECKSUM foi introduzido no SQL Server 2005

Conforme citado neste artigo do MSDN intitulado "Gerenciamento de buffer": A detecção de página rasgada foi introduzida no SQL Server 2000. A soma de verificação foi introduzida no SQL Server 2005.

Uma sinopse de outras coisas observadas neste artigo é que o mecanismo de verificação da página é especificado no momento da criação do banco de dados. Portanto, depende de quem e como eles criaram o banco de dados, para o que está definido, também pode ser controlado pelo modelo de banco de dados configurado. Também interessante notar é que, se você alterar a configuração, ela não afetará todo o banco de dados, somente quando a página for gravada na próxima. De acordo com Paul Randal, isso é feito apenas quando a página é lida na memória, alterada e depois gravada de volta no disco; essa informação está aqui .

Eu tenho um banco de dados de produção que entrou em produção usando o SQL Server 2000, embora possa ter sido desenvolvido no SQL Server 7.0 e, desde então, foi transferido para um servidor SQL Server 2008 R2. A verificação de página está definida como NENHUM, embora eu esperasse que fosse DETECÇÃO DE PÁGINAS TORNADAS.

Qualquer pessoa que tenha permissões para a instância do banco de dados pode modificar esse valor. Poderia ter persistido através de atualizações, conforme indicado no MSDN aqui :

Quando um banco de dados do usuário ou do sistema é atualizado para o SQL Server 2005 ou uma versão posterior, o valor PAGE_VERIFY (NONE ou TORN_PAGE_DETECTION) é mantido

Também poderia ter sido modificado posteriormente porque alguém não entendeu a configuração e estava atirando no escuro para tentar resolver um problema.

Gostaria de saber quando TORN PAGE DETECTION se tornou um recurso de verificação de página

SQL Server 2000, conforme indicado acima.

como ele se comporta quando migrado ou atualizado para edições mais recentes.

A configuração anterior é mantida durante a atualização, conforme indicado acima.

Agora, gostaria de salientar o fato de que outros links fornecidos por pessoas afirmam que o SQL Server 7.0 é quando a detecção de página rasgada estava disponível. O que, conforme mencionado nesses artigos, é verdadeiro, no entanto, é comprovado muitas vezes que a documentação da Microsoft não deve ser considerada verdadeira em todas as circunstâncias. Há muitos onde eles estão errados. Então, com isso dito, como você pode determinar qual resposta é aceitável? Todos nós fornecemos documentação da Microsoft para apoiar nossa resposta.

Observe também que a detecção de página rasgada está na lista de depreciação do SQL Server 2012, então qual é a preocupação com a forma como foi definida nos bancos de dados para começar. Se o vi definido como algo diferente de CHECKSUM, mudei-o imediatamente e segui para outra tarefa mais importante. Não tenho nenhuma preocupação sobre como uma configuração ruim foi implementada; é mais importante corrigi-la e garantir que aqueles que têm permissões para alterá-la sejam informados do motivo pelo qual esse item de configuração não deve ser alterado para outra coisa. Apenas meus $ 0,02

Shawn Melton
fonte
Eu acho que 2000 foi quando o TPD assumiu o padrão ON. Como em muitos outros novos recursos do SQL Server, eles o liberam como desativado / desativado por padrão e forçam os DBAs a ativá-lo. De qualquer forma, +1 de mim para o aviso de descontinuação.
swasheck 19/09/13
É um bom ponto, você tem um bom link que parece fazer backup do que você diz. Mas sinto que o link fornecido por outra pessoa ( support.microsoft.com/kb/230785 ) o substitui. É mais provável que eu ache que a seção de gerenciamento de buffer entendeu meio errado do que o outro link, totalmente errado. Se isso faz sentido, não tenho certeza absoluta de que estou me saindo muito bem!
Paul Paul
É uma daquelas coisas como licenciamento, nada MS põe para fora sobre isso é muito clara ou ...
Shawn Melton
0

Como o @Thomas Stringer e o @Kin disseram, ele foi introduzido no SQL Server 2005 e acredito que funciona em todas as edições do SQL Server. Para TempDB, embora o CHECKSUM tenha sido introduzido no SQL Server 2008

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/23/checksum-and-tempdb.aspx

DaniSQL
fonte
Obrigado @DaniSQL, no entanto, ninguém respondeu à pergunta na íntegra ainda. isto é, quando foi introduzida a DETECÇÃO DE PÁGINAS PÁGINAS e como se comportou durante as atualizações / migrações.
Paul
Deixarei que os historiadores descubram :-) Quanto à atualização / migrações, nada acontecerá, a menos que você altere manualmente a opção de verificação da página para CHECKSUM em cada banco de dados. Mesmo assim, as páginas já existentes não terão soma de verificação. blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/29/…
DaniSQL
obrigado @DaniSQL, é assim que entendo as migrações para o SQL2005 e superior para que funcionem. Eu só queria ter certeza de que as versões anteriores também manteve esse comportamento
Paul