Recuperar banco em modo Suspected

Este é um dos momentos altos na vida de um DBA ou administrador de sistemas: o banco não está disponível, o sistema não funciona e o seu telefone não pára! O ideal é que o bom administrador tenha sempre suas cópias de segurança (backup) atualizadas, backup de log de transações, snapshots, enfim, esteja pronto para o pior. Abaixo seguem uma seqüência de comandos que normalmente ajudam nestas horas: EXEC sp_resetstatus 'Banco-em-Suspect'; ALTER DATABASE [Banco-em-Suspect] SET EMERGENCY; DBCC CHECKDB('Banco-em-Suspect'); ALTER DATABASE [Banco-em-Suspect] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DBCC CHECKDB('Banco-em-Suspect', REPAIR_ALLOW_DATA_LOSS); ALTER DATABASE [Banco-em-Suspect] SET MULTI_USER; Explicando os comandos EXEC sp_resetstatus 'Banco-em-Suspect' Reseta o status de 'Suspect' do banco de dados. O log de erros do SQL Server deve ser consultado e todos os problemas resolvidos antes de executar esta stored procedure. Pare e reinicie a instância do SQL Server após rodarsp_resetstatus. ALTER DATABASE [Banco-em-Suspect] SET EMERGENCY O banco de dados é marcado como READ_ONLY (somente leitura), o log está desabilitado e o acesso fica limitado a quem faz parte da função fixa de servidorsysadmin. DBCC CHECKDB('Banco-em-Suspect') DBCC CHECKDB('Banco-em-Suspect', REPAIR_ALLOW_DATA_LOSS) Verifica a integridade física e lógica de todos os obejtos do banco de dados. A opção REPAIR_ALLOW_DATA_LOSS tenta reparar todos os erros relatados. Esses reparos podem provocar alguma perda de dados.

Use as opções REPAIR apenas como um último recurso. Para reparar erros, recomendo restaurar de um backup. Operações de reparo não consideram nenhuma das restrições que podem existir em tabelas ou entre tabelas. Se a tabela especificada estiver envolvida em uma ou mais restrições, recomendo executar DBCC CHECKCONSTRAINTS após uma operação de reparo. Se for necessário usar REPAIR, execute DBCC CHECKDB sem uma opção de reparo para localizar o nível de reparo a ser usado. Se você usar o nível de REPAIR_ALLOW_DATA_LOSS, recomendo fazer backup do banco de dados antes de executar DBCC CHECKDB com essa opção.

ALTER DATABASE [Banco-em-Suspect] SET SINGLE_USER WITH ROLLBACK IMMEDIATE ALTER DATABASE [Banco-em-Suspect] SET MULTI_USER SINGLE_USER especifica que somente um usuário por vez pode acessar o banco de dados. ROLLBACK IMMEDIATE especifica que a reversão (rollback) deve ser feita imediatamente. MULTI_USER libera o banco para acesso de todos os usuários após a verificação. Agora faltam as devidas observações e comentários para e considerações em versões anteriores ao SQL Server 2005. Lembrem-se: Nada como um bom e velho backup!