Il ripristino del backup differenziale crea il file di registro DEFUNCT?

Ecco il mio problema Sto cercando di spostare un database su un nuovo server tramite un ripristino completo, quindi il ritaglio con un backup / ripristino differenziale rapido. Posso eseguire un ripristino completo senza problemi, ma quando ripristino il backup differenziale, ricevo il seguente avviso:

Messaggio 3127, livello 16, stato 1, riga 1 Il file 'Database_Log2' del database ripristinato 'DatabaseName' viene lasciato nello stato defunto perché il database utilizza il modello di recupero semplice e il file è contrassegnato per l'accesso in lettura / scrittura. Pertanto, solo i file di sola lettura possono essere recuperati mediante ripristino frammentario.

Il database viene ripristinato ed è considerato online, ma qualsiasi operazione di backup non riesce a causa di questo file DEFUNCT con il seguente errore:

Messaggio 3636, livello 16, stato 2, riga 1 Si è verificato un errore durante l'elaborazione dei metadati "BackupMetadata" per l'ID file ID database 10 6. Messaggio 3046, livello 16, stato 2, riga 1 Sono stati rilevati metadati incoerenti. L'unica operazione di backup possibile è un backup del registro di coda che utilizza l'opzione WITH CONTINUE_AFTER_ERROR o NO_TRUNCATE. Messaggio 3013, livello 16, stato 1, riga 1 BACKUP DATABASE termina in modo anomalo.

Se eseguo un RESTORE FILELISTONLY in modo completo e differenziale, entrambi mi danno lo stesso output, che corrisponde a quello che vedo dai file sys.database_files sul database di origine. Il server è SQL2012 SP1, nell'edizione per sviluppatori.

Posso fare un backup completo, e subito dopo fare un differenziale, e ripristinare questi file su un database diverso sullo stesso server e vedere lo stesso identico problema, quindi c'è qualcosa con il modo in cui viene creato il differenziale che sta causando questo. Se ripristino il backup completo CON RECUPERO non ci sono problemi. Non so se questo file esistesse in questo database, ma è del tutto possibile che questo file esistesse ed è stato eliminato molto tempo fa. Se eseguo una query su sys.database_files sul database ripristinato, il file DEFUNCT ha un valore per drop_lsn, che sembra confermare questo. Attualmente nel database di origine è presente un solo filegroup (PRIMARY), 4 file di dati e un file di registro.

Qualche idea?

Ecco i passaggi per riprodurlo, testato su SQL 2012 SP1 Developer Edition. Ciò non si verifica in SQL 2008. Per riassumere, un database creato in SQL 2012 mentre il database del modello è in recupero SEMPLICE, con un backup completo eseguito mentre esiste un file di registro aggiuntivo, non può creare backup differenziali utilizzabili se quel file di registro aggiuntivo è mai cancellato.

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

Ho inviato un articolo Connect per questo bug qui . L'unico modo in cui sono stato in grado di rimuovere questo file defunto è di staccare il database e ricollegarlo con ATTACH_REBUILD_LOG.

AGGIORNAMENTO: il bug che crea questo scenario nel mio script repro sembra essere stato corretto da questo KB: https://support.microsoft.com/en-us/kb/2830400 . Dai commenti sembra che sia disponibile una correzione aggiuntiva per SQL2012 / 2014, gli scenari sembrano molto simili: https://support.microsoft.com/en-us/kb/3009576