Início / dba / Perguntas / 63354
Accepted
FilamentUnities
Asked: 2014-04-17 07:54:34 +0800 CST

Restaurar backup diferencial cria arquivo de log DEFUNCT?

  • 772

Aqui está o meu problema. Estou tentando mover um banco de dados para um novo servidor por meio de uma restauração completa e, em seguida, substituir com um rápido backup/restauração diferencial. Posso fazer uma restauração completa sem problemas, mas ao restaurar o backup diferencial, recebo o seguinte aviso:

Msg 3127, Nível 16, Estado 1, Linha 1 O arquivo 'Database_Log2' do banco de dados restaurado 'DatabaseName' está sendo deixado no estado extinto porque o banco de dados está usando o modelo de recuperação simples e o arquivo está marcado para acesso de leitura/gravação. Portanto, somente arquivos somente leitura podem ser recuperados por meio da restauração gradual.

O banco de dados é restaurado e é considerado online, mas qualquer operação de backup falha devido a este arquivo DEFUNCT com o seguinte erro:

Msg 3636, Nível 16, Estado 2, Linha 1 Ocorreu um erro ao processar os metadados 'BackupMetadata' para o banco de dados id 10 arquivo id 6. Msg 3046, Nível 16, Estado 2, Linha 1 Foram encontrados metadados inconsistentes. A única operação de backup possível é um backup de final de log usando a opção WITH CONTINUE_AFTER_ERROR ou NO_TRUNCATE. Msg 3013, Nível 16, Estado 1, Linha 1 BACKUP DATABASE está terminando de forma anormal.

Se eu fizer um RESTORE FILELISTONLY no full e no diferencial, ambos me darão a mesma saída, que corresponde ao que vejo em sys.database_files no banco de dados de origem. O servidor é SQL2012 SP1, na edição Developer.

Posso fazer um backup completo e imediatamente depois fazer um diferencial e restaurar esses arquivos em um banco de dados diferente no mesmo servidor e ver exatamente o mesmo problema, então há algo em como o diferencial é criado que está causando isso. Se eu restaurar o backup completo COM RECUPERAÇÃO, não há problema. Não sei se este arquivo existia neste banco de dados, mas é perfeitamente possível que este arquivo existisse e tenha sido excluído há muito tempo. Se eu consultar sys.database_files no banco de dados restaurado, o arquivo DEFUNCT terá um valor para drop_lsn, o que parece confirmar isso. Atualmente, no banco de dados de origem, há apenas um grupo de arquivos (PRIMARY), 4 arquivos de dados e um arquivo de log.

Alguma ideia?

sql-server sql-server-2012

1 respostas

  1. Best Answer

    Aqui estão as etapas para reproduzir isso, testadas no SQL 2012 SP1 Developer Edition. Isso não ocorre no SQL 2008. Para resumir, um banco de dados criado no SQL 2012 enquanto o banco de dados modelo está em recuperação SIMPLE, que tem um backup completo feito enquanto existe um arquivo de log extra, não pode criar backups diferenciais utilizáveis ​​se esse arquivo de log extra for alguma vez excluído. 

    ALTER DATABASE [model] SET RECOVERY SIMPLE
GO
CREATE DATABASE [DefunctTest]
GO
ALTER DATABASE [DefunctTest] ADD LOG FILE ( NAME = N'DefunctTest_log2', FILENAME = N'D:\DefunctTest_log2.ldf' , SIZE = 25600KB , FILEGROWTH = 10%)
GO
BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestPostLogFile.bak' WITH INIT
GO
ALTER DATABASE [DefunctTest]  REMOVE FILE [DefunctTest_log2]
GO

BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestFull.bak' WITH INIT
GO
BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestDiff.bak' WITH DIFFERENTIAL, INIT
GO
--Show that the backups only have the one log file.
RESTORE FILELISTONLY FROM DISK = 'D:\DefunctTestFull.bak'
RESTORE FILELISTONLY FROM DISK = 'D:\DefunctTestDiff.bak'
GO
RESTORE DATABASE [DefunctTest2] FROM DISK = 'D:\DefunctTestFull.bak' WITH 
MOVE 'DefunctTest' TO 'D:\DefunctTest2.mdf',
MOVE 'DefunctTest_log' TO 'D:\DefunctTest2_log.ldf', REPLACE, NORECOVERY
GO
--This restore will have the error.
RESTORE DATABASE [DefunctTest2] FROM DISK = 'D:\DefunctTestDiff.bak' WITH RECOVERY
GO

USE [DefunctTest2]
SELECT * FROM sys.database_files
GO

    Enviei um item Connect para este bug aqui . A única maneira de remover esse arquivo extinto é desanexar o banco de dados e reanexar com ATTACH_REBUILD_LOG.

    ATUALIZAÇÃO: O bug que cria esse cenário no meu script de reprodução parece ter sido corrigido por este KB: https://support.microsoft.com/en-us/kb/2830400 . Pelos comentários, parece que uma correção adicional está disponível para SQL2012/2014, os cenários parecem muito semelhantes: https://support.microsoft.com/en-us/kb/3009576

    • 5

relate perguntas