Impossibile ripristinare il database abilitato per TDE quando si utilizzano MAXTRANSFERSIZE e CHECKSUM

Aggiornamento : @AmitBanerjee - Senior Program Manager per il gruppo di prodotti Microsoft SQL Server ha confermato che MS esaminerà il problema in quanto si tratta di un difetto.

Qualcuno ha riscontrato problemi durante il ripristino dei backup eseguiti su SQL Server 2016 con TDE abilitato e utilizzando MAXTRANSFERSIZE> 65536 (nel mio caso, ho scelto 65537 in modo da poter comprimere il database TDE ) e CHECKSUM?

Di seguito è una riproduzione:

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

Prendi il backup completo solo della copia .. fallo due volte ..

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

Ora fai un verifyonly...

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

Messaggio di errore :

Messaggio 3241, livello 16, stato 40, riga 11 La famiglia di supporti sul dispositivo "D: \ temporary-short-term \ test_restore_KIN_test_restore_1.bak" è formata in modo errato. SQL Server non può elaborare questa famiglia di supporti. Messaggio 3013, livello 16, stato 1, riga 11 VERIFY DATABASE si sta chiudendo in modo anomalo.

Risultati (1 = ON, 0 = OFF) con diverse combinazioni:

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

Il problema si verifica su:

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

Sono stato in grado di riprodurre il tuo problema.

L'aggiunta FORMATal BACKUPcomando ha risolto il problema per me.

Sebbene non riesca a trovare una documentazione concreta, è mia opinione che ciò sia correlato al fatto che INITmantiene l'intestazione del supporto esistente sul set di backup mentre FORMATcrea una nuova intestazione del supporto.

Sto ancora cercando questo problema e se trovo ulteriori informazioni, aggiornerò questa risposta.

Sembra che questo potrebbe essere stato risolto con KB 4032200:

• FIX: impossibile comprimere il file di backup quando si utilizza l'opzione INIT e COMPRESSION in un database abilitato TDE in SQL Server 2016

Da quella voce:

Sintomi

Si supponga che si attiva Transparent Data Encryption (TDE) per un database di Microsoft SQL Server 2016. Si tenta di eseguire il backup del database utilizzando l' BACKUP DATABASEistruzione T-SQL che ha sia COMPRESSIONe INITopzione specificata. In questo scenario, è possibile notare che il file di backup esistente viene sovrascritto dal nuovo file di backup e che il nuovo file di backup non è compresso.

Risoluzione

Questo problema è stato risolto nei seguenti aggiornamenti cumulativi per SQL Server:

• Aggiornamento cumulativo 7 per SQL Server 2016 RTM
• Aggiornamento cumulativo 4 per SQL Server 2016 SP1

Questo sembra potenzialmente essere lo stesso problema a cui il post sul blog a cui hai fatto riferimento nella tua domanda è stato successivamente aggiornato per fare riferimento a:

Aggiornamento 6 aprile 2017

Di recente abbiamo scoperto alcuni problemi relativi all'utilizzo di TDE e alla compressione del backup in SQL Server 2016. Mentre li risolviamo, ecco alcuni suggerimenti per aiutarti a evitare di imbatterti in questi problemi noti:

• Attualmente non è consigliabile utilizzare backup con striping con TDE e compressione del backup

• Se il tuo database ha file di log virtuali (VLF) di dimensioni superiori a 4 GB, non utilizzare la compressione di backup con TDE per i tuoi backup di log. Se non sai cos'è un VLF, inizia qui .

• Evitare di utilizzare WITH INIT per ora quando si lavora con TDE e la compressione del backup. Invece, per ora puoi usare WITH FORMAT.

L'ingegneria SQL sta lavorando su correzioni per questi problemi in SQL Server 2016. Aggiorneremo nuovamente questo post sul blog una volta che avremo ulteriori informazioni da condividere.

Nonostante questa nota, il post sul blog non è stato aggiornato con ulteriori informazioni da allora.

Tuttavia, 4019893 KB può anche risolvere questo problema:

• FIX: il ripristino non riesce quando si esegue il backup utilizzando la compressione e il checksum su un database abilitato TDE in SQL Server 2016

Sebbene il messaggio di errore riportato nell'articolo KB sia diverso da quello che stai segnalando, i fattori che contribuiscono sembrano molto simili. SQL Server 2016 SP1 CU3 includeva innanzitutto la correzione, come si vede nel suo elenco di aggiornamenti rapidi . Tuttavia, è stato riferito che non ha risolto il problema in tutte le situazioni.

SQL Server 2016 SP1 CU4 include anche una correzione (presumibilmente aggiornata) per questo , e da allora KB 4019893 è stato aggiornato per mostrare SP1 CU4 come versione in cui è stato risolto il problema.

Sfortunatamente, posso confermare dalla mia esperienza che anche la correzione in SP1 CU4 non risolve completamente quel problema. Al momento ho un database abilitato per TDE che produce ancora backup costantemente corrotti anche su SP1 CU4 quando si utilizza COMPRESSION(tramite MAXTRANSFERSIZE> 64 KB) e CHECKSUM. Ho anche diverse dozzine di altri database abilitati TDE in questo ambiente che costantemente non producono backup corrotti in quelle impostazioni, incluso uno che è una variazione di quello che fa, con uno schema quasi identico ma un set di dati più piccolo. Ciò sembrerebbe indicare che Microsoft sta effettivamente eliminando gli scenari che possono causare questo, ma non li ha ancora risolti tutti.

Non ho ancora provato FORMATa risolvere questo problema, come indicato in un'altra risposta e nel post del blog SQLCAT , ma fornirò un aggiornamento qui se sono in grado di provarlo e risolve il problema. L'unico database che ho che riproduce questo è purtroppo piuttosto grande (~ 1 TB), e risiede in un cluster di sviluppo / QA che non ha molto spazio di archiviazione aggiuntivo (almeno su quella scala), quindi testare varianti di questo ha dimostrato di essere logisticamente impegnativo e che richiede tempo.