Aguarde… Carregando

Cliente diz: “Tenho Backups e meu banco está seguro”. Será???

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 pois 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ções?

  • 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 te 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 tiver 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

8 thoughts on “Cliente diz: “Tenho Backups e meu banco está seguro”. Será???

  1. Olá Fabrício,

    Fiquei curioso com seu artigo.
    Como sou leigo neste assunto, pergunto se você poderia me sanar minhas curiosidades.

    1)- Se existem tantas probabilidades de ocorrer corrupções em DBs , quais as razões de se ter poucos procedimentos e mesmo assim,como você cita, são apenas para monitorar e diminuir a ocorrência ?

    2)- Fico na dúvida se os produtos não são lá grande coisa ou alguns DBAs tem forte participação nas corrupções.

    Parabéns pelo artigo.
    Abraços
    Rapanelli

    1. Boa Noite Rapanelli,

      1) O número de corrupções que acontecem não é pequeno, mas comparado a quantidade de ambientes existentes, o percentual é muito baixo. entendeu?

      Não tenho como medir esses números, mas já vi acontecer em alguns bancos e também em fóruns existem bastante relatos. Para algumas pessoas, corrupção é uma coisa de outro mundo e nunca vai acontecer com ele.

      Chuto que acontece em menos de 1 % dos ambientes. Mas transformando esses 1% em quantidade, afeta bastante gente.

      2) O problema é que discos, drivers, controladoras e etc são coisas feitas pelo homem e estão sujeitas a bugs e o disco tem um tempo de vida. Outro fator que influencia são problemas de desligamentos inesperados. O DBA dificilmente causa uma corrução. O papel dele é descobrir uma o mais rápido possível e ter conhecimento para saber o que fazer para recuperar o ambiente. Após corrompido ele pode piorar ainda mais a situação tomando uma decisão errada.

      Mesmo acontecendo em menos de 1% dos ambientes, um desses ambientes pode ser o seu. Por isso essa preocupação deve existir.

      Espero ter sido claro.

  2. Muito bom seu artigo falando sobre Backups e sua importancia. Acredito que foi em 2011 ou em 2012, onde eu reformulei a politica de backups da empresa onde trabalho, pois os backups funcionavam da seguinte forma: um full diário, mas esse backup começava a partir das 12h, ou seja, se acontecesse alguma coisa com a base no dia posterior, vc só teria um backup e informacóes do dia anterior, em linhas gerais, vc perderia 1 dia de informaçao e isso é muito. A politica que eu adotei foi fazer um full as 7h e a cada 2 logs, ele fazia um diferencial. Isso era feito ate as 19h quando acaba o expediente. Isso é feito de 2 a sábado. Quando eu terminei de implementar a politica de backups (isso foi na segunda feira), como eu sou bem audacioso, eu implantei na produção. E quando foi na terça-feira, justamente as 11:20h, o que aconteceu? Houve uma queda de energia muito forte e quando retornou (as 13h aproximadamente) e que retornou os servidores com o SQL Server, o que aconteceu? O Sistema interno nao estava funcionando, dizia que nao encontrava a base nem nada. Fui olhar no servidor, o desastre: a base se corrompeu! Efetuei um CHECKDB e tudo, mas sem sucesso! Ai entao, tive de fazer uma copia da base fisica com problema e criar novamente a base e efetuar o restore com o backup do ultimo momento do desastre. Adivinha?! Tudo certinho e o sistema voltou ao normal, sem perda de dados nenhuma. Confesso que fui irresponsavel ao implantar sem antes testar se estava funcionando corretamente, mas eu sou assim, um pouco audacioso nas coisas, gosto de ver as coisas funcionando a vera mesmo e o resultado foi muito bom! E detalhe: estudei as policitas de backups no seu site mesmo Fabricio e no site tambem da microsoft, pois eu nao sabia muita coisa a respeito disso, fiz curso e tudo, porém, o instrutor nao foi muito didático, infelizmente! Mas parabens Fabricio pelo artigo.

  3. Muito bom Fabrício!!

    Coincidentemente começamos na nossa empresa a sugerir aos clientes a realização de testes de restore para evitar problemas.

    Outra situação que já vi é de clientes que ele faziam backups full e de log constantemente e da forma correta, então resolveram a fazer backups também com outra solução externa como o BackupExec, pra “melhorar” a segurança, utilizando duas ferramentas e consequentemente bagunçando toda a cadeia de backups…

Deixe uma resposta

%d blogueiros gostam disto: