क्या कोई COMMIT कथन (SQL में) कभी विफल हो सकता है? कैसे?

Question

डेटाबेस लेनदेन के साथ काम करते समय, संभावित स्थितियों (यदि कोई है) क्या हैं जो लेनदेन में अंतिम COMMIT स्टेटमेंट विफल होने का कारण बनते हैं, मानते हैं कि लेनदेन के भीतर सभी बयान पहले ही बिना किसी मुद्दे के निष्पादित किए गए हैं?

---

उदाहरण के लिए ... मान लीजिए कि आप कुछ two-phase या three-phase commit protocol जहां बयान के एक झुंड करते हैं, तो जब यह ठीक है अंत में लेन-देन के लिए प्रतिबद्ध करने के लिए कुछ गुरु प्रक्रिया में बताने के लिए के लिए प्रतीक्षा डालते हैं:

-- <initial handshaking stuff> 
START TRANSACTION; 
-- <Execute a bunch of SQL statements> 
-- <Inform master of readiness to commit> 
-- <Time passes... background transactions happening while we wait> 
-- <Receive approval to commit from master (finally!)> 
COMMIT; 

यदि आपका कोड उस अंतिम COMMIT कथन पर जाता है और इसे आपके डीबीएमएस पर भेजता है, तो क्या आपको उस वक्तव्य में कभी भी एक त्रुटि (विशिष्टता समस्या, डेटाबेस पूर्ण, आदि) मिल सकती है? क्या त्रुटियां? क्यूं कर? वे कैसे दिखाई देते हैं? क्या यह आपके द्वारा चलाए जाने वाले डीबीएमएस के आधार पर भिन्न होता है?

Answer 1

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

Answer 2

निश्चित रूप से।

एक बहु-उपयोगकर्ता वातावरण में, COMMIT अन्य उपयोगकर्ताओं द्वारा किए गए परिवर्तनों के कारण विफल हो सकता है (उदा। वर्तमान COMMIT अब वर्तमान डेटाबेस पर लागू होने पर एक रेफरेंसियल बाधा का उल्लंघन करेगा ...)।

थॉमस

Answer 3

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

इग्नासिओ राज्यों के रूप में, स्थगित बाधा जांच हो सकती है (यह डीबीएमएस इंजन के आधार पर केवल बाधा का कोई भी रूप नहीं हो सकता है)।

SQL सर्वर विशिष्ट: FILESTREAM डेटा को फ़्लश करने से प्रतिबद्ध समय तक स्थगित किया जा सकता है। वह असफल हो सकता है।

Answer 4

एक बहुत ही सरल और अक्सर अनदेखा आइटम: हार्डवेयर विफलता। यदि अंतर्निहित सर्वर मर जाता है तो प्रतिबद्धता विफल हो सकती है। यह डिस्क, सीपीयू, मेमोरी, या यहां तक ​​कि नेटवर्क से संबंधित हो सकता है।

लेनदेन विफल हो सकता है अगर इसे मास्टर से अनुमोदन प्राप्त नहीं होता है (किसी भी कारण से)।

Answer 5

COMMIT विफल हो सकता है। आपके द्वारा किए गए सभी परिवर्तनों को लॉग इन करने के लिए आपके पास पर्याप्त संसाधन हो सकते हैं, लेकिन वास्तव में परिवर्तनों को लागू करने के लिए संसाधनों की कमी है।

और वह अन्य कारणों से यह असफल हो सकता है पर विचार नहीं कर रहा है:

1. परिवर्तन ही डेटाबेस की कमी फिट नहीं हो सकता है।

2. पावर लॉस चीजों को पूरा करने से रोकता है।

3. अनुरोधित चयन समेकन का स्तर एक अद्यतन को अस्वीकार कर सकता है (उदाहरण के लिए संशोधित तालिका को अपडेट करने वाले कर्सर)।

4. प्रतिबद्धता समय-समय पर हो सकती है या भुखमरी के मुद्दों के कारण कनेक्शन हो सकती है।

5. क्लाइंट और डेटाबेस के बीच नेटवर्क कनेक्शन खो सकता है।

और अन्य सभी "सरल" कारण जो मेरे सिर के शीर्ष पर नहीं हैं।

Answer 6

कोई फर्क नहीं पड़ता कि एक प्रणाली को कितनी आश्चर्यजनक तरीके से डिजाइन किया जा सकता है, कुछ संभावना होने जा रही है कि एक प्रतिबद्धता ऐसी स्थिति में आ जाएगी जहां यह जानना असंभव है कि यह सफल हुआ या नहीं। कुछ मामलों में इससे कोई फर्क नहीं पड़ता (उदाहरण के लिए यदि डेटाबेस को पकड़ने वाली हार्ड ड्राइव स्लैग के ढेर में बदल जाती है, तो यह बता देना असंभव हो सकता है कि प्रतिबद्धता सफल हुई है या नहीं, लेकिन इससे कोई फर्क नहीं पड़ता); हालांकि, दूसरों के मामलों में, यह एक समस्या हो सकती है। विशेष रूप से वितरित डेटाबेस सिस्टम के साथ, यदि किसी प्रतिबद्धता के दौरान सही समय पर कनेक्शन विफलता होती है, तो दोनों पक्षों के लिए यह सुनिश्चित करना संभव होगा कि दूसरी तरफ प्रतिबद्धता या रोलबैक की अपेक्षा है या नहीं।

Answer 7

यदि आप दो चरण प्रतिबद्धता का उपयोग कर रहे हैं, तो नहीं। सब कुछ जो गलत हो सकता है तैयार चरण में किया जाता है।

प्रतिबद्धता के दौरान अभी भी नेटवर्क आउटेज, पावर कम, ब्रह्मांडीय किरण आदि हो सकता है, लेकिन फिर भी, लेनदेन स्थायी भंडारण के लिए लिखा गया होगा, और यदि कोई प्रतिबद्धता ट्रिगर की गई है, तो पुनर्प्राप्ति प्रक्रियाओं को उन्हें ले जाना चाहिए के माध्यम से।

उम्मीद है कि।