ไม่สามารถกู้คืนฐานข้อมูลที่เปิดใช้งาน TDE เมื่อใช้ MAXTRANSFERSIZE และ CHECKSUM


10

Update : @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'

ข้อความผิดพลาด :

ข่าวสารเกี่ยวกับ 3241 ระดับ 16 สถานะ 40 สาย 11 ตระกูลสื่อบนอุปกรณ์ 'D: \ ชั่วคราวระยะสั้น \ test_restore_KIN_test_restore_1.bak' เกิดขึ้นไม่ถูกต้อง SQL Server ไม่สามารถประมวลผลตระกูลสื่อบันทึกนี้ได้ ข่าวสารเกี่ยวกับ 3013 ระดับ 16 สถานะ 1 บรรทัด 11 ฐานข้อมูลการตรวจสอบกำลังยกเลิกอย่างผิดปกติ

ผลลัพธ์ (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) 11 กรกฎาคม 2559 22:05:22 ลิขสิทธิ์ (c) Microsoft Corporation รุ่นองค์กรองค์กร (64 บิต) บน Windows Server 2012 R2 มาตรฐาน 6.3 (รุ่น 9600) :)

คำตอบ:


6

ฉันสามารถที่จะทำให้เกิดปัญหาของคุณ

เพิ่มFORMATไปยังBACKUPคำสั่งแก้ไขได้สำหรับฉัน

ในขณะที่ฉันดูเหมือนจะไม่พบเอกสารที่เป็นรูปธรรม แต่ฉันคิดว่ามันเกี่ยวข้องกับความจริงที่ว่าINITรักษาส่วนหัวของสื่อที่มีอยู่ในชุดข้อมูลสำรองในขณะที่FORMATสร้างส่วนหัวของสื่อใหม่

ฉันยังคงค้นคว้าปัญหานี้และหากฉันค้นหาข้อมูลเพิ่มเติมฉันจะอัปเดตคำตอบนี้


อ๋อที่จะเขียนทับหัวเป็นอย่างดีและมันไม่ได้เกิดขึ้นเมื่อมีการใช้FORMAT FORMATยังคงนี้เป็นความลึกลับเป็นเหตุผลที่ส่วนหัวของการสำรองข้อมูล (หรือการสำรองข้อมูลโดยรวม) ได้รับความเสียหายเมื่อใช้MAXTRANSFERSIZEและCHECKSUMร่วมกันพร้อมกับ INIT นี้ไม่เคยเกิดขึ้นในรุ่นที่ต่ำกว่า MAXTRANSFERSIZEแต่ในนั้นไม่มี ขอบคุณสำหรับคำตอบ. จะเปิดไว้ถ้าใครมีข้อมูลเพิ่มเติม
Kin Shah

3

ดูเหมือนว่าสิ่งนี้อาจได้รับการแก้ไขด้วย KB 4032200:

จากรายการนั้น:

อาการ

สมมติว่าคุณเปิดใช้งานการเข้ารหัสข้อมูลโปร่งใส (TDE) สำหรับฐานข้อมูลใน Microsoft SQL Server 2016 คุณพยายามสำรองฐานข้อมูลโดยใช้BACKUP DATABASEคำสั่ง T-SQL ที่มีทั้งตัวเลือกCOMPRESSIONและINITตัวเลือกที่ระบุ ในสถานการณ์สมมตินี้คุณอาจสังเกตเห็นว่าไฟล์สำรองที่มีอยู่ถูกเขียนทับโดยไฟล์สำรองใหม่และไฟล์สำรองใหม่ไม่ได้ถูกบีบอัด

มติ

แก้ไขปัญหานี้ในการปรับปรุงที่สะสมต่อไปนี้สำหรับ SQL Server:


1

ดูเหมือนว่าอาจเป็นปัญหาเดียวกันกับที่โพสต์บล็อกที่คุณอ้างถึงในคำถามของคุณได้รับการอัปเดตในภายหลังเพื่ออ้างถึง:

อัพเดท 6 เมษายน 2017

เราเพิ่งค้นพบปัญหาบางอย่างที่เกี่ยวข้องกับการใช้ TDE และการบีบอัดข้อมูลสำรองใน SQL Server 2016 ในขณะที่เราแก้ไขปัญหาต่อไปนี้เป็นเคล็ดลับที่จะช่วยให้คุณหลีกเลี่ยงปัญหาที่ทราบเหล่านี้:

  • ในปัจจุบันไม่แนะนำให้ใช้การสำรองข้อมูลแบบสไทรพ์กับ TDE และการบีบอัดข้อมูลสำรอง

  • หากฐานข้อมูลของคุณมีไฟล์บันทึกเสมือน (VLF) ที่ใหญ่กว่า 4GB อย่าใช้การบีบอัดข้อมูลสำรองด้วย TDE สำหรับการสำรองข้อมูลบันทึกของคุณ หากคุณไม่ได้รู้ว่าสิ่งที่ VLF คือเริ่มต้นที่นี่

  • หลีกเลี่ยงการใช้ WITH INIT ในตอนนี้เมื่อทำงานกับ TDE และการบีบอัดข้อมูลสำรอง แต่สำหรับตอนนี้คุณสามารถใช้กับ FORMAT

SQL วิศวกรรมกำลังทำงานเพื่อแก้ไขปัญหาเหล่านี้ใน SQL Server 2016 เราจะอัปเดตโพสต์บล็อกนี้อีกครั้งเมื่อเรามีข้อมูลเพิ่มเติมที่จะแบ่งปัน

แม้จะมีข้อความดังกล่าว แต่โพสต์บล็อกยังไม่ได้รับการอัปเดตด้วยข้อมูลเพิ่มเติมใด ๆ

อย่างไรก็ตามKB 4019893อาจแก้ไขปัญหานี้ด้วย:

แม้ว่าข้อความแสดงข้อผิดพลาดที่รายงานในบทความ KB นั้นจะแตกต่างจากข้อความที่คุณกำลังรายงาน แต่ปัจจัยที่สนับสนุนมีความคล้ายคลึงกันมาก SQL Server 2016 SP1 CU3 แรกที่รวมการแก้ไขเท่าที่เห็นในของรายการโปรแกรมแก้ไขด่วน อย่างไรก็ตามมีรายงานว่าไม่สามารถแก้ไขปัญหาได้ในทุกสถานการณ์

SQL Server 2016 SP1 CU4 ยังมีการแก้ไข (คาดว่าน่าจะอัพเดต) สำหรับเรื่องนี้และKB 4019893ได้รับการอัปเดตเพื่อแสดง SP1 CU4 เป็นรุ่นที่ปัญหาได้รับการแก้ไข

น่าเสียดายที่ฉันสามารถยืนยันได้จากประสบการณ์ของตัวเองว่าแม้การแก้ไขใน SP1 CU4 ไม่สามารถแก้ไขปัญหานั้นได้ ฉันกำลังมีหนึ่งในฐานข้อมูล TDE-เปิดการใช้งานที่ยังคงผลิตสำรองข้อมูลความเสียหายอย่างต่อเนื่องแม้ใน SP1 CU4 เมื่อใช้COMPRESSION(ผ่านMAXTRANSFERSIZE> 64 KB) CHECKSUMและ ฉันยังมีฐานข้อมูลที่เปิดใช้งาน TDE อื่น ๆ อีกหลายโหลในสภาพแวดล้อมนี้ที่ไม่ได้สร้างการสำรองข้อมูลที่เสียหายอย่างต่อเนื่องภายใต้การตั้งค่าเหล่านั้นรวมถึงฐานข้อมูลที่มีรูปแบบของฐานข้อมูลเดียวกัน ดูเหมือนว่านี่เป็นการบ่งชี้ว่า Microsoft กำลังพยายามหลีกเลี่ยงสถานการณ์ที่อาจทำให้เกิดปัญหานี้ แต่ก็ยังไม่สามารถแก้ไขได้ทั้งหมด

ฉันยังไม่ได้ลองใช้FORMATเพื่อแก้ไขปัญหานี้ตามที่อ้างอิงในคำตอบอื่นและโพสต์บล็อก SQLCAT แต่ฉันจะให้การอัปเดตที่นี่หากฉันสามารถลองได้และจะแก้ไขปัญหาได้ ฐานข้อมูลเดียวที่ฉันทำซ้ำนี้น่าเสียดายที่มีขนาดค่อนข้างใหญ่ (~ 1 TB) และอยู่ในคลัสเตอร์ Development / QA ที่ไม่มีพื้นที่เก็บข้อมูลเพิ่มเติมมากพอ (อย่างน้อยก็ในระดับนั้น) ดังนั้นการทดสอบรูปแบบนี้จึงมี พิสูจน์แล้วว่ามีความท้าทายด้านโลจิสติกส์และใช้เวลานาน


ปัญหานี้ยังคงมีอยู่ใน SQL 2017
swaroopa kothapally
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.