Início / dba / Perguntas / 854
Accepted
Fuzzy Purple Monkey
Asked: 2011-01-25 18:46:26 +0800 CST

Reconstruindo o log de transações

  • 772

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 o arquivo de log de transações

... mas nada funcionou até agora.

Atualmente estamos executando:

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

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

Perguntas

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

      DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

  • Devemos estar executando REPAIR_ALLOW_DATA_LOSSem vez disso?

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

Atualizar

Para aqueles que 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 quais 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, será necessário redefinir as opções do banco de dados e excluir quaisquer arquivos de log extras.

Em seguida, executamos um DBCC CHECKDB(levou cerca de 13 horas) que foi bem-sucedido. Vamos apenas dizer que todos nós aprendemos a importância dos backups de banco de dados (e conceder aos gerentes de projeto acesso ao servidor...).

sql-server sql-server-2005

2 respostas

  1. Best Answer

    Nunca desconecte um banco de dados suspeito. De qualquer forma, como você anexou o banco de dados depois de desanexá-lo? Você usou CREATE DATABASEcom FOR ATTACH_REBUILD_LOGopção?

    Esses comandos devem 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 ambos para reconstruir o arquivo de log, mas com CHECKDBvocê reconstruir o log e verificar se há erros de integridade no banco de dados também.

    Além disso, o segundo (alter database) não funcionará se houver transações ativas (não gravadas no disco) quando o arquivo de log for perdido. Na inicialização ou anexação, o SQL Server desejará realizar a recuperação (reversão e reversão) do arquivo de log que não está lá. Isso acontece quando um disco trava 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 se resolveu bem para você.

    1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)executado em um banco de dados em estado de emergência verifica o banco de dados quanto a erros de inconsistência, tenta primeiro usar o arquivo de log para recuperar quaisquer inconsistências. Se isso estiver ausente, o log de transações será reconstruído.

    2. ALTER DATABASE REBUILD LOG ON...é um procedimento não documentado e requer um posterior DBCC CHECKDBpara corrigir quaisquer erros.

    • 20

  2. 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á iniciar e executar 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 esta postagem no blog de Paul S. Randal :

    Reparação em modo EMERGÊNCIA: o último recurso

    • 12

relate perguntas