使用MAXTRANSFERSIZE和CHECKSUM时，无法还原启用TDE的数据库

更新：@AmitBanerjee -Microsoft SQL Server产品组的高级程序经理，确认MS将调查此问题，因为它是缺陷。

有没有人遇到在启用TDE并使用MAXTRANSFERSIZE> 65536的情况下还原在SQL Server 2016上进行的备份的问题（对于我而言，我选择了65537，以便可以压缩TDE数据库）和CHECKSUM？

下面是一个副本：

--- create database 
create database test_restore
go
-- create table
create table test_kin (fname char(10))
go
-- Enable TDE 

use master
GO
CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert'
GO
SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore'
GO
use test_restore
go
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE test_restore
GO 
alter database test_restore set encryption ON

只做完整副本备份..做两次..

backup database test_restore 
to disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak' -- change as per your location !!
with init, stats =10  -- overwrite ..using INIT !!
, maxtransfersize = 65537
, compression
,CHECKSUM

现在做一个verifyonly...

restore verifyonly from disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak'

错误信息 ：

消息3241，第16级，状态40，第11行第设备'D：\ temporary-short-term \ test_restore_KIN_test_restore_1.bak'上的媒体系列格式错误。SQL Server无法处理此媒体系列。消息3013，级别16，状态1，第11行验证数据库异常终止。

不同组合的结果（1 =开，0 =关）：

+-------------------------+-------------+----------+--------+
| MAXTRANSFERSIZE (65537) | COMPRESSION | CHECKSUM | RESULT |
+-------------------------+-------------+----------+--------+
|                       1 |           1 |        1 | FAIL   |
|                       1 |           1 |        0 | PASS   |
|                       1 |           0 |        1 | FAIL   |
|                       0 |           0 |        0 | PASS   |
|                       0 |           1 |        1 | PASS   |
|                       0 |           1 |        0 | PASS   |
+-------------------------+-------------+----------+--------+

问题发生在：

Microsoft SQL Server 2016（RTM-CU1）（KB3164674）-13.0.2149.0（X64）2016年7月11日22:05:22版权所有（c）Windows Server 2012 R2 Standard 6.3（Build 9600）上的Microsoft Corporation Enterprise Edition（64位） :)

我能够重现您的问题。

添加FORMAT到BACKUP命令为我解决了。

虽然我似乎找不到具体的文档，但我认为这与以下事实有关：INIT在FORMAT创建新的媒体头时，将现有媒体头保留在备份集上。

我仍在研究此问题，如果我发现其他信息，我将更新此答案。

似乎KB 4032200已解决此问题：

• FIX：无法在SQL Server 2016中启用TDE的数据库中使用INIT和COMPRESSION选项时压缩备份文件

从该条目：

病征

假设您在Microsoft SQL Server 2016中为数据库启用了透明数据加密（TDE）。您尝试使用BACKUP DATABASE同时指定COMPRESSION和INIT选项的T-SQL语句来备份数据库。在这种情况下，您可能会注意到现有的备份文件被新的备份文件覆盖，并且新的备份文件未压缩。

解析度

SQL Server的以下累积更新中已解决此问题：

• SQL Server 2016 RTM的累积更新7
• SQL Server 2016 SP1的累积更新4

这似乎是与您在问题中引用的博客帖子后来被更新为引用相同的问题：

2017年4月6日更新

最近，我们发现了一些与SQL Server 2016中TDE的使用和备份压缩有关的问题。在修复这些问题的同时，以下一些技巧可帮助您避免遇到那些已知问题：

• 当前不建议将带区备份与TDE和备份压缩一起使用

• 如果您的数据库具有大于4GB的虚拟日志文件（VLF），则不要将TDE的备份压缩用于日志备份。如果您不知道什么是VLF，请从此处开始。

• 在使用TDE和备份压缩时，请避免现在使用WITH INIT。相反，现在您可以使用WITH FORMAT。

SQL工程部门正在针对SQL Server 2016中的这些问题进行修复。一旦有更多信息要分享，我们将再次更新此博客文章。

尽管有该说明，但此后该博客帖子尚未更新任何其他信息。

但是，KB 4019893也可以解决此问题：

• FIX：当您通过在SQL Server 2016中启用TDE的数据库上使用压缩和校验和进行备份时，还原将失败

尽管该知识库文章中报告的错误消息与您所报告的错误消息不同，但其影响因素听起来非常相似。SQL Server 2016 SP1 CU3首先包含此修复程序，如其修复程序列表所示。但是，有报告称它不能在所有情况下都解决问题。

SQL Server 2016 SP1 CU4也对此进行了修复（可能已更新），并且KB 4019893已更新为将SP1 CU4显示为已解决该问题的版本。

不幸的是，我可以根据自己的经验确认即使SP1 CU4中的修复程序也不能完全解决该问题。我目前有一个启用TDE的数据库，即使使用COMPRESSION（通过MAXTRANSFERSIZE> 64 KB）和，即使在SP1 CU4上，该数据库仍会产生持续损坏的备份CHECKSUM。在此环境中，我还有数十个其他启用TDE的数据库，这些数据库在这些设置下始终不会产生损坏的备份，其中包括一个数据库的损坏备份，它具有几乎相同的架构，但数据集较小。这似乎表明Microsoft确实在设法解决可能导致这种情况的情况，但尚未解决所有问题。

我还没有尝试过使用FORMAT该方法来解决此问题，如另一个答案和SQLCAT 博客文章中所引用的那样，但是如果可以尝试并解决了问题，我将在此处提供更新。不幸的是，我拥有一个可以重现此数据的数据库，它相当大（〜1 TB），并且驻留在一个Development / QA集群中，该集群没有太多可用的存储空间（至少在该规模下），因此测试该数据库的变体事实证明，这在后勤方面具有挑战性且耗时。