Impossible de restaurer la base de données compatible TDE lorsque MAXTRANSFERSIZE et CHECKSUM sont utilisés

Mise à jour : @AmitBanerjee - Responsable de programme principal pour le groupe de produits Microsoft SQL Server a confirmé que MS examinera le problème car il s'agit d'un défaut.

Quelqu'un a-t-il rencontré un problème de restauration des sauvegardes effectuées sur SQL Server 2016 avec TDE activé et en utilisant MAXTRANSFERSIZE> 65536 (dans mon cas, j'ai choisi 65537 pour pouvoir compresser la base de données TDE ) et CHECKSUM?

Ci-dessous une repro:

--- 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

Prendre une copie de sauvegarde complète seulement .. faites-le deux fois ..

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

Maintenant, faites un verifyonly...

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

Message d'erreur :

Msg 3241, niveau 16, état 40, ligne 11 La famille de supports sur le périphérique «D: \ temporaire-à court terme \ test_restore_KIN_test_restore_1.bak» est incorrectement formée. SQL Server ne peut pas traiter cette famille de supports. Msg 3013, niveau 16, état 1, ligne 11 VERIFY DATABASE se termine anormalement.

Résultats (1 = ON, 0 = OFF) avec différentes combinaisons:

+-------------------------+-------------+----------+--------+
| 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   |
+-------------------------+-------------+----------+--------+

Le problème se produit sur:

Microsoft SQL Server 2016 (RTM-CU1) (KB3164674) - 13.0.2149.0 (X64) 11 juillet 2016 22:05:22 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) sur Windows Server 2012 R2 Standard 6.3 (Build 9600 :)

J'ai pu reproduire votre problème.

L'ajout FORMATà la BACKUPcommande l'a résolu pour moi.

Bien que je n'arrive pas à trouver de documentation concrète, je pense que cela est lié au fait que INITconserve l'en-tête de média existant sur le jeu de sauvegarde tout en FORMATcréant un nouvel en-tête de média.

Je suis toujours à la recherche de ce problème et si je trouve des informations supplémentaires, je mettrai à jour cette réponse.

Il semble que cela aurait pu être résolu avec KB 4032200:

• CORRECTIF: échec de compression du fichier de sauvegarde lorsque l'option INIT et COMPRESSION est utilisée dans une base de données activée TDE dans SQL Server 2016

De cette entrée:

Symptômes

Supposons que vous activez le chiffrement transparent des données (TDE) pour une base de données dans Microsoft SQL Server 2016. Vous essayez de sauvegarder la base de données en utilisant l' BACKUP DATABASEinstruction T-SQL qui a les deux COMPRESSIONet l' INIToption spécifiée. Dans ce scénario, vous pouvez remarquer que le fichier de sauvegarde existant est remplacé par le nouveau fichier de sauvegarde et que le nouveau fichier de sauvegarde n'est pas compressé.

Résolution

Ce problème est résolu dans les mises à jour cumulatives suivantes pour SQL Server:

• Mise à jour cumulative 7 pour SQL Server 2016 RTM
• Mise à jour cumulative 4 pour SQL Server 2016 SP1

Il semblerait que ce soit le même problème que le billet de blog auquel vous avez fait référence dans votre question a été mis à jour par la suite pour faire référence à:

Mise à jour du 6 avril 2017

Nous avons récemment découvert certains problèmes liés à l'utilisation de TDE et de la compression de sauvegarde dans SQL Server 2016. Bien que nous les résolvions, voici quelques conseils pour vous aider à éviter de rencontrer ces problèmes connus:

• Actuellement, il n'est pas conseillé d'utiliser des sauvegardes par bandes avec TDE et la compression de sauvegarde

• Si votre base de données contient des fichiers journaux virtuels (VLF) supérieurs à 4 Go, n'utilisez pas la compression de sauvegarde avec TDE pour vos sauvegardes de journaux. Si vous ne savez pas ce qu'est un VLF, commencez ici .

• Évitez d'utiliser WITH INIT pour l'instant lorsque vous travaillez avec TDE et la compression de sauvegarde. Au lieu de cela, pour l'instant, vous pouvez utiliser WITH FORMAT.

L'ingénierie SQL travaille sur des correctifs pour ces problèmes dans SQL Server 2016. Nous mettrons à jour ce billet de blog une fois que nous aurons d'autres informations à partager.

Malgré cette note, le blog n'a pas été mis à jour avec plus d'informations depuis lors.

Cependant, KB 4019893 peut également résoudre ce problème:

• CORRECTIF: la restauration échoue lorsque vous effectuez une sauvegarde à l'aide de la compression et de la somme de contrôle sur une base de données activée TDE dans SQL Server 2016

Bien que le message d'erreur signalé dans cet article de la base de connaissances soit différent de celui que vous signalez, les facteurs contributifs semblent très similaires. SQL Server 2016 SP1 CU3 a tout d'abord inclus le correctif, comme indiqué dans sa liste de correctifs . Cependant, selon certaines informations , cela n'a pas résolu le problème dans toutes les situations.

SQL Server 2016 SP1 CU4 comprend également un correctif (vraisemblablement mis à jour) pour cela , et KB 4019893 a depuis été mis à jour pour afficher SP1 CU4 comme la version dans laquelle le problème a été résolu.

Malheureusement, je peux confirmer de ma propre expérience que même le correctif dans SP1 CU4 ne résout pas complètement ce problème. J'ai actuellement une base de données compatible TDE qui produit toujours des sauvegardes systématiquement corrompues, même sur SP1 CU4 lors de l'utilisation COMPRESSION(via MAXTRANSFERSIZE> 64 Ko) et CHECKSUM. J'ai également plusieurs dizaines d'autres bases de données compatibles TDE dans cet environnement qui ne produisent pas systématiquement de sauvegardes corrompues sous ces paramètres, dont une qui est une variante de celle qui le fait, avec un schéma presque identique mais un ensemble de données plus petit. Cela semblerait indiquer que Microsoft réduit en effet les scénarios qui peuvent provoquer cela, mais ne les a pas encore tous résolus.

Je n'ai pas encore essayé d'utiliser FORMATpour contourner ce problème, comme référencé dans une autre réponse et le billet de blog SQLCAT , mais je fournirai une mise à jour ici si je peux essayer cela et cela résout le problème. La seule base de données que je possède qui le reproduit est malheureusement assez volumineuse (~ 1 To) et réside dans un cluster de développement / AQ qui n'a pas beaucoup d'espace de stockage supplémentaire disponible (au moins à cette échelle), donc tester des variations de cela a s'est avéré être un défi logistique et chronophage.