MAXTRANSFERSIZE और CHECKSUM का उपयोग होने पर TDE सक्षम डेटाबेस को पुनर्स्थापित करने में असमर्थ


10

अद्यतन : @AmitBanerjee - Microsoft SQL सर्वर उत्पाद समूह के वरिष्ठ कार्यक्रम प्रबंधक ने पुष्टि की कि MS इस समस्या को देखेगा क्योंकि यह एक दोष है।

क्या किसी को भी TDE सक्षम और उपयोग करते हुए SQL सर्वर 2016 पर लिया गया बैकअप बहाल करने में समस्या का सामना करना पड़ा है 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'

त्रुटि संदेश :

Msg 3241, स्तर 16, राज्य 40, लाइन 11 डिवाइस 'D: \ अस्थायी-अल्पकालिक \ test_restore_KIN_test_restore_1.bak' पर मीडिया परिवार गलत तरीके से बनता है। SQL सर्वर इस मीडिया परिवार को संसाधित नहीं कर सकता है। Msg 3013, लेवल 16, स्टेट 1, लाइन 11 VERIFY DATABASE असामान्य रूप से समाप्त हो रहा है।

विभिन्न संयोजनों के साथ परिणाम (1 = ON, 0 = OFF):

+-------------------------+-------------+----------+--------+
| 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) Jul 11 ​​2016 22:05:22 कॉपीराइट (c) Microsoft कॉर्पोरेशन एंटरप्राइज़ संस्करण (64-बिट) Windows Server 2012 R2 मानक 6.3 (बिल्ड 9600 पर) :)

जवाबों:


6

मैं आपकी समस्या को पुन: पेश करने में सक्षम था।

कमांड में जोड़ने FORMATसे BACKUPयह मेरे लिए हल हो गया।

हालांकि मैं ठोस दस्तावेज़ीकरण नहीं खोज सकता, लेकिन यह मेरी राय है कि यह इस तथ्य से संबंधित है जो एक नया मीडिया हेडर बनाते INITसमय बैकअप सेट पर मौजूदा मीडिया हेडर को बरकरार रखता है FORMAT

मैं अभी भी इस मुद्दे पर शोध कर रहा हूं और यदि मुझे अतिरिक्त जानकारी मिलती है, तो मैं इस उत्तर को अपडेट करूंगा।


हाँ, FORMATहेडर को भी अधिलेखित कर देगा और इसका उपयोग करते समय ऐसा नहीं होता है FORMAT। फिर भी यह एक रहस्य है कि आईएनआईटी के साथ उपयोग करने MAXTRANSFERSIZEऔर CHECKSUMसाथ में बैकअप हेडर (या संपूर्ण के रूप में बैकअप) क्यों दूषित हो जाता है । यह निचले संस्करणों पर कभी नहीं हुआ, लेकिन उन में ऐसा नहीं था MAXTRANSFERSIZE। आपके उत्तर के लिए धन्यवाद। अगर किसी के पास अधिक जानकारी है तो उसे खुला रखेंगे।
परिजन शाह

3

ऐसा लगता है कि KB 4032200 के साथ संबोधित किया गया हो सकता है:

उस प्रविष्टि से:

लक्षण

मान लें कि आप Microsoft SQL Server 2016 में किसी डेटाबेस के लिए पारदर्शी डेटा एन्क्रिप्शन (TDE) सक्षम करते हैं। आप BACKUP DATABASEदोनों COMPRESSIONऔर INITनिर्दिष्ट निर्दिष्ट विकल्प के साथ T-SQL कथन का उपयोग करके डेटाबेस का बैकअप लेने का प्रयास करते हैं । इस परिदृश्य में, आप देख सकते हैं कि मौजूदा बैकअप फ़ाइल नई बैकअप फ़ाइल द्वारा अधिलेखित है, और नई बैकअप फ़ाइल संपीड़ित नहीं है।

संकल्प

यह समस्या SQL सर्वर के लिए निम्न संचयी अद्यतन में ठीक किया गया है:


1

यह संभवतः उसी समस्या के रूप में दिखाई देगा जिसे आपने अपने प्रश्न में संदर्भित ब्लॉग पोस्ट को बाद में संदर्भित करने के लिए अद्यतन किया था:

अपडेट 6 अप्रैल, 2017

हमने हाल ही में SQL सर्वर 2016 में TDE और बैकअप कम्प्रेशन के उपयोग से संबंधित कुछ मुद्दों की खोज की है। जब हम उन्हें ठीक करते हैं, तो यहाँ उन ज्ञात मुद्दों में भाग लेने से बचने में आपकी मदद करने के लिए कुछ सुझाव दिए गए हैं:

  • वर्तमान में TDE और बैकअप कम्प्रेशन के साथ धारीदार बैकअप का उपयोग करना उचित नहीं है

  • अगर आपके डेटाबेस में वर्चुअल लॉग फाइल (VLF) 4GB से बड़ी है तो अपने लॉग बैकअप के लिए TDE के साथ बैकअप कम्प्रेशन का उपयोग न करें। यदि आपको नहीं पता कि वीएलएफ क्या है, तो यहां से शुरू करें

  • TDE और बैकअप कम्प्रेशन के साथ काम करते समय अभी के लिए INIT के उपयोग से बचें। इसके बजाय, अब आप FORMAT के साथ उपयोग कर सकते हैं।

SQL Server 2016 में इन समस्याओं के लिए SQL इंजीनियरिंग फ़िक्सेस पर काम कर रही है। हम इस ब्लॉग पोस्ट को एक बार फिर अपडेट करेंगे, जब हमारे पास साझा करने के लिए और जानकारी होगी।

उस नोट के बावजूद, ब्लॉग पोस्ट को तब से किसी भी अन्य जानकारी के साथ अपडेट नहीं किया गया है।

हालाँकि, KB 4019893 भी इसे संबोधित कर सकता है:

यद्यपि उस KB आलेख में रिपोर्ट किया गया त्रुटि संदेश आपके द्वारा रिपोर्ट किए जा रहे से भिन्न है, योगदान कारक बहुत समान लगते हैं। SQL सर्वर 2016 SP1 CU3 ने सबसे पहले फिक्स को शामिल किया, जैसा कि इसकी हॉटफ़िक्स सूची में देखा गया है । हालांकि, ऐसी रिपोर्टें आई हैं कि इसने सभी स्थितियों में इस मुद्दे को हल नहीं किया।

SQL सर्वर 2016 SP1 CU4 में इसके लिए एक (संभवतः अद्यतित) फिक्स भी शामिल है , और KB 4019893 के बाद से SP1 CU4 को दिखाने के लिए अद्यतन किया गया है क्योंकि संस्करण समस्या में तय किया गया था।

दुर्भाग्य से, मैं अपने स्वयं के अनुभव से पुष्टि कर सकता हूं कि यहां तक ​​कि SP1 CU4 में फिक्स उस समस्या को पूरी तरह से हल नहीं करता है। मेरे पास वर्तमान में एक TDE- सक्षम डेटाबेस है जो अभी भी SP1 COMPRESSION( CU MAXTRANSFERSIZE> 64 KB) का उपयोग करते समय और यहां तक ​​कि SP1 CU4 पर लगातार भ्रष्ट बैकअप उत्पन्न करता है CHECKSUM। मेरे पास इस वातावरण में कई दर्जन अन्य टीडीई-सक्षम डेटाबेस भी हैं जो लगातार उन सेटिंग्स के तहत भ्रष्ट बैकअप का उत्पादन नहीं करते हैं, जिनमें एक ऐसा है जो कि लगभग समान स्कीमा लेकिन छोटे डेटासेट के साथ भिन्नता है। ऐसा प्रतीत होता है कि Microsoft वास्तव में उन परिदृश्यों को दूर कर रहा है जो इसका कारण बन सकते हैं, लेकिन अभी तक उन सभी को हल नहीं किया है।

मैंने अभी तक FORMATइस मुद्दे के आसपास काम करने की कोशिश नहीं की है , जैसा कि एक अन्य उत्तर और SQLCAT ब्लॉग पोस्ट में संदर्भित किया गया है , लेकिन मैं यहां एक अपडेट प्रदान करूंगा अगर मैं यह कोशिश कर पाऊंगा और यह समस्या को हल करता है। एक डेटाबेस जो मेरे पास है वह इसे पुन: बनाता है दुर्भाग्य से बड़ा है (~ 1 टीबी), और एक विकास / क्यूए क्लस्टर में रहता है जिसमें बहुत अतिरिक्त भंडारण स्थान उपलब्ध नहीं है (कम से कम उस पैमाने पर), इसलिए इसका परीक्षण रूपांतर है तार्किक रूप से चुनौतीपूर्ण और समय लेने वाली साबित हुई।


यह समस्या अभी भी SQL 2017 में मौजूद है।
स्वरुप kothapally
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.