लेन-देन लॉग का पुनर्निर्माण

Question

हमारे पास एक बहुत बड़ा डेटाबेस (~ 6TB) है, जिसकी लेन-देन लॉग फ़ाइल हटा दी गई थी (जबकि SQL सर्वर बंद हो गया था। हमने कोशिश की है:

1. डेटाबेस का पता लगाना और पुन: परीक्षण करना; तथा
2. लेन-देन लॉग फ़ाइल को हटाना

... लेकिन अभी तक कुछ भी काम नहीं किया है।

वर्तमान में हम चल रहे हैं:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... लेकिन डेटाबेस के आकार को देखते हुए, इसे पूरा होने में शायद कुछ दिन लगेंगे।

प्रशन

• क्या ऊपर और निम्न कमांड के बीच अंतर है?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• क्या हमें REPAIR_ALLOW_DATA_LOSSइसके बजाय क्रियान्वित होना चाहिए ?

यह ध्यान देने योग्य है कि डेटा अन्य स्रोतों से प्राप्त होता है, इसलिए डेटाबेस को फिर से बनाया जा सकता है, हालांकि हमें संदेह है कि डेटाबेस की मरम्मत के लिए सभी डेटा को फिर से पुन: स्थापित करने की तुलना में यह बहुत तेज होगा।

---

अपडेट करें

स्कोर रखने वालों के लिए: ALTER DATABASE/REBUILD LOGकमान लगभग 36 घंटे के बाद पूरी हुई और रिपोर्ट की गई:

चेतावनी: डेटाबेस के लिए लॉग 'dbname' को फिर से बनाया गया है। लेन-देन की संगति खो गई है। RESTORE श्रृंखला टूट गई थी, और सर्वर में अब पिछली लॉग फ़ाइलों पर संदर्भ नहीं है, इसलिए आपको यह जानना होगा कि वे क्या थे।
भौतिक संगतता को मान्य करने के लिए आपको DBCC CHECKDB चलाना चाहिए। डेटाबेस को केवल डीबो मोड में रखा गया है। जब आप डेटाबेस को उपयोग के लिए उपलब्ध करने के लिए तैयार हों, तो आपको डेटाबेस विकल्प को रीसेट करने और किसी भी अतिरिक्त लॉग फाइल को हटाने की आवश्यकता होगी।

हमने तब एक DBCC CHECKDB(लगभग 13hrs लिया) भाग लिया जो सफल रहा। मान लीजिए कि हमने सभी डेटाबेस बैकअप (और परियोजना प्रबंधकों को सर्वर तक पहुंच प्रदान करने ...) का महत्व सीखा है।

Answer 1

कभी भी एक संदिग्ध डेटाबेस को अलग न करें। वैसे भी, आपने डेटाबेस को अलग करने के बाद उसे कैसे संलग्न किया? आप विकल्प के CREATE DATABASEसाथ इस्तेमाल किया FOR ATTACH_REBUILD_LOG?

इन आदेशों को किया जाना चाहिए:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

मैंने इस स्थिति के लिए एक पोस्ट लिखी है:

SQL 2005/2008 डेटाबेस रिकवरी प्रक्रिया - लॉग फाइल डिलीट (भाग 3)

आपने इस अंतर के बारे में पूछा:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) तथा
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

बात यह है कि आप लॉग फ़ाइल को फिर से बनाने के लिए दोनों को चला सकते हैं, लेकिन CHECKDBआप लॉग के साथ ही अखंडता त्रुटियों के लिए डेटाबेस को फिर से बनाते हैं।

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

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)आपातकालीन स्थिति में डेटाबेस पर चलने से असंगतता त्रुटियों के लिए डेटाबेस की जाँच होती है, किसी भी विसंगतियों से उबरने के लिए लॉग फ़ाइल का उपयोग करने की कोशिश करता है। यदि यह गायब है, तो लेन-देन लॉग फिर से बनाया गया है।

2. ALTER DATABASE REBUILD LOG ON...एक अनैच्छिक प्रक्रिया है और DBCC CHECKDBकिसी भी त्रुटि को ठीक करने के लिए एक बाद की आवश्यकता होती है ।

Answer 2

हां, वे दो अलग-अलग कथन हैं, प्रत्येक बहुत अलग चीजें कर रहे हैं।

डेटाबेस की स्थिति के आधार पर जब फ़ाइल को हटा दिया गया था, तो आप डेटाबेस को संलग्न करके और लॉग का उपयोग करके पुन: निर्माण और चलाने में सक्षम हो सकते हैं:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

उत्पाद दस्तावेज़ीकरण में sp_attach_single_file_db (Transact-SQL) देखें ।

पॉल एस। रैंडल की इस ब्लॉग पोस्ट को भी देखें :

आपातकालीन-मोड की मरम्मत: बहुत, बहुत अंतिम उपाय