Recoverability, strict schedules और log-based recovery
लक्ष्य तथा model
Read-from relation और commit/abort order से schedules classify करें, cascading rollback समझें और atomicity/durability को write-ahead logging से जोड़ें। r_i(X),w_i(X),c_i,a_i notation है। Single-version examples में read को latest preceding write मिलती है। Initial committed value पढ़ने पर दूसरे active transaction की dependency नहीं बनती। Recovery examples में before/after-image logging assumptions स्पष्ट हैं; सभी database engines के समान algorithm का दावा नहीं।
1. Recoverable schedule
Tj यदि Ti का लिखा value पढ़े तो recoverable schedule में Tj के commit से पहले Ti का commit जरूरी है। Tj, Ti के commit से पहले पढ़ सकता है और आगे execute भी कर सकता है, लेकिन पहले commit नहीं कर सकता। Ti abort करे तो Tj उस dirty value पर निर्भर रहकर commit नहीं कर सकता; rollback आगे फैल सकता है। Recoverability committed work को aborted work पर निर्भर होने से बचाती है।
w1(X),r2(X),c1,c2 recoverable है क्योंकि T2 ने T1 से पढ़ा और c1 पहले है। लेकिन r2, c1 से पहले है, इसलिए dirty read है। Recoverable का अर्थ cascadeless नहीं। w1(X),r2(X),c2,a1 में T2 उस value के आधार पर commit हो गया जिसका writer बाद में abort हुआ; यह unrecoverable है। Conflict-equivalent serial order T1 फिर T2 होने से commit-order problem हल नहीं होती।
हर read का असली source पहचानें। w1(X),c1,w3(X),c3,r2(X),c2 में T2 का source T3 है, हर पुराना writer नहीं। T3 की अपनी transitive dependencies भी महत्वपूर्ण हो सकती हैं। केवल same item का नाम होने से read-from relation न बनाएँ।
2. Cascadeless और strict schedules
Cascadeless schedule में Ti के लिखे value को Ti के commit के बाद ही पढ़ सकते हैं। Dirty reads रोकने से source transaction के abort के कारण readers को abort करने की जरूरत नहीं पड़ती। w1(X),r2(X),c1,c2 recoverable लेकिन cascadeless नहीं। इसे w1(X),c1,r2(X),c2 करें तो cascadeless है।
Strict schedule में Ti द्वारा X लिखने के बाद, Ti के commit या abort तक कोई दूसरा transaction X को न पढ़ सकता है, न लिख सकता है। इससे dirty reads तथा dirty writes दोनों रुकते हैं। Strict ⇒ cascadeless ⇒ recoverable। Reverse implications सही नहीं। ये schedule properties हैं; strict two-phase locking ऐसा schedule enforce करने वाला protocol है, strictness की definition नहीं।
Cascadeless से strict जरूरी नहीं: w1(X),w2(X),c1,c2 में reads नहीं हैं, इसलिए cascadeless vacuously है। लेकिन T2 ने T1 के समाप्त होने से पहले X overwrite किया, इसलिए strict नहीं। इसका conflict graph acyclic है, फिर भी uncommitted data overwrite करने से rollback मुश्किल होता है। Schedule classification और किसी specific recovery algorithm द्वारा उसे safely execute कर पाना अलग प्रश्न हैं।
Strictness अकेले conflict serializability नहीं देती। r1(A),r2(B),w1(B),w2(A),c1,c2 में हर write के बाद उस item को दूसरा transaction writer के समाप्त होने से पहले access नहीं करता। इसलिए schedule strict है। फिर भी A पर T1→T2 और B पर T2→T1 cycle है। Strict 2PL, two-phase rule जोड़कर conflict serializability भी देता है।
3. Cascading abort trace
w1(X),r2(X),w2(Y),r3(Y),a1 लें। T2 ने T1 का uncommitted value पढ़ा; T3 ने T2 का uncommitted output पढ़ा। T1 abort हो तो T2 और T3 दोनों rollback करेंगे, भले T3 ने X सीधे न पढ़ा हो। Chain T1→T2→T3 है। Suitable multiversion protocol में पुरानी committed version पढ़ने पर यह dirty-read chain नहीं बनती; classification बदलने से पहले version rules बताएँ।
4. Buffer policies से UNDO/REDO समझें
Memory की modified data pages, transaction commit से अलग समय पर disk जा सकती हैं। STEAL में uncommitted update वाली page disk पर जा सकती है, इसलिए failure के बाद UNDO चाहिए हो सकता है। NO-STEAL यह रोकता है और इस model में उस UNDO आवश्यकता को हटाता है। FORCE में transaction की सभी modified data pages commit तक durable होती हैं। NO-FORCE में committed updates memory में रह सकती हैं, इसलिए failure के बाद REDO चाहिए हो सकता है।
Abstract combinations: STEAL/NO-FORCE में UNDO तथा REDO दोनों; STEAL/FORCE में UNDO; NO-STEAL/NO-FORCE में REDO; NO-STEAL/FORCE में इस crash model के data-page UNDO/REDO दोनों की आवश्यकता नहीं। इसका अर्थ सभी metadata, logs या failure handling की जरूरत खत्म होना नहीं। कई practical systems performance के लिए STEAL/NO-FORCE और अधिक sophisticated recovery लेते हैं।
5. Write-ahead logging और crash उदाहरण
Update record <Ti,X,old,new> में संबंधित log information को modified data page disk लिखने से पहले durable करना आवश्यक है। यही write-ahead rule है। Log-based NO-FORCE recovery में commit report करने से पहले required transaction log records और commit record durable करें। Commit पर सभी data pages force करना जरूरी नहीं। Log durability और data-page durability अलग हैं।
उदाहरण: initial disk X=10,Y=20। Durable log में <T1,X,10,15>, <commit T1>, <T2,Y,20,25> हैं; T2 का commit नहीं। मानें T1 की X page flush नहीं हुई लेकिन T2 की Y page flush हो गई; फिर crash हुआ। इस before/after-image model में committed T1 का REDO करके X=15 और uncommitted T2 का UNDO करके Y=20 करें। Final intended state X=15,Y=20 है। केवल UNDO करने से T1 का committed update खोता; केवल REDO से T2 का uncommitted update बचता।
Aborted transaction की अनेक updates को reverse order में undo करें। T2 पहले X को 10 से 12, फिर 12 से 19 करे तो दूसरी update reverse करने पर 12 और पहली reverse करने पर 10 मिलेगा। Forward order में before-images restore करने से 12 बच सकता है। Real recovery में compensation records, page sequence numbers तथा repeat-history हो सकते हैं। इस simple trace को full ARIES specification न समझें।
6. Checkpoints और सावधानियाँ
Checkpoint recovery-relevant progress save करता है ताकि restart पर पूरा historical log बिना सीमा न खोजना पड़े। Simple quiescent checkpoint transactions और flushes coordinate कर सकता है; fuzzy checkpoint concurrent work allow करता और अधिक metadata चाहता है। Checkpoint का अर्थ सभी transactions committed होना नहीं। कौन-सी pages/log prefix flush होंगी, यह protocol पर निर्भर है।
Exam schedule में पहले हर read का source पहचानें; फिर recoverability के लिए commit order, cascadelessness के लिए source commit के सापेक्ष read time, और strictness के लिए uncommitted writes के बाद reads तथा writes दोनों जाँचें। Recovery में committed/incomplete transactions, buffer policy और durable log boundary स्पष्ट करें, फिर undo/redo तय करें। खोए हुए volatile log की operation को crash के बाद उपलब्ध न मानें।
मौलिक अभ्यास: छह single-correct MCQ
ये मौलिक शिक्षण प्रश्न हैं, पिछले वर्षों के प्रश्न नहीं। ठीक एक उत्तर चुनें।
P01. w1(X),r2(X),c1,c2 कैसा है?
A. Unrecoverable B. Recoverable लेकिन cascadeless नहीं C. Strict D. Cascadeless लेकिन recoverable नहीं
उत्तर: B
A: Source का commit reader के commit से पहले है।
B: Commit order सुरक्षित है, लेकिन r2 dirty read है।
C: T2 ने T1 खत्म होने से पहले पढ़ा।
D: Cascadeless से recoverable मिलता है; यहाँ dirty read है।
P02. कौन-सी implication हमेशा सही है?
A. Recoverable ⇒ strict B. Cascadeless ⇒ strict C. Strict ⇒ cascadeless D. Conflict serializable ⇒ recoverable
उत्तर: C
A: Recoverable schedules में dirty reads हो सकती हैं।
B: Cascadeless schedules में dirty writes हो सकती हैं।
C: Strictness uncommitted writes पढ़ने से रोकती है।
D: Commit order फिर भी unsafe हो सकता है।
P03. w1(X),w2(X),c1,c2 में reads नहीं। सही classification?
A. Strict B. Cascadeless लेकिन strict नहीं C. Recoverable नहीं D. Cascadeless नहीं
उत्तर: B
A: दूसरी write ने uncommitted data overwrite किया।
B: Dirty reads नहीं, लेकिन dirty write है।
C: Read-from commit dependency violation नहीं है।
D: Reads न होने से cascadelessness vacuously सत्य है।
P04. बताए buffer-policy model में STEAL तथा NO-FORCE के लिए क्या support चाहिए?
A. केवल UNDO B. केवल REDO C. UNDO तथा REDO दोनों D. दोनों नहीं
उत्तर: C
A: NO-FORCE में committed pages missing हो सकती हैं।
B: STEAL में disk पर uncommitted pages हो सकती हैं।
C: STEAL से UNDO और NO-FORCE से REDO चाहिए।
D: दोनों प्रकार के crash effects संभव हैं।
P05. Write-ahead logging में update log record कब से पहले durable चाहिए?
A. Changed data page flush होने से पहले B. Transaction कोई item पढ़ने से पहले C. हर SELECT शुरू होने से पहले D. DBMS कोई memory allocate करने से पहले
उत्तर: A
A: Persisted update की recovery के लिए log चाहिए।
B: Ordinary reads unrelated update logs का इंतजार नहीं करतीं।
C: SELECT start write-ahead ordering rule नहीं।
D: Memory allocation इस rule से संबंधित नहीं।
P06. T2 ने X:10→12, फिर X:12→19 लिखा और abort हुआ। सही before-image undo क्रम?
A. पहले 10, फिर 12 restore B. पहले 12, फिर 10 restore C. Writes हो गईं इसलिए 19 रखें D. केवल 12 restore
उत्तर: B
A: Forward undo intermediate value छोड़ सकता है।
B: Reverse update order original 10 लौटाता है।
C: इस model में aborted effects नहीं बचने चाहिए।
D: दो updates के लिए एक reversal पर्याप्त नहीं।
स्रोत और दायरा
यह 2026 course के बताए भाग का पाठ है, पूरे Databases syllabus की समाप्ति नहीं। सभी गणनात्मक उदाहरण और प्रश्न मौलिक हैं। 2027 की पूर्णता का दावा नहीं।
प्रगति सहेजने के लिए साइन इन करें। साइन इन