बैकअप भ्रष्टाचार का पता लगाता है, लेकिन CHECKDB नहीं करता है


12

मेरे पास एक डेटाबेस है जहां मैं बैकअप कमांड चलाता हूं

BACKUP DATABASE [MyDatabase] TO     
DISK =  'G:\Backup\MyDatabase_01_01_2018.bak'   
WITH    NOFORMAT, NOSKIP, COMPRESSION, INIT, BUFFERCOUNT = 100

मुझे त्रुटि संदेश मिलता है

Msg 3043, स्तर 16, राज्य 1, पंक्ति 8
बैकप 'MyDatabase' ने फ़ाइल 'F: \ Data \ MyDatabase_1.ndf' में पेज (1: 745345) पर एक त्रुटि का पता लगाया।
Msg 3013, लेवल 16, स्टेट 1, लाइन 8
बैकअप डेटा असामान्य रूप से समाप्त हो रहा है।

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

DBCC CHECKDB('MyDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS,
DATA_PURITY, EXTENDED_LOGICAL_CHECKS;

SQL लॉग से:

DBCC CHECKDB (MyDatabase) with all_errormsgs, no_infomsgs, xxx द्वारा निष्पादित data_purity में 0 त्रुटियां पाई गईं और 0 त्रुटियों की मरम्मत की गई। बीता समय: 0 घंटे 21 मिनट 46 सेकंड। आंतरिक डेटाबेस स्नैपशॉट में विभाजन बिंदु LSN = 000ab776: 0000112f: 0001 और पहला LSN = 000ab776: 0000112d: 0001 है।

मैंने DBCC पेज चलाया, लेकिन इसमें त्रुटियां हैं (पहली बार में यह सही पृष्ठ पर वापस लौटती भी नहीं है)। मैं इसे प्रिंट विकल्प 2 के साथ चला सकता हूं और यह वापस आ गया है लेकिन ईमानदारी से मुझे नहीं पता कि मैं वहां क्या देख रहा हूं।

DBCC PAGE ('MyDatabase',1,745345,3)
पेज: (3: 513793)

बफर:


BUF @ 0x00000003811F8280

bpage = 0x00000000F2D70000 bhash = 0x0000000000000000 bpageno = (1: 745345)
bdbid = 5 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 44283 bstat = 0x809
ब्लॉग = 0x5adb215a bnext = 0x0000000000000000          

पेज हैडर:


पेज @ 0x00000000F2D70000

m_pageId = (3: 513793) m_headerVersion = 1 m_type = 2
m_typeFlagBits = 0x4 m_level = 0 m_flagBits = 0x0
m_objId (AllocUnitId.idObj) = 1075937538 m_indexId (AllocUnitId.idInd) = 2
मेटाडेटा: एलोक्युनीट आई डी = 633462595911680 मेटाडेटा: विभाजन आईडी = 0
मेटाडाटा: इंडेक्सआईड = -1 मेटाडेटा: ऑब्जेक्टआईड = ० एम_पर्वपेज = (३: ५ Index IndexII)
m_nextPage = (3: 513820) pminlen = 17 m_slotCnt = 426
m_freeCnt = 2 m_freeData = 7338 m_reservedCnt = 0
m_lsn = (608841: 643611: 411) m_xactReserved = 0 m_xdesId = (0: 0)
m_ghostRecCnt = 0 m_tornBits = 0 DB Frag ID = 1

आवंटन की स्थिति

GAM (1: 511232) = आवंटित SGAM (1: 511233) = आवंटित नहीं     
PFS (1: 744096) = 0x40 आवंटित 0_PCT_FULL DIFF (1: 511238) = नहीं बदला गया
ML (1: 511239) = MIN_LOGGED नहीं      

Msg 2514, स्तर 16, राज्य 8, पंक्ति 20
A DBCC पृष्ठ त्रुटि हुई है: अमान्य पृष्ठ मेटाडेटा - डंप शैली 3 संभव है।

किसी भी विचार मैं आगे क्या कोशिश कर सकता है? सर्वर संस्करण है

select @@version
Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    फरवरी 21 2018 12:19:47 
    कॉपीराइट (c) Microsoft Corporation
    विंडोज NT 6.3 पर डेवलपर संस्करण (64-बिट) (बिल्ड 9600:) (हाइपरविजर)

DB का संगतता स्तर 100 (SQL 2008) है।


इस प्रश्न पर टिप्पणी को चैट में स्थानांतरित कर दिया गया है
पॉल व्हाइट 9

जवाबों:


9

यह जवाब पॉल रैंडल द्वारा लिखित SQLskills.com न्यूज़लेटर के एक अंक से लिया गया है, "एक डेटाबेस जो पेज चेकसम त्रुटियों के साथ बैकअप विफल होगा, लेकिन एक DBCC CHECKDB" के बारे में।

ऐसा केवल तभी हो सकता है जब कोई सीमा मिश्रित सीमा होती है (जहां हद में 8 पृष्ठ संभावित 8 अलग-अलग आवंटन इकाइयों को आवंटित किए जा सकते हैं - यहां देखें ) और कुछ पेजों को संबंधित पीएफएस पृष्ठ द्वारा गलत तरीके से आवंटित के रूप में चिह्नित किया गया है।

जब ऐसा होता है, DBCC CHECKDBतो उन पृष्ठों को पढ़ने का प्रयास नहीं करेंगे, क्योंकि यह पता चलता है कि आवंटन इकाई के IAM पृष्ठों से कौन से पृष्ठ पढ़ने हैं (जिनमें से पहले मिश्रित सीमा से आवंटित पृष्ठों को सूचीबद्ध करता है)। यह मामला DBCC CHECKDBभ्रष्टाचार का पता लगाने वाले तर्क में एक अंतर है ।

[क्योंकि] DBCC CHECKDBभ्रष्टाचार का पता नहीं लगा सकता था, उन्हें ठीक करने के लिए आवश्यक मरम्मत करना संभव नहीं था। इसलिए DBCC WRITEPAGE, उपयोग करते हुए , मैंने गलत तरीके से आवंटित पृष्ठों के लिए आवंटन की स्थिति में आवश्यक बदलाव किए, सीधे पीएफएस पृष्ठ में, और यह काम किया!

यह एक अत्यंत दुर्लभ मामला था - यह बहुत अधिक सामान्य है जो DBCC CHECKDB विफल रहता है लेकिन एक बैकअप सफल होगा।

मेरी राय में, पॉल का रिज़ॉल्यूशन आपके द्वारा किए गए डेटा को निर्यात करने और आयात करने के ऊपर और परे है, इसलिए मुझे लगता है कि आपने सही काम किया।

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