Olá Pessoal,

O objetivo desse post é fazer um alerta a todos vocês que são responsáveis por um banco de dados SQL Server, seja você um desenvolvedor, um analista de banco de dados, um coordenador ou gerente de TI.

Já atendi muitos clientes na minha Consultoria SQL Server que contrataram um pacote de Tuning comigo, mas não quiseram contratar o pacote de reestruturação das rotinas de backups e alertas, pois ele já tinha um backup rodando no banco de dados ou tinha um servidor na nuvem onde existe uma garantia de alta disponibilidade do servidor virtual ou por outros motivos.

Acontece que mesmo com uma excelente rotina de backups você pode perder dados no SQL Server. Isso não é um problema exclusivo do SQL Server, dados também podem se corromper nos outros SGBDs do mercado (Oracle, DB2 e etc).

Em um exemplo real, um cliente me ligou pedindo ajuda depois que sua base estava corrompida. Ao fazer uma análise do nível de corrupção desse cliente, não seria possível recuperar essa base, pois páginas de estruturas internas da única tabela existente na base estavam corrompidas. Nem o comando CHECKDB com REPAIR_ALLOW_DATA_LOSS era possível ser executado nessa base dado o nível de corrupção. Solicitei os backups ao cliente e ele disse que tinha apenas um backup feito na semana anterior, mas que já tinha restaurado e o backup também já estava com a base corrompida.

Nesse caso, o backup era executado com sucesso, mas a base possuía páginas corrompidas. A única solução possível foi realizar um SELECT nos dados que ainda estavam sendo retornados e inserir esses dados em uma nova Base/Tabela.

Resultado: Perda de dados para a empresa.

Imagina se isso acontece com o banco de dados da sua empresa e com a tabela mais importante que existe?

Outro caso real e mais grave é contado pelo Paul Randal (cara que escreveu o CHECKDB). Um Banco dos EUA teve um problema de corrupção em um índice nonclustered. A princípio essa é uma corrupção simples de resolver, mas o DBA tomou uma série de ações erradas que aumentou ainda mais o problema. Chamaram o Paul Randal e após análise do ambiente ele pediu os backups para recuperar a base. O Banco tinha um backup FULL de 4 meses atrás e backups do Log até o dia do problema, tudo em fita. Milagrosamente, todos os backups foram restaurados com sucesso, mas o banco ficou parado por 2 dias para concluir essa operação. Os clientes que não conseguiram tirar extratos ou sacar seu dinheiro por dois dias mudaram de banco e logo em seguida o banco quebrou.

Resultado: Empresa falida e com uma contribuição significativa do DBA. Para verem o poder que esse profissional tem em mãos e muitas vezes isso não é valorizado até que um desastre como esse aconteça.

Mas o que pode ser feito para evitar ou amenizar esses problemas de corrupção?

• A primeira dica é cuidar muito bem do seu sistema de I/O (discos, drives, controladoras e etc).
• Cuidar do seu fornecimento de energia para evitar quedas inesperadas do seu servidor.
• Monitorar a tabela suspect_pages no MSDB.
• Monitorar os alertas 823, 824 e 825.
• Executar o CHECKDB com a maior frequencia possível, mas em horários não produtivos pois é um procedimento muito pesado. Em caso de encontrar uma corrupção, um alerta deve ser enviado imediatamente.
• Ter um Database Mirroring ou AlwaysOn Availability Groups configurado. Como essas tecnologias replicam log de transação, uma corrupção de página não é replicada para os servidores secundários. Além disso, em alguns casos, a página corrompida é recuperada automaticamente do servidor secundário para o servidor primário.  Isso já seria um grande motivo para convencer seu gerente a investir nessas tecnologias.
• Ter uma rotina de backup adequada com backups redundantes e realizar testes de restore com esses backups. Não adianta ter backup e o mesmo não funcionar na hora de restaurar por estar corrompido.

Evitar 100% uma corrupção não é possível, mas você deve ter meios de identificar essa corrupção o mais rápido possível para poder atuar e diminuir os impactos causados por essa corrupção.

Corrupções em banco de dados acontecem com mais frequência do que imaginamos, basta dar uma busca nos fóruns que encontrará várias threads com alguém solicitando ajuda em uma corrupção. Também vejo esses relatos em muitas listas de e-mail e agora até dos clientes que atendo como consultoria.

Para finalizar esse post, se você é responsável pela TI da sua empresa, possui um banco SQL Server e não tem ninguém com conhecimento para administrá-lo, você tem duas opções:

• Contratar um especialista SQL Server para analisar seu ambiente e criar os procedimentos necessários para alertar rapidamente em caso de corrupção.
• Treinar um de seus colaboradores para que possam realizar essas tarefas de administração do ambiente.

Espero ter contribuído para evitar que esse problema aconteça com vocês. Corrupção é o problema que mais me dá medo nos bancos de dados SQL Server que sou responsável.

Para refletir:

Backups, Alertas e Monitoramento é igual seguro de carro, tenho seguro de carro há 5 anos e nunca usei, contudo, o dia que meu carro for roubado, minhas perdas serão mínimas. Eu pago o seguro para ficar mais tranquilo.

O mesmo vale para um banco de dados de uma empresa que vale muito mais que um carro. Seu banco de dados pode estar há 5 anos sem nenhum problema, contudo, o dia que acontecer um problema grave e você não estiver preparado, suas perdas podem ser muito maiores do que seria se seu carro fosse roubado.

Vale a pena fazer um “seguro” do banco de dados da sua empresa?

Gostou desse Post?

Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Abraços,

Fabrício Lima

MCITP – Database Administrator

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006