Recuperando um banco de dados que perdeu o arquivo de LOG (pt-BR)

Após um monitoramento de rotina, você depara com a seguinte mensagem:

Msg 945, Level 14, State 2, Line 2
Database 'Teste' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.

Após checar memória e disco, constata que está tudo em ordem.

Nesse caso, precisamos saber se existem outros bancos com problemas.

A view de sistema sys.databases pode nos auxiliar.

Ela retorna informações sobre o estado do banco de dados.

Observe atentamente a coluna state_desc, qualquer status diferente de online significa que há algo de errado com os bancos.

select * from sys.databases

Ao observar a coluna state_desc, encontramos um RECOVERY_PENDING.

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture2_thumb.png

Resta agora saber o que está causando esse status.

Para isso, vamos recorrer ao log da instância. 

Na pasta ManagemetSQL Server Logs e escolha o atual (current)

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture3_thumb.png

Ao clicar no log atual, os eventos do log serão mostrados.

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture4_thumb.png

Outra forma de se fazer isso é através de uma stored procedure chamada xp_readerrorlog.

A procedure xp_readerrorlog nos mostra as mesma informações que a ferrementa gráfica.

EXEC master..xp_readerrorlog

Veja o resultado:

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture5_thumb.png

Encontramos o motivo do recovery pending: um arquivo do banco listado foi removido ou corrompido, no caso, o arquivo de log.

Quando o SQL Server não encontra um arquivo, marca no status do banco como recovery pending e o banco fica inacessível.

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture1_thumb.png

Caso precise acessar os arquivos de dados provisóriamente, podemos colocar o banco de dados em modo de emergência.

O modo de emergência nos permite acessar o banco somente para leitura, sem suporte à transações.

USE MASTER
GO

ALTER DATABASE TESTE SET EMERGENCY

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture2_thumb1.png

Os objetos do banco estão acessíveis, podemos fazer select nas tabelas, mas não podemos criar nada de novo.

Aproveite para exportar os dados, pois backups não são permitidos com o banco em modo de emergência.

Agora é preciso adicionar um novo arquivo de log.

O banco de dados precisa estar em single user mode para que possamos repará-lo.

ALTER DATABASE TESTE SET SINGLE_USER

Devemos usar agora o DBCC CHECKDB para adicionar um arquivo de log novo ao banco.

DBCC CHECKDB (‘TESTE’, REPAIR_ALLOW_DATA_LOSS)

http://www.sqlinsiders.net/wp-content/uploads/2011/05/Capture_thumb.png

O DBCC CHECKDB não só verifica a consistência dos arquivos, ele também faz a manutenção do log caso tenha perdido.

Agora é só pôr o banco em multi_user e continuar trabalhando.

ALTER DATABASE TESTE SET MULTI_USER

Pronto! Banco preparado para o uso.