विलंबित अद्यतन पुनर्प्राप्ति:विश्वसनीय डेटा अखंडता के लिए NO-UNDO और REDO का उपयोग करना
<पी> विलंबित अद्यतन पुनर्प्राप्ति में, लेन-देन शुरू होने तक डिस्क पर वास्तविक डेटाबेस संशोधनों को स्थगित कर दिया जाता है। निष्पादन के दौरान अपडेट केवल लॉग और कैश बफ़र्स में रिकॉर्ड किए जाते हैं। यदि कोई लेन-देन प्रतिबद्ध होने से पहले विफल हो जाता है, तो डिस्क पर डेटाबेस अप्रभावित रहता है इसलिए NO-UNDO। प्रतिबद्ध लेनदेन के लिए केवल REDO की आवश्यकता है जिनके परिवर्तन डिस्क पर नहीं लिखे गए हैं। स्थगित अद्यतन प्रोटोकॉल
- कोई लेनदेन डिस्क पर डेटाबेस को तब तक संशोधित नहीं कर सकता जब तक कि वह अपने प्रतिबद्ध बिंदु तक नहीं पहुंच जाता।
- सभी REDO लॉग प्रविष्टियों को कमिट करने से पहले डिस्क पर बलपूर्वक लिखा जाना चाहिए (राइट-अहेड लॉगिंग)।
- केवल REDO लॉग प्रविष्टियाँ (नए मान/AFIM) की आवश्यकता है, UNDO प्रविष्टियों की आवश्यकता नहीं है।
रिकवरी प्रक्रिया (RDU_M)
<पी> सख्त दो-चरण लॉकिंग वाले बहुउपयोगकर्ता सिस्टम के लिए, पुनर्प्राप्ति एल्गोरिदम दो सूचियाँ बनाए रखता है - प्रतिबद्ध सूची अंतिम चेकपॉइंट के बाद से किए गए लेनदेन।
- सक्रिय सूची लेनदेन जो अभी भी सक्रिय थे (प्रतिबद्ध नहीं थे)।
<पी> REDO को लॉग ऑर्डर में प्रतिबद्ध लेनदेन के WRITE संचालन पर लागू किया जाता है। सक्रिय (अप्रतिबद्ध) लेनदेन प्रभावी रूप से रद्द कर दिए जाते हैं और इन्हें पुनः सबमिट किया जाना चाहिए। उदाहरण समयरेखा
चेकपॉइंट (t1) क्रैश (t2) T1 (प्रतिबद्ध) T2 → REDO T3 → REDO T4 → अनदेखा (कोई प्रतिबद्धता नहीं) T5 → अनदेखा (कोई प्रतिबद्धता नहीं) <पी> T1 चेकपॉइंट से पहले प्रतिबद्ध है, दोबारा करने की कोई आवश्यकता नहीं है। चेकपॉइंट के बाद प्रतिबद्ध T2, T3 को फिर से किया जाना चाहिए। T4, T5 ने कभी भी अनदेखा नहीं किया (स्थगित अद्यतन के तहत डिस्क पर कोई परिवर्तन नहीं)। REDO अनुकूलन
<पी> यदि आइटम X को प्रतिबद्ध लेनदेन द्वारा कई बार अद्यतन किया गया था, तो केवल अंतिम अद्यतन को फिर से करने की आवश्यकता है - लॉग को उल्टे क्रम में घुमाएं।
- पहले से तैयार किए गए आइटमों की एक सूची बनाए रखें।
- सूची में पहले से मौजूद आइटम छोड़ें (अंतिम मान पहले ही पुनर्प्राप्त हो चुका है)।
- केवल वही आइटम दोबारा बनाएं जो अभी तक सूची में नहीं हैं, फिर उन्हें जोड़ें।
फायदे और सीमाएं
फायदे | सीमाएं | विफलता पर कोई रोलबैक की आवश्यकता नहीं है (NO-UNDO) राइट-लॉक किए गए आइटम कमिट होने तक लॉक रहते हैं, कोई कैस्केडिंग रोलबैक नहीं (कमिट होने तक लॉक किए गए आइटम) कमिट होने तक सभी अपडेट के लिए बफर स्पेस की आवश्यकता होती है, निरस्त किए गए लेनदेन को फिर से सबमिट किया जाता है, केवल कुछ बदलावों के साथ छोटे लेनदेन के लिए व्यावहारिक निष्कर्ष
<पी> NO-UNDO/REDO आस्थगित अद्यतन डिस्क राइट को प्रतिबद्ध होने तक स्थगित कर देता है, जिससे पुनर्प्राप्ति के दौरान UNDO संचालन की आवश्यकता समाप्त हो जाती है। अंतिम चेकपॉइंट के बाद केवल प्रतिबद्ध लेनदेन को फिर से करने की आवश्यकता है। यह पुनर्प्राप्ति को सरल बनाता है लेकिन संगामिति को सीमित करता है और सभी अप्रतिबद्ध परिवर्तनों को रखने के लिए पर्याप्त बफर स्थान की आवश्यकता होती है। <पी>