ऑनलाइन पेज 1000 सीमा से टकराने को पुनर्स्थापित करता है

Question

मुझे एक डेटाबेस को पुनर्प्राप्त करने का प्रयास करने का काम सौंपा गया है जो भ्रष्टाचार से पीड़ित था (I / O की विफलता के कारण, जो तब से तय हो गया है)। मैं डेटाबेस से परिचित नहीं हूँ या इसमें क्या है।

मुझे एक पुराना (~ 3 सप्ताह) पूर्ण बैकअप दिया गया है और लेन-देन लॉग की एक श्रृंखला है ... हालांकि लापता लेनदेन लॉग हैं, इसलिए मैं केवल एक निश्चित तिथि तक ही पुनर्प्राप्त कर सकता हूं। 2.5 सप्ताह का डेटा गायब है (और लगातार इस डेटाबेस में बहुत सारा डेटा जोड़ा जा रहा है)।

मुझे भ्रष्ट डेटाबेस की एक प्रति भी दी गई है (जो कि सुलभ है, लेकिन बहुत सारे पृष्ठ भ्रष्ट / गायब हैं)।

मैंने सामान्य DBCC CHECKDBआदेशों की कोशिश की है (फिर भी नहीं repair_allow_data_loss, यह मेरा अंतिम उपाय होगा यदि कुछ और काम नहीं करता)।

कई आने के बाद और डेटाबेस में जाता है (डीबी एक 1.5 टेराबाइट वाला छोटा राक्षस है और मैं जो कुछ भी करता हूं वह धीमा है और थोड़ी देर लगता है), मैंने भ्रष्ट पृष्ठों के लिए अंतिम ज्ञात अच्छे बैकअप से एक ऑनलाइन पेज को पुनर्स्थापित करने की कोशिश की है।

ऐसा करने के लिए, मैंने एक स्क्रिप्ट बनाई है जो आउटपुट RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'से कई कमांड्स बनाती है DBCC CHECKDB(बेज़िकली एक रेग्क्स और एक अलग) ... अब तक अच्छा, यह एक बिंदु तक काम करता था जहां यह कहा जाता था कि मैं 1000 पृष्ठों की सीमा तक पहुंच गया हूं प्रति फ़ाइल (इस db पर 8 फाइलें हैं) प्रति पुनर्स्थापना आदेश।

तो यह मुझे "ऑनलाइन पुनर्स्थापना को पूरा करने" के लिए कहता है, लेकिन मैं ऐसा करने के नुकसान पर हूं ... मेरे पास एक पूंछ लॉग या पूर्ण बैकअप की तुलना में अधिक पूर्ण कुछ भी नहीं है जो मैं शुरू कर रहा हूं, इसलिए मैं मूल रूप से बाकी पृष्ठों के साथ प्रयास करते रहने के लिए पुनर्स्थापना को पूरा करने का तरीका नहीं जानता।

मैंने कोशिश की है, RESTORE DATABASE <foo> WITH RECOVERYलेकिन यह भी काम नहीं किया, यह मुझे एक लॉग के लिए पूछता है जो मेरे पास नहीं है।

क्या किसी के पास कोई सुझाव है कि मैं कैसे यहां से कुछ भी ठीक करने की कोशिश कर सकता हूं? या ऑनलाइन पुनर्स्थापना को "पूरा" कैसे करें ताकि मैं अधिक पृष्ठों को पुनर्प्राप्त करने के लिए प्रयास कर सकूं? यदि मैं एक ऑफ़लाइन पुनर्स्थापना (मूल रूप WITH NORECOVERYसे सब कुछ जोड़ने और फिर इसे अंत में वापस लाने का प्रयास करता हूं) तो क्या मुझे भी यही समस्या होगी ?

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

कुछ डेटा हानि स्वीकार्य होगी, लेकिन डीबी पर स्थिरता कम से कम हासिल करने की कोशिश करनी चाहिए।

भ्रष्ट डेटाबेस -still- ऑनलाइन है और ग्राहक इस पर काम कर रहे हैं (इसलिए यह नया डेटा प्राप्त करता रहता है), इसलिए मैं लैब बेंच पर जो भी प्रक्रिया करता हूं, उसे प्रोडक्शन डेटाबेस पर बाद में पुन: पेश करना चाहिए (डाउनटाइम इसके लिए कठिन होगा)।

यह SQL Server 2014 एंटरप्राइज़ है

पुनश्च: मैं कोई डीबीए नहीं हूं ... मैं एक प्रोग्रामर हूं, लेकिन क्लाइंट ने कुछ "विशेषज्ञ" एसक्यूएल आपदा रिकवरी सेवाओं की कोशिश की है और उन्होंने हार मान ली है, इसलिए मुझे इसे देखने और देखने के लिए कहा गया है कि क्या मैं कर सकता हूं कुछ भी करो।

---

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

Answer 1

मानक प्रक्रिया निम्नानुसार होगी:

1. उस पृष्ठ ID को प्राप्त करें जिसे पुनर्स्थापित करना है।
2. एक पूर्ण डेटाबेस के साथ एक पृष्ठ बहाल करना शुरू करें।
3. सबसे हाल के अंतर बैकअप लागू करें।
4. बाद में लॉग बैकअप लागू करें।
5. नया लॉग बैकअप बनाएं।
6. नए लोब बैकअप को पुनर्स्थापित करें।

नया लॉग बैकअप लागू होने के बाद, पेज रिस्टोर पूरा हो गया है और पेज फिर उपयोग करने योग्य हैं।

उदाहरण पुनर्स्थापित करें

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

संदर्भ: पुनर्स्थापना पृष्ठ (SQL सर्वर) (Microsoft डॉक्स) संदर्भ: अन्य विवरण (लेनदेन-SQL) (Microsoft डॉक्स)

हालाँकि, आपके पास अपने TLOG बैकअप में छेद हैं, और उपरोक्त प्रक्रिया के साथ बहाल करने से आपके डेटाबेस को उस स्थिति में वापस लाया जा सकता है जब आप इच्छा नहीं करते हैं।

---

आप एक जटिल स्थिति में हैं।

1. आपके डेटाबेस में भ्रष्ट पृष्ठ हैं और आपकी कंपनी मुद्दों के साथ डेटाबेस में लगातार नए डेटा जोड़ रही है। यह डेटाबेस के कुल डाउनटाइम में परिणाम हो सकता है। क्या आप जोखिम लेना चाहते हैं?

2. किसी को जिम्मेदार ठहराया जा रहा है और जितना अधिक आप इसे ठीक करने की कोशिश करेंगे, उतना अधिक प्रबंधन यह तय करने के लिए इच्छुक होगा कि आप अंत में उस व्यक्ति हो सकते हैं। क्या आप जोखिम लेना चाहते हैं?

3. आप खुद को एक मुश्किल स्थिति में डाल रहे हैं, एक ऐसी भूमिका निभाकर, जिसके लिए आप नियोजित नहीं थे। आप कुछ ऐसा हासिल करने की कोशिश कर रहे हैं जो न तो आपकी कंपनी डीबीए और न ही आपके बाहरी सलाहकार सक्षम थे। हालांकि यह एक अच्छा इशारा हो सकता है, आप खुद को जोखिम में डाल रहे हैं। आपके पास "निहित रूप से वादा किया गया" कुछ ऐसा हो सकता है जिसे आप कभी पूरा नहीं कर पाएंगे। क्या आप जोखिम लेना चाहते हैं?

4. जब डेटाबेस के साथ काम करने वाला कोई व्यक्ति डेटा को भ्रष्ट करता है, तो वे संभवतः एक त्रुटि संदेश प्राप्त करने जा रहे हैं। दैनिक कार्य पहले से ही प्रभावित हो रहे हैं। जितनी देर आप अपरिहार्य के साथ प्रतीक्षा करेंगे उतनी अधिक उत्पादकता प्रभावित होगी। क्या आप जोखिम लेना चाहते हैं? (यह सवाल प्रबंधन के साथ भी उठाया जा सकता है)

5. आपकी कंपनी की बैकअप प्रक्रिया दोषपूर्ण लगती है (अन्यथा TLOG बैकअप कैसे गायब होगा?) और आप अभी भी अपना उत्पादन डेटाबेस चला रहे हैं जैसे कि कोई समस्या नहीं थी। क्या आप जोखिम लेना चाहते हैं?

सबसे अच्छी सिफारिश जो मैं आपको दे सकता हूं वह है उत्पादन को रोकना और Microsoft को कॉल करना! या कम से कम Microsoft को कॉल करें और संभवतः उत्पादन को रोकें।

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

जितनी देर आप करेंगे उतनी महंगी रिकवरी हो सकती है।

---

पृष्ठ पुनर्स्थापना पर सीमा के लिए के रूप में, यहाँ आधिकारिक प्रलेखन से एक उद्धरण:

पुनर्स्थापना क्रम में किसी भी एक फ़ाइल में पुनर्स्थापित किए जा सकने वाले पृष्ठों की अधिकतम संख्या 1000 है । हालाँकि, यदि आपके पास फ़ाइल में कम संख्या में क्षतिग्रस्त पृष्ठ हैं, तो पृष्ठों के बजाय संपूर्ण फ़ाइल को पुनर्स्थापित करने पर विचार करें।

^{( जोर मेरा)}

संदर्भ: अन्य विवरण - तर्क (लेनदेन-एसक्यूएल) (Microsoft डॉक्स)

---

जब सब सामान्य हो जाता है, तो DBA और / या बाहरी सलाहकार आपके डेटाबेस के लिए एक अलग बैकअप / पुनर्स्थापना नीति / प्रक्रिया को लागू करने पर विचार कर सकते हैं। जैसा कि 7x24 होना चाहिए, आप एक बैकअप प्रक्रिया होने का जोखिम नहीं उठा सकते जो किसी भी स्थिति के लिए पर्याप्त पुनर्स्थापना क्षमता प्रदान नहीं करता है।

Comments

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

— जेसीएल

Answer 2

मैं देख रहा हूं कि आपने विशेष रूप से 1 टीबी के आकार के साथ इस भ्रष्ट डेटाबेस को ठीक करने के लिए डेटा रिकवरी "विशेषज्ञों" के साथ काम करने सहित विभिन्न तरीकों की कोशिश की है। इससे प्रक्रिया बहुत कठिन हो जाती है और समय के खिलाफ एक दौड़ हो जाती है। एक अनुभवी डीबीए के रूप में, मैं ऐसी ही स्थितियों में आया हूं जहां अधिकांश समय, बहाल करने के लिए अच्छे बैकअप उपलब्ध हैं। खराब बैकअप और भ्रष्ट डेटाबेस को विरासत में देने के मामले में, मैंने स्टेलर फीनिक्स SQL ​​डेटाबेस रिपेयर टूल नामक तीसरे पक्ष के टूल पर बहुत भरोसा किया है । यह उपकरण भ्रष्ट डेटाबेस (.mdf और .ndf) की मरम्मत के लिए प्रसिद्ध है। उपकरण के कुछ कार्य नीचे दिए गए हैं:

• मरम्मत भ्रष्ट SQL डेटाबेस (.mdf और .ndf) फ़ाइलें
• टेबल, ट्रिगर्स, इंडेक्स, चाबियाँ, नियम और संग्रहीत कार्यविधियाँ पुनर्प्राप्त करता है

• SQL डेटाबेस से हटाए गए रिकॉर्ड की पुनर्प्राप्ति करता है

• बाद में स्टेज पर रिकवरी करने के लिए डेटाबेस का स्कैन परिणाम बचाता है

• MSSQL, HTML, XLS और CSV स्वरूपों में मरम्मत की गई फ़ाइल को सहेजने की अनुमति देता है
• एमएस SQL ​​सर्वर 2016, 2014, 2012,2008 और पुराने संस्करणों का समर्थन करता है

टूल को .mdf और .ndf फ़ाइलों को ऑफ़लाइन होने की आवश्यकता होती है, इसलिए यह बहुत अच्छा काम करता है कि आपके पास दूषित PROD डेटाबेस की एक प्रति है और SQL सर्वर सेवाओं को रोकना नहीं है।

सबसे अच्छा हिस्सा यह है कि परीक्षण संस्करण आपको उपकरण की पूर्ण कार्यक्षमता प्रदान करता है सिवाय इसके कि मरम्मत किए गए डेटाबेस को निर्यात / सहेजा नहीं जा सकता है। आप अभी भी बरामद सभी डेटाबेस ऑब्जेक्ट और व्यापक मरम्मत लॉग फ़ाइल को देख पाएंगे जो मरम्मत प्रक्रिया के विभिन्न चरणों पर विवरण प्रदान करता है।

बेझिझक डाउनलोड करें और देखें कि क्या यह मदद करता है। यहाँ डाउनलोड करें

मैंने यह भी लिखा है कि इस साइट पर टूल कैसे काम करता है: समोसेक ब्लॉग

धन्यवाद और HTH आप दिन के हीरो बनाने के लिए!

पुनश्च। जब यह तूफान खत्म हो जाता है, तो प्रबंधन को बताना याद रखें कि विशेष रूप से ऐसे डेटाबेस के लिए उनकी बैकअप प्रक्रियाओं का एक बड़ा ओवरहाल होना चाहिए। इस परिदृश्य का दोहराव पूरी तरह से अस्वीकार्य है! :)