MAXTRANSFERSIZEおよびCHECKSUMが使用されている場合、TDE対応データベースを復元できません


10

更新@AmitBanerjee -Microsoft SQL Server製品グループのシニアプログラムマネージャーは、MSが問題であることを調査することを確認しました

TDEを有効にし、MAXTRANSFERSIZE> 65536 を使用してSQL Server 2016で作成したバックアップを復元するときに問題が発生しましたか(私の場合、TDEデータベースを圧縮できるように65537を選択しました)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

完全なコピーのみのバックアップを取る.. 2回実行する..

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:\ temporary-short-term \ 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)2016年7月11日22:05:22著作権(c)Microsoft Corporation Enterprise Edition(64ビット)on Windows Server 2012 R2 Standard 6.3(Build 9600 :)

回答:


6

私はあなたの問題を再現することができました。

コマンドに追加FORMATするBACKUPことで解決しました。

具体的なドキュメントを見つけることができないようですが、これは新しいメディアヘッダーINITFORMAT作成するときにバックアップセットの既存のメディアヘッダーを保持するという事実に関連していると私は考えています。

私はまだこの問題を調査しており、追加情報が見つかった場合は、この回答を更新します。


うん、はFORMATヘッダーも上書きし、を使用すると発生しませんFORMAT。それでも、INIT MAXTRANSFERSIZECHECKSUM一緒に使用するとバックアップヘッダー(または全体としてのバックアップ)が破損するのはなぜか、これは謎です。これは以前のバージョンでは決して発生しませんでしたが、それらにはありませんでしたMAXTRANSFERSIZE。ご回答有難うございます。誰かがより多くの情報を持っている場合、これを開いたままにします。
Kin Shah

3

このような問題は、KB 4032200で対処されている可能性があります。

そのエントリから:

症状

あなたはあなたが使用してバックアップするデータベースを試すのMicrosoft SQL Serverの2016年におけるデータベースの透過的データ暗号化(TDE)を有効にすることを想定しBACKUP DATABASE、両方持っているT-SQL文COMPRESSIONINITオプション指定を。このシナリオでは、既存のバックアップファイルが新しいバックアップファイルによって上書きされ、新しいバックアップファイルは圧縮されないことに気付く場合があります。

解決

この問題は、SQL Serverの以下の累積的な更新で修正されています。


1

これは、質問で参照したブログ投稿が後で参照するように更新されたのと同じ問題である可能性があります。

2017年4月6日更新

最近、SQL Server 2016でのTDEとバックアップ圧縮の使用に関連するいくつかの問題を発見しました。これらを修正する一方で、これらの既知の問題が発生しないようにするためのヒントをいくつか紹介します。

  • 現在、TDEおよびバックアップ圧縮でストライプバックアップを使用することはお勧めできません。

  • データベースに4GBを超える仮想ログファイル(VLF)がある場合は、ログバックアップにTDEでバックアップ圧縮を使用しないでください。VLFがわからない場合は、ここから始めてください

  • TDEおよびバックアップ圧縮を使用する場合は、現時点ではWITH INITを使用しないでください。代わりに、現時点ではWITH FORMATを使用できます。

SQLエンジニアリングは、SQL Server 2016でこれらの問題の修正に取り組んでいます。共有できる詳細情報があり次第、このブログ投稿を再度更新します。

そのメモにもかかわらず、それ以降、ブログの投稿は更新されていません。

ただし、KB 4019893でもこれに対処できます。

そのKB記事で報告されたエラーメッセージは、報告しているものとは異なりますが、要因は非常に似ています。SQL Server 2016 SP1 CU3には、その修正プログラムリストにあるように、最初に修正が含まれていました。ただし、すべての状況で問題を解決できなかったという報告があります

SQL Serverの2016 SP1 CU4も、このための(おそらく更新)修正が含まれ、KB 4019893は、以来、問題がで修正されたバージョンとしてSP1 CU4を示すように更新されました。

残念ながら、私自身の経験から、SP1 CU4の修正でさえ、その問題を完全には解決しないことを確認できます。現在、1つのTDE対応データベースがあり、SP1 CU4でもCOMPRESSIONMAXTRANSFERSIZE> 64 KB を介して)およびを使用すると、一貫して破損したバックアップを生成しますCHECKSUM。また、この環境には他にも数十のTDE対応データベースがあり、それらの設定で一貫て破損したバックアップを生成しません。これには、スキーマがほぼ同じでデータセットが小さい場合のバリエーションのバックアップも含まれます。これは、Microsoftがこれを引き起こす可能性のあるシナリオを実際に削っていることを示しているようですが、まだすべてを解決していません。

FORMAT別の回答とSQLCAT ブログの投稿で参照されているように、私はまだこの問題を回避するためにを試していませんが、それを試すことができて問題が解決した場合は、ここで更新情報を提供します。これを再現する1つのデータベースは、残念ながらかなり大きく(約1 TB)、(少なくともその規模で)利用可能な追加のストレージ領域がない開発/ QAクラスターにあるため、これのバリエーションをテストするとロジスティックに挑戦し、時間がかかることが証明されています。


この問題は、まだSQL 2017に存在する
swaroopa kothapally
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.