Devo executar o DBCC checkdb antes dos backups completos? Ou depois?

Question

Temos uma mistura de servidores SQL 2000, 2005 e 2008, e sempre executamos um DBCC CHECKDB todas as noites antes dos backups completos, sob a teoria de que você quer ter certeza de que o banco de dados está em boa forma antes de você apoia-la. (Obviamente, a verificação completa dos backups só pode ser feita por meio de restaurações de teste, mas isso é um tópico ligeiramente diferente.)

Supondo que não posso descarregar os DBCCs em um servidor de backup ou algo assim (o que seria ideal), DBCC CHECKDB é seguido por FULL BACKUP a melhor seqüência?

O único documento de "melhores práticas" que encontrei para discutir isso foi um Melhores práticas para a manutenção do SQL Server para SAP de 2006 eu encontrei no TechNet:

Ideally, a consistency check using DBCC CHECKDB sould be run before performing an online database backup.

Este conselho está correto? Está correto para todas as versões do SQL?

(Caso isso ajude, parte da motivação para perguntar isso é que o tempo de execução do DBCC parece variar bastante da noite para a noite, então não podemos confiar exatamente quando os backups serão concluídos, o que torna o agendamento Além disso, se a manutenção for longa e precisar ser cancelada por qualquer motivo, prefiro que o backup seja concluído de forma confiável do que o DBCC.)

    

Answer 1

Outra coisa que você pode considerar, é se você tem outro servidor (Dev ou outro) que você pode usar para testar a restauração de seus arquivos de backup, você pode querer fazer isso lá. Então, RESTORE DATABASE e, em seguida, DBCC CHECKDB. Dessa forma, você não apenas está validando que seus arquivos de backup são bons, mas também está validando que os bancos de dados são bons sem afetar a produção.

Testamos a restauração de todos os nossos backups semanalmente para outro servidor e, em seguida, executamos o CHECKDB neles.

    

Answer 2

Aqui está a minha opinião ...

Em termos de capacidade de recuperação, não importa exatamente quando você executa o CHECKDB, mas pode ajudar a sua confiança sobre se o backup é bom ou não.

Diga que seu banco de dados está corrompido.

Quando seu pré-backup DBCC CHECKDB falhar, você saberá que seu backup subseqüente possivelmente não é bom.

Executando o backup primeiro, CHECKDB depois, você teria MUITO menos certeza de ter um backup bom ou ruim (existe a possibilidade de que a corrupção possa ter ocorrido entre o backup e o CHECKDB). Isso importa para você?

Eu diria que, enquanto você executa o CHECKDB regularmente, não importa exatamente quando. E como você mencionou, não há substituto para testes regulares de restaurações.

    

Answer 3

Se você não conseguir ajustar um DBCC CHECKDB completo em uma janela de manutenção, poderá adicionar COM CHECKSUM para suas rotinas de backup, e faça check-ins completos em um horário diferente (SQL 2005 e posterior).

Note que um BACKUP [...] com CHECKSUM não substitui o DBCC CHECKDB. Paul Randal tem mais detalhes aqui .

    

Answer 4

Também seria útil entender qual é a sua estratégia de recuperação se você determinar que há corrupção de dados. Se você pretende restaurar um ponto de falha, a execução do checkdb antes de um backup pode economizar tempo e perda de dados.