पुनर्स्थापित करने में असमर्थ (त्रुटि 3456)

Question

मेरे पास एक ऐसी स्थिति है जिसका पता लगाना आसान नहीं है, और मैंने सोचा कि मैं इस मंच पर पूछूंगा कि क्या दूसरों के सुझाव हो सकते हैं।

मैं Windows Server 2008R2 एंटरप्राइज़ पर SQL Server 2008 R2 मानक SP3 चला रहा हूं।

एक डेटाबेस को कुछ रखरखाव की आवश्यकता थी, और इस तथ्य के बाद मुझे दूसरे सर्वर पर पुनर्स्थापित करने की आवश्यकता थी। मैं एक पूर्ण DB बैकअप COPY_ONLY प्लस 4 tlog बैकअप का एक सेट के साथ किया है।

1. शुरू करने से पहले, tlogbackup1 बनाएं
2. से बदलने FULLके लिए BULK_LOGGEDवसूली मॉडल
3. नया फ़ाइल समूह जोड़ें
4. newfilegroup में फ़ाइल जोड़ें
5. डिफ़ॉल्ट होने के लिए newfilegroup सेट करें
6. तालिका में चयन करें (newfilegroup पर)
7. मूल तालिका छोड़ें
8. मूल फ़ाइल हटाएं
9. मूल फ़ाइल समूह हटाएं
10. मूल तालिका से मिलान करने के लिए नई तालिका का नाम बदलें
11. मूल फ़ाइल समूह से मेल करने के लिए newfilegroup का फ़ाइल नाम बदलें
12. मूल फ़ाइल नाम से मिलान करने के लिए कैटलॉग में फ़ाइल का नाम बदलें
13. मूल फ़ाइल नाम से मिलान करने के लिए OS स्तर पर फ़ाइल नाम बदलें
14. मूल होने के लिए डिफ़ॉल्ट फ़ाइल समूह सेट करें
15. ऑनलाइन DB लाओ
16. से बदलने BULK_LOGGEDके लिए FULLवसूली मॉडल
17. सभी चरणों के पूरा होने के बाद, tlogbackup2 बनाएं

पुनर्स्थापना सर्वर पर ड्राइव अक्षर परिवर्तन के कारण सभी बैकअप के पुनर्स्थापना को MOVE के साथ उपयोग करना चाहिए।

पुनर्प्राप्ति चरण:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

अंतिम टाल बहाल करने के लिए 100% हो जाता है और फिर त्रुटि 3456 के साथ विफल हो जाता है:

डेटाबेस 'SomeDB' के लिए 368 पृष्ठों की प्रक्रिया, फ़ाइल 1 पर 'SystemData' फ़ाइल।

डेटाबेस 'SomeDB' के लिए 7656520 पेज प्रोसेस किए गए, फ़ाइल 1 पर 'SystemDataPDS' फ़ाइल।

डेटाबेस 'SomeDB' के लिए 172430 पृष्ठों की प्रक्रिया, फ़ाइल 1 पर 'SystemData_log' फ़ाइल।

Msg 3456, स्तर 16, राज्य 1, पंक्ति 1
लेन-देन आईडी रिकॉर्ड (210388: 123648: 232), लेनदेन आईडी (0: 1016710921) के लिए, पृष्ठ (4: 8088) पर, डेटाबेस 'SomeDB (डेटाबेस आईडी 6) नहीं कर सका। । पेज: LSN = (0: 0: 1), टाइप = 11. लॉग: OpCode = 4, संदर्भ 11, PrevPLSLSN: (210388: 122007: 1)। डेटाबेस के बैकअप से पुनर्स्थापित करें, या डेटाबेस की मरम्मत करें। Msg 3013, लेवल 16, स्टेट 1, लाइन 1 RESTORE लॉग असामान्य रूप से समाप्त हो रहा है।

बस यह सत्यापित करने के लिए कि पूर्ण डीबी बैकअप ठीक था, मैंने इसे फिर से चालू किया CHECKDB, और इसमें कोई त्रुटि नहीं थी।

सभी प्रतिक्रिया का स्वागत किया।

अग्रिम में धन्यवाद,

नेड ओटर

Comments

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

— थॉमस केजर

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

— नेडऑटर

त्रुटि भ्रष्टाचार जैसी दिखती है। यह एक आंतरिक त्रुटि है। क्या आप सभी बैकअप फ़ाइलों की अखंडता को सत्यापित कर सकते हैं? क्या वे चेकसम के साथ हैं?

— usr

मैंने सत्यापित किया कि पूर्ण db बैकअप में CHECKDB चलाकर 0 त्रुटियाँ थीं। मुझे यह देखने के लिए जांचना होगा कि क्या CHECKSUM का उपयोग किया गया था।

— नेडऑटर

यदि बैकअप में चेकसम सक्षम है, तो आपको पुनर्स्थापना के लिए भी चेकसम का उपयोग करना चाहिए। पृष्ठ प्रकार 11 एक पीएफएस पृष्ठ है, जिसका अर्थ है कि आप इसे ठीक नहीं कर सकते, आप केवल एक पूर्ण पुनर्स्थापना कर सकते हैं। इसके अलावा, आप यह नहीं कहते हैं कि जब कॉपी केवल बैकअप लिया गया था। टाइम लाइन में वह बैकअप कहां था?

— रॉबर्ट एल डेविस

Answer 1

यह समझने के लिए कि त्रुटि 3456 को क्यों फेंका जाएगा, हमें थोड़ा कदम पीछे लेने और यह समझने की आवश्यकता है कि SQL सर्वर पुनर्प्राप्ति के इस कोने को कैसे संभालता है।

जब SQL सर्वर किसी ऑपरेशन को फिर से कर रहा होता है, और वह रीडो एक पेज संशोधन होता है, तो यह एक त्वरित जांच करता है। पेज हेडर में अंतत: एक होने जा रहा है PageLSN, जो पिछले एलएसएन का एक संकेत है जिसने उस पेज को संशोधित किया है, जो पेज द्वारा रिकॉर्ड किया गया है। इसके बारे में इस तरह से सोचें, पेज अंतिम एलएसएन का ट्रैक रखता है जिसने इसमें संशोधन किए हैं। यह है PageLSN।

हर बार एक लॉग पृष्ठ संशोधन ऑपरेशन होता है, उस लॉग रिकॉर्ड में कुछ LSN शामिल होते हैं। अर्थात्, लॉग रिकॉर्ड का एलएसएन (सोचो ... करंट एलएसएन ), और फिर इसे पिछला पेज एलएसएन ( PrevPageLSNआगे बढ़ने वाला) कहा जाता है । इसलिए जब हम एक पृष्ठ को संशोधित करते हैं, तो लॉग रिकॉर्ड में डाले गए डेटा के टुकड़ों में से एक पृष्ठ को संशोधित करने से पहले पृष्ठ अंतिम एलएसएन होने के रूप में इंगित करता है ।

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

यह कुछ भ्रामक हो सकता है, इसलिए अनुक्रमिक पृष्ठ संशोधनों पर नीचे इस छवि पर एक नज़र डालें, और कैसे PageLSNऔर PrevPageLSNसंबंधित:

आइए अब चारों ओर लूप करें, क्योंकि जब आप किसी पृष्ठ (पुनर्स्थापना, पुनर्प्राप्ति, हाए, आदि) पर एक ऑपरेशन को फिर से करने की आवश्यकता होती है, तो यह सब खेल में आता है । जब SQL सर्वर को एक पृष्ठ संचालन को फिर से करने की आवश्यकता होती है, तो यह देखने के लिए एक पवित्रता जांच करता है कि क्या PageLSNपृष्ठ पर PrevPageLSNलॉग रिकॉर्ड शामिल है। यदि वह समान नहीं है, तो आप देखेंगे कि त्रुटि 3456 है।

क्या PageLSN बराबर PrevPageLSN ? नहीं??? रोकें और त्रुटि बढ़ाएं 3456 ...

आइए अपने त्रुटि संदेश का विश्लेषण करें, जिसमें शामिल हैं:

लॉग इन रिकॉर्ड (210388: 123648: 232), लेन-देन आईडी (0: 1016710921) के लिए, पृष्ठ (4: 8088), डेटाबेस 'SomeDB' (डेटाबेस आईडी 6) पर फिर से नहीं किया जा सका। पेज: LSN = (0: 0: 1) , टाइप = 11. लॉग: OpCode = 4, संदर्भ 11, PrePPLSLSN: (210388: 122007: 1) । डेटाबेस के बैकअप से पुनर्स्थापित करें, या डेटाबेस की मरम्मत करें। Msg 3013, लेवल 16, स्टेट 1, लाइन 1 RESTORE लॉग असामान्य रूप से समाप्त हो रहा है।

मेरे पास डेटा के दो टुकड़े हैं जो त्रुटि के कारण असमानता है। आप देख सकते हैं कि हमारे PageLSNहै 0: 0: 1 (इस पृष्ठ के हेडर में पाया गया था), और हमारे PrevPageLSNहै 210,388: 122,007: 1 (इस लॉग रिकॉर्ड पर डेटा कि पुनः किया जा करने के लिए प्रयास कर रहा था में पाया गया था)। ये स्पष्ट रूप से नहीं के बराबर हैं, इसलिए mis3456 है।

तो इस घटना के कारण का पता लगाने के लिए , यह पता लगाना होगा कि यहाँ एक असमानता क्यों है। हमें वास्तव में पेज 4: 8088 के जीवनचक्र का पता लगाने की जरूरत है और देखें कि डिस्कनेक्ट कहां है। दुर्भाग्यवश आगे की जानकारी के बिना, या हाथों की समस्या के निवारण के लिए और कुछ नहीं है इसके अलावा मैं आपको इस पुनर्प्राप्ति ऑपरेशन की पृष्ठभूमि दे सकता हूं और त्रुटि का कारण बनता है।

Comments

मुझे पता है कि थोड़ी देर हो गई है लेकिन फिर भी ... अच्छी चीजें, पूरी तरह से समझाने के लिए धन्यवाद!

— आरटीएचओएम