🐢 💳 🍝 मदद, मेरा डेटाबेस भ्रष्ट है। अब क्या? 🈚️ 👨‍🎨 🖇️

एक दूषित डेटाबेस संभवतः अधिकांश डेटाबेस व्यवस्थापकों के बुरे सपने में से एक है। क्षति का परिणाम डाउनटाइम, चिल्ला प्रबंधक और अन्य सभी अप्रिय चीजें हैं।
इस लेख में मैं समझाता हूं कि आप एक क्षतिग्रस्त डेटाबेस के साथ क्या नहीं कर सकते हैं और कुछ का वर्णन करने की आवश्यकता है, कुछ प्रकार के नुकसान और उन्हें कैसे ठीक करें।

कैसे पता लगाया जाए कि एक डेटाबेस दूषित है

आमतौर पर, क्षति का पता तब लगाया जाता है जब किसी क्षतिग्रस्त पृष्ठ तक पहुँचने की कोशिश की जाती है। अनुरोध, बैकअप, या रींडेक्सिंग प्रक्रियाएं उच्च गंभीरता स्तरों के साथ त्रुटियों का परिणाम हैं।
डेटाबेस भ्रष्टाचार का पता चलने पर सिस्टम संदेशों के कुछ उदाहरण यहां दिए गए हैं:

SQL सर्वर ने तार्किक संगतता-आधारित I / O त्रुटि का पता लगाया: गलत चेकसम (अपेक्षित: 0xfdff74c9; वास्तविक: 0xfdff74cb)। यह डेटाबेस ID 13 में पेज 1 (6: 665) के रीडिंग के दौरान 'D: \ Develop \ Dat \ Broken1.mdf' फाइल में ऑफसेट 0x0000002229a000 पर होता है।

डेटाबेस 13 में तार्किक पृष्ठ 1: 69965 लाने का प्रयास विफल रहा। यह आवंटन इकाई 72057594049069056 से लेकर 281474980642816 तक नहीं है।

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

यदि डेटाबेस अभी भी क्षतिग्रस्त है तो क्या करें

घबराओ मत
इसे अलग न करें
SQL सर्वर को पुनरारंभ न करें
ठीक से वसूली शुरू न करें
इंटीग्रिटी चेक चलाएं
एक कारण खोजें

घबराओ मत

एक डेटाबेस भ्रष्टाचार का पता लगाने के लिए सबसे महत्वपूर्ण बात यह है कि घबराओ मत। किसी भी निर्णय को सावधानीपूर्वक तौला जाना चाहिए, सभी संभावित कारकों को ध्यान में रखा जाना चाहिए। यह स्पष्ट नहीं है कि अस्पष्ट निर्णय लेने से स्थिति खराब हो जाएगी।

डेटाबेस को अलग न करें

ज्यादातर मामलों में, जब SQL सर्वर डेटाबेस भ्रष्टाचार का पता लगाता है, तो इसका मतलब है कि डेटाबेस में वास्तव में भ्रष्ट पृष्ठ हैं। SQL सर्वर को यह समझाने की कोशिश करना कि डेटाबेस को अलग करके उसे फिर से जोड़ना और फिर उसे फिर से जोड़ना, SQL सर्वर सेवा को फिर से शुरू करना, या सर्वर को रिबूट करने की स्थिति नहीं है, जिससे त्रुटि गायब हो जाएगी।
यदि डेटाबेस दूषित है और SQL सर्वर संलग्न पर यह पता लगाता है, तो वह इसे संलग्न करने में सक्षम नहीं होगा। इस डेटाबेस को देखने के कई तरीके हैं, लेकिन इसे डिस्कनेक्ट नहीं करना बेहतर है।

SQL सर्वर को पुनरारंभ न करें

उसी तरह जब डिस्कनेक्ट और ज्वाइनिंग होती है, तो SQL सर्वर सेवा को फिर से शुरू करने से पता की गई त्रुटियों (यदि कोई है) को ठीक नहीं किया जा सकेगा।
सेवा को फिर से शुरू करने से स्थिति और खराब हो सकती है। यदि SQL सर्वर पुनरारंभ होने के बाद डेटाबेस पुनर्प्राप्ति चरण के दौरान त्रुटियों का पता लगाता है, तो वह इसे "संदिग्ध" के रूप में चिह्नित करेगा, जो डेटाबेस पुनर्प्राप्ति प्रक्रिया को बहुत जटिल करेगा।

ठीक से वसूली शुरू न करें

आपको केवल "रिकवरी" पैरामीटर (आमतौर पर डेटा हानि) में से एक के साथ DBCC CHECKDB चलाने के लिए लुभाया जा सकता है और आशा है कि सब कुछ बेहतर हो जाएगा ( मेरे अनुभव में, गैर-मुख्य SQL सर्वर फ़ोरम में अनुशंसित पहली चीज़ DBK CHECKDB REPAIR_ALLOW_DATA_LOSS को चलाने के लिए है) - एक अनुवादक की टिप्पणी )। कई मामलों में, ऐसी वसूली शुरू करने की सिफारिश नहीं की जाती है। यह सभी त्रुटियों के सुधार की गारंटी नहीं देता है और अस्वीकार्य डेटा हानि हो सकती है।
यह पुनर्प्राप्ति त्रुटियों को ठीक करने का अंतिम चरण है। यह केवल तभी शुरू किया जाना चाहिए जब आपके पास पहले से कोई अन्य विकल्प न हो, लेकिन पहले स्थान पर नहीं।

इंटीग्रिटी चेक चलाएं

डेटाबेस को कैसे ठीक किया जाए, यह तय करने के लिए, हमें निश्चित रूप से यह जानने की जरूरत है कि वास्तव में क्या क्षतिग्रस्त है। एकमात्र तरीका जो हम पता लगा सकते हैं वह है DBCC CHECKDB को All_ErrorMsgs पैरामीटर (SQL Server 2005 SP3, SQL Server 2008 SP1 में और पुराने संस्करणों में, यह पैरामीटर डिफ़ॉल्ट रूप से सक्षम है, इसे निर्दिष्ट करना आवश्यक नहीं है)। याद रखें कि यदि आप No_InfoMsgs पैरामीटर के बिना DBCC CHECKDB चलाते हैं, तो इस प्रक्रिया के आउटपुट में प्रत्येक तालिका में पंक्तियों और पृष्ठों की संख्या के बारे में जानकारी होगी, जो त्रुटियों का विश्लेषण करने में आपकी रुचि की संभावना नहीं है।
DBCC CHECKDB को बड़े डेटाबेस पर चलने में लंबा समय लग सकता है, लेकिन आपको यह प्रक्रिया पूरी होने तक प्रतीक्षा करनी चाहिए। डेटाबेस में सभी समस्याओं के बारे में जानकारी होने पर ही एक सक्षम पुनर्प्राप्ति रणनीति बनाई जा सकती है।

एक कारण खोजें

एक बार त्रुटियां ठीक हो जाने के बाद, कार्य समाप्त नहीं माना जा सकता है। यदि इन त्रुटियों के कारण की पहचान नहीं की जाती है, तो वे फिर से हो सकते हैं। आमतौर पर, त्रुटियों का मुख्य कारण I / O सबसिस्टम के साथ समस्याएं हैं, लेकिन वे "निम्न-स्तरीय सॉफ़्टवेयर" (जैसे एंटीवायरस), मानव क्रिया या SQL सर्वर बग के गलत संचालन के कारण भी हो सकते हैं।

आगे क्या है

त्रुटियों को सुधारने के लिए और कदम पूरी तरह से पूरी तरह से CheckDB के परिणामों पर निर्भर करते हैं। थोड़ा और मैं सबसे अधिक बार होने वाली त्रुटियों में से कुछ दिखाऊंगा (ध्यान दें कि यह लेख सभी प्रकार की त्रुटियों का पूर्ण विवरण होने का दावा नहीं करता है)।
वर्णित त्रुटियों को गंभीरता के बढ़ते क्रम में व्यवस्थित किया जाता है - कम से कम गंभीर से सबसे गंभीर तक। सामान्य तौर पर, चेकडीबी द्वारा पाई गई सबसे गंभीर त्रुटियों के लिए, उन्हें हल करने के लिए उपलब्ध तरीकों का वर्णन है।
यदि आपको अचानक लेख में वर्णित त्रुटि नहीं मिलती है, तो अंतिम अनुभाग पर ध्यान दें - "मदद के लिए खोज"।

अमान्य पृष्ठ स्थान की जानकारी

एमएसजी 2508, लेवल 16, स्टेट 3, लाइन 1
इन-रो डेटा आरएसवीडी पृष्ठ संख्या ऑब्जेक्ट "ब्रोकन 1", इंडेक्स आईडी 0, विभाजन आईडी 76911687695381 के लिए, यूनिट आईडी 76911687695381 (टाइप इन-पंक्ति डेटा) गलत है। DBCC UPDATEUSAGE चलाएं।

SQL सर्वर 2000 में मेटाडेटा में संग्रहीत तालिका या अनुक्रमणिका में पंक्तियों और पृष्ठों की संख्या सही नहीं हो सकती (और नकारात्मक भी हो सकती है) और DBCC CHECKDB ने इसके साथ कुछ भी गलत नहीं देखा। SQL सर्वर 2005 में, यह संख्या सही होनी चाहिए और चेकबीडी चेतावनी जारी करेगा यदि यह अचानक एक बेमेल पाता है।
यह एक छोटी सी समस्या है और इसे हल करना बहुत आसान है। संदेश में कहा गया है, आपको बस वांछित डेटाबेस के संदर्भ में DBCC UPDATEUSAGE को चलाने की आवश्यकता है और चेतावनी गायब हो जाती है। SQL Server 2000 से अपग्रेड किए गए डेटाबेस में यह त्रुटि आम है और SQL Server 2005/2008 में बनाए गए डेटाबेस में दिखाई नहीं देना चाहिए।

एमएसजी 8914, लेवल 16, स्टेट 1, लाइन 1
पृष्ठ ID (1: 26839) के लिए गलत PFS मुक्त स्थान की जानकारी ऑब्जेक्ट आईडी 181575685, इंडेक्स आईडी 1, विभाजन आईडी 293374720802816, आवंटित यूनिट आईडी 76911687695381 (टाइप LOB डेटा)। अपेक्षित मूल्य 0_PCT_FULL, वास्तविक मूल्य 100_PCT_FULL।

यह त्रुटि तब दिखाई देती है जब पीएफएस पृष्ठ (पेज फ्री स्पेस), जो इस बात को ध्यान में रखता है कि डेटाबेस में पृष्ठ कितने भरे हुए हैं, गलत मान शामिल हैं। यह त्रुटि, जैसा कि पहले उल्लेख किया गया है, गंभीर नहीं है। एल्गोरिथ्म यह निर्धारित करने के लिए उपयोग किया जाता है कि SQL Server 2000 में पेज कितने भरे हुए थे, हमेशा सही तरीके से काम नहीं करते थे। इस समस्या को हल करने के लिए, आपको REPAIR_ALLOW_DATA_LOSS पैरामीटर के साथ DBCC CHECKDB को चलाने की आवश्यकता है और, यदि यह डेटाबेस में एकमात्र त्रुटि है, तो कोई डेटा वास्तव में प्रभावित नहीं होगा।

केवल गैर-संकुल अनुक्रमणिका को नुकसान

यदि CheckDB द्वारा पाई गई सभी त्रुटियां ID = 2 या अधिक के साथ अनुक्रमणिकाओं से संबंधित हैं, तो इसका मतलब है कि केवल गैर-संकुल अनुक्रमणिका क्षतिग्रस्त हो गई थी। चूंकि गैर-क्लस्टर किए गए अनुक्रमित में निहित जानकारी "निरर्थक" है ( वही डेटा हीप पर संग्रहीत है, या क्लस्टर इंडेक्स में - लगभग। ट्रांसलेटर ), इन नुकसानों की मरम्मत किसी भी डेटा को खोए बिना की जा सकती है।
यदि चेकबैंक द्वारा पाई गई सभी त्रुटियां गैर-संकुल अनुक्रमित से संबंधित हैं, तो DBCC CHECKDB के लिए अनुशंसित "रिकवरी स्तर" REPAIR_REBUILD है। ऐसी त्रुटियों के उदाहरण (वास्तव में, इस प्रकार की बहुत अधिक त्रुटियां हैं):

एमएसजी 8941, लेवल 16, स्टेट 1, लाइन 1
तालिका त्रुटि: ऑब्जेक्ट आईडी 181575685, सूचकांक आईडी 4, पृष्ठ (3: 224866)। परीक्षण (क्रमबद्ध [i] .offset> = PAGEHEADSIZE) विफल रहा। स्लॉट 159, ऑफसेट 0x1 अमान्य है।

एमएसजी 8942, स्तर 16, राज्य 1, पंक्ति 1
तालिका त्रुटि: ऑब्जेक्ट आईडी 181575685, सूचकांक आईडी 4, पृष्ठ (3: 224866)। परीक्षण (क्रमबद्ध [i] .offset> = max) विफल रहा। स्लॉट 0, ऑफसेट 0x9f पूर्व पंक्ति के साथ ओवरलैप होता है।

इस मामले में, क्षतिग्रस्त गैर-क्लस्टर इंडेक्स को हटाकर और उन्हें फिर से बनाने के द्वारा क्षति की पूरी तरह से मरम्मत की जा सकती है। अनुक्रमणिका (ALTER INDEX REBUILD) को ऑन-लाइन (और कभी-कभी ऑफ-लाइन) फिर से बनाना पुराने सूचकांक के पृष्ठों को एक नया बनाने के लिए पढ़ता है और, इसलिए, विफल हो जाएगा। इसलिए, आपको पुराने अनुक्रमों को हटाना होगा और उन्हें फिर से बनाना होगा।
यह वास्तव में DBCC CHECKDB REPAIR_REBUILD पैरामीटर के साथ क्या करेगा, लेकिन डेटाबेस एकल-उपयोगकर्ता मोड में होना चाहिए। यही कारण है कि आमतौर पर इन ऑपरेशनों को मैन्युअल रूप से करना सबसे अच्छा है ताकि डेटाबेस को काम करना जारी रखा जा सके, जबकि अनुक्रमित को फिर से बनाया जाए।
यदि आपके पास आवश्यक अनुक्रमणिका को पुनः बनाने के लिए पर्याप्त समय नहीं है और लेन-देन लॉग की एक अखंड श्रृंखला के साथ "क्लीन" (त्रुटि रहित) पूर्ण बैकअप और बैकअप लॉग हैं, तो आप उनसे क्षतिग्रस्त पृष्ठों को पुनर्स्थापित कर सकते हैं।

LOB पेज भ्रष्टाचार

एमएसजी 8964, लेवल 16, स्टेट 1, लाइन 1
तालिका त्रुटि: ऑब्जेक्ट आईडी 181575685, सूचकांक आईडी 1, विभाजन आईडी 72057594145669120, आवंटित इकाई आईडी 72057594087800832 (टाइप एलओबी डेटा)। पेज (1: 2444050), स्लॉट 0, टेक्स्ट आईडी 901891555328 पर ऑफ-पंक्ति डेटा नोड को संदर्भित नहीं किया जाता है।

त्रुटि इंगित करती है कि LOB पृष्ठ (बड़े OBjects) हैं, जिनसे कोई डेटा पृष्ठ लिंक नहीं होता है। यह तब हो सकता है जब क्लस्टर इंडेक्स (या हीप) पहले क्षतिग्रस्त हो गया था और उसके क्षतिग्रस्त पृष्ठ हटा दिए गए थे।
अगर चेकबैंक केवल ऐसी त्रुटियों के बारे में बात करता है, तो आप REPAIR_ALLOW_DATA_LOSS पैरामीटर के साथ DBCC CHECKDB चला सकते हैं - ये पृष्ठ नष्ट हो जाएंगे। चूंकि आपके पास अभी भी इन पृष्ठों से लिंक करने वाले डेटा पृष्ठ नहीं हैं, इसलिए अधिक डेटा हानि नहीं होगी।

सीमा त्रुटियों से बाहर

एमएसजी 2570, एसवाई 16, राज्य 3, लाइन 17
पृष्ठ (1: 1103587), ऑब्जेक्ट आईडी 34 में स्लॉट 24, इंडेक्स आईडी 1, विभाजन आईडी 281474978938880, यूनिट आईडी 281474978938880 ("इन-पंक्ति डेटा" टाइप करें)। कॉलम "संशोधित" मूल्य डेटा प्रकार "डेटाइम" के लिए सीमा से बाहर है। स्तंभ को एक कानूनी मूल्य पर अपडेट करें।

इन त्रुटियों से संकेत मिलता है कि कॉलम में वे मान हैं जो सीमा से बाहर हैं। यह एक डेटाटाइम मान हो सकता है जो मानता है कि आधी रात के बाद से 1440 से अधिक मिनट बीत चुके हैं, एक यूनिकोड स्ट्रिंग जिसमें बाइट्स की संख्या 2 से विभाज्य नहीं है, या एक गलत सटीक मान के साथ फ्लोट / रियल है।
इन त्रुटियों के लिए जाँच करना डिफ़ॉल्ट रूप से SQL Server 2000 या इससे पहले के डेटाबेस से अपग्रेड नहीं किया जाता है, यदि DATA_PURITY पैरामीटर सक्षम DBCC CHECKDB कमांड पहले कभी नहीं चला है।
चेकडीबी इन त्रुटियों को ठीक करने में सक्षम नहीं होगा, क्योंकि यह ज्ञात नहीं है कि गलत लोगों के बजाय क्या मान निर्धारित करना है। ऐसी त्रुटियों के सुधार के लिए बहुत प्रयास की आवश्यकता नहीं होती है, लेकिन मैन्युअल रूप से किया जाता है। गलत मानों को कुछ स्वीकार्य के साथ प्रतिस्थापित किया जाना चाहिए। मुख्य समस्या गलत मान रही है। इस नॉलेज बेस आलेख में चरण-दर-चरण निर्देश हैं।

क्लस्टर सूचकांक या ढेर भ्रष्टाचार

यदि यह पता चला है कि क्लस्टर इंडेक्स के ढेर या पत्ती के पृष्ठ क्षतिग्रस्त हैं, तो इसका मतलब है कि उन पर डेटा खो गया है। क्लस्टर किए गए अनुक्रमणिका के पत्ती स्तर के पृष्ठों में सीधे डेटा पृष्ठ होते हैं और उनके लिए किसी भी तरह से अतिरेक प्रदान नहीं किया जाता है।
अगर चेकबैंक क्लस्टर अनुक्रमित के पत्ती स्तर के पन्नों को नुकसान की रिपोर्ट करता है, तो DBCC CHECKDB के लिए आवश्यक "पुनर्प्राप्ति स्तर" REPAIR_ALLOW_DATA_LOSS है।
ऐसी त्रुटियों के उदाहरण:

सर्वर: संदेश 8976, स्तर 16, राज्य 1, पंक्ति 2
तालिका त्रुटि: ऑब्जेक्ट आईडी 181575685, इंडेक्स आईडी 1, विभाजन आईडी 76911687695381, यूनिट आईडी 76911687695381 (टाइप-इन-पंक्ति डेटा) आवंटित करें। पृष्ठ (1: 22417) को स्कैन में नहीं देखा गया था, हालांकि इसके अभिभावक (1: 479) और पिछले (1: 715544) इसका उल्लेख करते हैं।

सर्वर: संदेश 8939, स्तर 16, राज्य 1, पंक्ति 2
तालिका त्रुटि: ऑब्जेक्ट आईडी 181575685, सूचकांक आईडी 0, पृष्ठ (1: 168576)। परीक्षण (m_freeData> = PAGEHEADSIZE && m_freeData <= (UINT) PAGESIZE - m_slotCnt * sizeof (स्लॉट) विफल। मान 44 और 8028 हैं।

यह याद रखना चाहिए कि अगर चेकडीबी द्वारा लौटी त्रुटियां इंडेक्स आईडी = 0 या 1 से संबंधित हैं, तो इसका मतलब है कि डेटा सीधे क्षतिग्रस्त है।
इस प्रकार की त्रुटि ठीक है, लेकिन सुधार लाइनों या पूरे पृष्ठों को नष्ट करना है। जब चेकडीबी त्रुटि सुधार डेटा हटाता है, तो विदेशी कुंजी द्वारा लगाए गए प्रतिबंधों की जाँच नहीं की जाती है और न ही आग लगती है। लाइनें या पृष्ठ बस हटा दिए जाते हैं। परिणामस्वरूप, डेटा असंगत हो सकता है, या तार्किक अखंडता का उल्लंघन हो सकता है (एक भी लाइन अब एलओबी पेजों से लिंक नहीं हो सकती है, या गैर-क्लस्टर इंडेक्स लाइनें "कहीं नहीं" का संकेत दे सकती हैं)। ऐसे परिणामों के कारण, ऐसी वसूली की सिफारिश नहीं की जाती है।
यदि आपके पास "क्लीन" बैकअप है, तो आमतौर पर इस तरह की त्रुटियों को ठीक करने के लिए इससे वसूली बेहतर है। यदि डेटाबेस पूर्ण पुनर्प्राप्ति मॉडल में है और आपके पास लॉग्स की अटूट श्रृंखला (अंतिम "क्लीन" फुल बैकअप से शुरू) के साथ लेन-देन लॉग का बैकअप है, तो आप लॉग के सक्रिय भाग का बैकअप ले सकते हैं और पूरे डेटाबेस को पुनर्स्थापित कर सकते हैं (या केवल क्षतिग्रस्त पृष्ठों को, में) नतीजतन, डेटा बिल्कुल भी खो नहीं जाएगा।
यदि बिना बैकअप डेटा के साथ कोई बैकअप नहीं है, तो आपके पास एक ही विकल्प है - DBCC CHECKDB को REPAIR_ALLOW_DATA_LOSS पैरामीटर के साथ लॉन्च करें। इस प्रक्रिया की पूरी अवधि के लिए डेटाबेस को एकल-उपयोगकर्ता मोड में रखना होगा।
और यद्यपि आपके पास डेटा हानि से बचने का कोई तरीका नहीं है, आप देख सकते हैं कि क्लस्टर किए गए इंडेक्स से कौन सा डेटा हटा दिया जाएगा। इसके लिए पॉल रेनाडल की इस पोस्ट को देखें।

मेटाडाटा भ्रष्टाचार

एमएसजी 3853, स्तर 16, राज्य 1, पंक्ति 1
पंक्ति में पंक्ति का ऑब्जेक्ट (object_id = 181575685) (object_id = 181575685, column_id = 1), sys.objects में मिलान पंक्ति (object_id = 181575685) नहीं है।

इसी तरह की त्रुटियां आमतौर पर SQL सर्वर 2000 से अपग्रेड किए गए डेटाबेस में होती हैं जब किसी ने सिस्टम टेबल में सीधे टिंकर किया था।
SQL सर्वर के किसी भी संस्करण के सिस्टम टेबल में, विदेशी कुंजियों का उपयोग नहीं किया जाता है, इसलिए SQL सर्वर 2000 में sysobjects (उदाहरण के लिए, एक तालिका) से एक पंक्ति को हटाना संभव था और syscolumns और sysindexes तालिकाओं में हटाए गए पंक्ति का संदर्भ देते हुए पंक्तियों को छोड़ दें।
SQL Server 2000 में, CheckDB ने सिस्टम कैटलॉग की अखंडता की जाँच नहीं की, और इस तरह की समस्याओं को अक्सर किसी ने नहीं देखा। SQL सर्वर 2005 में, चेकबैंक सिस्टम कैटलॉग की अखंडता की जांच करता है और ऐसी त्रुटियां हो सकती हैं।
इन त्रुटियों का सुधार सबसे आसान बात नहीं है। चेकडीबी उन्हें ठीक नहीं कर सकता है, क्योंकि केवल एक चीज जो हो सकती है वह है सिस्टम तालिकाओं से रिकॉर्ड को हटाना, जो बदले में, बड़ी मात्रा में डेटा के नुकसान का कारण बन सकता है। यदि आपके पास SQL Server 2005 में नवीनीकरण से पहले किए गए इस डेटाबेस का बैकअप है और अद्यतन बहुत हाल ही में किया गया था, तो आप इसे SQL Server 2000 में वितरित कर सकते हैं, मैन्युअल रूप से उस पर सिस्टम तालिकाओं को सही करें और डेटाबेस को फिर से SQL Server 2005 में स्थानांतरित करें।
यदि आपके पास SQL Server 2000 पर डेटाबेस का बैकअप नहीं है या अपडेट बहुत लंबा था और डेटा हानि अस्वीकार्य है, तो दो तरीके हैं। SQL सर्वर 2005 में सिस्टम टेबल्स को संपादित करने के लिए सबसे पहले है, लेकिन ध्यान रखें कि यह एक जटिल और जोखिम भरा प्रक्रिया है, क्योंकि सिस्टम टेबल डॉक्यूमेंटेड नहीं हैं और पहले के संस्करणों की तुलना में बहुत अधिक जटिल हैं। आप इस पोस्ट में अधिक जानकारी पा सकते हैं।
दूसरा तरीका सभी डेटाबेस ऑब्जेक्ट्स को स्क्रिप्ट करना और सभी डेटा निर्यात करना है, जिसके बाद एक नया डेटाबेस बनाते हैं, ऑब्जेक्ट्स को पुनर्स्थापित करते हैं और डेटा को भरते हैं। यह विकल्प अधिक बेहतर है।

अपूरणीय क्षति

चेकडीबी सब कुछ ठीक नहीं कर सकता। नीचे दी गई कोई भी त्रुटि जैसे कि वह अमिट है और एकमात्र विकल्प डेटाबेस को बैकअप से पुनर्स्थापित करना है जिसमें ऐसी कोई क्षति नहीं है। यदि आपके पास एक पूर्ण बैकअप है और लॉग चेन वर्तमान समय तक टूटी नहीं है, तो आप लेन-देन लॉग के अंतिम टुकड़े का बैकअप ले सकते हैं और डेटाबेस को किसी भी डेटा को खोए बिना बहाल किया जा सकता है।
यदि ऐसा कोई बैकअप नहीं है, तो केवल एक चीज जो आप कर सकते हैं, उन वस्तुओं को स्क्रिप्ट करना और अभी भी उपलब्ध डेटा को अपलोड करना है। यह संभावना है कि भ्रष्टाचार के कारण, सभी डेटा सुलभ नहीं होंगे, और सबसे अधिक संभावना है, सभी वस्तुओं को त्रुटियों के बिना स्क्रिप्ट में सक्षम नहीं किया जा सकेगा।

सिस्टम तालिकाओं को नुकसान

एमएसजी 7985, स्तर 16, राज्य 2, पंक्ति 1
सिस्टम टेबल प्री-चेक: ऑब्जेक्ट आईडी 4. लैच प्रकार एसएच के साथ पेज (1: 358) को पढ़ा और लैच नहीं कर सका।
अप्राप्य त्रुटि के कारण समाप्त किए गए विवरण की जाँच करें।

एमएसजी 8921, स्तर 16, राज्य 1, पंक्ति 1
जाँच समाप्त। तथ्यों को एकत्र करते समय एक विफलता का पता चला था। संभवतः अंतरिक्ष या सिस्टम टेबल से बाहर टेम्पर्ड असंगत है।

डेटाबेस में क्या होना चाहिए, इसका अंदाजा लगाने के लिए चेकबैंक कई महत्वपूर्ण प्रणाली तालिकाओं पर निर्भर करता है। यदि ये तालिकाएँ स्वयं क्षतिग्रस्त हो जाती हैं, तो चेकबीडी यह मान भी नहीं सकती है कि डेटाबेस में क्या होना चाहिए और वर्तमान स्थिति की तुलना किस चीज़ से की जानी चाहिए, न कि किसी चीज़ को ठीक करने के लिए।

वितरण कार्डों को नुकसान

एमएसजी 8946, लेवल 16, स्टेट 12, लाइन 1
तालिका त्रुटि: आवंटन पृष्ठ (1: 2264640) में PFS_PAGE पृष्ठ शीर्षक मान अमान्य हैं। टाइप है 0. चेक टाइप, पेज पर यूनिट आईडी और पेज आईडी आवंटित करें।

Msg 8998, स्तर 16, राज्य 2, पंक्ति 1
GAM, SGAM, या PFS पृष्ठों पर पृष्ठ त्रुटियां डेटाबेस आईडी 13 पृष्ठ (1: 2264640) से (1: 2272727) में आवंटन अखंडता जांच को रोकती हैं

इस स्थिति में, डेटाबेस में डेटा की नियुक्ति ( वितरण कार्ड - लगभग। अनुवादक ) का निर्धारण करने वाले एक या कई पृष्ठ क्षतिग्रस्त हो जाते हैं। इन पृष्ठों का उपयोग यह निर्धारित करने के लिए किया जाता है कि डेटाबेस में कौन से पृष्ठ और विस्तार का उपयोग किया जाता है और कौन से मुक्त हैं। चेकबैंक ऐसी त्रुटियों को ठीक नहीं कर सकता है, क्योंकि यह निर्धारित करना लगभग असंभव है (इन पृष्ठों के बिना) जो डेटा रखने के लिए उपयोग किए जाते हैं और जो नहीं हैं। इस तरह के "वितरण मानचित्र" का एक सरल विलोपन असंभव है, क्योंकि उनमें से किसी को हटाने से 4 जीबी डेटा का विलोपन होगा।

खोज में मदद करें

यदि आप सुनिश्चित नहीं हैं कि आपको क्या करने की आवश्यकता है, तो मदद के लिए पूछें। यदि आपको अचानक डेटाबेस भ्रष्टाचार के बारे में एक संदेश प्राप्त होता है जो आपके लिए समझ से बाहर है और जो ऊपर वर्णित नहीं है - मदद के लिए पूछें। यदि आप सुनिश्चित नहीं हैं कि आपने सबसे अच्छा पुनर्प्राप्ति विधि चुना है, तो मदद के लिए पूछें।
यदि आपके पास एक वरिष्ठ डीबीए है, तो उससे संपर्क करें। यदि आपके पास "संरक्षक" है - तो उससे पूछें। मंचों में सलाह के लिए पूछें, लेकिन याद रखें कि मंचों में प्राप्त सभी सलाह सहायक नहीं हैं। वास्तव में, यह वहां से है कि समय-समय पर बिल्कुल गलत और खतरनाक फैसले प्रकाशित किए जाते हैं।
Microsoft समर्थन से संपर्क करें, अंत में। यह मुफ़्त नहीं होगा, लेकिन वे वास्तव में जानते हैं कि एक क्षतिग्रस्त डेटाबेस के साथ क्या किया जा सकता है और यह संभावना है कि यदि आपका डेटाबेस उद्यम के लिए महत्वपूर्ण है, तो एक समाधान के लिए एक स्वतंत्र खोज के दौरान डाउनटाइम की लागत संपर्क समर्थन की लागत से बहुत अधिक होगी।

निष्कर्ष

इस लेख में, मैंने एक उदाहरण दिया कि क्षतिग्रस्त डेटाबेस का पता चलने पर क्या किया जा सकता है और इससे भी महत्वपूर्ण बात यह है कि क्या नहीं किया जाना चाहिए। मुझे उम्मीद है कि अब आप बेहतर तरीके से समझते हैं कि बताई गई समस्याओं को हल करने के लिए किन तरीकों का इस्तेमाल किया जा सकता है और कितना अच्छा बैकअप होना जरूरी है ( और सही रिकवरी मॉडल का चयन करें - लगभग। अनुवादक )।

नोट: यह मेरा पहला अनुवाद है, जो, इसके अलावा, एक समय में नहीं किया गया था, लेकिन कई दृष्टिकोणों में, शाम को, जब खाली समय दिखाई दिया, इसलिए संपूर्ण पाठ, शायद, कुछ हद तक असंगत प्रतीत होगा। अगर कहीं मैं बहुत ज़्यादा ज़ुबान से जुड़ा हुआ था और पाठ का कुछ हिस्सा अचानक समझ में आ गया, तो मैं ख़ुशी-ख़ुशी सभी टिप्पणियाँ सुनूँगा।
सादर, अधूरा।
PS जब मैं "प्रकाशित" बटन पर क्लिक करने वाला था, तो इस तरह की कॉमिक के साथ SQL सर्वर सेंट्रल की एक मेलिंग सूची मेरे मेल पर बाहर आ गई ।

मदद, मेरा डेटाबेस भ्रष्ट है। अब क्या?