Oracle RAC में Cache Fusion में महारत: प्रमुख अवधारणाएं और व्यावहारिक अंतर्दृष्टि

Cache Fusion, Oracle® Real Application Clusters (RAC) में दो इंस्टेंस के बीच ब्लॉक का स्थानांतरण है, जो RAC में मुख्य और सबसे महत्वपूर्ण विशेषता है।

परिचय

Oracle के अनुसार Oracle RAC Cache Fusion में, "RAC क्लस्टर में प्रत्येक इंस्टेंस का अपना स्थानीय बफर कैश होता है जहां यह कैश कार्यक्षमता करता है। लेकिन जब कई उपयोगकर्ता अलग-अलग नोड्स से जुड़े होते हैं, तो [उपयोगकर्ता अक्सर] किसी अन्य इंस्टेंस के स्वामित्व वाले डेटा ब्लॉक को एक्सेस या लॉक करने की आवश्यकता होती है।

"ऐसे मामलों में, [अनुरोध करने वाला] इंस्टेंस उस डेटा ब्लॉक के लिए एक होल्डिंग इंस्टेंस का अनुरोध करता है और [एक] इंटरकनेक्ट तंत्र के माध्यम से इसे एक्सेस करता है। इस अवधारणा को Cache Fusion के रूप में जाना जाता है।"

सिंगल इंस्टेंस

Cache Fusion का पता लगाने से पहले, आइए देखें कि जब डेटा ब्लॉक अनुरोध होता है तो नॉन-RAC डेटाबेस कैसे व्यवहार करते हैं।

सिंगल इंस्टेंस में चार-चरणीय लेनदेन प्रक्रिया निम्नलिखित है (Gopi के Cache Fusion ब्लॉग पोस्ट से ली गई):

1. जब कोई उपयोगकर्ता हाल ही में संशोधित ब्लॉक पढ़ता है, तो उसे ब्लॉक में एक सक्रिय लेनदेन मिल सकता है।
2. उपयोगकर्ता को यह तय करने के लिए अनडू सेगमेंट हेडर पढ़ने की आवश्यकता होगी कि लेनदेन प्रतिबद्ध किया गया है या नहीं।
3. यदि लेनदेन प्रतिबद्ध नहीं है, तो प्रक्रिया बफर कैश में ब्लॉक में डेटा और अनडू सेगमेंट में संग्रहीत डेटा का उपयोग करके ब्लॉक का एक सुसंगत पढ़ें (CR) संस्करण बनाती है।
4. यदि अनडू सेगमेंट दिखाता है कि लेनदेन प्रतिबद्ध है, तो प्रक्रिया को ब्लॉक को फिर से देखना होगा और ब्लॉक को साफ करना होगा और परिवर्तनों के लिए रीडो जनरेट करना होगा।

अब, आइए दो-इंस्टेंस क्लस्टर के साथ RAC में उसी परिदृश्य को देखें, जिसे Cache Fusion के रूप में जाना जाता है।

Cache Fusion

Gopi जारी रखते हैं, "RAC में, [दो] या अधिक इंस्टेंस समान डेटाबेस फ़ाइलों तक पहुंचते हैं [जो समान स्टोरेज में हैं (जैसे, ASM)]। प्रत्येक इंस्टेंस का अपना SGA, बैकग्राउंड प्रोसेस होता है, जिसका अर्थ है कि प्रत्येक इंस्टेंस का अपना बफर कैश होता है (प्रत्येक इंस्टेंस के लिए स्थानीय)। ये बफर कैश इंस्टेंस स्तर पर व्यक्तिगत रूप से कार्य करते हैं और डेटाबेस स्तर पर एक साथ जुड़कर एक इकाई (ग्लोबल कैश) बनाते हैं [ताकि] उनके बीच डेटा ब्लॉक साझा किए जा सकें। इसे Cache Fusion कहा जाता है। Cache Fusion क्लस्टर में इंस्टेंस के बीच डेटा ब्लॉक के कैश-टू-कैश ट्रांसफर प्रदान करने के लिए एक हाई-स्पीड IPC इंटरकनेक्ट का उपयोग करता है। यह डेटा-ब्लॉक शिपिंग डिस्क I/O को समाप्त करता है और पढ़ने/लिखने की समवर्ती को अनुकूलित करता है।"

यह समझ हमें ग्लोबल कैश सर्विस (GCS) की ओर ले जाती है, जो इंस्टेंस के बीच ब्लॉक ट्रांसफर के लिए जिम्मेदार है।

Gopi की पोस्ट में उल्लिखित GCS बैकग्राउंड प्रोसेस निम्नलिखित हैं:

• ग्लोबल कैश सर्विस प्रोसेस (LMSn)
• ग्लोबल एनक्यू सर्विस डेमन (LMD)

Gopi आगे कहते हैं, "इन बैकग्राउंड प्रोसेस में जाने से पहले, [sic] आइए देखें कि Oracle डेटा ब्लॉक को कैसे व्यवहार करता है और उन्हें कैसे प्रबंधित करता है।

"Oracle डेटा ब्लॉक को संसाधनों के रूप में मानता है। इनमें से प्रत्येक संसाधन को विभिन्न मोड में रखा जा सकता है, जो डेटा अखंडता बनाए रखने के लिए [एक] महत्वपूर्ण तंत्र है। ये मोड इस बात पर निर्भर करते हुए [तीन] प्रकारों में वर्गीकृत हैं कि संसाधन धारक डेटा को संशोधित करना चाहता है या पढ़ना चाहता है।"

Gopi मोड को निम्नानुसार सूचीबद्ध करता है:

• Null (N) मोड: Null मोड आमतौर पर प्लेसहोल्डर के रूप में रखा जाता है।
• Shared (S) मोड: इस मोड में, एक डेटा ब्लॉक को किसी अन्य सत्र द्वारा संशोधित नहीं किया जाता है लेकिन समवर्ती साझा एक्सेस की अनुमति देगा।
• Exclusive (X) मोड: यह स्तर धारक प्रक्रिया को विशेष पहुंच प्रदान करता है। अन्य प्रक्रियाएं संसाधन में लिख नहीं सकतीं। इसमें सुसंगत पढ़ें ब्लॉक हो सकते हैं।

ग्लोबल कैश सर्विस डेमन (LMSn)

जब किसी इंस्टेंस से अनुरोध होता है, तो Gopi हमें बताते हैं, "GCS मेमोरी में ब्लॉक कॉपी को बनाए रखते हुए अन्य इंस्टेंस को ब्लॉक शिपिंग का आयोजन करता है। ऐसी प्रत्येक कॉपी को पास्ट इमेज (PI) कहा जाता है। [...] डेटा ब्लॉक के एक से अधिक PI होना भी संभव है, यह इस बात पर निर्भर करता है कि ब्लॉक को डर्टी चरण में कितनी बार अनुरोध किया गया था।"

नोट: Gopi जोड़ते हैं, "यदि आप एक डेटा ब्लॉक पढ़ना चाहते हैं, तो इसे [एक] सुसंगत स्थिति में पढ़ा जाना चाहिए। आपको दूसरों द्वारा किए गए परिवर्तनों को पढ़ने की अनुमति नहीं है।"

ग्लोबल एनक्यू सर्विस डेमन (LMD)

Gopi बताते हैं, "ग्लोबल एनक्यू सर्विस (GES) सभी Oracle एनक्यूइंग तंत्र की स्थिति को ट्रैक करता है। GES डिक्शनरी कैश लॉक, लाइब्रेरी कैश लॉक, और लेनदेन पर समवर्ती नियंत्रण करता है। यह उन संसाधनों के लिए इस ऑपरेशन को करता है जिन्हें एक से अधिक इंस्टेंस द्वारा एक्सेस किया जाता है। GES डेटा फ़ाइलों और कंट्रोल फ़ाइलों तक पहुंच को नियंत्रित करता है लेकिन डेटा ब्लॉक के लिए नहीं।"

Gopi द्वारा साझा किए गए GES प्रबंधित संसाधन निम्नलिखित हैं:

• लेनदेन लॉक: जब कोई लेनदेन अपना परिवर्तन शुरू करता है (इन्सर्ट, अपडेट, आदि) तो यह विशेष मोड में प्राप्त होता है। लॉक तब तक रखा जाता है जब तक लेनदेन प्रतिबद्ध या रोल बैक नहीं हो जाता।
• लाइब्रेरी कैश लॉक: जब किसी डेटाबेस ऑब्जेक्ट (जैसे टेबल, व्यू, पैकेज, पैकेज बॉडी, [...] और इसी तरह) को SQL, DML या DDL, PL/SQL, या Java स्टेटमेंट के पार्सिंग या कंपाइलिंग के दौरान संदर्भित किया जाता है, तो स्टेटमेंट को पार्स या कंपाइल करने वाली प्रक्रिया सही मोड में लाइब्रेरी कैश लॉक प्राप्त करती है।
• डिक्शनरी कैश लॉक: क्लस्टर डेटाबेस मोड में ग्लोबल एनक्यू का उपयोग किया जाता है। डेटा डिक्शनरी संरचना क्लस्टर डेटाबेस में सभी Oracle इंस्टेंस के लिए समान होती है।
• टेबल लॉक: ये GES लॉक हैं जो पूरी टेबल की रक्षा करते हैं। जब कोई टेबल संशोधित होती है तो एक लेनदेन टेबल लॉक प्राप्त करता है। एक टेबल लॉक को कई मोड में रखा जा सकता है: null (N), रो शेयर (RS), रो एक्सक्लूसिव (RX), शेयर लॉक (S), शेयर रो एक्सक्लूसिव (SRX), या एक्सक्लूसिव (X)।

पास्ट और सुसंगत पढ़ें इमेज

मुख्य परिदृश्य पर जाने से पहले, हमें पास्ट इमेज (PI) और सुसंगत पढ़ें (CR) इमेज को समझने की आवश्यकता है।

पास्ट इमेज

Rohit Gupta अपने लेख Oracle RAC Cache Fusion में साझा करते हैं, "पास्ट इमेज की अवधारणा RAC सेटअप के लिए बहुत विशिष्ट है। एक इंस्टेंस पर विचार करें जो अपडेट के लिए डेटा ब्लॉक पर [एक] विशेष लॉक रखता है। यदि RAC में कोई अन्य इंस्टेंस ब्लॉक की आवश्यकता है, तो होल्डिंग इंस्टेंस ब्लॉक को अनुरोध करने वाले इंस्टेंस को भेज सकता है (इसे डिस्क पर लिखने के बजाय) अपने बफर कैश में ब्लॉक की PI (पास्ट इमेज) रखकर। मूल रूप से, PI डेटा ब्लॉक की कॉपी है इससे पहले कि ब्लॉक को डिस्क पर लिखा जाए।"

सुसंगत पढ़ें इमेज:

Gupta जारी रखते हैं, "एक सुसंगत पढ़ें की आवश्यकता होती है जब एक विशेष ब्लॉक को लेनदेन [A1] द्वारा एक्सेस/संशोधित किया जा रहा है, और उसी समय दूसरा लेनदेन [A2] ब्लॉक को एक्सेस/पढ़ने का प्रयास करता है। यदि [A1] प्रतिबद्ध नहीं किया गया है, तो [A2] को आगे बढ़ने के लिए ब्लॉक की एक सुसंगत पढ़ें [(गैर-संशोधित ब्लॉक)] कॉपी की आवश्यकता होती है। उस ब्लॉक के लिए UNDO डेटा का उपयोग करके एक CR कॉपी बनाई जाती है।"

Cache Fusion परिदृश्य

Cache Fusion के तीन अलग-अलग परिदृश्य हैं:

• रीड-रीड परिदृश्य
• रीड-राइट परिदृश्य
• राइट-राइट परिदृश्य

रीड-रीड परिदृश्य:

यह एक गैर-महत्वपूर्ण परिदृश्य है क्योंकि ब्लॉक का अनुरोध करने वाला इंस्टेंस और ब्लॉक का अनुरोध करने वाला इंस्टेंस दोनों रीड लेनदेन का अनुरोध कर रहे हैं। यहां, कोई विशेष लॉक नहीं होता है। इंस्टेंस B GCS को एक रीड ब्लॉक का अनुरोध करता है। GCS ब्लॉक की उपलब्धता की जांच करता है, जो इंस्टेंस A के स्वामित्व में है, और एक साझा लॉक प्राप्त करता है। अब GCS अनुरोध करता है कि इंस्टेंस A अनुरोधित ब्लॉक को इंस्टेंस B को भेजे।

रीड-राइट परिदृश्य:

यह एक महत्वपूर्ण परिदृश्य है।

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

GCS जांचता है और पाता है कि इंस्टेंस ने उसी ब्लॉक पर विशेष लॉक प्राप्त कर लिया है। इसलिए, GCS इंस्टेंस A को ब्लॉक जारी करने के लिए कहता है। अब, इंस्टेंस A अपने स्वयं के बफर कैश में एक CR इमेज बनाता है और GCS को तदनुसार सूचित करता है ताकि इसे इंस्टेंस B को भेजा जा सके।

CR इमेज निर्माण में GCS शामिल है, और इसे अनुरोधित इंस्टेंस में भेजना वह जगह है जहां Cache Fusion चलन में आता है।

राइट-राइट परिदृश्य

इंस्टेंस A और इंस्टेंस B दोनों एक डेटा ब्लॉक पर विशेष लॉक प्राप्त करने का प्रयास कर रहे हैं।

इंस्टेंस B GCS को एक ब्लॉक अनुरोध भेजता है। GCS उपलब्धता की जांच करता है और पाता है कि इंस्टेंस A ने लॉक प्राप्त कर लिया है। इस प्रकार, GCS इंस्टेंस A को इंस्टेंस B के लिए ब्लॉक जारी करने के लिए कहता है। अब, इंस्टेंस A अपने बफर में अपने स्वयं के वर्तमान ब्लॉक का PI बनाता है, रीडो एंट्री बनाता है, और GCS को इंस्टेंस B को ब्लॉक भेजने के लिए सूचित करता है।

इंस्टेंस B अब ब्लॉक का उपयोग करता है और हमेशा की तरह परिवर्तन करता है।

CR और PI के बीच मुख्य अंतर

Gupta PI बनाम CR इमेज के बारे में निम्नलिखित अंतिम विचार जोड़ते हैं: "[CR] इमेज को [एक] रीड-राइट प्रकार के विवाद से बचने के लिए भेजा गया था क्योंकि अनुरोध करने वाला इंस्टेंस लिखने का ऑपरेशन नहीं करना चाहता और इसलिए ब्लॉक पर विशेष लॉक की आवश्यकता नहीं होगी। इस प्रकार एक रीड ऑपरेशन के लिए, ब्लॉक की CR इमेज पर्याप्त होगी। जबकि राइट-राइट विवाद के लिए, अनुरोध करने वाला इंस्टेंस भी डेटा ब्लॉक पर विशेष लॉक प्राप्त करने की आवश्यकता होती है। [लिखने के ऑपरेशन के लिए लॉक प्राप्त करने के लिए, इसे वास्तविक ब्लॉक की आवश्यकता होगी न कि CR इमेज की। होल्डिंग इंस्टेंस इसलिए वास्तविक ब्लॉक भेजता है लेकिन ब्लॉक के डिस्क पर लिखे जाने तक ब्लॉक का PI रखने के लिए उत्तरदायी होता है। इसलिए, यदि कोई इंस्टेंस विफलता या क्रैश होता है, तो Oracle RAC इंस्टेंस में PI का उपयोग करके ब्लॉक बनाने में सक्षम होता है। एक बार ब्लॉक डिस्क पर लिख दिया जाता है, तो क्रैश के मामले में रिकवरी की आवश्यकता नहीं होगी, और इसलिए संबंधित PI को त्यागा जा सकता है।"

हमारी डेटा सेवाओं के बारे में अधिक जानें।

कोई टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें। आप हमसे बातचीत भी शुरू कर सकते हैं।