अनुक्रमणिका का पुनर्निर्माण करते समय Sort_in_tempdb का उपयोग कब करें?

Question

हम बहस कर रहे हैं कि हमारे DW टेबल के लिए SORT_IN_TEMPDB विकल्प का उपयोग करें या नहीं। मेरी समझ यह है कि इस विकल्प का उपयोग करते समय अधिक लिखते हैं, हालांकि वे अधिक अनुक्रमिक हैं। हमारे पास एक SAN (जो कई बार कुख्यात रहा है), इसलिए हमारे मामले में हम जितना संभव हो उतना लिखना सीमित करना चाहते हैं। मेरा मानना ​​है कि tempdb एक अलग LUN (डिस्क का सेट) पर है।

हमारे डेटा फ़ाइल में और हमारे tempdb फ़ाइल में डिस्क स्थान बहुत है। इस स्थिति में, क्या हमें SORT_IN_TEMPDB का उपयोग करने से लाभ होगा?

एक बात जिसने मुझे मारा वह इस उत्तर पर टिप्पणी थी

जब एक इंडेक्स का पुनर्निर्माण किया जाता है तो आपको छँटाई के लिए इंडेक्स + 20% के दो बार स्पेस की आवश्यकता होती है। तो सामान्य तौर पर आपके db में हर इंडेक्स को फिर से बनाने के लिए आपको अपने DB में अपने सबसे बड़े इंडेक्स के 120% की आवश्यकता होती है। यदि आप SORT_IN_TEMPDB का उपयोग करते हैं, तो आप केवल 20% जीतते हैं, फिर भी आपको अपनी डेटा फ़ाइल में 100% एक एडिशनल की आवश्यकता होती है। इससे भी अधिक, tempdb में सॉर्ट का उपयोग करने से आपका IO लोड बहुत अधिक बढ़ जाता है, क्योंकि इंडेक्स को एक बार डेटाफ़ाइल में लिखने के बजाय, आप अब इसे एक बार tempdb पर लिखते हैं और फिर इसे डेटा फ़ाइल में लिखते हैं। इसलिए यह हमेशा आदर्श नहीं होता है।

हम निश्चित रूप से अपने धीमे / संभवतः गलत तरीके से किए गए SAN के साथ हमारे IO लोड को बढ़ाना नहीं चाहते हैं।

इसे परखने का सबसे अच्छा तरीका क्या होगा? बस विकल्प के साथ और बिना तालिका का पुनर्निर्माण करके और बार लॉग इन करें?

संपादित करें : हमारे पास 8 tempdb फाइलें हैं, प्रत्येक 15GB। हमारे पास TF 1117/1118 झंडे सेट हैं और IFI सक्षम है। वर्तमान में हम Sort_in_tempdb विकल्प के साथ और इसके बिना पुनर्निर्माण का मिश्रण करते हैं।

धन्यवाद!

SQL सर्वर 2012 एंटरप्राइज़

Answer 1

SORT_IN_TEMPDBइसका मतलब है कि SQL सर्वर tempdbउपयोगकर्ता डेटाबेस में स्थान आवंटित करने के लिए अस्थायी स्थान आवंटित करने के लिए उपयोग करेगा जिसका सूचकांक पुनर्निर्माण किया जा रहा है। इसका मतलब यह है कि आपको अपने उपयोगकर्ता डेटाबेस में एक इंडेक्स पुनर्निर्माण ऑपरेशन के दौरान कम खाली स्थान की आवश्यकता होगी और टेम्पर्ड बी में अधिक खाली स्थान की आवश्यकता होगी।

उपयोगकर्ता डेटाबेस से एक अलग डिस्क (LUN) पर है जब यह बेहतर लाभ देता है।

से SORT_IN_TEMPDB विकल्प - बोल :

यदि SORT_IN_TEMPDB विकल्प ON पर सेट है और tempdb गंतव्य फ़ाइलसमूह से डिस्क के एक अलग सेट पर है , तो पहले चरण के दौरान, डेटा पेज की रीड्स एक अलग डिस्क पर लिखने से tempdb में सॉर्ट कार्य क्षेत्र में होती हैं। इसका मतलब यह है कि डिस्क डेटा कीज़ को पढ़ती है जो आमतौर पर डिस्क पर अधिक क्रमिक रूप से जारी रहती है, और टेम्पर्ड डिस्क पर राइट्स भी आमतौर पर सीरियल होते हैं, जैसा कि फाइनल इंडेक्स बनाने के लिए लिखते हैं। यहां तक ​​कि अगर अन्य उपयोगकर्ता डेटाबेस का उपयोग कर रहे हैं और अलग-अलग डिस्क पते तक पहुंच रहे हैं, तो SORT_IN_TEMPDB निर्दिष्ट नहीं है जब यह नहीं है, तो रीड एंड राइट का समग्र पैटर्न अधिक कुशल होता है।

सुनिश्चित करें कि SORT_IN_TEMPDB चालू होने पर आप डिस्क स्थान आवश्यकताओं को पढ़ें ।

धीमी गति से / संभवतः गलत तरीके से SAN

आपको दर्द की बात पता है। आप इसे ठीक करने के लिए अपने SAN व्यवस्थापक के साथ काम क्यों नहीं करते? गलत और धीमी गति से SAN धीमेपन की तरह सभी समस्याओं का कारण होगा ।

नोट करने के लिए कुछ महत्वपूर्ण बिंदु:

• ऑनलाइन इंडेक्स पुनर्निर्माण करते समय MAXDOP = 1 का उपयोग करें - अन्यथा यह विखंडन को बढ़ाएगा।
• विखंडन स्तर के साथ-साथ पृष्ठ के टुकड़ों के आधार पर अपने इंडेक्स को फिर से समझें / फिर से बनाएं ।
• 60 GB इंडेक्स बनाने के साथ SQLFool का अनुभव पढ़ें
• सुनिश्चित करें कि आप कॉन्फ़िगर किया है tempdb ठीक से करें - TF 1117 (सभी फाइलों में एक FILEGROUP को आगे बढ़ाएं समान रूप से) और 1118 (पूर्ण विस्तार केवल) और अधिक tempdb डाटाफाइलों ।

इसे परखने का सबसे अच्छा तरीका क्या होगा?

हां, आपको प्रतीक्षा सूची का विश्लेषण करके इसका परीक्षण करना होगा जब आप सूचकांक को बिना और उसके साथ पुनर्निर्माण करते हैं SORT_IN_TEMPDB। PROD के रूप में अच्छी तरह से चलाने के समय को मापें और सुनिश्चित करें कि आप इसे रखरखाव विंडो या कम सर्वर गतिविधि के दौरान करते हैं। इसके अलावा अपने पढ़ने / लिखने के डेटा और लॉग विलंबता की जाँच करें ।

मुझे यकीन नहीं है कि आपके पास तत्काल फ़ाइल आरंभीकरण है , लेकिन डेटा फ़ाइलों के ऑटोग्रॉथ के दौरान और एक नया डेटाबेस बनाते समय (बस पूर्णता का उल्लेख करते हुए) इसका फायदा होगा।

Comments

मैंने अपनी टिप्पणी को अपने tempdb विन्यास के साथ संपादित किया। धन्यवाद, धारावाहिक ऑनलाइन पुनर्निर्माण टिप के बारे में नहीं पता था। मैं कुछ और परीक्षण करूँगा और कोशिश करूँगा SAN एडमिन के साथ, जो दुर्भाग्य से स्वागत करने से कम है। क्या कोई विशिष्ट वेटस्टैट्स है जिसकी मुझे तुलना करनी चाहिए (उदा। PageIOLatch)? हमारे tempdb लिखते हैं सुपर उच्च (4000ms) जो भयावह है। मुख्य DBs के लिए 40ms के तहत। हालांकि यह एक और समय के लिए एक सवाल हो सकता है ...!

— गाबे

@Gabe आपको अपने SAN व्यवस्थापक को उचित तथ्यों को दिखाना चाहिए कि यह वास्तव में एक SAN समस्या है - विलंबता को पढ़ें / लिखें - sysinos_io_virtual_file_stats । क्या आपका टेम्पर्ड LUN अलग है?

— परिजन शाह