एमएस SQL ​​सर्वर 2005 में क्षतिग्रस्त पृष्ठ संख्या द्वारा क्षतिग्रस्त वस्तु की खोज करें

इन दिनों में से एक एमएस SQL ​​सर्वर डेटाबेस में से एक को संदेह में बदल दिया गया था, लॉग में एक त्रुटि संदेश था:

एमएसजी 7105, लेवल 22, स्टेट 9, लाइन 14
डेटाबेस ID 6, पृष्ठ (1: 386499), LOB डेटा प्रकार नोड के लिए स्लॉट 0 मौजूद नहीं है। यह आमतौर पर लेनदेन के कारण होता है जो किसी डेटा पृष्ठ पर अनक्मिटेड डेटा पढ़ सकता है। DBCC CHECKTABLE चलाएं।

डेटाबेस को आपातकाल में स्थानांतरित कर दिया गया और DBCC CHECKDB को निष्पादित करने का प्रयास किया गया, लेकिन निष्पादन तुरंत बाधित हो गया:

एमएसजी 8921, स्तर 16, राज्य 1, पंक्ति 13
जाँच समाप्त। तथ्यों को एकत्र करते समय एक विफलता का पता चला था। संभवतः अंतरिक्ष या एक सिस्टम टेबल से बाहर टेम्पर्ड असंगत है। पिछली त्रुटियों की जाँच करें।
Msg 7105, लेवल 22, स्टेट 9, लाइन 13
डेटाबेस ID 6, पृष्ठ (1: 386499), LOB डेटा प्रकार नोड के लिए स्लॉट 0 मौजूद नहीं है। यह आमतौर पर लेनदेन के कारण होता है जो किसी डेटा पृष्ठ पर अनक्मिटेड डेटा पढ़ सकता है। DBCC CHECKTABLE चलाएं।

DBCC CHECKALLOC कमांड को एक समान त्रुटि के साथ बाधित किया गया था। सब कुछ इस तथ्य से जटिल था कि एसक्यूएल सर्वर संस्करण 9.0.1399 था, अर्थात। बिना किसी अपडेट के आरटीएम।

TABLOCK संकेत का उपयोग करने और लेन-देन अलगाव के स्तर को स्पष्ट रूप से बढ़ाने के प्रयासों से कुछ भी नहीं हुआ (अस्थायी त्रुटि के साथ पर्याप्त डिस्क स्थान था और DBCC CHECKALLOC के साथ ESTIMATEONLY एक ही त्रुटि के साथ विफल रहा)। मैं वास्तव में एसपी को एक क्षतिग्रस्त डेटाबेस के साथ सर्वर पर रोल नहीं करना चाहता था, और यह पूरी तरह से समझ में नहीं आता था कि समस्या क्या विशिष्ट वस्तु थी। इसके अलावा, ऐसा लगा कि DBCC CHECKDB संदेश का वास्तविकता से कोई लेना-देना नहीं था, क्योंकि msdb.dbo.suspect_pages में एक रिकॉर्ड था, लेकिन पृष्ठ संख्या उस एक से भिन्न थी जिसे DBCC CHECKDB ने मुद्रित किया था।

DBCC CHECKDB निर्देशों का पालन करने और DBCC CHECKTABLE को निष्पादित करने के लिए, आपको तालिका जानना आवश्यक है। और एक लंबी खोज के बाद, एक निर्देश मिला ।

निष्पादित करने के लिए पहली चीज़ (क्षतिग्रस्त डेटाबेस के संदर्भ में) DBCC PAGE (database_id, file_id, page_id, printopt) है:

DBCC TRACEON (3604); DBCC PAGE(5, 1, 3242342, 0) DBCC TRACEOFF (3604); 

या:

 DBCC PAGE(5, 1, 3242342, 0) WITH TABLERESULTS. 

यदि आप भाग्यशाली हैं (या आप एक जीवित आधार पर खेल रहे हैं), तो परिणामस्वरूप, आपको मेटाडेटा: ऑब्जेक्टआईड फ़ील्ड और वास्तव में, वांछित ऑब्जेक्ट_ड दिखाई देगा:



हालाँकि, यदि आप, हमारी तरह, अशुभ हैं, तो आप निम्नलिखित देखेंगे:

मेटाडेटा: = ऑफ़लाइन डीबी में अनुपलब्ध

यदि मेटाडेटा उपलब्ध नहीं है, तो सब कुछ खो नहीं जाता है, इस मामले में, हमें m_objId फ़ील्ड (AllocUnitId.idObj) की आवश्यकता है। अगर m_objId = 255, परेशानी है, तो लेख को बंद करें और कुछ और देखें (स्क्रिप्ट की कोशिश करें जो आप कर सकते हैं और डेटा को हटा सकते हैं, DBCC CHECKDB को "रिकवरी" मापदंडों के साथ नेत्रहीन रूप से निष्पादित करें)।
स्क्रीनशॉट से पता चलता है कि मेरे पास m_objId = 9931 है, अर्थात पर जा सकते हैं।

अब आपको आवंटन यूनिट आईडी की गणना करने के लिए कुछ गणना करने की आवश्यकता है (आवंटन इकाइयों के बारे में अधिक जानकारी यहां मिल सकती है ):

आवंटन इकाई आईडी = m_objid * 65536 + (2 ^ 56)

हमारे मामले में:

आवंटन इकाई आईडी = 9931 * 65536 + (2 ^ 56) = 72057594688765952

इसलिए, आवंटन इकाई आईडी को जानकर, आप देख सकते हैं कि हमारे पास सिस्टम व्यू sys.allocation_units में क्या है :

 SELECT * FROM sys.allocation_units WHERE allocation_unit_id = 72057594688765952 

और वहाँ, मामले में टाइप = 1 या 3 (IN_ROW_DATA, ROW_OVERFLOW_DATA), कॉलम कंटेनर_id = sys.partitions.hobt_id ("हीप-ऑर-बी-ट्री आईडी"), अर्थात आप अनुरोध चला सकते हैं:

 SELECT * FROM sys.partitions WHERE hobt_id = 72057594661437440 

और यहाँ पहले से ही सही object_id और index_id है। अब आप देख सकते हैं कि हमारे पास sys.objects और sys.indexes में क्या है, और बस निष्पादित करें:

 SELECT OBJECT_NAME(object_id) 

सौभाग्य से, दोनों वास्तविक स्थिति में और यहाँ, गैर-क्लस्टर सूचकांक की पुष्टि हुई, जिसके पुनर्गठन के बाद सब कुछ सामान्य हो गया (वास्तव में, नहीं, लेकिन यह एक और कहानी है)।

संदर्भ :
DBCC पेज का उपयोग कैसे करें
समस्या निवारण और फिक्सिंग SQL सर्वर पृष्ठ स्तर भ्रष्टाचार
आवंटन इकाइयाँ क्या हैं?
पेज आईडी से टेबल का नाम ढूंढना
sys.allocation_units