प्रोग्रामर के लिए ओरेकल डीबी

क्या एक एप्लिकेशन प्रोग्रामर को यह समझने की आवश्यकता है कि डेटाबेस कैसे काम करता है? टॉम पतंग, एक मान्यता प्राप्त ओरेकल विशेषज्ञ, प्रसिद्ध आस्कटॉम कॉलम के लेखक, अपनी पुस्तक ओरेकल फॉर प्रोफेशनल्स में। वास्तुकला और प्रमुख विशेषताएं। ”जोर देकर कहते हैं कि यह एक जरूरी है। यहां तक ​​कि अगर आपकी टीम में एक सक्षम प्रशासक है, तो यह जानना कि ओरेकल डीबीएमएस कैसे काम करता है, आपको एक-दूसरे को बेहतर ढंग से समझने और अधिक प्रभावी ढंग से बातचीत करने में मदद करेगा, न कि उस मामले का उल्लेख करने के लिए जब आपके पास ऐसा विशेषज्ञ नहीं है। इस विषय में, मैं उन मुख्य बातों का उल्लेख करूँगा जो समझ आपको Oracle डेटाबेस के साथ सक्षम रूप से काम करने की अनुमति देगा और इसकी कुछ विशेषताओं का उपयोग आपके आवेदन के लिए बड़े प्रभाव के साथ करेगा। यदि आप पहले ही टॉम कीइट द्वारा उपर्युक्त पुस्तक पढ़ चुके हैं, तो आप बस इस लेख को मेमो के रूप में उपयोग कर सकते हैं। एक टिप्पणी - मैंने लंबे समय तक किताब पढ़ी, और फिर ओरेकल डेटाबेस का नवीनतम संस्करण 9i था, मैंने नौ में प्रशासन पाठ्यक्रम भी लिया, इसलिए अगर कुछ बदल गया है और शीर्ष दस में जोड़ा गया है, तो मुझे दोष न दें। हालांकि मैं काफी मौलिक चीजों के बारे में लिख रहा हूं जो बहुत अधिक बदलने की संभावना नहीं है।

ओरेकल डेटाबेस क्या इतनी तेजी से बनाता है?

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

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

डेटा रिकवरी तंत्र

आप Oracle DBMS में उपरोक्त संचालन लॉग फ़ाइलों को संग्रहीत करने में सक्षम कर सकते हैं, और सभी परिवर्तन संग्रहीत किए जाएंगे। इस प्रकार, डेटा ब्लॉकों के साथ किसी भी डिस्क के नुकसान की स्थिति में, हम किसी भी समय उन्हें पुनर्स्थापित कर सकते हैं, जिसमें क्रैश से ठीक पहले का क्षण, नवीनतम संग्रह लॉग फ़ाइलों पर वर्तमान ऑनलाइन जर्नल को रोल करके।

कॉपी करके खड़े हो जाओ

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

कुछ लिखने का अनुरोध लटका

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

नॉन-ब्लॉकिंग रीडिंग और रोलबैक सेगमेंट

ओरेकल डीबीएमएस की सबसे उल्लेखनीय विशेषताओं में से एक गैर-अवरुद्ध रीडिंग है, जो रोलबैक सेगमेंट के माध्यम से प्राप्त की जाती है। ओरेकल के लिए अनुरोध पढ़ें कभी भी अवरुद्ध नहीं होते हैं, क्योंकि डेटा को लगभग हमेशा रोलबैक सेगमेंट से पढ़ा जा सकता है।

रोलबैक सेगमेंट एक और वरदान देता है: इसमें से आप कुछ टेबल के लिए थोड़ा पुराना डेटा पढ़ने की कोशिश कर सकते हैं जो एक निश्चित बिंदु पर था। इस सुविधा को फ्लैशबैक कहा जाता है ।

हालांकि, कभी-कभी एक रोलबैक सेगमेंट को एक सुअर द्वारा रखा जा सकता है: यदि आपके पास बल्क डेटा डिलीट करने के लिए एक बड़ा काम है (रोलबैक सेगमेंट में सभी अधिक डेटा को हटाता है), तो आप ORA-01555: स्नैपशॉट बहुत पुराना पा सकते हैं । इस मामले में याद रखने वाली मुख्य बात यह है कि आपको अपनी नौकरी को फिर से लिखने की ज़रूरत नहीं है ताकि यह हर एन ऑपरेशन को शुरू कर दे, लेकिन आपको इस तरह के ऑपरेशन के लिए एक विशेष रूप से निर्मित रोलबैक सेगमेंट का उपयोग करने की आवश्यकता है।

लेन-देन अलगाव स्तर

Oracle में, कोई READ_UNCOMMITED अलगाव स्तर बिल्कुल नहीं है। तथ्य यह है कि अन्य डेटाबेस में रीड लॉक को हटाकर अधिकतम समानता प्राप्त करने के लिए इसका उपयोग किया जाता है। लेकिन ओरेकल में, पठन हमेशा ताले के बिना किया जाता है, इसलिए हमारे पास पहले से ही सभी फायदे हैं जो इस स्तर पर बिना किसी अतिरिक्त प्रतिबंध के शुरू कर सकते हैं।

सामान्य तौर पर, ओरेकल में केवल दो अलगाव स्तर स्पष्ट रूप से उपलब्ध हैं: READ_COMMITTED का उपयोग डिफ़ॉल्ट रूप से किया जाता है, लेकिन आप चाहें तो SERIALIZABLE सेट कर सकते हैं।

हालाँकि, स्टेटमेंट लेवल (SELECT, UPDATE, आदि) पर, आपके पास पहले से ही डिफ़ॉल्ट रूप से REPEATABLE_READ है, अर्थात। एक ऑपरेटर के ढांचे के भीतर, आपको हमेशा एक सुसंगत रीड मिलता है, जो रोलबैक सेगमेंट के कारण निश्चित रूप से प्राप्त होता है। मैं हमेशा टॉम काइट द्वारा दिए गए उदाहरण को पसंद करता हूं जो यह बताता है कि यह क्या देता है। मान लीजिए कि आपके पास खातों के साथ एक बहुत बड़ी तालिका है और आप राशि प्राप्त करने के लिए चयन करते हैं। ओरेकल में, कई अन्य डेटाबेस के विपरीत, भले ही आपकी क्वेरी के बीच में एक और लेनदेन पहले खाते से आखिरी तक एक निश्चित राशि को स्थानांतरित करता है, फिर भी आप अपनी क्वेरी की शुरुआत में वास्तविक डेटा प्राप्त करेंगे, क्योंकि जब आप अंतिम पंक्ति तक पहुंचते हैं तो आपका चयन देखेंगे यह रेखा बदल दी गई है, यह रोलबैक सेगमेंट में जाएगी और क्वेरी शुरू होने के समय इस सेल में मौजूद डेटा को पढ़ेगी। कई अन्य डेटाबेस में, आपको एक राशि के रूप में प्रतिक्रिया मिलेगी जो आपके टेबल में कभी मौजूद नहीं है। हालांकि, इस मामले में ओरेकल -ओ -1555 पाने के लिए ओरेकल में एक खतरा है : स्नैपशॉट बहुत पुराना है ।

मानक अलगाव स्तरों के अलावा, ओरेकल में तथाकथित READ_ONLY लेनदेन भी हैं, जो पूरे लेनदेन के भीतर REPEATABLE_READ देते हैं, और केवल एक बयान के भीतर नहीं। लेकिन जैसा कि नाम का तात्पर्य है, ऐसे लेनदेन में आप केवल पढ़ सकते हैं।

ओरेकल कैश को प्रभावी रूप से अपना डेटा दें

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

खाली लाइनें

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

सूचकांक

बी-पेड़ों के रूप में प्रसिद्ध इंडेक्सों के अलावा, ओरेकल में तथाकथित बिट इंडेक्स भी हैं, जो क्वेरी पर बहुत उच्च प्रदर्शन दिखाते हैं जिसमें टेबल पर बहुत कम मूल्य वाले कॉलम होते हैं। इस मामले में विशेष रूप से प्रभावी प्रश्न (नियमित अनुक्रमित की तुलना में) काम करेंगे, जिसमें OR और AND के विरल स्तंभों के जटिल संयोजन हैं। यह सूचकांक बी-ट्री में संग्रहीत नहीं है, लेकिन बिटमैप्स में, जो वर्णित अनुरोधों को जल्दी से निष्पादित करना संभव बनाता है। प्रश्न तालिका में अद्वितीय मानों की संख्या है, जिस पर यह सूचकांक और भी बेहतर होगा, बहुत जटिल है: यह या तो 10 अद्वितीय मूल्य हो सकते हैं या 10,000 हो सकते हैं। यहां आपको एक विशिष्ट तालिका पर एक सूचकांक बनाने की जरूरत है और देखें कि क्या होता है। मुख्य बात यह है कि बड़ी संख्या में आवेषण और अद्यतन किए गए स्तंभ के अपडेट के साथ तालिकाओं पर इस सूचकांक का उपयोग करने की कोशिश न करें, क्योंकि इस तरह के संचालन अनुक्रमित तालिका में काफी बड़े वर्गों को अवरुद्ध कर देंगे और आपका सिस्टम एक हिस्सेदारी प्राप्त कर सकता है या गतिरोध भी पकड़ सकता है।

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

इंडेक्स की एक और दिलचस्प संपत्ति यह है कि इंडेक्स NULL मानों को संग्रहीत नहीं करता है। इस प्रकार, यदि आप अनुक्रमित स्तंभ पर <,> या <> के साथ प्रश्न बनाते हैं, तो आपको अनुक्रमित कॉलम में NULL मान के साथ लाइनें वापस नहीं मिलेंगी। दूसरी ओर, कुछ विशिष्ट मामलों के लिए इस संपत्ति का बहुत प्रभावी ढंग से उपयोग किया जा सकता है। उदाहरण के लिए, आपके पास एक बहुत बड़ी प्लेट है जिसमें ऑर्डर जमा किए जाते हैं, जिसे कभी भी साफ नहीं किया जाता है। और एक पृष्ठभूमि प्रक्रिया है जो सभी आदेशों को किसी बैकऑफ़िस सिस्टम में भेजने के लिए बाध्य है। पहला समाधान जो भीख मांगता है वह is_sent ध्वज के साथ एक और कॉलम प्राप्त करता है, जहां यह शुरू में 0 पर खड़ा होता है, और भेजते समय, हम नीचे डाल देंगे 1. वह है प्रत्येक शुरुआत में पृष्ठभूमि की प्रक्रिया तालिका के साथ स्थिति को_सेंट = 0 पर क्वेरी करेगी। आप यहां बिट इंडेक्स का उपयोग नहीं कर सकते हैं, क्योंकि प्लेट बहुत सक्रिय रूप से फिर से भरना है। बी-ट्री पर आधारित एक नियमित सूचकांक में बहुत अधिक स्थान होगा, क्योंकि आपको बड़ी संख्या में लाइनों को लिंक करने की आवश्यकता होती है। लेकिन अगर हम अपने तर्क को भेजने वाले चिह्न के रूप में थोड़ा बदल देते हैं और is_sent कॉलम में हम 1 के बजाय NULL डालेंगे, तो हमारा सूचकांक छोटा हो जाएगा, क्योंकि किसी भी समय यह केवल गैर-NULL मान संग्रहीत करेगा, और उनमें से बहुत कम होंगे।

टेबल्स अलग हैं

नियमित तालिकाओं के अलावा, ओरेकल में, कई अन्य डेटाबेस की तरह, तथाकथित सूचकांक तालिकाएं होती हैं, जब ये तालिकाएं प्राथमिक कुंजी के इंडेक्स ट्री में सीधे झूठ होती हैं। इस प्रकार, दो चीजें एक ही बार में प्राप्त की जाती हैं: सबसे पहले, प्राथमिक कुंजी पर डेटा पढ़ने के लिए, आपके पास एक कम पढ़ना है, दूसरे, तालिका में डेटा प्राथमिक कुंजी द्वारा सॉर्ट किया जाता है, इसलिए अतिरिक्त संचालन के बिना ORDER BY PK ऑपरेशन किया जाएगा। नुकसान में यह तथ्य शामिल है कि अब आप इस अनुक्रमणिका की ऑपरेशनल लॉग फ़ाइलों में लॉगिंग के बीच अंतर नहीं कर सकते हैं।

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

क्लस्टर टेबलों के आधार पर, क्लस्टर हैश टेबल भी हैं, जिसमें B- ट्री के बजाय, क्लस्टर कुंजी के हैश पर आधारित तालिका का उपयोग किया जाता है। ऐसा लगता है, ज़ाहिर है, बहुत दिलचस्प है, लेकिन, ईमानदार होने के लिए, मैंने इसे अभ्यास में कभी भी सामना नहीं किया है।

चर बंधन

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

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

प्रोग्रामर के लिए एक जोड़ी अधिक नोट्स

यदि आपका कॉलम VARCHAR2 (100) प्रकार का है, तो स्ट्रिंग longString.substring (0, 100) को रटना करने का प्रयास करना, ऐसा कोई तथ्य नहीं है जो सफल होगा, क्योंकि डिफ़ॉल्ट कॉलम परिभाषा में प्रतिबंध 100 बाइट्स की संख्या को संदर्भित करता है, इसलिए वर्ण नहीं। डबल-बाइट पात्रों की उपस्थिति में आप मुसीबत में पड़ सकते हैं। वास्तव में, इस व्यवहार को थोड़ा कॉन्फ़िगर किया जा सकता है, अधिक विवरण यहां पाया जा सकता है । यह अच्छा है यदि आप अभी तक एक अंतहीन लूप में डालने की कोशिश नहीं कर रहे हैं, तो इसे अभी तक करने के सिद्धांत पर, इस मामले में "वर्क आउट" करने के लिए कभी नहीं।

खैर, सभी प्रकार के डेटाबेस के लिए एक सामान्य अनुशंसा: किसी ऑब्जेक्ट फ़ील्ड को बदलते समय तालिका के सभी स्तंभों को कभी भी अपडेट न करें। यह बहुत स्पष्ट लगता है, लेकिन जैसा कि अभ्यास से पता चलता है, इस एंटीपैटर्न में अक्सर एक जगह होती है, इसलिए मैं अत्यधिक जाँच की सलाह देता हूं कि आपके ढांचे केवल बदले हुए क्षेत्रों का अद्यतन करते हैं।

निष्कर्ष

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