मैं सोच रहा हूं कि क्या होगा अगर आप एक डीबी में लेनदेन शुरू करते हैं और इसे कमिट करना या रोलबैक करना भूल जाते हैं। क्या सर्वर डाउन होगा? कहते हैं कि आपने इसे 3 दिनों के लिए छोड़ दिया है।
ऐसे उपयोगकर्ता भी हैं जो यह मानकर उपयोग कर रहे हैं कि अन्य उपयोगकर्ताओं को यह नहीं पता था कि एक बिना लेनदेन के है (चलो मान लेते हैं कि उपयोगकर्ता डेटाबेस पर केवल डेटा डाल रहे हैं)। इस कार्रवाई के परिणाम क्या हैं?
जवाबों:
अपने आप से एक खुला लेनदेन होने का कोई परिणाम नहीं होगा। एक सरल
BEGIN TRANSACTION
-- wait for a while, doing nothing
-- wait a bit longer
COMMIT
सबसे खराब स्थिति में, मानों की कुछ बाइट पकड़ेंगी। कोई बड़ी बात नहीं।
अधिकांश कार्यक्रम लेन-देन के भीतर वास्तविक काम करेंगे और यह एक और मामला है। लेन-देन की बात यह है कि आप यह सुनिश्चित कर सकते हैं कि डेटाबेस के भीतर कई तथ्य एक साथ सच हैं, इसके बावजूद कि अन्य उपयोगकर्ता समान डेटाबेस में समान रूप से लिख रहे हैं।
बैंक खातों के बीच धन हस्तांतरित करने का तोपखाना उदाहरण लें। सिस्टम को यह सुनिश्चित करना होगा कि स्रोत खाता मौजूद है, उसके पास पर्याप्त धन है, गंतव्य खाता मौजूद है, और यह कि डेबिट और क्रेडिट दोनों ही होते हैं या न ही होते हैं। अन्य लेनदेन होने पर इसकी गारंटी देनी चाहिए, शायद इन दोनों खातों के बीच भी। सिस्टम संबंधित तालिकाओं पर ताले लगाकर इसे सुनिश्चित करता है । ताले को क्या लिया जाता है, और आप कितने अन्य लोगों के काम को देखते हैं, यह लेनदेन के अलगाव स्तर द्वारा नियंत्रित किया जाता है ।
इसलिए यदि आप बहुत काम करते हैं तो एक अच्छा मौका है कि अन्य लेनदेन उन वस्तुओं के इंतजार में कतारबद्ध हो जाएंगे जिन पर आप ताले रखते हैं। यह सिस्टम के समग्र प्रवाह को कम करेगा। आखिरकार वे टाइमआउट सीमा से टकराएंगे और असफल होंगे, जो समग्र प्रणाली व्यवहार के लिए एक समस्या है। यदि आप एक आशावादी अलगाव के स्तर का उपयोग करते हैं तो जब आप दूसरे के काम के कारण प्रतिबद्ध होते हैं तो आपका लेनदेन विफल हो सकता है।
तालों को धारण करने से सिस्टम संसाधन लग जाते हैं। यह स्मृति है जो सिस्टम अन्य अनुरोधों को संसाधित करने के लिए उपयोग नहीं कर सकता है, थ्रूपुट को कम कर सकता है।
यदि बहुत काम किया गया है तो सिस्टम लॉक एस्केलेशन का चयन कर सकता है । व्यक्तिगत पंक्तियों को लॉक करने के बजाय पूरी तालिका को लॉक कर दिया जाएगा। तब अधिक समवर्ती उपयोगकर्ता प्रभावित होंगे, सिस्टम थ्रूपुट आगे गिर जाएगा और आवेदन प्रभाव अधिक होगा।
डेटा परिवर्तन लॉग फ़ाइल में लिखे जाते हैं, जैसे कि वे ताले हैं जो उनकी रक्षा करते हैं। लेन-देन शुरू होने तक इन्हें लॉग से साफ़ नहीं किया जा सकता है। इसलिए बहुत लंबे लेन-देन से लॉग फ़ाइल ब्लोट से संबंधित समस्याओं के कारण हो सकती है।
यदि वर्तमान कार्य टेम्पर्डब का उपयोग करता है, जो बड़े कार्यभार की संभावना है, तो लेनदेन के अंत तक वहां संसाधनों को बांधा जा सकता है। चरम मामलों में यह अन्य कार्यों को विफल करने का कारण बन सकता है क्योंकि उनके लिए अब पर्याप्त जगह नहीं है। मेरे पास ऐसे मामले हैं जहां एक खराब कोडित UPDATE ने टेम्पर्डब को भरा था इसलिए एक रिपोर्ट के SORT के लिए अपर्याप्त डिस्क छोड़ दी गई थी और रिपोर्ट विफल हो गई थी।
यदि आप लेन-देन को चुनते हैं, या सिस्टम विफल हो जाता है और ठीक हो जाता है, तो सिस्टम के दोबारा उपलब्ध होने में लगने वाला समय इस बात पर निर्भर करेगा कि कितना काम किया गया था। बस एक लेन-देन खुला होने से वसूली समय प्रभावित नहीं होगा, यह है कि कितना काम किया गया था। यदि लेन-देन खुला था, लेकिन एक घंटे की वसूली के लिए निष्क्रिय लगभग तात्कालिक होगा। यदि यह उस घंटे के लिए लगातार लिख रहा था कि अंगूठे का नियम है कि पुनर्प्राप्ति समय भी लगभग एक घंटा होगा।
जैसा कि आप देख सकते हैं कि लंबा लेनदेन समस्याग्रस्त हो सकता है। ओएलटीपी सिस्टम के लिए सबसे अच्छा अभ्यास प्रति व्यापार लेनदेन में एक डेटाबेस लेनदेन करना है। ब्लॉकों में बैच कार्य प्रक्रिया इनपुट के लिए, अक्सर कमिट के साथ, और लॉजिक कोडित को पुनरारंभ करें। आमतौर पर कई हजार रिकॉर्ड एक ही डीबी लेनदेन के अंदर संसाधित किए जा सकते हैं, लेकिन इसे संगामिति के लिए परीक्षण किया जाना चाहिए और खपत को पुनर्जीवित करना चाहिए।
दूसरे चरम पर जाने और लेन-देन और ताले से पूरी तरह से बचने का लालच न करें। यदि आपको अपने डेटा के भीतर निरंतरता बनाए रखने की आवश्यकता है (और आप किसी डेटाबेस का उपयोग क्यों कर रहे हैं?) अलगाव स्तर और लेनदेन एक बहुत ही महत्वपूर्ण उद्देश्य है। अपने विकल्पों के बारे में जानें और यह तय करें कि आपके आवेदन के प्रत्येक भाग के साथ रहने के लिए आप क्या संगामिति और शुद्धता का संतुलन बनाते हैं।
आपका सबसे बड़ा परिणाम लेन-देन में उपयोग की जाने वाली वस्तुओं को अवरुद्ध करना होगा। विशेष रूप से यदि आप मानते हैं कि आपके उपयोगकर्ता डेटा डाल रहे हैं, तो लंबे समय तक चलने वाले लेनदेन में आमतौर पर उपयोग किए जाने वाले तालिकाओं पर SELECT स्टेटमेंट शामिल हो सकते हैं। आपके उपयोगकर्ता के अपडेट स्टेटमेंट उनके अपडेट या आवेषण को पूरा करने के लिए आवश्यक लॉक प्राप्त करने में सक्षम नहीं हो सकते हैं।
एक द्वितीयक चीज़ जो हो सकती है वह है लॉग फ़ाइल गतिविधि, यह कहना कि यदि आप एक बड़े डेटासेट को अपडेट कर रहे थे, तो लॉग का वह भाग जो लेन-देन का उपयोग कर रहा है, उस लेनदेन की अवधि के लिए सक्रिय रखा जाता है। लेन-देन किए जाने या वापस रोल किए जाने तक आप लॉग के उस हिस्से का पुन: उपयोग नहीं कर पाएंगे। उन परिदृश्यों में जहां आप एक भारी सक्रिय ओएलटीपी प्रणाली में हो सकते हैं, इससे आपकी लॉग फ़ाइल जल्दी से विकसित हो सकती है, आपके संग्रहण उपकरण को भर सकती है।
अधूरा लेनदेन बड़ी संख्या में ताले लगा सकता है और अवरोध पैदा कर सकता है
जब कोई लेन-देन पूरा नहीं होता है क्योंकि क्वेरी बाहर हो जाती है या क्योंकि लेनदेन पूरा करने के लिए COMMIT या ROLLBACK स्टेटमेंट जारी किए बिना लेन-देन के बीच में बैच रद्द हो जाता है, तो लेन-देन खुला रह जाता है और उस लेन-देन के दौरान अधिग्रहीत सभी ताले जारी रहते हैं आयोजित होने वाला। एक ही कनेक्शन के तहत निष्पादित लेनदेन को नेस्टेड लेनदेन के रूप में माना जाता है, इसलिए इन पूर्ण किए गए लेनदेन में प्राप्त सभी ताले जारी नहीं किए जाते हैं। यह समस्या उसी कनेक्शन से निष्पादित सभी लेन-देन के साथ दोहराती है जब तक कि एक रोलबैक निष्पादित नहीं किया जाता है। नतीजतन, बड़ी संख्या में ताले लगे होते हैं, उपयोगकर्ता अवरुद्ध हो जाते हैं, और लेनदेन खो जाते हैं, जिसके परिणामस्वरूप डेटा वह होता है जो उससे अपेक्षा करता है।