主页 / dba / 问题 / 158632
Accepted
Kin Shah
Asked: 2016-12-20 14:35:11 +0800 CST

使用 MAXTRANSFERSIZE 和 CHECKSUM 时无法恢复启用 TDE 的数据库

  • 772

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

MAXTRANSFERSIZE是否有人在启用 TDE 并使用> 65536（在我的情况下，我选择了 65537 以便我可以压缩 TDE 数据库）的情况下恢复在 SQL Server 2016 上进行的备份时遇到问题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 = ON，0 = OFF）：

+-------------------------+-------------+----------+--------+
| 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) Microsoft Corporation Enterprise Edition (64-bit) o​​n Windows Server 2012 R2 Standard 6.3 (Build 9600) :)

sql-server restore

3 个回答

  1. Best Answer

    我能够重现您的问题。

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

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

    我仍在研究这个问题，如果我找到更多信息，我会更新这个答案。

    • 6

  2. 似乎这可能已通过 KB 4032200 解决：

    从那个条目：

    症状

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

    解析度

    此问题已在 SQL Server 的以下累积更新中得到修复：

    • 3

  3. 这似乎与您在问题中引用的博客文章后来更新为引用的问题相同：

    2017 年 4 月 6 日更新

    我们最近发现了一些与 SQL Server 2016 中使用 TDE 和备份压缩相关的问题。虽然我们修复了这些问题，但这里有一些提示可以帮助您避免遇到这些已知问题：

    • 目前不建议使用带 TDE 和备份压缩的条带备份

    • 如果您的数据库具有大于 4GB 的虚拟日志文件 (VLF)，则不要将备份压缩与 TDE 一起用于日志备份。如果您不知道 VLF 是什么，请从这里开始。

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

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

    尽管有这样的说明，但自那以后，博客文章还没有更新任何进一步的信息。

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

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

    SQL Server 2016 SP1 CU4 还包括一个（可能已更新）对此的修复，并且KB 4019893已更新以将 SP1 CU4 显示为修复问题的版本。

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

    正如另一个答案和 SQLCAT博客文章中所引用的那样，我尚未尝试使用FORMAT来解决此问题，但如果我能够尝试并解决问题，我将在此处提供更新。不幸的是，我拥有的一个能够重现此问题的数据库相当大（~1 TB），并且驻留在没有太多额外存储空间可用的开发/质量检查集群中（至少在那个规模上），因此测试它的变体有事实证明，在后勤方面具有挑战性且耗时。

    • 1

相关问题