SQL Server Database Corruption: o que fazer para evitar

Corrupções de dados acontecem a todo momento e seus motivos vão de problemas aleatórios a falhas no subsistema de I/O. Paul Randal, um dos maiores especialistas na área, sempre diz que as pessoas que nunca passaram por um cenário de corrupção durante a carreira são sortudas, pois em algum momento inevitavelmente irão passar por ela.

Sabendo que corrupções acontecem bastante, a questão principal é estar preparado para quando acontecer e ter a capacidade de identificar o quanto antes, pois em muitas situações ela só é encontrada tarde demais, quando já tomou proporções enormes e o estrago já foi feito. Esse tipo de caso acontece, por exemplo, pela falta de preparo em sua identificação ou o não entendimento dos alertas que o subsistema de I/O gera.

Levando em consideração estas informações, temos dois pontos principais:

· Quanto mais rápido a corrupção for identificada, mais facilmente você será capaz de efetuar a recuperação com menor inatividade e perda de dados;

· As pessoas não sabem o que fazer depois que detectam uma corrupção, o que leva diretamente a uma chance maior de perda de dados e tempo de inatividade do que é necessário.

Esses dois pontos são muito importantes, porque também impactam muitas vezes na saúde financeira da corporação, podendo levar ao afastamento do DBA.

Piores práticas

Muitos DBAs não têm ideia do que fazer quando uma corrupção de dados acontece. Em cenários reais, essa situação vem em conjunto com a pressão imediata dos superiores. Dessa maneira, processos de recuperação podem acabar sendo executados incorretamente, utilizando as piores práticas.

Uma das práticas mais comuns após a corrupção ser identificada é a reinicialização do SQL Server, em uma tentativa de possível correção após o serviço iniciar novamente. Essa prática, na grande maioria das vezes, irá apenas atrasar o processo de recuperação devido ao tempo de reinicialização.

Outra situação bem comum é partir para o último recurso de recuperação e causar a perda de dados. Por exemplo, executar a recuperação com a opção que permite a perda de dados sem avaliar a utilização dos backups ou, ainda pior, saber que existe uma corrupção, mas não utilizar o DBCC CHECKDB para identificar o tipo e a melhor opção para correção.

Remover o log de transação ou a base corrompida também são casos que já foram vistos por DBAs achando que ajudariam a corrigir a corrupção, quando na verdade só pioram mais levando a novos problemas.

Causa

É importante entender as diferentes causas de uma corrupção e porque é quase inevitável que ela aconteça. Em 99% das vezes é o subsistema de I/O que causa a corrupção. Pode-se entender como subsistema de I/O qualquer componente que esteja abaixo do SQL Server, sendo assim, as principais causas são as seguintes:

· Sistema Operacional: quando o SQL Server inicialmente escreve uma página de dados, ele pede ao Windows para que faça esse trabalho;

· File system: a execução é feita em cima de um sistema de arquivos, geralmente NTFS. Assim, podem haver File System Filter Drivers de terceiros instalados como antivírus, criptografia, etc;

· Placas de Rede/Switches/Cabos: a página será transportada através da infraestrutura de rede;

· Controlador de SAN/RAID: para acessar o disco, a página ainda terá que passar pela controladora do SAN (storage area network) e controladora do RAID (redundant array of independent disks).

Todo esse caminho demonstra a intensa movimentação que existe no subsistema de I/O, com várias partes móveis e códigos envolvidos. Toda vez que existem códigos escritos por desenvolvedores, existe um potencial de bug e as coisas podem dar errado. É por isso que existem os Services Packs, atualizações cumulativas para o SQL Server e também as atualizações no seu firmware.

Além dos 99% dos casos no qual a corrupção é causada pelo subsistema de I/O, existe o outro 1% com as possíveis causas:

· Corrupção de memória: páginas de dados do SQL Server são armazenadas no buffer pool, que é basicamente um grande bloco de memória cache. Dessa forma, os chips de memória que realmente armazenam aquele dado dentro do servidor podem falhar. Se um chip de memória falha, pode causar uma corrupção a uma porção de dados mantida na memória;

· Bugs do SQL Server: o SQL Server é um grande produto, tendo milhões de linhas de códigos. Ocasionalmente existem bugs no SQL Server que podem causar corrupção;

· Erro humano: essa é uma referência a uma pessoa fazendo algo que não deveria fazer manualmente. Por exemplo, colocar o banco de dados offline e editar o arquivo de dados do SQL Server ou excluir o arquivo de log de transações. Quando o serviço subir novamente, as transações ativas não poderão ser revertidas, causando corrupção de dados.

Existem muitos equívocos no entendimento dos causadores de corrupção, assim como, dos não causadores. Vejamos quais são eles:

· Qualquer coisa que a aplicação possa fazer;

· Qualquer operação que você possa fazer no SQL Server, desde que, com os comandos suportados e documentados;

· Interromper um shrink na base de dados, rebuild de índice ou queries de longa duração;

· Parar o serviço do SQL Server, a menos que exista algo ocorrendo por trás do SQL Server. Na realidade, o SQL Server é projetado para sofrer falhas e conseguir voltar, é por isso que temos o log de transações.

Propagação da corrupção

Nenhuma das tecnologias de redundância que o SQL Server tem (database mirroring, log shipping, replication e always on) vão propagar corrupção de arquivos de dados causados pelo subsistema de I/O. Esses recursos têm em comum o fato de todos enviarem registros ou blocos de transação e não páginas dos arquivos de dados do disco, sendo assim, caso o subsistema de I/O corrompa uma página em disco, essas tecnologias não enviarão a corrupção a um subsistema de I/O remoto.

Corrupção misteriosa

Esse fenômeno não é muito comum, mas existem situações nas quais uma corrupção é detectada em uma rotina automatizada que faz verificações de consistência. Entretanto, ao efetuar uma segunda verificação, a corrupção não aparece, levando a crer que o comando DBCC CHECKDB está com falha ou simplesmente deixando uma incógnita. Imagine o seguinte cenário: existe uma série de rotinas automáticas sendo executadas durante a madrugada, sendo que, entre elas temos uma verificação de integridade e uma manutenção de índice. O DBA recebe uma notificação no dia seguinte informando que uma corrupção foi detectada. Logo em seguida, ele executa o comando DBCC CHECKDB para analisar o tipo de corrupção, mas como foi dito antes, a corrupção não aparece.

A corrupção não desapareceu simplesmente na primeira vez que foi relatado, realmente a mesma tinha acontecido e provavelmente com uma notificação de corrupção em páginas atribuídas a um índice. Em seguida, a verificação de integridade, alguma outra rotina de manutenção de índice foi executada, ou seja, o índice que estava corrompido foi reconstruído e quando um índice é reconstruído ele monta uma nova estrutura de índice com novas páginas no arquivo de dados e, em seguida, tira as alocações das antigas páginas dos índices. Assim, eles não fazem mais parte da tabela.

Dessa forma, quando uma segunda verificação de integridade é feita, nenhuma inconsistência será encontrada no índice original, pois o mesmo foi reconstruído em uma rotina executada depois e novas páginas de dados estão sendo lidas.

Mecanismos de detecção e alerta

O SQL Server possui vários mecanismos integrados que lhe permite detectar e alertar automaticamente quando problemas de corrupção são encontrados durante operações de I/O. Existem quatro pontos que serão abordados nos tópicos em seguida:

· Proteção de Página - Torn-page Detection;

· Proteção de Página - Page Checksum;

· Diferentes tipos de erros de I/O;

· Monitoramento de erros de I/O.

Opções de proteção de página

O SQL Server possui uma maneira de manter protegidas as páginas de dados que estão no disco como um meio rápido de detectar corrupção quando uma página for lida na memória. As configurações de proteção a página de dados podem ser habilitadas ou alteradas, assim como mostra a Listagem 1.

Listagem 1. Alteração do nível de proteção da página de dados.

  USE MASTER
  GO
  /*COLOQUE O NOME DO BANCO DE DADOS E O TIPO DE PROTEÇÃO OPTADO*/
  ALTER DATABASE “NOME BD” SET PAGE_VERIFY “TIPO DE PROTEÇÃO”

Existem três tipos de opção para utilizar como configuração: checksum, torn-page detection ou nenhuma. Não importa qual tipo de opção você escolher, todo o trabalho é feito pela área do buffer pool, que é o bloco de memória onde o SQL Server mantém cópias das páginas do arquivo de dados.

Torn-Page Detection

No SQL Server, toda página de dados tem o tamanho de 8 Kb, sendo dividida em 16 blocos de discos com 512 bytes. Para uma página ser corretamente escrita no disco, cada um desses 16 blocos deve ser escrito de forma adequada, mas claro que é possível que uma página não seja escrita corretamente como, por exemplo, se a energia falhar ou o disco não conseguir capacidade suficiente para terminar de escrever esses 16 blocos. Torn-Page é exatamente quando acontece algum desses casos citados.

O SQL Server tem um mecanismo que permite detectar quando um Torn-Page acontece, sendo feito através de cálculos com os bits dos blocos e os cabeçalhos das páginas. Com esse mecanismo o SQL Server é capaz de detectar se uma página não foi completamente escrita.

Esse método é muito bom para detectar quando um Torn-Page ocorre, mas não permite ao SQL Server identificar quando aconteceu um problema ou uma corrupção dentro de um setor de disco.

Page Checksum

O Torn-Page Detection não pode detectar problemas que ocorrem no meio dos blocos de disco e é exatamente isso que o Page Checksum faz. Essa opção de verificação por página foi introduzida no SQL Server 2005 e todas as bases criadas a partir dessa versão já estão com essa configuração habilitada por padrão, menos o TempDB que teve que esperar até o SQL Server 2008 para poder também trabalhar com o Page Checksum.

Assim como o Torn-Page Detection, o Page Checksum também atua no buffer pool e sua lógica é simples. Há um valor de 4 Bytes que é calculado para o Page Checksum e guardado no cabeçalho da página, sendo este o último passo que o SQL Server realiza quando vai escrever uma página no disco. Quando uma página for lida novamente a partir do disco para memória, a primeira coisa que será feita é o recálculo do Page Checksum para verificar se o valor é igual ao que está armazenado na página. Caso o Page Checksum não esteja correto, o SQL Server sabe que algo abaixo dele corrompeu a página. Uma boa prática é sempre utilizar essa opção para os bancos de dados.

Uma página é verificada pelo Page Checksum nas seguintes condições:

· Sempre que é lida pelo Buffer Pool, seja normalmente ou por alguma rotina de verificação de consistência;

· No procedimento de backup, mas nesse caso o Buffer Pool não é utilizado, um canal próprio para os dados/log é aberto e sua leitura é feita diretamente;

· Se um backup tiver sido criado com a opção do Page Checksum habilitada, sempre que as pág ...