DBCC_OBJECT_METADATA कुंडी

कुंडी पर लेखों की अपनी श्रृंखला को जारी रखते हुए, इस बार मैं DBCC_OBJECT_METADATA कुंडी पर चर्चा करने जा रहा हूं और यह दिखाऊंगा कि यह कैसे कुछ परिस्थितियों में SQL सर्वर 2016 से पहले स्थिरता जांच के लिए एक बड़ी बाधा हो सकती है। समस्या DBCC CHECKDB, DBCC CHECKTABLE, और DBCC CHECKFILEGROUP को प्रभावित करती है, लेकिन स्पष्टता के लिए मैं इस पोस्ट के बाकी हिस्सों के लिए केवल DBCC CHECKDB का संदर्भ दूंगा।

आपको आश्चर्य हो सकता है कि मैं एक ऐसे मुद्दे के बारे में क्यों लिख रहा हूं जो पुराने संस्करणों को प्रभावित करता है, लेकिन अभी भी बड़ी संख्या में SQL सर्वर 2014 और पुराने उदाहरण हैं, इसलिए यह मेरी श्रृंखला के लिए एक मान्य विषय है।

मैं दृढ़ता से अनुशंसा करता हूं कि आप इससे पहले श्रृंखला में प्रारंभिक पोस्ट पढ़ लें, ताकि आपको कुंडी के बारे में सभी सामान्य पृष्ठभूमि ज्ञान हो।

DBCC_OBJECT_METADATA कुंडी क्या है?

इस कुंडी को समझाने के लिए, मुझे डीबीसीसी CHECKDB कैसे काम करता है, इसके बारे में थोड़ा समझाने की जरूरत है।

DBCC CHECKDB द्वारा की जाने वाली बड़ी संख्या में संगतता जाँचों में गैर-संकुल अनुक्रमणिका की शुद्धता की जाँच है। विशेष रूप से, DBCC CHECKDB सुनिश्चित करता है:

1. प्रत्येक गैर-संकुल अनुक्रमणिका में प्रत्येक गैर-संकुल अनुक्रमणिका रिकॉर्ड के लिए, आधार तालिका (या तो एक ढेर या एक संकुल अनुक्रमणिका) में ठीक एक "मिलान" डेटा रिकॉर्ड होता है
2. तालिका में प्रत्येक डेटा रिकॉर्ड के लिए, फ़िल्टर किए गए अनुक्रमणिका को ध्यान में रखते हुए तालिका के लिए परिभाषित प्रत्येक गैर-संकुल अनुक्रमणिका में ठीक एक "मिलान" गैर-संकुल अनुक्रमणिका रिकॉर्ड होता है

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

साथ ही गैर-संकुल अनुक्रमणिका शुद्धता जांच, यदि कोई निरंतर है तालिका की परिभाषा में गणना किए गए कॉलम, फिर तालिका में प्रत्येक डेटा रिकॉर्ड के लिए, DBCC CHECKDB को यह जांचना होगा कि स्थायी मान सही है, भले ही वह कॉलम गैर-क्लस्टर इंडेक्स का हिस्सा हो या नहीं।

तो यह परिकलित स्तंभ मानों का पता कैसे लगाता है?

क्वेरी प्रोसेसर गणना किए गए कॉलम मानों की गणना के लिए एक तंत्र प्रदान करता है, जिसे "अभिव्यक्ति मूल्यांकनकर्ता" कहा जाता है। DBCC CHECKDB उस फ़ंक्शन को कॉल करता है, उपयुक्त मेटाडेटा जानकारी और डेटा रिकॉर्ड प्रदान करता है, और अभिव्यक्ति मूल्यांकनकर्ता मेटाडेटा में परिकलित कॉलम की संग्रहीत परिभाषा और डेटा रिकॉर्ड से मानों का उपयोग करता है और उपयोग करने के लिए DBCC CHECKDB के लिए गणना किए गए कॉलम का मान देता है। . अभिव्यक्ति मूल्यांकनकर्ता के आंतरिक कामकाज डीबीसीसी कोड के नियंत्रण से बाहर हैं, लेकिन अभिव्यक्ति मूल्यांकनकर्ता का उपयोग करने में सक्षम होने के लिए, पहले एक कुंडी हासिल की जानी चाहिए; DBCC_OBJECT_METADATA कुंडी।

कुंडी कैसे एक अड़चन बन जाती है?

यहां समस्या है:केवल एक स्वीकार्य मोड है जिसमें अभिव्यक्ति मूल्यांकनकर्ता का उपयोग करने से पहले DBCC_OBJECT_METADATA कुंडी प्राप्त की जा सकती है, और वह EX मोड (अनन्य) है। और जैसा कि आप इंट्रो पोस्ट को पढ़ने से लेकर सीरीज़ तक जानेंगे, एक बार में केवल एक थ्रेड EX मोड में लैच को होल्ड कर सकता है।

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

लेकिन याद रखें, यह अड़चन केवल SQL सर्वर 2016 से पहले SQL सर्वर के संस्करणों के लिए होती है। SQL सर्वर 2016 में Microsoft ने डिफ़ॉल्ट रूप से गणना किए गए कॉलम का उपयोग करके गैर-अनुक्रमित अनुक्रमितों के चेक को बंद करके और केवल उन्हें करते समय टोंटी को "ठीक" करने का निर्णय लिया। EXTENDED_LOGICAL_CHECKS विकल्प का उपयोग किया जाता है।

बाधा दिखा रहा है

आप डेटाबेस पर DBCC CHECKDB चलाकर आसानी से अपने लिए अड़चन को पुन:उत्पन्न कर सकते हैं, जिसमें या तो परिकलित कॉलम या गैर-संकुलित अनुक्रमणिकाएँ हैं जिनमें परिकलित कॉलम हैं, और Microsoft द्वारा प्रदान किया गया एडवेंचरवर्क्स डेटाबेस एक बेहतरीन उदाहरण है। आप यहां से अपने SQL सर्वर के संस्करण के लिए AdventureWorks का बैकअप डाउनलोड कर सकते हैं। मैंने SQL सर्वर 2014 इंस्टेंस (32-कोर डेल R720 पर) पर एक AdventureWorks2014 डेटाबेस का उपयोग करके कुछ परीक्षण चलाए, और मैंने जोनाथन की स्क्रिप्ट का उपयोग करके डेटाबेस को कुछ सौ जीबी तक बढ़ा दिया।

जब मैंने DBCC CHECKDB चलाया, जिसमें सर्वर MAXDOP 0 पर सेट था, इसे चलने में 5 घंटे से अधिक समय लगा। LATCH_EX प्रतीक्षा प्रकार लगभग 30% प्रतीक्षाओं के लिए जिम्मेदार था, प्रत्येक प्रतीक्षा केवल 1 मिलीसेकंड की शर्मीली थी, और LATCH_EX के 99% प्रतीक्षा DBCC_OBJECT_METADATA लैच के लिए थे।

मैंने निम्नलिखित कोड का उपयोग करके गणना किए गए कॉलम वाले गैर-संकुल अनुक्रमणिका की तलाश की:

SELECT
      [s].[name] AS [Schema],
      [o].[name] AS [Object],
      [i].[name] AS [Index],
      [c].[name] AS [Column],
      [ic].*
  FROM sys.columns [c]
  JOIN sys.index_columns [ic]
      ON [ic].[object_id] = [c].[object_id]
      AND [ic].[column_id] = [c].[column_id]
  JOIN sys.indexes [i]
      ON [i].[object_id] = [ic].[object_id]
      AND [i].[index_id] = [ic].[index_id]
  JOIN sys.objects [o]
      ON [i].[object_id] = [o].[object_id]
  JOIN sys.schemas [s]
      ON [o].[schema_id] = [s].[schema_id]
  WHERE [c].[is_computed] = 1;

उस कोड को AdventureWorks2014 डेटाबेस में छह गैर-संकुल अनुक्रमणिकाएँ मिलीं। मैंने सभी छह इंडेक्स (ALTER INDEX ... DISABLE का उपयोग करके) को निष्क्रिय कर दिया और DBCC CHECKDB को फिर से चलाया और यह लगभग 18 मिनट में पूरा हो गया। तो DBCC_OBJECT_METADATA लैच अड़चन, DBCC CHECKDB के 16 गुना से अधिक धीमी गति से चलने का एक प्रमुख कारक था!

सारांश

दुर्भाग्य से, गणना किए गए स्तंभों का उपयोग करके गैर-संकुलित अनुक्रमणिका को अक्षम करना (और फिर बाद में उन्हें ALTER INDEX ... REBUILD का उपयोग करके पुन:सक्षम करना) SQL सर्वर 2016 से पहले के संस्करणों में DBCC_OBJECT_METADATA लैच अड़चन को दूर करने का *एकमात्र* तरीका है, जबकि अभी भी DBCC की अन्य सभी कार्यक्षमता को बनाए रखना है। चेकडीबी. जब तक आपके पास शून्य गतिविधि रखरखाव विंडो न हो, तब तक गैर-अनुक्रमित अनुक्रमणिका को अक्षम करना कुछ ऐसा नहीं है जिसे आप उत्पादन वातावरण में करना चाहते हैं। इसका मतलब यह है कि यदि आप बैकअप-कॉपी-पुनर्स्थापना-CHECKDB पद्धति का उपयोग करके किसी अन्य सर्वर पर आपकी संगतता जांच को लोड करते हैं, तो आप शायद केवल उन गैर-अनुक्रमित अनुक्रमितों को अक्षम करने जा रहे हैं ताकि बाधा को दूर किया जा सके।

ऐसा करने का एक और तरीका है कि DBCC CHECKDB चलाते समय WITH PHYSICAL_ONLY विकल्प का उपयोग करें, लेकिन फिर आप सभी गहन तार्किक जाँचों से चूक जाते हैं, इसलिए मैं समाधान के रूप में इसकी अनुशंसा करने का बड़ा प्रशंसक नहीं हूं।