व्यवहार अलगाव पातळी

2.1 अप्रतिबंधित वाचा

"ट्रान्झॅक्शन आयसोलेशन लेव्हल" म्हणजे डीबीएमएसच्या अंतर्गत यंत्रणेद्वारे प्रदान केलेल्या संरक्षणाची डिग्री (म्हणजे विशेष प्रोग्रामिंगची आवश्यकता नाही) वरील सर्व किंवा काही प्रकारच्या डेटा विसंगती जे व्यवहारांच्या समांतर अंमलबजावणी दरम्यान उद्भवतात. SQL-92 मानक चार अलगाव पातळीचे स्केल परिभाषित करते:

• बिनधास्त वाचा
• वचनबद्ध वाचा
• पुनरावृत्ती करण्यायोग्य वाचन
• अनुक्रमांक

त्यापैकी पहिला सर्वात कमकुवत आहे, शेवटचा सर्वात मजबूत आहे, त्यानंतरच्या प्रत्येकामध्ये मागील सर्व समाविष्ट आहेत.

सर्वात कमी (प्रथम) अलगाव पातळी. अनेक समांतर व्यवहारांनी समान सारणी पंक्ती सुधारण्याचा प्रयत्न केल्यास, अंतिम पंक्तीमध्ये यशस्वीरित्या पूर्ण झालेल्या व्यवहारांच्या संपूर्ण संचाद्वारे निर्धारित मूल्य असेल. या प्रकरणात, केवळ तार्किकदृष्ट्या विसंगत डेटाच वाचणे शक्य आहे, परंतु डेटा देखील वाचणे शक्य आहे ज्याचे बदल अद्याप रेकॉर्ड केले गेले नाहीत.

या आयसोलेशन लेव्हलची अंमलबजावणी करण्याचा एक सामान्य मार्ग म्हणजे अपडेट कमांडच्या कालावधीसाठी डेटा लॉक करणे, जे हे सुनिश्चित करते की समान पंक्तींवर समानांतर चालवल्या जाणार्‍या बदल आदेश अनुक्रमे चालवले जातात आणि कोणतेही बदल गमावले जात नाहीत. केवळ-वाचनीय व्यवहार या अलगाव स्तराखाली कधीही ब्लॉक होत नाहीत.

2.2 वचनबद्ध वाचा

बहुतेक औद्योगिक डीबीएमएस, विशेषतः मायक्रोसॉफ्ट एसक्यूएल सर्व्हर, पोस्टग्रेएसक्यूएल आणि ओरॅकल, डीफॉल्टनुसार ही पातळी वापरतात. या स्तरावर, मसुद्यापासून संरक्षण, "गलिच्छ" वाचन प्रदान केले जाते, तथापि, एका व्यवहाराच्या ऑपरेशन दरम्यान, दुसरा यशस्वीरित्या पूर्ण केला जाऊ शकतो आणि त्याद्वारे केलेले बदल निश्चित केले जातात. परिणामी, पहिला व्यवहार वेगळ्या डेटा सेटसह कार्य करेल.

पूर्ण वाचनाची अंमलबजावणी दोन पैकी एका पद्धतीवर आधारित असू शकते: अवरोधित करणे किंवा आवृत्ती करणे.

वाचनीय आणि बदलण्यायोग्य डेटा अवरोधित करणे.

यामध्ये लेखन व्यवहार रीड कमिटेड लेव्हलवर किंवा उच्च पातळीवर चालणाऱ्या व्यवहारांच्या वाचनासाठी बदलता येणारा डेटा ब्लॉक करतो जोपर्यंत ते पूर्ण होत नाही, त्यामुळे "घाणेरडे" वाचन रोखले जाते आणि वाचन व्यवहाराद्वारे लॉक केलेला डेटा ऑपरेशन पूर्ण झाल्यानंतर लगेच रिलीझ केला जातो. SELECT(अशा प्रकारे, "पुनरावृत्ती न करता येणारी वाचन" परिस्थिती दिलेल्या अलगाव पातळीवर येऊ शकते).

समांतर बदलणाऱ्या पंक्तींच्या अनेक आवृत्त्या जतन करत आहे.

प्रत्येक वेळी पंक्ती बदलल्यावर, DBMS या पंक्तीची एक नवीन आवृत्ती तयार करते, ज्याद्वारे डेटा बदलणारा व्यवहार कार्य करत राहतो, तर इतर कोणताही “रीडिंग” व्यवहार शेवटची वचनबद्ध आवृत्ती परत करतो. या दृष्टिकोनाचा फायदा असा आहे की ते जलद आहे कारण ते अवरोधित करणे प्रतिबंधित करते. तथापि, पहिल्याच्या तुलनेत, RAM चा लक्षणीय वापर आवश्यक आहे, जो पंक्तीच्या आवृत्त्या संग्रहित करण्यासाठी खर्च केला जातो.

याव्यतिरिक्त, जेव्हा एकाधिक व्यवहार डेटा समांतर बदलतात, तेव्हा ते अशी परिस्थिती निर्माण करू शकते जिथे अनेक समवर्ती व्यवहार एकाच डेटामध्ये विसंगत बदल करतात (कोणतेही लॉक नसल्यामुळे, काहीही होण्यापासून प्रतिबंधित करणार नाही). नंतर प्रथम केलेला व्यवहार मुख्य डेटाबेसमध्ये त्याचे बदल जतन करेल आणि उर्वरित समांतर व्यवहार करणे अशक्य होईल (कारण यामुळे पहिल्या व्यवहाराचे अपडेट गमावले जाईल). अशा परिस्थितीत डीबीएमएस फक्त एकच गोष्ट करू शकते की उरलेले व्यवहार मागे घेणे आणि "रेकॉर्ड आधीच बदलले गेले आहे" असा त्रुटी संदेश जारी करणे.

डीबीएमएस डेव्हलपरद्वारे एक विशिष्ट अंमलबजावणी पद्धत निवडली जाते आणि काही प्रकरणांमध्ये ती सानुकूलित केली जाऊ शकते. म्हणून, डीफॉल्टनुसार, एमएस एसक्यूएल लॉक वापरते, परंतु (आवृत्ती 2005 आणि उच्च मध्ये) READ_COMMITTED_SNAPSHOTडेटाबेस पॅरामीटर सेट करताना, ते व्हर्जनिंग स्ट्रॅटेजीवर स्विच करते, ओरॅकल सुरुवातीला केवळ आवृत्ती केलेल्या योजनेनुसार कार्य करते. USELASTCOMMITTEDInformix मध्ये, तुम्ही कॉन्फिगरेशन पर्याय (आवृत्ती 11.1 नुसार) सेट करून वाचन आणि लेखन व्यवहारांमधील विरोधाभास रोखू शकता ज्यामुळे वाचन व्यवहाराला नवीनतम वचनबद्ध डेटा प्राप्त होतो.

2.3 पुनरावृत्ती करण्यायोग्य वाचन

ज्या स्तरावर वाचन व्यवहार "दिसत नाही" तो पूर्वी वाचलेल्या डेटामध्ये बदलतो. त्याच वेळी, इतर कोणताही व्यवहार वर्तमान व्यवहाराद्वारे वाचलेला डेटा संपेपर्यंत बदलू शकत नाही.

शेअर्ड मोडमधील लॉक व्यवहारातील कोणत्याही सूचनांद्वारे वाचलेल्या सर्व डेटावर लागू केले जातात आणि व्यवहार पूर्ण होईपर्यंत ते धरून ठेवले जातात. हे प्रलंबित व्यवहाराद्वारे वाचलेल्या पंक्ती सुधारण्यापासून इतर व्यवहारांना प्रतिबंधित करते. तथापि, इतर व्यवहार वर्तमान व्यवहारात असलेल्या सूचनांसाठी शोध परिस्थितीशी जुळणार्‍या नवीन ओळी टाकू शकतात. जेव्हा वर्तमान व्यवहाराद्वारे विधान रीस्टार्ट केले जाते, तेव्हा नवीन पंक्ती प्राप्त केल्या जातील, परिणामी एक फँटम रीड होईल.

प्रत्येक विधानाच्या शेवटी रिलीझ होण्याऐवजी, व्यवहाराच्या समाप्तीपर्यंत सामायिक केलेले लॉक ठेवलेले असतात हे लक्षात घेता, समरूपतेची डिग्री अलगाव पातळीपेक्षा कमी असते READ COMMITTED. म्हणून, हे आणि उच्च व्यवहार पातळी अनावश्यकपणे वापरण्याची शिफारस केली जात नाही.

2.4 अनुक्रमे करण्यायोग्य

अलगावची सर्वोच्च पातळी; व्यवहार एकमेकांपासून पूर्णपणे विलग आहेत, प्रत्येकाला असे कार्यान्वित केले जाते की जणू काही समांतर व्यवहार नाहीत. केवळ या स्तरावर समवर्ती व्यवहार "फँटम रीड" प्रभावाच्या अधीन नाहीत.

2.5 वास्तविक DBMS मध्ये व्यवहार अलगावसाठी समर्थन

ट्रान्झॅक्शनल डीबीएमएस नेहमी सर्व चार स्तरांना समर्थन देत नाहीत आणि अतिरिक्त देखील सादर करू शकतात. इन्सुलेशन प्रदान करण्यात विविध बारकावे देखील आहेत.

तर, तत्त्वतः, ओरॅकल शून्य पातळीला समर्थन देत नाही, कारण त्याच्या व्यवहारांच्या अंमलबजावणीमध्ये “डर्टी रीड” वगळण्यात आले आहे, आणि औपचारिकपणे पुनरावृत्ती करण्यायोग्य वाचन पातळी सेट करण्यास परवानगी देत ​​​​नाही, म्हणजेच ते केवळ समर्थन करते (डीफॉल्टनुसार) Read committedआणि Serializable. त्याच वेळी, वैयक्तिक आदेशांच्या स्तरावर, ते प्रत्यक्षात वाचण्याच्या पुनरावृत्तीची हमी देते (जर SELECTपहिल्या व्यवहारातील कमांड डेटाबेसमधून पंक्तींचा संच निवडत असेल आणि यावेळी समांतर दुसरा व्यवहार यातील काही पंक्ती बदलत असेल, तर पहिल्या व्यवहाराद्वारे प्राप्त झालेल्या परिणाम सेटमध्ये अपरिवर्तित पंक्ती असतील, जसे की दुसरा व्यवहार झाला नाही). ओरॅकल तथाकथित READ-ONLYव्यवहारांना देखील समर्थन देते, जे सोबत संबंधित आहेत Serializable, परंतु डेटा स्वतः बदलू शकत नाहीत.

आणि मायक्रोसॉफ्ट एसक्यूएल सर्व्हर सर्व चार मानक ट्रान्झॅक्शन आयसोलेशन स्तरांना सपोर्ट करतो, आणि त्याव्यतिरिक्त, स्नॅपशॉट स्तर, ज्यावर व्यवहार लॉन्च करण्यापूर्वी कमिट केलेली डेटा स्थिती पाहतो, तसेच स्वतःच केलेले बदल पाहतो, म्हणजेच ते असे वागते. जर ते स्टार्टअपवर प्राप्त झाले, तर डीबी डेटाचा स्नॅपशॉट आणि त्याच्यासह कार्य करते. सिरियलाइज्ड मधील फरक असा आहे की कोणतेही लॉक वापरले जात नाहीत, परंतु परिणामी, समवर्ती व्यवहाराने पूर्वी समान डेटा बदलला असल्यास बदल करणे शक्य होणार नाही; या प्रकरणात, दुसरा व्यवहार, कार्यान्वित करण्याचा प्रयत्न करताना, COMMITएक त्रुटी संदेश वाढवेल आणि रद्द केला जाईल.