यदि आप सर्वर को सॉकेट से बाहर निकालते हैं, या डमी के लिए डीबी ओआरएसीएलई से बाहर निकलते हैं, तो क्या आधार टूट जाएगा

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


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

डीबीए और अन्य विशेषज्ञों के लिए (अच्छे तरीके से) - सामग्री को जानबूझकर अधिकतम सरलीकृत किया जाता है, इस वजह से कुछ अशुद्धियां होती हैं। लक्ष्य एक अप्रस्तुत व्यक्ति को मूल सिद्धांतों को व्यक्त करना था।

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



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



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



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

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



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

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

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

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

हां, यह सभी जानकारी उपयोगी है, लेकिन डेवलपर्स को किस पर ध्यान देना चाहिए?

• पहला गैर-स्पष्ट बिंदु - ORACLE में अन्य DBMS के विपरीत, अक्सर COMMIT हानिकारक है। इस आदेश की जानकारी प्राप्त होने पर, थोड़ी मात्रा में, डिस्क पर लिखा जाना चाहिए। यह प्रक्रिया जितनी जल्दी हो सके होती है, लेकिन यदि आप 10 मिलियन टेबल के लिए प्रत्येक रिकॉर्ड को बदलने के बाद इसे निष्पादित करने का प्रयास करते हैं ... सिस्टम को इस तरह से डिज़ाइन किया गया है कि COMMIT बनाने के लिए जब यह व्यापारिक तर्क के दृष्टिकोण से आवश्यक हो, और अधिक बार नहीं।
लेन-देन के रोलबैक (रोलबैक) को जितना संभव हो उतना टाला जाना चाहिए, एक नियम के रूप में, रोलबैक का समय अक्सर परिवर्तनों के समय के बराबर होता है। UPDATE एक घंटे चल रहा था, हमने वापस रोल करने का फैसला किया, ROLLBACK भी एक तुलनीय समय चलाएगा। और कमिट एक विभाजित सेकंड के लिए पारित हो जाता।

• दूसरा बिंदु, किसी कारण से कई डेवलपर्स के लिए स्पष्ट नहीं है, यह है कि डेटा परिवर्तन कभी भी पढ़ने को अवरुद्ध नहीं करते हैं। यह याद किया जाना चाहिए, लेकिन सामान्य तौर पर डेवलपर के दृष्टिकोण से डेटा तक एक साथ पहुंच के कार्यान्वयन के लिए एक अलग लेख की आवश्यकता होती है।

• तीसरा बिंदु - join'ov से डरो मत, यह त्रुटिपूर्ण MySQL नहीं है। एक ठीक से ट्यून किया गया डेटाबेस डेटा अखंडता और प्रदर्शन दोनों को बनाए रखने में मदद करेगा। हास जौन, मेरिन जॉय, इंडेक्स ऑर्गेनाइज्ड टेबल, कार्डिनलिटी, क्वर्टी रीवेरिटिंग और मैटेरियल सेट व्यू कमेटी ऑन कमेटी की स्थापना से जानकार एडमिन को अच्छी स्पीड हासिल करने में मदद मिलेगी। लेकिन एक-दो वर्षों में गैर-सुसंगत संप्रदाय प्रणाली को बनाए रखना अधिक कठिन होगा।

• और अंत में - संबंधित चर का उपयोग करें! यह आपको महत्वपूर्ण रूप से, कई बार उत्पादकता में वृद्धि करने की अनुमति देगा और, एक मुफ्त बोनस के रूप में, एसक्यूएल से बचें!



निष्कर्ष - ORACLE ने एक विश्वसनीय DBMS बनाया है, लेकिन यह कितनी तेजी से काम करेगा, यह डेवलपर्स पर निर्भर करता है। गैर-इष्टतम समाधान किसी भी सर्वर को दया के लिए कहेंगे।