Recuperando o banco SUSPECT criando um novo arquivo de LOG

Galera esse é um artigo relativamente simples e bem útil para o dia a dia do DBA, quem ainda não ficou de frente com um banco de dados corrompido?
Pois é irei mostrar uma maneira de recuperar um banco de dados em modo SUSPECT, criando um novo arquivo de LOG do banco. Claro que antes de realizar este procedimento tem que olhar o log do SQL Server e ver qual motivo o banco ficou suspect, se no log tiver a mensagem que não foi possível recuperar o arquivo de log e o banco foi marcado como suspeito então este scritp resolverá seu problema.

Este scritp é válido para o SQL Server 2000, pois o comando DBCC REBUILD_LOG foi descontinuado no SQL Server 2005 e 2008.

Segue script comentado:

--VOLTA BANCO SUSPECT CRIANDO OUTRO ARQUIVO DE LOG
/*
1° Passo -> Verificar porque o banco ficou suspect, se foi porque não conseguiu fazer recovery do arquivo de log
este script resolverá o problema
*/
--EXECUTAR TODOS OS SCRIPTS SEPARADAMENTE
--Executar este primeiro comando, com este configuração é possível alterar as tabelas de sistema
sp_configure 'allow updates',1
reconfigure with override
go
--Executar e verificar se o banco e as tabelas estão acessíveis
sp_resetstatus 'NomeBancoDeDados'
go
--Caso o comando acima não funcione, executa este comando que deixará o banco em emergency mode
Update sysdatabases set status = 32768   where name ='NomeBancoDeDados'
go
--Após o comando ser executado com sucesso, executar este comando para criar novo arquivo de log para o banco,
--passa o nome do banco e o caminho onde será criado o novo arquivo
DBCC Rebuild_log ('NomeBancoDeDados','C:\CAMINHO\NomeDoArquivo.ldf')
go
-- Aqui o banco já estará on line... Mas temos que verificar se existem erros de integridade
-- Vamos colocar o banco e modo single user
Use Neo
go
sp_dboption 'NomeBancoDeDados','single_user', true
go
--Executamos o comando para reparar os erros, caso existam
use master
go
dbcc checkdb ('NomeBancoDeDados',repair_allow_data_loss)
go
--Tirar o banco do modo single user
use Neo
go
sp_dboption 'NomeBancoDeDados','single_user', false
go
--Voltar este parametro para 0
sp_configure 'allow updates',0
reconfigure with override
go

Apenas explicando o parâmetro REPAIR_ALLOW_DATA_LOSS, quando uma página está corrompida ao usar este parâmetro no DBCC CHECKDB a página anterior simplesmente muda o ponteiro e aponta para a próxima página que estiver OK, então é possível que exista perda de dados. Então em qualquer situação de banco de dados corrompido o mais adequado é recuperar o backup.

Abraços,
Rodrigo Figueiredo
figueiredo.rodrigo@hotmail.com