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 d ...