बैकवर्ड ऑर्डर में अनकम्पोजिट ट्रांजैक्शन पूर्ववत क्यों होना चाहिए?

Question

मेरे पास एक डेटाबेस लॉग है जहां कुछ लेनदेन जीतते हैं (वे दुर्घटना से पहले प्रतिबद्ध होते हैं) और कुछ हार जाते हैं (अभी तक प्रतिबद्ध नहीं हैं)। हमने कक्षा में सीखा कि हारने वालों के कार्यों को पीछे की ओर पूर्ववत करना है।

क्या इसके पीछे की ओर करने का कोई कारण है? क्या कोई लॉग का सरल उदाहरण दे सकता है जहां आगे चलकर पूर्ववत गलत परिणाम मिलेंगे?

Comments

क्या यह प्रश्न किसी अन्य विशिष्ट वेबसाइट में नहीं पूछा जाना चाहिए?

— नबंवर

Answer 1

मूल लेनदेन:

1. रिकॉर्ड डालें ।$r$
2. अद्यतन कुछ क्षेत्र के आर ।$f$$r$

पूर्ववत करें:

1. रिकॉर्ड हटाएँ ।$r$
2. - ओह प्रतीक्षा करने के लिए अद्यतन को उल्टा करें, r अब मौजूद नहीं है! यह एक त्रुटि का कारण बनता है।$r$$r$

Comments

क्या चीजों को भौतिक रूप से व्यक्तिगत रूप से पूर्ववत क्रम में पूर्ववत करने की आवश्यकता है यदि सिस्टम यह पता लगा सकता है कि किसी और चीज को संसाधित करने से पहले सभी आवश्यक परिवर्तनों को लागू करने के लिए राज्य की किन चीजों को वापस करने की आवश्यकता है?

— सुपरकैट

रिवर्स ऑर्डर में परिवर्तन पूर्ववत करना आसान बनाता है। आप इसे अपने आप पर कठिन बनाने की कोशिश क्यों करेंगे?

— gnasher729

नहीं, सिस्टम सब कुछ नहीं करेगा लेकिन फिर भी यह पता लगाएगा कि पिछड़े क्रम में क्या है।

— ईविल

कई वास्तविक विश्व डेटाबेस प्रणालियों में इसे उल्टे क्रम में नहीं करना टेबल पर महत्वपूर्ण बाधाओं के कारण भी संभव नहीं होगा।

— सीनआर

Answer 2

DylanSp के उत्तर को जोड़ने के लिए, गैर-मौजूदा रिकॉर्ड में फ़ील्ड को अपडेट करने का प्रयास विफल हो जाएगा, लेकिन परिणाम अभी भी अपेक्षित परिणाम होगा: रिकॉर्ड r मौजूद नहीं है।

हालांकि, ऐसी स्थिति पर विचार करें जहां रिकॉर्ड को हटाना वास्तव में विफल हो जाएगा:

1. आदेश ओ डालें।
2. आदेश एल डालें।

आइए, मान लें कि अनुचित रूप से नहीं, कि प्रत्येक ऑर्डरलाइन एक आदेश से संबंधित होनी चाहिए।

अब ऑर्डर को हटाने के साथ शुरू होने वाला लेन-देन वापस करना विफल हो जाएगा क्योंकि यह हमारे व्यापार नियम का उल्लंघन करेगा।

इतना होने के बाद

1. डिलीट ऑर्डर ओ। (विफल)
2. आयुध एल। (सफलता) हटाएँ

हम मौजूदा ऑर्डर (ऑर्डरलाइन के बिना) के साथ समाप्त हो सकते हैं।

बेशक, इस मामले में हम एक कैस्केडिंग डिलीट का उपयोग कर सकते हैं, लेकिन इसका मतलब है कि चरण 2 असफल होगा (प्रभाव के बिना)। इससे भी बदतर, यह आदेशों पर कैस्केडिंग हटाने को लागू करने के लिए अवांछित व्यवहार हो सकता है।

Comments

ठीक है, यह समझ में आता है। आपकी मदद के लिए Thx

— prjctdth

क्या यह मान लेना उचित है कि "सामान्य" परिस्थितियों में लेनदेन से पहले या बाद में बाधाओं का उल्लंघन नहीं किया गया था? सामान्य रूप से, मेरा मतलब है कि यदि केवल एक व्यक्ति डेटाबेस का उपयोग कर रहा था तो लेनदेन विफल नहीं होगा। यदि यह सच है, तो पूर्ववत प्रक्रिया के दौरान अड़चनों का उल्लंघन न करना क्यों महत्वपूर्ण होगा? ऐसा लगता है कि बाधाओं को पूर्ववत् की शुरुआत में बंद किया जा सकता है और ऑपरेशन पूरा होने के बाद सक्षम किया जाता है।

— नॉक्टिस स्काईटॉवर

@NoctisSkytower एक सामान्य I / O ऑपरेशन के दौरान बाधाओं को बंद करना उन्हें बेकार कर देता है। वे एक कारण के लिए मौजूद हैं। मेरा उदाहरण स्पष्ट रूप से दिखाता है कि कैसे बाधाओं को सामान्य परिस्थितियों में पूरा किया जा सकता है, फिर भी रोलबैक के दौरान उल्लंघन किया जा सकता है। रोल बैक के दौरान बाधाओं को बंद करना अनावश्यक रूप से जटिल है, और गलत समस्या को ठीक करता है। समस्या बाधा नहीं है, समस्या गलत तरीके से वापस रोल करने की कोशिश से इसका उल्लंघन है।

— ऑर्केलेंस

हाँ, यह समझ में आता है, लेकिन क्यों रोलबैक के दौरान बाधाओं की जाँच करें? मान लिया जाए कि रोलबैक एक समस्या के बिना पूरा होने की गारंटी के लिए तैयार किए गए हैं, तो अनावश्यक रूप से समय की कमी की जाँच करें यदि यह ज्ञात हो कि रोलबैक के पूरा होने तक उनका उल्लंघन नहीं किया जाएगा? BTW, यह एक गारंटी होनी चाहिए क्योंकि अगर एक रोलबैक विफल रहा, तो DB को रोल-फॉरवर्ड करने की आवश्यकता होगी जो यह नहीं कर सकता है।

— नॉक्टिस स्काईटॉवर

@NoctisSkytower DB के लिए कभी भी ऐसी स्थिति में होना असंभव होना चाहिए जहां बाधाओं का उल्लंघन किया जाता है, भले ही यह एक अस्थायी राज्य हो। यदि पूरा रोलबैक परमाणु है, तो इससे कोई फर्क नहीं पड़ता कि यह किस क्रम में होता है क्योंकि कोई आदेश नहीं है, यह एक एकल निर्देश है जो "सभी में एक बार होता है"। यदि दो या अधिक लेनदेन ऐसे हैं जो किसी क्रम में अलग से वापस किए गए हैं, तो यह अनिवार्य है कि यह आदेश ऐसा हो कि बीच में डेटा पढ़ने वाला कोई भी पर्यवेक्षक केवल एक ऐसी स्थिति देख सके जहां सभी बाधाएं हों।

— पीटरिस

Answer 3

सादृश्य द्वारा चलते हैं: कहते हैं कि आप रात के खाने के लिए बाहर जा रहे हैं।

1. मोज़े रखो।
2. जूते रखो।
3. खड़े हो जाओ।
4. दरवाजे तक चलो।

फिर आपको एक फोन कॉल आता है। रात्रिभोज की योजना रद्द

1. मोजे उतारो।
2. जूते उतार दो।
3. बैठ जाओ।
4. दरवाजे से दूर चलो।

वहां कुछ गलत हो जाता है। आप यात्रा कर सकते हैं और खुद को चोट पहुँचा सकते हैं। या अधिक संभावना है, आपको पता चल जाएगा कि कुछ क्रियाएं पूर्ववत नहीं की जा सकती हैं जब तक कि बाद में क्रियाएं पहले से पूर्ववत नहीं होती हैं।

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

गणितीय रूप से बोलना: क्रियाएं कम्यूट नहीं हो सकती हैं, इसलिए जब भी यह मायने रखता है कि आप कौन सा कदम पहले या दूसरे पर करते हैं, तो जिस क्रम में आप कदम उठाएंगे वह मायने रखेगा।

Answer 4

यह सही है क्योंकि लेन-देन एक-दूसरे के ऊपर बनाया गया है और लेनदेन का परिणाम उस स्थिति पर बहुत निर्भर है, जब वह प्रतिबद्ध था।

आइए देखें वित्तीय लेनदेन:

(शुरुआत में, लेनदेन से पहले aमुझे 100 USD चुकाने होंगे)

1. a मुझ पर 100 USD (अब कुल ऋण 200) बकाया है
2. aवह मुझे जो बकाया है उस पर 10% की छूट प्राप्त करता है। (अब कुल कर्ज 180)

मान लीजिए कि मैं दो लेनदेन को रद्द करना चाहता हूं।

यदि हम पहले पहले को रद्द कर देते हैं, तो हम समाप्त कर देंगे:

1. कम ऋण 100 (अब ऋण 80 है)
2. 10% छूट रद्द करें (अब ऋण 80 / 0.9 = 88 है)

यह गलत है, हमें 100 के ऋण को वापस पाने की आवश्यकता है। यह सही होगा यदि हम रिवर्स ऑर्डर में लेनदेन को रद्द करते हैं।

1. छूट को रद्द करें - अब ऋण 200 है
2. कम 100 ऋण - अब ऋण 100 है

Answer 5

मान लें कि केवल एक स्तंभ के साथ एक तालिका T है।

मान लें कि "पूर्ववत करें" एक डेटाबेस फ़ाइल है जिसमें अनअकाउंटेड लेन-देन है, और यह कि "रीडो लॉग" एक डेटाबेस फ़ाइल है जिसमें अनकम्यूटेड और कमिटेड लेनदेन दोनों हैं जो अभी तक डेटाफ़ाइल्स पर लागू नहीं हुए हैं।

At 8:00 A.M., Transaction 100 inserts rows with values 101, 102 and 103 into table T. At 8:10 A.M., Transaction 100 is committed and the commit for transaction 100 completes. At 8:15 A.M., Transaction 200 updates row 101 to 201, 102 to 202 and 103 to 203. At 8:20 A.M., Transaction 200 has not been committed and remains in the undo log of the database. At 8:25 A.M., Transaction 300 increments each row by 50, changing row 201 to 251, 202 to 252, and 203 to 253. At 8:30 A.M., Transaction 300 has not been committed and remains in the undo log of the database. At 8:35 A.M., The instance providing access to the database crashes.

At 8:40 A.M., The instance is restarted, and the database files are opened as the instance is started:

              The committed values in T are still 101, 102 and 103.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, if they are written into the "redo
              log" of the database, there is a need to "roll back"
              the transactions AFTER the "redo log" is applied.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, they are in the "undo log"
              of the database.

              The undo log of the database is used BOTH to (1) roll
              back a transaction that is deliberately rolled 
              back in the memory structure of the database instance, 
              and also (2) during the instance recovery at 8:40 A.M.

At 8:41 A.M., The redo log has been applied, and the T table contains values 251, 252 and 253 in the instance memory.

              The undo log has not yet been applied.

At 8:42 A.M., The undo log is applied in the reverse order: Uncommitted transaction 300 is undone, and Uncommitted transaction 200 is undone.

क्यों बीओटीएच प्रतिबद्ध और अप्रकाशित लेनदेन को रीडो लॉग फ़ाइल में लिखे गए हैं? इसका कारण पॉइंट-इन-टाइम रिकवरी प्रदान करना है।

इसका मतलब यह है कि "रीडो लॉग" फ़ाइल की सामग्री लेनदेन-संगत नहीं है। इस कारण से, जब भी डेटा फ़ाइलों के लिए प्रतिबद्ध लेन-देन को लागू करने के लिए रीडो लॉग का उपयोग किया जाता है, तो "अनडू लॉग" केवल अलोकृत लेनदेन को वापस करने के लिए उपयोग किया जाना चाहिए।

"पूर्ववत करें" में लेन-देन को उल्टे क्रम में वापस क्यों लाया जाता है? लेनदेन 300 ने प्रत्येक पंक्ति के प्रत्येक कॉलम के मौजूदा मूल्य में 50 को जोड़ा है। इसलिए, यदि लेन-देन 200 पहले वापस कर दिया जाता है, तो मान 251, 252 और 253 से 201, 202 और 203 में बदल जाएंगे। यदि लेन-देन 300 को अंतिम बार वापस ले लिया गया, तो मान 151, 152 और 153 हो जाएंगे - जो मेल नहीं खाते मूल प्रतिबद्ध मूल्य।

संदर्भ:

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273

Answer 6

यह स्वाभाविक नहीं है। रोलबैक बस उन ब्लॉकों को फिर से लागू कर सकता है जिन्हें पूर्ववत लॉग में कैश किया गया था ताकि अंतिम स्थिति प्रारंभिक राज्य के समान हो। क्योंकि लॉग फॉरवर्ड ऑर्डर में लिखा गया था, मैंने अपना रोलबैक भी फॉरवर्ड ऑर्डर में लागू किया था। जब तक लॉग फ़ाइल को बंद के रूप में चिह्नित नहीं किया जाता तब तक रोलबैक वापस आ जाएगा क्योंकि यह आदेश कोई मायने नहीं रखता था।