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?

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

Mas no SQL 2005 e superior, uma nova configuração PAGE_VERIFY substituiu o antigo 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 dirá se os dados armazenados nesses 512 byes estão realmente corretos ou não devido ao fato de que alguns bytes podem ter sido gravados incorretamente.

CHECKSUM - irá calcular uma soma de verificação da página tanto quando uma página é escrita quanto quando uma página é lida, assumindo que tem checksum nela.

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, ele 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, presume-se que a página não foi corrompida durante o ciclo de leitura e gravação.

Como o custo de calcular a soma de verificação é incorrido em cada leitura e gravação de página, isso pode aumentar a sobrecarga da CPU e possivelmente afetar o rendimento de sua carga de trabalho. Outra coisa 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 ser mapeadas para o mesmo valor de checksum. Portanto, há uma 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 Checksum foi introduzido no SQL2005 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. ou seja, não houve atualização implícita.

Sim CHECKSUM foi introduzido no SQL Server 2005 e é o DEFAULT . Ao atualizar de 2000 para 2005, você precisa alterar explicitamente a opção do banco de dados Page Verify 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 na opção Verificar página.

Não consegui pesquisar quando a detecção de página rasgada entrou

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

Versões do SQL Server anteriores a 7.0

Versões do SQL Server anteriores à 7.0 não forneciam paridade de log ou recursos de detecção de bits interrompidos. Na verdade, essas versões podem gravar a mesma página de log várias vezes até que os registros de log preencham a página de log de 2 KB. Isso pode expor transações que foram confirmadas com sucesso. 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 habilitado (mesmo link) .

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

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

Editar: 24/09/2013 Para melhorar a resposta:

Referindo-me às minhas notas internas do SQL Server de SQLSkills, descobri que, usando um despejo de página, você pode verificar se a detecção de bit interrompido - TORN_PAGE_DETECTION ou CHECKSUM foi ativado 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 : contém a soma de verificação da página ou os bits que foram deslocados pelos bits de proteção de página interrompida - dependendo de qual forma de proteção de página está ativada para o banco de dados.

Observação : não tenho nenhuma versão mais antiga do SQL Server em execução. Abaixo está confirmado do sql server 2000 e superior . Se você tem um 7.0 ou 6.5 rodando, pode confirmar também :-)

Dê uma olhada na referência do BOL :

Quando um usuário ou banco de dados do sistema é atualizado para SQL Server 2005 ou uma versão posterior, o valor PAGE_VERIFY (NONE ou TORN_PAGE_DETECTION) é retido. 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 ao 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 de página.

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

Existem três como você afirmou: 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 de página é especificado no momento da criação do banco de dados. Portanto, depende de quem e como eles criaram o banco de dados quanto ao que está definido, também pode ser controlado por qual modelo de banco de dados está configurado. Também é interessante observar que, se você alterar a configuração, ela não afetará todo o banco de dados, apenas quando a próxima página for gravada. Também de acordo com Paul Randal, isso só é feito 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, movido para um servidor SQL Server 2008 R2. A verificação de página está definida como NONE, embora eu esperasse que fosse DETECÇÃO DE PÁGINA RASGADA.

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

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

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

Eu queria saber quando a DETECÇÃO DE PÁGINA RASGADA 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 apontar o fato de que outros links fornecidos por pessoas afirmam que o SQL Server 7.0 é quando a detecção de página interrompida estava disponível. O que, conforme declarado nesses artigos, é verdade, 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 a partir do SQL Server 2012, então qual é a preocupação com a forma como ela foi definida em seus bancos de dados para começar. Se eu o vir configurado para algo diferente de CHECKSUM, imediatamente o altero e passo para outra tarefa mais importante. Não tenho nenhuma preocupação sobre como uma configuração ruim foi implementada, é mais importante corrigi-la e, em seguida, garantir que aqueles que têm permissões para alterá-la sejam informados sobre o motivo pelo qual esse item de configuração não deve ser alterado para qualquer outra coisa. Apenas meus $ 0,02

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

Link