डीबीए जो पुनर्गठन या अनुक्रमणिका के पुनर्निर्माण के लिए चिंतित है, डेटा हानि का कारण हो सकता है?


14

हमारे पास अनुक्रमणिका विखंडन के साथ कुछ डेटाबेस हैं जो कि> 95% है। जैसा कि सबसे अच्छा मैं बता सकता हूं कि अनुक्रमणिका को कभी भी बहुत कम पुनर्गठित नहीं किया गया है। सालों में।

(निष्पक्षता में, इन तालिकाओं में स्वतः-अद्यतित आँकड़े सक्षम होते प्रतीत होते हैं। निष्पक्षता में भी, वे बैकअप के बारे में मेहनती हैं: प्रतिदिन पूर्ण और ट्रक्स लॉग प्रति घंटा।)

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

मैं एक डीबीए नहीं हूं, लेकिन मैंने जो पढ़ा है, उससे उनकी चिंता लगती है ... मेरे लिए समझना मुश्किल है।

मुझे यकीन नहीं है कि आगे क्या करना है। सुझाव है कि मुझे कैसे आगे बढ़ना चाहिए?


जब तक कि डेटाबेस को 24/7 मुश्किल नहीं मारा जाता है, और अगर यह ऑफ़लाइन हो जाता है, तो दुनिया खत्म हो जाएगी, इस तरह के व्यवहार के लिए कोई बहाना नहीं है। मैं हर हफ्ते 12,000 से अधिक डेटाबेस पर एक दूसरे विचार के बिना रीगो और आँकड़े स्क्रिप्ट करता हूं। 16 वर्षों में मैंने एक खराब नियंत्रक के कारण केवल एक भ्रष्ट किया है।
ब्रेन2000

जवाबों:


22

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

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


11
व्यामोह के लिए +1 अच्छा डीबीए ट्रेट है
जोएल कोएल

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

1
बस एक अनुस्मारक है कि सूचकांक का पुनर्गठन हमेशा ऑनलाइन होता है (सभी सूचकांक डीफ़्रैग के दौरान उपलब्ध होते हैं) और सूचकांक पुनर्निर्माण को भी ऑनलाइन बनाया जा सकता है ( WITH (ONLINE=ON)जब तक कि सूचकांक में BLOB कॉलम नहीं होते हैं।
Remus Rusanu

@Greg हाँ, "चलो बस उसे अनुक्रमित नहीं करते हैं जो इतने खंडित हैं कि शायद वे प्रदर्शन को खराब कर रहे हैं" मानसिकता मुझे नरक से भी भ्रमित करती है - कभी-कभी REINDEXउन तालिकाओं पर "निवारक रखरखाव" के रूप में जहां सूचकांक सामग्री बहुत अधिक बदल जाती है मेरे अनुभव में आम (यदि इंडेक्स ज्यादातर स्थिर है तो यह किसी चीज से कम नहीं है)
voretaq7

@Remus अच्छा टिप - यह प्रदर्शन प्रभाव को कम करता है (आप अभी भी उच्च डिस्क I / O करने जा रहे हैं, जो आपको कुछ धीमा कर देगा, लेकिन कम से कम चीजें जो एक सूचकांक का उपयोग करेगी वह अभी भी अनुक्रमिक स्कैन का सहारा लेने के बजाय इसका उपयोग कर सकती हैं। )
voretaq7

6

इंडेक्स के पुनर्निर्माण या डीफ़्रैग करने से डेटा हानि का कोई जोखिम नहीं है।


जब तक आप पहले से ही कुछ हद तक डेटा भ्रष्टाचार, या हार्डवेयर विफल हो रहा है। लेकिन उन दोनों मामलों में, सूचकांक विखंडन आपकी चिंताओं में से सबसे कम है!
db2

लेकिन यह एक सूचकांक पुनर्निर्माण से भ्रष्टाचार नहीं होगा, लेकिन कुछ अन्य समस्या से।
mrdenny

4

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

मैं voretaq7 से सहमत हूं, अगर वह सूचकांक के साथ काम करने के बारे में चिंतित है, तो विकास या परीक्षण सर्वर पर पहले यह देखने की कोशिश करें कि प्रतिक्रिया कैसी है।


लेने के लिए एक और दृष्टिकोण स्पष्ट रूप से DROP INDEXऔर फिर से हो सकता है CREATE INDEX- मैं SQL सर्वर के बारे में निश्चित नहीं हूं, लेकिन मुझे पता है कि PostgreSQL कभी-कभी एक सूचकांक को उड़ाने से बेहतर होता है और REINDEXइसे फिर से बनाने ( ) के बजाय खरोंच से शुरू होता है ।
voretaq7

मुझे पूरा यकीन है कि ड्रॉप करना और फिर से बनाना SQL सर्वर पर अनावश्यक है।
जस्टिन डियरिंग

@ जस्टिन मुझे पूरा यकीन है कि आप सही कह रहे हैं (वास्तव में मेरे साइबेस दिनों से मुझे याद है कि रिइंडेक्सिंग व्यवहार प्रभावी रूप से एक ड्रॉप / क्रिएट है, इसलिए पोस्टग्रेस में कोई इंडेक्स-लॉकिंग विषमता नहीं है)
voretaq7

पुनर्गठन सूचकांक में कम समय लग सकता है। कौन सा अधिक समय लेता है यह सूचकांक के विखंडन की मात्रा पर निर्भर करेगा।
mrdenny
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.