Reconstruindo o log de transações

Temos um banco de dados muito grande (~ 6 TB), cujo arquivo de log de transações foi excluído (enquanto o SQL Server foi desligado. Tentamos:

1. Desanexando e reconectando o banco de dados; e
2. Recuperando a exclusão do arquivo de log de transações

... mas nada funcionou até agora.

No momento, estamos executando:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... mas, considerando o tamanho do banco de dados, isso provavelmente levará alguns dias para ser concluído.

Questões

• Existe uma diferença entre o comando acima e o seguinte?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Em REPAIR_ALLOW_DATA_LOSSvez disso, deveríamos estar executando ?

Vale a pena notar que os dados são derivados de outras fontes para que o banco de dados possa ser reconstruído, no entanto, suspeitamos que será muito mais rápido reparar o banco de dados do que reinserir todos os dados novamente.

Atualizar

Para quem mantém a pontuação: o ALTER DATABASE/REBUILD LOGcomando foi concluído após cerca de 36 horas e relatou:

Aviso: O log do banco de dados 'dbname' foi reconstruído. A consistência transacional foi perdida. A cadeia RESTORE foi interrompida e o servidor não tem mais contexto nos arquivos de log anteriores, portanto, você precisará saber o que eles eram.
Você deve executar o DBCC CHECKDB para validar a consistência física. O banco de dados foi colocado no modo somente dbo. Quando estiver pronto para disponibilizar o banco de dados para uso, você precisará redefinir as opções do banco de dados e excluir todos os arquivos de log extras.

Em seguida, executamos um DBCC CHECKDB(demorou cerca de 13 horas) que foi bem-sucedido. Digamos que todos aprendemos a importância dos backups do banco de dados (e concedendo aos gerentes de projeto acesso ao servidor ...).

Nunca desanexe um banco de dados suspeito. De qualquer forma, como você anexou o banco de dados depois de desanexá-lo? Você usou CREATE DATABASEcomFOR ATTACH_REBUILD_LOG opção?

Estes comandos deveriam ter feito o truque:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Eu escrevi um post para esta situação:

Procedimento de recuperação de banco de dados SQL 2005/2008 - arquivo de log excluído (parte 3)

Você perguntou sobre a diferença entre:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) e
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

O problema é que você pode executar os dois para reconstruir o arquivo de log, mas com CHECKDBvocê reconstruir o log e verificar o banco de dados quanto a erros de integridade.

Além disso, o segundo (alterar banco de dados) não funcionará se houver transações ativas (não gravadas no disco) quando o arquivo de log for perdido. Na inicialização ou conexão, o SQL Server deseja executar a recuperação (reversão e reversão) do arquivo de log que não existe. Isso acontece quando um disco falha ou ocorre um desligamento inesperado do servidor e o banco de dados não é desligado corretamente. Acho que não foi o seu caso e tudo foi bom para você.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)executar em um banco de dados em status de emergência verifica se há erros de inconsistência no banco de dados, primeiro tenta usar o arquivo de log para recuperar-se de qualquer inconsistência. Se isso estiver faltando, o log de transações será reconstruído.

2. ALTER DATABASE REBUILD LOG ON...é um procedimento não documentado e requer um subseqüente DBCC CHECKDBpara corrigir qualquer erro.

Sim, essas são duas declarações diferentes, cada uma fazendo coisas muito diferentes.

Dependendo do estado do banco de dados quando o arquivo foi excluído, você poderá começar a funcionar anexando o banco de dados e reconstruindo o log usando:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Consulte sp_attach_single_file_db (Transact-SQL) na documentação do produto.

Veja também este post de Paul S. Randal :

Reparo no modo EMERGÊNCIA: o último, muito último recurso