मैंने एक टूटे हुए आधार को कैसे तय किया और इसके बारे में क्या आया

एक बार मुझे एक डेटाबेस को "ठीक" करने में मदद करने के लिए कहा गया था। चेक के दौरान CHECKDB ने त्रुटियों की एक सूची दी, जिनमें से कुछ को "अविवेकी" के रूप में चिह्नित किया गया था। एप्लिकेशन ने काम किया, लेकिन यह अभी भी किसी तरह बेचैन था।

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

इतिहास

त्रासदी के पैमाने को समझने के लिए पहला कदम DBCC CHECKDB लॉन्च करना है। टीम ने ईमानदारी से सभी तालिकाओं के माध्यम से भाग लिया, अधिकांश भाग को कोई समस्या नहीं मिली। उसी निष्कर्ष में, "सुधारात्मक" त्रुटियों की सौ रिपोर्टें थीं। कुछ इस तरह:

Index row (1:386974:44) with values (C_FK_6bb5032ec2f94557a7d4a9d39a356168 = '04DA7FC4-B8F2-4D97-B8D2-B207A918D3DF' and C_PK_dd87d9cad5504a1199d4ddaf511ea6a9 = 'F44E8C34-862D-4952-8821-D0E87143A74E') pointing to the data row identified by (C_PK_dd87d9cad5504a1199d4ddaf511ea6a9 = 'F44E8C34-862D-4952-8821-D0E87143A74E'). 

और कुछ और गंभीर त्रुटियां:

 Table error: Object ID 1333579789, index ID 1, partition ID 72057609974841344, alloc unit ID 72057610075701248 (type In-row data). Page (1:20426) is missing a reference from previous page (1:267203). Possible chain linkage problem. 

तो ठीक है। काम का पैमाना रेखांकित है, चलिए शुरू करते हैं!

सुधारने योग्य त्रुटियाँ

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

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

कार्य पूरी तरह से रचनात्मक नहीं है, इसलिए आप इसे सुरक्षित रूप से एक स्मारिका कार को सौंप सकते हैं। आदेश निष्पादित करें

 DBCC CHECKDB (< >, REPAIR_REBUILD) 

और प्रगति रिपोर्ट का अध्ययन करें।

"ठीक" के बाद स्रोत लॉग और लॉग दोनों भ्रष्ट पृष्ठों के पते की सुविधा देते हैं। हम इन पतों की तुलना करते हैं और सुनिश्चित करते हैं कि "सुधारात्मक" के रूप में चिह्नित सभी त्रुटियों को वास्तव में सफलतापूर्वक काम किया गया था।

डेटा कनेक्टिविटी विकार

अब कुछ ज्यादा ही गंभीर। गैर-संकुलित सूचकांक को ठीक करने और सूचना संदेशों से लॉग को साफ़ करने के बाद, रिपोर्ट में "घातक" त्रुटियों के तीन रिकॉर्ड हैं

आप निश्चित रूप से, DBCC CHECKDB कमांड (<DB नाम>, REPAIR_ALLOW_DATA_LOSS) के साथ हार और काट सकते हैं। लेकिन ... मैं सिर्फ डेटा खोना नहीं चाहता। मैं वह सब कुछ बहाल करना चाहता हूं जो अधिकतम संभव है। इसलिए, आइए अधिक विवरण में देखें कि त्रुटि रिपोर्ट हमें सामान्य रूप से क्या बताती है।

 Table error: Object ID 1333579789, index ID 1, partition ID 72057609974841344, alloc unit ID 72057610075701248 (type In-row data). Page (1:20426) is missing a reference from previous page (1:267203). Possible chain linkage problem. Table error: Object ID 1333579789, index ID 1, partition ID 72057609974841344, alloc unit ID 72057610075701248 (type In-row data). The previous link (1:267203) on page (1:267204) does not match the previous page (1:20426) that the parent (1:218898), slot 213 expects for this page. Table error: Object ID 1333579789, index ID 1, partition ID 72057609974841344, alloc unit ID 72057610075701248 (type In-row data). B-tree chain linkage mismatch. (1:20426)->next = (1:267204), but (1:267204)->Prev = (1:267203). 

रिपोर्ट में एक अस्पष्ट कहानी है जिसमें एक पृष्ठ पड़ोसी को देखने की उम्मीद करता है, लेकिन पड़ोसी को इसके बारे में कुछ भी पता नहीं है। कुछ pelevinsky नाविक Zheleznyak: डेक पर चला गया, लेकिन कोई डेक नहीं।

संपूर्ण समझ के लिए, अधिक विवरण की आवश्यकता है और उन्हें सीधे पृष्ठों की सामग्री पर जाना होगा। लेकिन इससे पहले, हम यह पता लगाएंगे कि SQL सर्वर इंडेक्स पेज सामान्य रूप से कैसे संबंधित हैं।

जाहिर है, पृष्ठों में पदानुक्रमित "ऊर्ध्वाधर" लिंक हैं, जो बी-ट्री बनाते हैं। शीर्ष पृष्ठ में निचले स्तर के पृष्ठों और इसी तरह बहुत पत्तियों पर लिंक शामिल हैं। जैसा कि मैंने पहले ही कहा था, यह मूल्यों को खोजने के लिए बहुत सुविधाजनक है: आप "वास्या पुप्किन" और कुछ पृष्ठों के बाद ("बी से जी" → "बा से बीबी" → "वास्या पुप्किन") के बाद आप इच्छित वांछित पाते हैं।

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

त्रुटि लॉग द्वारा देखते हुए, हमारे पास क्षैतिज और ऊर्ध्वाधर कनेक्शन का एक बेमेल था। लेकिन आखिरकार इस बारे में आश्वस्त होने के लिए, आइए हम स्वयं पृष्ठों को देखें।

हमें और गहरे जाने की जरूरत है!

पृष्ठों को देखने के लिए, हम पुरानी, ​​अच्छी तरह से योग्य और अनिर्दिष्ट डीबीसीसी पृष्ठ टीम का उपयोग करेंगे। यह 4 पैरामीटर लेता है:

• ईद का बेस
• आधार फाइल आई.डी.
• पेज आईडी
• विस्तार का स्तर (0 से 3)

अंतिम पैरामीटर के आधार पर, आप केवल सेवा शीर्षक (0), या पृष्ठ की संपूर्ण सामग्री (3), या शीर्षक और सामग्री के कुछ भाग (1 और 2) को देख सकते हैं

वैसे, SQL Server 2019 में, एक दस्तावेज दृश्य sys.db_db_page_info अंत में दिखाई दिया है, जो समान कार्य करता है। दुर्भाग्य से, यह केवल हेडर डेटा (ड्रिलडाउन 0 के अनुरूप) दिखाता है, इसलिए यह अभी भी हमारे कार्यों का पूरी तरह से जवाब नहीं देता है।

तो, शुरुआत के लिए, कमांड निष्पादित करें

 DBCC TRACEON (3604, 1) 

ताकि शेष DBCC कमांड का आउटपुट हमारे कंसोल को प्राप्त हो, और ErrorLog को नहीं

उसके बाद, पृष्ठ 20426 शीर्षक देखें:

 DBCC PAGE (11, 1, 20426, 0) 

मैं देखता हूं। पृष्ठ 267203 और 267204 पृष्ठों के बीच होना चाहता है। लेकिन इन पृष्ठों के बारे में क्या है?





नींद नहीं, आत्मा नहीं! वे बिना बिन बुलाए मेहमान हैं।
ठीक है, आइए सामग्री की आगामी तालिका देखें:



पहेली धीरे-धीरे विकसित होती है:

• "वर्टिकल" लिंक्स (इंडेक्स ट्री स्ट्रक्चर) के संदर्भ में, पृष्ठ 20426 267203 और 267204 के बीच होना चाहिए
• क्षैतिज कनेक्शन इसका खंडन करते हैं और कहते हैं कि 267203 और 267204 के बीच कोई नहीं है।

अब आइए समझने की कोशिश करें कि विफलता से किस तरह का डेटा मिला।

पृष्ठ के भीतर की पंक्तियों को इंडेक्स कुंजी द्वारा क्रमबद्ध किया जाता है। तदनुसार, पृष्ठ पर पहली और अंतिम कुंजी जानने के बाद, आप "प्रभावित" रिकॉर्ड की सीमा पा सकते हैं।

सूचकांक के विवरण में कुंजी को बस देखा जा सकता है। हम इसके लिए sp_helpindex कमांड का उपयोग करेंगे। इस स्थिति में, कुंजी केवल एक कॉलम है, incl। उसकी ओर सभी ध्यान दें।



पृष्ठ पर मिली कुंजियों को खोजने के लिए, हम डीबीसीसी पृष्ठ का अधिकतम, 3 स्तर के विवरण के साथ उपयोग करते हैं। यदि आप आउटपुट लॉग के माध्यम से स्क्रॉल करते हैं, तो आप प्रत्येक पंक्ति की "कच्ची" सामग्री और प्रत्येक क्षेत्र के लिए एक ब्रेकडाउन देख सकते हैं:



वैसे, प्रमुख सीमा मूल्यों (पृष्ठ पर पहला मूल्य) को डीबीसीसी पृष्ठ आउटपुट में भी बेहतर सूचकांक पृष्ठ (218898, ऊपर स्क्रीनशॉट देखें) के लिए देखा जा सकता है। उन्हें पृष्ठ संख्या के तुरंत बाद कॉलम में दिखाया गया है।

पृष्ठों की एक परीक्षा से पता चलता है कि पृष्ठ 20426 में पृष्ठ 267203 से ठीक आधी लाइनें शामिल हैं। विफलता की प्रकृति स्पष्ट हो जाती है। जब डेटाबेस पेज भरा होता है और इसमें नया डेटा डालने के लिए अधिक जगह नहीं होती है, तो यह आधे से 2 नए पेजों में विभाजित हो जाता है। जाहिरा तौर पर, जब पृष्ठ २ became६२०३ पूर्ण हो गया, समस्या पृष्ठ २०४२६ बनाया गया। डीबीएमएस ने अपने लिंक का पुनर्निर्माण करना शुरू किया: यह सूचकांक संरचना में एक नया पृष्ठ लिखने में कामयाब रहा। लेकिन किसी कारण से, क्षैतिज रिकॉर्ड को अद्यतन नहीं किया जा सकता है और एक अपरिभाषित स्थिति में नया पृष्ठ "त्रिशंकु" है।

यह सब हमारे लिए क्या होगा?

वहाँ निश्चित रूप से बहुत अच्छा नहीं है। पृष्ठ लिंक स्पष्ट रूप से डेटा तक पहुँचने के लिए आवश्यक हैं। क्वेरी निष्पादित करते समय, डीबीएमएस स्वतंत्र रूप से यह निर्धारित करता है कि इस बहुत डेटा को किस तरीके से प्राप्त किया जाए। लेकिन सामान्य नियम (जिससे अपवाद संभव हैं) यह है:

• "वाइड" चयन (उदाहरण के लिए, रिपोर्ट के लिए) क्षैतिज रिकॉर्ड का उपयोग करके किए जाते हैं। क्रमिक रूप से कई पृष्ठों को स्क्रॉल करना आसान है, एक बड़ी सीमा को चुनना
• "पॉइंट" क्वेश्चन (एक विशेष रिकॉर्ड अपडेट करें) "सामग्री की तालिका" सर्च द्वारा किया जाता है।

यह पता चला है, जब विशिष्ट रिकॉर्ड बदलते हैं, DBMS "समस्या" पृष्ठ 20426 पर जाता है। और जब यह रिपोर्ट चलाता है, तो यह डेटा "क्षैतिज" पढ़ता है और किए गए परिवर्तनों को नहीं देखता है। एक बार फिर: व्यवहार में, एल्गोरिथ्म अधिक जटिल हो सकता है, लेकिन संभावित समस्याओं का वर्ग अभी भी समझ में आता है।

रूसी बौद्धिक के शाश्वत प्रश्न

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

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

क्या करना है बहुत स्पष्ट है। किसी तालिका की कनेक्टिविटी को पुनर्स्थापित करने के लिए, इसके डेटा को किसी अन्य तालिका में कॉपी करने के लिए पर्याप्त है ताकि प्रतिलिपि बनाते समय क्षैतिज रीडिंग का उपयोग किया जाए। निष्ठा के लिए, आप स्पष्ट रूप से FORMSCAN संकेत का उपयोग करके सही DBMS पहुंच विधि निर्दिष्ट कर सकते हैं

 select * into T_bca79e9e77c24cdc8bbb7cfd0ddc16fd_BKP from T_bca79e9e77c24cdc8bbb7cfd0ddc16fd with (FORCESCAN) 

उसके बाद, आप स्रोत तालिका को साफ़ कर सकते हैं और वहां कॉपी किए गए डेटा को वापस कर सकते हैं।

लेकिन तब पृष्ठ 20426 में किए गए परिवर्तन खो जाएंगे। इसलिए, तालिका की एक प्रति बनाने से पहले, आपको पृष्ठ 20426 से पहचानकर्ताओं के साथ पंक्तियों की प्रतिलिपि बनाने की आवश्यकता है। और तालिका को पुनर्स्थापित करने के बाद, आवश्यक प्रविष्टियों को सही करें। पहचानकर्ताओं द्वारा पृष्ठ 20426 के रिकॉर्ड तक पहुंच आवश्यक है:

 select * from T_bca79e9e77c24cdc8bbb7cfd0ddc16fd where C_PK_bca79e9e77c24cdc8bbb7cfd0ddc16fd = '' 

पहचानकर्ता पृष्ठ की सामग्री को उसी DBCC पृष्ठ के साथ पढ़कर प्राप्त किया जा सकता है। जैसा कि मैंने पहले ही लिखा था, इन पेजों का आधा हिस्सा 267203 था, यानी 15 लिंक।

बैकअप क्षतिग्रस्त पृष्ठ, तालिका को फिर से लोड करना और मेल खाते रिकॉर्ड्स - दसियों मिनटों के बाद तालिका को पुनर्स्थापित किया गया।

हुर्रे, हम जीत गए! लेकिन क्या यह सच है?

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

विषय पर और क्या पढ़ना है

• कमांड सिंटैक्स CHECKDB (कमांड का उपयोग करने के संभावित जोखिमों के बारे में चेतावनी पर ध्यान दें!)
• DBCC पृष्ठ का अनौपचारिक विवरण
• एमएस एसक्यूएल इंडेक्स पर एक अच्छा लेख जो बहुत सारी दिलचस्प बातें बताता है। डेटाबेस में शारीरिक रूप से अनुक्रमित कैसे संग्रहीत किया जाता है सहित