Невозможно восстановить базу данных с поддержкой TDE, когда используются MAXTRANSFERSIZE и CHECKSUM

10

Обновление : @AmitBanerjee - старший менеджер программы для группы продуктов Microsoft SQL Server подтвердил, что MS рассмотрит проблему, поскольку она является дефектом.

Кто-нибудь сталкивался с проблемой восстановления резервных копий, сделанных на SQL Server 2016 с включенным TDE и использованием MAXTRANSFERSIZE> 65536 (в моем случае я выбрал 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: \ временное-краткосрочное \ test_restore_KIN_test_restore_1.bak' сформировано неправильно. SQL Server не может обработать это семейство носителей. Сообщение 3013, уровень 16, состояние 1, строка 11, VERIFY DATABASE завершается ненормально.

Результаты (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) 11 июля 2016 г. 22:05:22 Авторское право (c) Microsoft Corporation Enterprise Edition (64-разрядная версия) на Windows Server 2012 R2 Standard 6.3 (сборка 9600) :)

sql-server restore sql-server-2016 transparent-data-encryption Кин Шах
источник

Ответы:

6

Я смог воспроизвести вашу проблему.

Добавление FORMATв BACKUPкоманду решило это для меня.

Хотя я не могу найти конкретную документацию, я считаю, что это связано с тем, что INITсохраняет существующий заголовок носителя в резервном наборе, в то время как FORMATсоздается новый заголовок носителя.

Я все еще исследую эту проблему, и если я найду дополнительную информацию, я обновлю этот ответ.

Скотт Ходжин
источник
да, FORMATзаголовок будет также перезаписывать, и это не происходит при использовании FORMAT. Тем не менее, это загадка, почему заголовок резервной копии (или резервная копия в целом) поврежден при использовании MAXTRANSFERSIZEи CHECKSUMвместе с INIT. Это никогда не случалось на более низких версиях, но в тех не было MAXTRANSFERSIZE. Спасибо за Ваш ответ. Будет держать это открытым, если у кого-то есть больше информации.
Кин Шах
3

Похоже, что это может быть решено с помощью KB 4032200:

Из этой записи:

симптомы

Предположим, что вы включили прозрачное шифрование данных (TDE) для базы данных в Microsoft SQL Server 2016. Вы пытаетесь выполнить резервное копирование базы данных с помощью BACKUP DATABASEоператора T-SQL, в котором указаны оба параметра COMPRESSIONи INITпараметр. В этом случае вы можете заметить, что существующий файл резервной копии перезаписывается новым файлом резервной копии, а новый файл резервной копии не сжимается.

разрешение

Эта проблема исправлена ​​в следующих накопительных обновлениях для SQL Server:

Пол Уайт 9
источник
1

Возможно, это та же самая проблема, на которую позже было добавлено сообщение в блоге, на которое вы ссылались в своем вопросе:

Обновление 6 апреля 2017

Недавно мы обнаружили некоторые проблемы, связанные с использованием TDE и сжатием резервных копий в SQL Server 2016. Пока мы их исправляем, вот несколько советов, которые помогут вам избежать этих известных проблем:

  • В настоящее время не рекомендуется использовать чередующиеся резервные копии с TDE и сжатие резервных копий.

  • Если в вашей базе данных есть файлы виртуальных журналов (VLF) размером более 4 ГБ, не используйте сжатие резервных копий с TDE для резервного копирования журналов. Если вы не знаете, что такое VLF, начните здесь .

  • Избегайте использования WITH INIT на данный момент при работе с TDE и сжатием резервных копий. Вместо этого вы можете использовать WITH FORMAT.

SQL engineering работает над исправлением этих проблем в SQL Server 2016. Мы обновим этот пост еще раз, как только у нас появится дополнительная информация для обмена.

Несмотря на это, с тех пор пост в блоге не обновлялся.

Тем не менее, KB 4019893 может также решить эту проблему:

Хотя сообщение об ошибке, о котором сообщается в этой статье базы знаний, отличается от того, о котором вы сообщаете, способствующие факторы звучат очень похоже. SQL Server 2016 с пакетом обновления 1 (SP1) CU3 впервые включил исправление, как видно из его списка исправлений . Тем не менее, были сообщения, что это не решило проблему во всех ситуациях.

SQL Server 2016 с пакетом обновления 1 (SP1) CU4 также содержит исправление (предположительно обновленное) , и с тех пор KB 4019893 был обновлен и теперь показывает SP1 CU4 как версию, в которой исправлена ​​проблема.

К сожалению, я могу подтвердить из собственного опыта, что даже исправление в SP1 CU4 не решает полностью эту проблему. В настоящее время у меня есть одна база данных с поддержкой TDE, которая по-прежнему создает постоянно поврежденные резервные копии даже на SP1 CU4 при использовании COMPRESSION(через MAXTRANSFERSIZE> 64 КБ) и CHECKSUM. У меня также есть несколько десятков других баз данных с поддержкой TDE в этой среде, которые постоянно не создают поврежденных резервных копий при этих настройках, включая ту, которая является вариацией той, что делает, с почти идентичной схемой, но меньшим набором данных. Казалось бы, это указывает на то, что Microsoft действительно отказывается от сценариев, которые могут вызвать это, но еще не разрешила все из них.

Я еще не пытался использовать FORMATдля решения этой проблемы, как указано в другом ответе и сообщении в блоге SQLCAT , но я предоставлю здесь обновление, если смогу попробовать, и это решит проблему. У меня есть одна база данных, которая воспроизводит это, к сожалению, довольно большая (~ 1 ТБ) и находится в кластере Development / QA, который не имеет большого свободного места для хранения (по крайней мере, в таком масштабе), поэтому тестирование вариантов этого имеет доказано, что логистически сложным и трудоемким.

Кевин М. Оуэн
источник
Эта проблема все еще существует в SQL 2017.
swaroopa kothapally