Início / dba / Perguntas / 158632
Accepted
Kin Shah
Asked: 2016-12-20 14:35:11 +0800 CST

Não é possível restaurar o banco de dados habilitado para TDE quando MAXTRANSFERSIZE e CHECKSUM são usados

  • 772

Atualização : @AmitBanerjee - Gerente de Programa Sênior do Grupo de Produtos do Microsoft SQL Server confirmou que a MS examinará o problema, pois é um defeito.

Alguém encontrou problemas ao restaurar backups feitos no SQL Server 2016 com TDE habilitado e usando MAXTRANSFERSIZE> 65536 (no meu caso, escolhi 65537 para poder compactar o banco de dados TDE ) e CHECKSUM?

Abaixo segue uma reprodução:

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

Faça backup completo apenas da cópia .. faça duas vezes ..

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

Agora faça um verifyonly...

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

Mensagem de erro :

Msg 3241, nível 16, estado 40, linha 11 A família de mídia no dispositivo 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak' está formada incorretamente. O SQL Server não pode processar esta família de mídia. Msg 3013, Nível 16, Estado 1, Linha 11 VERIFY DATABASE está terminando de forma anormal.

Resultados (1 = ON, 0 = OFF) com diferentes combinações:

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

O problema acontece em:

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

sql-server restore

3 respostas

  1. Best Answer

    Consegui reproduzir seu problema.

    Adicionar FORMATao BACKUPcomando resolveu para mim.

    Embora eu não consiga encontrar documentação concreta, é minha opinião que isso está relacionado ao fato de que INITretém o cabeçalho de mídia existente no conjunto de backup enquanto FORMATcria um novo cabeçalho de mídia.

    Ainda estou pesquisando esse problema e, se encontrar informações adicionais, atualizarei esta resposta.

    • 6

  2. Parece que isso pode ter sido resolvido com o KB 4032200:

    A partir dessa entrada:

    Sintomas

    Suponha que você habilite Transparent Data Encryption (TDE) para um banco de dados no Microsoft SQL Server 2016. Você tenta fazer backup do banco de dados usando a BACKUP DATABASEinstrução T-SQL que tem a opção COMPRESSIONe INITespecificada. Nesse cenário, você pode observar que o arquivo de backup existente é substituído pelo novo arquivo de backup e o novo arquivo de backup não é compactado.

    Resolução

    Esse problema foi corrigido nas seguintes atualizações cumulativas para o SQL Server:

    • 3

  3. Isso parece ser potencialmente o mesmo problema que a postagem do blog que você mencionou em sua pergunta foi atualizada posteriormente para se referir a:

    Atualização em 6 de abril de 2017

    Descobrimos recentemente alguns problemas relacionados ao uso de TDE e compactação de backup no SQL Server 2016. Enquanto os corrigimos, aqui estão algumas dicas para ajudá-lo a evitar esses problemas conhecidos:

    • Atualmente não é aconselhável usar backups distribuídos com TDE e compactação de backup

    • Se seu banco de dados tiver arquivos de log virtual (VLFs) maiores que 4 GB, não use compactação de backup com TDE para seus backups de log. Se você não sabe o que é um VLF, comece aqui .

    • Evite usar WITH INIT por enquanto ao trabalhar com TDE e compactação de backup. Em vez disso, por enquanto você pode usar WITH FORMAT.

    A engenharia SQL está trabalhando em correções para esses problemas no SQL Server 2016. Atualizaremos esta postagem do blog mais uma vez assim que tivermos mais informações para compartilhar.

    Apesar dessa nota, a postagem do blog não foi atualizada com mais informações desde então.

    No entanto, o KB 4019893 também pode abordar isso:

    Embora a mensagem de erro relatada nesse artigo da base de conhecimento seja diferente daquela que você está relatando, os fatores contribuintes parecem muito semelhantes. O SQL Server 2016 SP1 CU3 incluiu primeiro a correção, conforme visto em sua lista de hotfix . No entanto, houve relatos de que não resolveu o problema em todas as situações.

    O SQL Server 2016 SP1 CU4 também inclui uma correção (presumivelmente atualizada) para isso , e o KB 4019893 foi atualizado para mostrar o SP1 CU4 como a versão em que o problema foi corrigido.

    Infelizmente, posso confirmar por experiência própria que mesmo a correção no SP1 CU4 não resolve totalmente esse problema. Atualmente, tenho um banco de dados habilitado para TDE que ainda produz backups corrompidos consistentemente, mesmo no SP1 CU4 ao usar COMPRESSION(via MAXTRANSFERSIZE> 64 KB) e CHECKSUM. Também tenho várias dezenas de outros bancos de dados habilitados para TDE neste ambiente que consistentemente não produzem backups corrompidos nessas configurações, incluindo um que é uma variação daquele que produz, com um esquema quase idêntico, mas um conjunto de dados menor. Isso parece indicar que a Microsoft está de fato eliminando os cenários que podem causar isso, mas ainda não resolveu todos eles.

    Ainda não tentei usar FORMATpara contornar esse problema, conforme mencionado em outra resposta e na postagem do blog SQLCAT , mas fornecerei uma atualização aqui se puder tentar e resolver o problema. Infelizmente, o banco de dados que tenho que reproduz isso é bastante grande (~ 1 TB) e reside em um cluster de desenvolvimento/QA que não tem muito espaço de armazenamento extra disponível (pelo menos nessa escala), portanto, testar variações disso tem provou ser logisticamente desafiador e demorado.

    • 1

relate perguntas