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

Оновлення : @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'

Повідомлення про помилку :

Msg 3241, рівень 16, стан 40, рядок 11 Сімейство носіїв на пристрої "D: \ тимчасово-короткочасне \ 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) 11 липня 2016 22:05:22 Авторські права (c) Microsoft Corporation Enterprise Edition (64-розрядна) на Windows Server 2012 R2 Standard 6.3 (збірка 9600 :)

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

Додавання FORMATдо BACKUPкоманди вирішило це для мене.

Хоча я не можу знайти конкретну документацію, я вважаю, що це пов'язано з тим, що INITзберігає існуючий медіа-заголовок у наборі резервних копій, FORMATстворюючи новий медіа-заголовок.

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

Схоже, це могло бути вирішено з KB 4032200:

• Виправлення: Не вдалося стиснути файл резервного копіювання, коли параметр INIT і COMPRESSION використовується в базі даних TDE у SQL Server 2016

З цього запису:

Симптоми

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

Дозвіл

Ця проблема виправлена ​​в наступних сукупних оновленнях для SQL Server:

• Сукупне оновлення 7 для RTM SQL Server 2016
• Сукупне оновлення 4 для SQL Server 2016 SP1

Можливо, це може бути те саме, що публікація в блозі, на яку ви посилалися у своєму запиті, пізніше була оновлена, щоб посилатися на:

Оновлення 6 квітня 2017 року

Нещодавно ми виявили деякі проблеми, пов’язані з використанням TDE та стиснення резервного копіювання в SQL Server 2016. Хоча ми їх виправляємо, ось декілька порад, які допоможуть вам не стикатися з відомими проблемами:

• В даний час не доцільно використовувати смугасті резервні копії з TDE та стисканням резервного копіювання

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

• Наразі уникайте використання З INIT під час роботи з TDE і резервного стиснення. Натомість зараз ви можете використовувати FOR FORAT.

Інженерія SQL працює над виправленням цих проблем у SQL Server 2016. Ми знову оновимо цю публікацію в блозі, як тільки матимемо додаткову інформацію.

Незважаючи на цю примітку, повідомлення блогу з цього часу не оновлювалося жодними додатковими відомостями.

Однак KB 4019893 може також вирішити це питання:

• ВИПРАВЛЕННЯ: Не вдалося відновити під час резервного копіювання за допомогою стиснення та контрольної суми в базі даних TDE у SQL Server 2016

Хоча повідомлення про помилку, повідомлене в статті KB, відрізняється від того, про яке ви повідомляєте, фактори, що сприяють, звучать дуже схоже. SQL Server 2016 SP1 CU3 вперше включив виправлення, як показано у його списку виправлень . Однак надійшло повідомлення про те, що це не вирішило це питання у всіх ситуаціях.

SQL Server 2016 SP1 CU4 також включає виправлення для цього (імовірно, оновлене) , і KB 4019893 з тих пір оновлено, щоб показати SP1 CU4 як версію, в якій було виправлено проблему.

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

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