恢复差异备份会创建DEFUNCT日志文件吗？

这是我的问题。我正在尝试通过完全还原将数据库移动到新服务器，然后使用快速差异备份/还原进行切换。我可以完全还原，但是还原差异备份时会收到以下警告：

消息3127，级别16，状态1，行1还原的数据库'DatabaseName'的文件'Database_Log2'处于关闭状态，因为该数据库正在使用简单恢复模型，并且该文件被标记为可读写访问。因此，只能通过逐段还原来恢复只读文件。

数据库已还原并被视为联机，但是由于此DEFUNCT文件而导致的任何备份操作失败，并出现以下错误：

消息3636，级别16，状态2，行1处理数据库ID 10文件ID 6的“ BackupMetadata”元数据时发生错误。消息3046，级别16，状态2，行1元数据不一致。唯一可能的备份操作是使用WITH CONTINUE_AFTER_ERROR或NO_TRUNCATE选项进行尾日志备份。消息3013，级别16，状态1，第1行BACKUP DATABASE异常终止。

如果我对完整文件和差异文件执行RESTORE FILELISTONLY，则两者都给我相同的输出，这与我从源数据库上的sys.database_files中看到的输出匹配。服务器为Developer Edition上的SQL2012 SP1。

我可以进行完整备份，然后立即进行差异处理，然后将这些文件还原到同一服务器上的其他数据库中，并看到完全相同的问题，因此造成差异的原因与创建差异有关。如果使用“恢复”还原完整备份，则没有问题。我不知道该文件是否曾经存在于该数据库中，但是该文件很可能曾经存在并且很久以前就被删除了。如果我在已还原的数据库上查询sys.database_files，则DEFUNCT文件具有drop_lsn的值，似乎可以确认这一点。当前，源数据库中只有一个文件组（PRIMARY），4个数据文件和一个日志文件。

有任何想法吗？

下面是重现此步骤的步骤，这些步骤已在SQL 2012 SP1 Developer Edition上进行了测试。在SQL 2008上不会发生这种情况。总而言之，当模型数据库处于SIMPLE恢复状态时在SQL 2012中创建的数据库在具有额外的日志文件的情况下进行了完整备份，如果该额外的日志文件为曾经被删除。

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

我在这里为此错误提交了一个Connect项目。我能够删除此已失效文件的唯一方法是分离数据库，然后使用ATTACH_REBUILD_LOG重新附加。

更新：在我的repro脚本中创建此方案的错误似乎已通过以下KB修复：https : //support.microsoft.com/en-us/kb/2830400。从注释中可以看出，SQL2012 / 2014可以使用其他修复程序，方案看起来非常相似：https : //support.microsoft.com/zh-cn/kb/3009576