Oracle डेटाबेस में 100,500 कैशिंग विधि

यह बताने के लिए कि कैश क्या है, परिणाम कैश क्या है, यह ओरेकल में और अन्य डेटाबेस में कैसे बनाया गया है, बहुत दिलचस्प और सुंदर बॉयलरप्लेट नहीं है। लेकिन सब कुछ पूरी तरह से अलग रंग लेता है जब विशिष्ट उदाहरणों की बात आती है। अलेक्जेंडर टोकरेव ( श्टॉक ) ने मामलों के आधार पर हाईलोड + ++ 2017 पर अपनी रिपोर्ट बनाई। और यह उन मामलों के आधार पर ठीक था जो उन्होंने मुझे बताया था कि जब घर का बना कैश सुविधाजनक हो सकता है, तो सर्वर-साइड रिजल्ट कैश का दर्द क्या है और इसे क्लाइंट-साइड एक के साथ कैसे बदला जाए, और सामान्य तौर पर मैं ओरेकल में रिजल्ट कैश स्थापित करने के लिए कई उपयोगी टिप्स लाया।


स्पीकर के बारे में: अलेक्जेंडर टोकरेव डेटाअर्ट में काम करता है और डेटाबेस से संबंधित मुद्दों से संबंधित है, जो खरोंच से बिल्डिंग सिस्टम और मौजूदा वाले को अनुकूलित करने के मामले में दोनों हैं।

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

वैसे, ओरेकल के पास पहले से ही 14 डेटाबेस हैं - अब तक 14 - भविष्य में क्या होगा यह अज्ञात है।

जैसा कि पहले ही उल्लेख किया गया है, सभी समस्याओं और समाधानों को विशिष्ट मामलों के साथ चित्रित किया जाएगा। ये DataArt परियोजनाओं से दो मामले होंगे, और एक तृतीय-पक्ष उदाहरण।

डेटाबेस कैश

शुरू करने के लिए, डेटाबेस में कौन से कैश हैं। सब कुछ यहाँ स्पष्ट है:

• बफर कैश - डेटा कैश - डेटा पेज / डेटा ब्लॉक के लिए कैश;
• स्टेटमेंट कैश - स्टेटमेंट्स का कैश और उनकी योजनाएं - कैश ऑफ क्वेरीज प्लान;
• परिणाम कैश - पंक्ति परिणाम का कैश - प्रश्नों से पंक्तियाँ;
• ओएस कैश - ऑपरेटिंग सिस्टम कैश।

इसके अलावा, परिणाम कैश, बड़े और केवल Oracle में उपयोग किया जाता है। वह एक बार MySQL में थे, लेकिन तब उन्हें वीरतापूर्वक काट दिया गया था। PostgreSQL में यह या तो नहीं है, यह एक रूप में या दूसरे में केवल तृतीय-पक्ष pgpool उत्पाद में मौजूद है।

केस 1. रिटेलर वॉल्ट

ऊपर वह उत्पाद आरेख है जो हमने साथ दिया - रिपॉजिटरी (ओरेकल 11, 20 टीबी, 300 उपयोगकर्ता), और इसमें कुछ प्रकार की ड्रियर रिपोर्ट शामिल हैं, जिसमें प्रति 5000 डेटा लाइनों में 350 अद्वितीय उत्पाद थे। इसे प्राप्त करने में लगभग 20 मिनट लगे, और उपयोगकर्ता उदास थे।

इस रिपोर्ट की प्रस्तुति , अन्य सभी की तरह, Highload ++ सम्मेलन स्थल पर उपलब्ध है।

इस रिपोर्ट में SELECT, JOINs और एक फंक्शन है। एक फ़ंक्शन के रूप में, सब कुछ ठीक होगा, केवल यह "ट्रांसफर प्राइसिंग मूल्य" नामक एक रहस्यमय पैरामीटर की गणना करता है, यह 0.2 एस के लिए काम करता है - ऐसा लगता है कि कुछ भी नहीं है, लेकिन इसे कई बार कहा जाता है क्योंकि तालिका में पंक्तियां हैं। इस फ़ंक्शन के बाद से SQL + PL / SQL की 400 पंक्तियाँ हैं उत्पाद समर्थन में है, इसे बदलना डरावना है।

उसी कारण से, result_cache का उपयोग नहीं किया जा सका।



समस्या को हल करने के लिए, हम हाथ से निर्मित कैशिंग के साथ मानक दृष्टिकोण का उपयोग करते हैं: हम सर्किट के पहले 3 ब्लॉकों को छोड़ देते हैं, जैसा कि यह था, बस हमारे sku_detail () फ़ंक्शन को sku_full () में बदलें और क्रमशः एक सहयोगी सरणी घोषित करें, जहां:

• चाबियाँ हमारे SKU (कमोडिटी आइटम) हैं,
  
• मान परिकलित हस्तांतरण रूपांतरण मूल्य हैं।
  

हम कैश (स्कू) फ़ंक्शन को स्पष्ट करते हैं: यदि हमारे सहयोगी सरणी में ऐसी कोई आईडी नहीं है, तो हमारा फ़ंक्शन लॉन्च किया जाता है, परिणाम कैश किया जाता है, सहेजा जाता है और वापस लौटाया जाता है। तदनुसार, यदि ऐसी आईडी है, तो यह सब नहीं होता है। वास्तव में, हम मांग कैश पर मिले।

इस प्रकार, हमने फ़ंक्शन कॉल की संख्या को उस राशि तक कम कर दिया है जो वास्तव में आवश्यक है। रिपोर्ट प्रसंस्करण समय 4 मिनट तक कम हो गया , सभी उपयोगकर्ताओं को अच्छा लगा।

हाथ से बनी कैशे मेमोरी

इस प्रणाली के नुकसान और फायदे इस बड़ी स्मार्ट तस्वीर से स्पष्ट हैं, जिसे हम बहुत कुछ संबोधित करेंगे - यह मेमोरी आर्किटेक्चर है।



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

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

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



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

सामान्य तौर पर, घर-निर्मित result_cache का सक्रिय रूप से उपयोग किया जाता है, लेकिन इन-डेटाबेस result_cache इस कार्य के कार्यान्वयन के लिए एक अलग दृष्टिकोण है। यह और यह कैसे काम नहीं किया त्वरित जीत हम आगे विचार करेंगे।

केस 2. वित्तीय दस्तावेज का प्रसंस्करण

तो, हमारा दूसरा मामला।



यह एक अर्ध-स्वचालित वित्तीय प्रलेखन प्रसंस्करण प्रणाली है - एक शास्त्रीय वास्तुकला के साथ एक नीच उद्यम, जिसमें शामिल हैं:

• पतला ग्राहक;
  
• 4,000 उपयोगकर्ता जो दुनिया के विभिन्न हिस्सों में रहते हैं;
  
• संतुलन;
  
• 2 व्यावसायिक तर्क की गणना के लिए JBoss;
  
• इन-मेमोरी क्लस्टर;
  
• कोर ओरेकल;
  
• ओरेकल बैकअप
  

इस प्रणाली के कई कार्यों में से एक सिफारिशों की गणना है ।



प्रत्येक संकेतक के लिए दस्तावेज हैं, जो सिस्टम द्वारा स्वचालित रूप से मान्यता प्राप्त नहीं है, संकेतक का एक सेट या तो पिछले ग्राहक दस्तावेजों से या एक समान उद्योग से, या समान लाभप्रदता से पेश किया जाता है, जबकि सूचक की तुलना मान्यता प्राप्त मूल्य के साथ की जाती है ताकि बहुत अधिक पेशकश न हो। क्या महत्वपूर्ण है, दस्तावेज बहुभाषी हैं ।

उपयोगकर्ता वांछित मान का चयन करता है और प्रत्येक खाली लाइन के लिए ऑपरेशन को दोहराता है।

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

1. बहुभाषावाद - लगभग 30 भाषाएँ। प्रत्येक भाषा के अपने स्वयं के उपजी, समानार्थक शब्द और अन्य विशेषताएं हैं।
2. इस ग्राहक का पिछला डेटा, या, उसके अभाव में, उसी उद्योग के ग्राहक का डेटा या लाभ में समान क्लाइंट।

वास्तव में, यह लगभग 12 बहुत ही जटिल नियम हैं।

प्रारंभिक अनुमान:

• एक बार में 100 से अधिक उपयोगकर्ता नहीं;
• मान्यता के लिए 2-3 कॉलम;
• 100 लाइनों।

कोई अतिभार नहीं - सब कुछ उबाऊ है।

तो, यह रिलीज के लिए समय है। कोड फ्रीज हुआ, जावा को छूने से डर लगता है, और दस्तावेज़ को संसाधित करने में कम से कम 5 मिनट लगते हैं।

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



हमने दस्तावेजों का अध्ययन किया और महसूस किया कि कुंजी-मूल्य जोड़े में मूल्यों को अक्सर दोहराया जाता है - 5-10 बार। तदनुसार, हमने डेटाबेस को कैश करने के लिए उपयोग करने का निर्णय लिया, क्योंकि यह पहले ही परीक्षण किया जा चुका है।

हमने Oracle सर्वर-साइड रिजल्ट कैश का उपयोग करने का निर्णय लिया, क्योंकि:

1. SQL के अनुकूलन के अवसर समाप्त हो गए हैं, क्योंकि यह Oracle पूर्ण पाठ खोज इंजन का उपयोग करता है;
   
2. डुप्लिकेट मापदंडों के लिए कैश का उपयोग किया जाएगा;
   
3. सिफारिशों के लिए अधिकांश डेटा प्रति घंटे एक बार पुनर्गणना किया जाता है, क्योंकि वे एक पूर्ण-पाठ सूचकांक का उपयोग करते हैं;
   
4. PL / SQL निषिद्ध है ।
   

Oracle परिणाम कैश

परिणाम कैश - परिणाम के Oracle कैशिंग - निम्नलिखित गुण हैं:

• यह मेमोरी क्षेत्र है जिसमें सभी क्वेरी परिणाम अफवाह हैं;
• सुसंगत पढ़ें, और इसका स्वत: अमान्य होना;
• आवेदन में न्यूनतम परिवर्तन आवश्यक हैं। आप आवेदन को बिल्कुल भी बदलने की आवश्यकता नहीं बना सकते हैं;
• बोनस - आप पीएल / एसक्यूएल तर्क को कैश कर सकते हैं, लेकिन यह यहां निषिद्ध है।

इसे कैसे सक्षम करें?

विधि संख्या 1

Result_cache स्टेटमेंट को निर्दिष्ट करना बहुत सरल है। स्लाइड से पता चलता है कि परिणाम पहचानकर्ता प्रकट हो गया है। तदनुसार, पहली बार क्वेरी निष्पादित की गई है, डेटाबेस कुछ काम करेगा, बाद के निष्पादन के दौरान, इस मामले में किसी भी कार्य की आवश्यकता नहीं है। सब ठीक है।

विधि संख्या 2

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

वैसे, आपको क्या लगता है, यदि कोई क्वेरी दो तालिकाओं को संदर्भित करती है, जिसमें से एक परिणाम_चैके के रूप में चिह्नित है, और दूसरी नहीं है, तो ऐसी क्वेरी का परिणाम क्या है?

जवाब है नहीं, बिल्कुल नहीं।

इसे कैश करने के लिए, क्वेरी में भाग लेने वाली सभी तालिकाओं में परिणाम_ कैश एनोटेशन होना चाहिए।

निर्भरता ट्रैकिंग

इसमें प्रासंगिक विचार हैं, जिसमें आप देख सकते हैं कि निर्भरताएं क्या हैं।



ऊपर दिए गए उदाहरण में, JOIN क्वेरी कुछ तालिका है जिसमें एक निर्भरता है। क्यों? क्योंकि ओरेकल न केवल पार्स करके निर्भरता निर्धारित करता है, बल्कि कार्य योजना के परिणामों के अनुसार इसे लागू करता है।

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

ओरेकल ट्रैक नहीं करता है जिसे ट्रैक करने की आवश्यकता नहीं है ।

पीएल / एसक्यूएल में, निर्भरता रन-टाइम पर चलती है ताकि आप गतिशील एसक्यूएल का उपयोग कर सकें और अन्य काम कर सकें।



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



और अंत में, डेटाबेस में भी एनकैप्सुलेशन होता है , हालांकि कोई भी इस पर विश्वास नहीं करता है। हम एक दृश्य लेते हैं, इसमें result_cache डालते हैं और हमारे प्रोग्रामर को यह एहसास भी नहीं होता है कि यह कैश्ड है। नीचे हम देखते हैं कि वास्तव में इसका एक हिस्सा ही काम करता है।

रद्द करना

तो, देखते हैं कि ओरेकल जब result_cache को अमान्य करता है। प्रकाशित स्थिति कैश वैधता की वर्तमान स्थिति दिखाती है। जब मैंने कहा कि result_cache करने का अनुरोध किया है, तो डेटाबेस में कोई काम नहीं है



जब हमने अपडेट किया था, तब भी स्थिति प्रकाशित की गई है, क्योंकि अपडेट नहीं किया गया है और अन्य सत्रों को पुराने result_cache को देखना चाहिए। यह कुख्यात पढ़ने की निरंतरता है।

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



यह प्रतीत होता है - एक सपना! निर्भरता को सही माना जाता है - केवल अनुरोध के आधार पर। लेकिन नहीं, कई बारीकियों का खुलासा किया गया। ऑरेकल विकलांग पैदा करता है और कई सारे मामले सामने आते हैं :

1. अद्यतन कॉल के लिए किसी भी चयन के साथ, निर्भरताएं उड़ जाती हैं।
2. यदि तालिका में गैर-अनुक्रमित विदेशी कुंजियाँ हैं, और तालिका में परिणाम result_cache पर एक अद्यतन होता है, जो कुछ भी प्रभावित नहीं करता है, लेकिन मूल तालिका में कुछ बदल गया है, तो कैश भी अमान्य हो जाएगा।
3. यह सबसे दिलचस्प बात है जो जीवन को जितना संभव हो उतना खराब कर देती है - यदि परिणाम के रूप में चिह्नित तालिका पर कुछ असफल अद्यतन है, तो कुछ भी काम नहीं किया गया, लेकिन फिर उसी लेनदेन में किसी भी अन्य परिवर्तन को लागू किया गया जो किसी भी तरह पहले तालिका को प्रभावित करता है, फिर भी result_cache रीसेट हो जाएगा।

अभी भी result_cache के बारे में ऐसी एक एंटीपैटर्न है, जब डेवलपर्स, सुना है कि ऐसी एक शांत चीज है, तो सोचो: "ओह, भंडारण है! अब हम कुछ अनुरोध करेंगे जो 2-3 विभाजन पर काम करते हैं - वर्तमान तिथि और पिछले एक पर, इसे result_cache के रूप में चिह्नित करें, और इसे हमेशा मेमोरी से लिया जाएगा! "

लेकिन जब आप पितृसत्ता को परिवर्तन में बदलते हैं, तो पूरा कैश उड़ जाता है, क्योंकि वास्तव में result_cache में निर्भरता ट्रैकिंग की इकाई हमेशा एक तालिका होती है, और मुझे नहीं पता है कि क्या कभी विभाजन होगा या नहीं।

हमने सोचा और फैसला किया कि हम ऐसी चीजों के साथ एक सिफारिश प्रणाली के उत्पादन में जाएंगे:

• हम अपनी सभी तालिकाओं को कैश नहीं करेंगे, हम केवल आवश्यक सामान ही लेंगे।
  
• लंबे समय से चल रहे क्वेरी के लिए result_cache सेट करें।
  

हमने सब कुछ जांचा, प्रदर्शन परीक्षण किए, प्रसंस्करण समय - 30 एस । सब कुछ बहुत अच्छा है, उत्पादन पर जाएं!

धराशायी हो गया - सो गया। हम सुबह पहुंचते हैं। हम एक पत्र देखते हैं: "मान्यता में कम से कम 20 मिनट लगते हैं, सत्र फ्रीज हो जाता है।" वे ठंड क्यों हैं? 30 सेकंड 20 मिनट में कैसे बदल गए ?

वे समझने लगे, डेटाबेस को देखो:

• सक्रिय सत्र - 400;
• मान्यता के लिए एक दस्तावेज़ में औसतन लाइनें - 500;
• कॉलम न्यूनतम - 5-8;
• डेटाबेस में सत्रों की संख्या हमेशा 3 से गुणा किए गए उपयोगकर्ता अनुप्रयोगों की संख्या के बराबर होती है! और result_cache को बार-बार एक्सेस करना पसंद नहीं है।

आंतरिक जांच करने के बाद, हमें पता चला कि जावा डेवलपर्स 3 थ्रेड्स में मान्यता प्राप्त करते हैं।

हम परेशान थे - एक 5 गुना लोड, ड्रॉप, गिरावट, और यहां तक ​​कि ऐसे मापदंडों के साथ ऐसा सबसेंक्शन नहीं होना चाहिए था।

जाहिर है, आपको समझने की जरूरत है।

निगरानी

निगरानी के लिए, हमारे पास दो प्रमुख बातें हैं:

1. V $ RESULT_CACHE_OBJECTS - सभी वस्तुओं की एक सूची;
2. V $ RESULT_CACHE_STATISTICS - संपूर्ण के रूप में result_cache के समग्र आंकड़े।

MEMORY_REPORT एक विषय पर विविधताएं हैं, हमें उनकी आवश्यकता नहीं होगी।

ओरेकल जादुई है! महान प्रलेखन है, लेकिन यह उन लोगों के लिए डिज़ाइन किया गया है जो अन्य डेटाबेस से स्विच करते हैं ताकि वे पढ़ें और सोचें कि ओरेकल बहुत अच्छा है! लेकिन result_cache पर सभी जानकारी केवल समर्थन के साथ निहित है ।



एक अति सूक्ष्म अंतर है जो इस तथ्य में शामिल है कि जैसे ही हम समस्या को हल करने के लिए इन वस्तुओं की ओर मुड़ते हैं, हम अंत में खुद को दफन करके इसे समाप्त कर देते हैं! Oracle12.2 तक, पिछले साल अक्टूबर में जिस पैच को जारी किया गया था, उससे पहले ये अनुरोध स्थिति के लिए result_cache को अप्राप्य बनाते हैं और पूरी तरह से गिने जाने तक लिखने के लिए।



इसलिए, v $ result_cache_objects व्यू का उपयोग करते हुए, हमें पता चला कि कैश्ड ऑब्जेक्ट्स की सूची में हजारों प्रविष्टियाँ हैं - जितना हम उम्मीद करते हैं, उससे कहीं अधिक। इसके अलावा, ये अजीब तालिकाओं पर हमारे कुछ प्रश्नों के ऑब्जेक्ट थे - छोटी गोलियां, और last_modified_date क्वेरी। जाहिर है, किसी ने हमारे आधार पर ईटीएल निर्धारित किया है ।

ETL डेवलपर्स की कसम खाने से पहले, हमने जाँच की कि result_cache बल विकल्प इन तालिकाओं के लिए सक्षम था, और याद रखें कि हमने इसे स्वयं चालू कर दिया था, क्योंकि इस डेटा में से कुछ को अक्सर एप्लिकेशन द्वारा आवश्यक था और कैशिंग उपयुक्त था।



लेकिन यह पता चला कि ये सभी अनुरोध सिर्फ हमारे कैश को लेते हैं और धोते हैं । सौभाग्य से, डेवलपर्स के पास उत्पादन में ETL को प्रभावित करने का अवसर था, इसलिए हम इन मिनट अनुरोधों को बाहर करने के लिए result_cache को बदलने में सक्षम थे।

क्या आपको लगता है कि यह आसान है? - बेहतर नहीं लग रहा है! कैश्ड ऑब्जेक्ट्स की संख्या कम हो गई, और फिर 12,000 तक फिर से बढ़ गया। हमने अध्ययन करना जारी रखा कि और क्या कैश किया गया था, क्योंकि गति में बदलाव नहीं हुआ।



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

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

लैच

Result_cache और DS SVC के बीच की प्रतिस्पर्धा इस तथ्य के कारण है कि ओरेकल के पास लैच है - हल्के छोटे ताले।



वे कैसे काम करते हैं, इसके बारे में विवरण में जाने के बिना, हम कई बार नामांकित कुंडी लगाने की कोशिश करते हैं - यह काम नहीं करता है - Oracle उठाता है और सो जाता है

जो कोई भी विषय में है, वह कह सकता है कि result_cache में, प्रत्येक ब्लॉक पर दो लेच लाए जाते हैं, जिनमें से एक है। ये विवरण हैं। Result_cache में दो तरह की कुंडी हैं:

1. जब हम result_cache में डेटा लिखते हैं, उस अवधि के लिए लैच करें।



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

2. दूसरे प्रकार के ताले - result_cache से भी प्राप्त करने के लिए पहली पंक्ति से अंतिम तक।
लेकिन चूंकि तात्कालिक स्मृति से भ्रूण आता है, उन्हें बहुत जल्दी हटा दिया जाता है।



यह ध्यान रखें कि जब डीबीए डेटाबेस में लैचेज़ देखता है, तो यह कहना शुरू कर देता है: “लैचेस! प्रतीक्षा समय - सब कुछ चला गया है! »और यहां सबसे दिलचस्प खेल शुरू होता है: डीबीए को विश्वास दिलाता हूं कि कुंडी से प्रतीक्षा समय वास्तव में क्वेरी रिट्री टाइम की तुलना में अतुलनीय रूप से कम है ।



जैसा कि हमारे अनुभव से पता चलता है, हमारे माप, परिणाम पर latches हैं अनुरोधों का 10% स्वयं पर कब्जा कर लेता है ।



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



support 2 , , result_cache . .

, . , , , workload 5 . , , .

?

: . , .



4 :

• RESULT_CACHE_MAX_SIZE;
  
• RESULT_CACHE_MAX_RESULT;
  
• RESULT_CACHE_MODE;
  
• _RESULT_CACHE_MAX_TIMEOUT.
  

— . , 100 512, 6 .

, - . , Invalidation Count = 10000.

, . , job , . , . job , , .



, invalid , . 40 .

, . , , Oracle. !



SHELFLIVE — , read-consistent , 10 , . . , , .

— SNAPSHOT . , , read-consistent — .

:

1. — SYS.
2. . , , Oracle , , . , Oracle , , 12.2 . , external - support, .
3. sql pl/sql : current_date, current_time . , current_time, .
4. .
5. , CLOB, BLOB .

Result cache inside Oracle

Result_cache — Oracle Core. , , job result_cache (, hint, ) , APEX.



, Dynamic sampling , , , result_cache.

Oracle internals for result cache

result_cache:

1. (storage) ;
   
2. result_cache;
   
3. result_cache shared pool.
   

:

• .
  
• read-consistent.
• Result_cache, , .

:

• .
  
• , .
  

!

, . support Oracle, , 29 2017 .: Oracle E-Business suite result_cache, .



, , . support , , .



:

1. - ;
   
2. , , , , v$result_cache_memory dbms_result_cache.memory_report, .
   

, , , v_result_cache_objects .

, support note — support , .

, , : - . , , :

1. hint result_cache;
2. hint no result_cache;
3. black_list, , , -.

?

• , - , , ;
• , , . , - , , .

, — . Oracle , .

Client side result cache

उनके डिवाइस का आरेख ऊपर दिखाया गया है, ये डेटाबेस और ड्राइवर के मुख्य घटक हैं।

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

एक दिलचस्प सवाल यह है कि विकलांगता कैसे होती है?

अमान्यकरण के दो तरीके हैं, जिन्हें पैरामीटर अमान्य अमान्य अंतराल द्वारा तेज किया जाता है। यह ओरेकल चालक कैश को गैर-सुसंगत बनाने की अनुमति देता है।

पहले मोड का उपयोग तब किया जाता है जब अनुरोध बार-बार जाते हैं और अमान्य लैग नहीं होता है। इस स्थिति में, स्ट्रीम डेटाबेस में जाएगी, कैश को अपडेट करेगी और उससे डेटा पढ़ेगी।



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

दूसरे मामले में, यदि अमान्य लैग से अधिक समय बीत चुका है, तो क्लाइंट result_cache स्वयं डेटाबेस में जाता है और कहता है: "मुझे परिवर्तनों की सूची दें!" अर्थात्, वह स्वयं अपनी पर्याप्त अवस्था को बनाए रखता है।

क्लाइंट-साइड परिणाम कैश को कॉन्फ़िगर करना बहुत सरल है । 2 विकल्प हैं:

1. CLIENT_RESULT_CACHE_LAG - कैश लैग मान;
2. CLIENT_RESULT_CACHE_SIZE - आकार (न्यूनतम 32 Kb, अधिकतम - 2 GB)।

एप्लिकेशन डेवलपर की दृष्टि से, क्लाइंट कैश सर्वर कैश से बहुत अलग नहीं है, उन्होंने संकेत result_cache भी दर्ज किया है। यदि यह था, तो यह केवल क्लाइंट द्वारा - नेट पर और जावा पर - दोनों का उपयोग करना शुरू कर देगा।



क्वेरी के 10 पुनरावृत्तियों को करने के बाद, मुझे निम्नलिखित मिला।



पहली अपील सृजन है, फिर 9 कैश एक्सेस। तालिका इंगित करती है कि मेमोरी को ब्लॉकों में भी आवंटित किया गया है। SELECT पर भी ध्यान दें - यह बहुत सहज नहीं है। ईमानदार होने के लिए, इससे पहले कि मैंने इससे निपटना शुरू कर दिया, मुझे यह भी नहीं पता था कि GV$SESSION_CONNECT_INFO का ऐसा प्रतिनिधित्व था। ओरेकल इसे सीधे इस तालिका में क्यों नहीं ले गया (और यह एक तालिका है, एक दृश्य नहीं है), मैं समझ नहीं सका। लेकिन यही कारण है कि मेरा मानना ​​है कि यह कार्यक्षमता बहुत लोकप्रिय नहीं है, हालांकि, जैसा कि मुझे लगता है, यह बहुत उपयोगी है।

ग्राहक कैशिंग के लाभ:

• सस्ती ग्राहक स्मृति;
• कोई भी ड्राइवर उपलब्ध - JDBC, .NET, आदि;
• आवेदन कोड में न्यूनतम प्रभाव।
• सीपीयू, आई / ओ और आम तौर पर डेटाबेस पर लोड को कम करना;
• सभी प्रकार की स्मार्ट कैशिंग परतों और एपीआई को सीखने और उपयोग करने की आवश्यकता नहीं है;
• कोई कुंडी नहीं।

नुकसान:

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

समर्थन पर, जो हम हमेशा result_cache के साथ काम करते समय उपयोग करते हैं, मुझे केवल 5 बग मिले। यह सुझाव देता है कि, सबसे अधिक संभावना है, कुछ लोगों को इसकी आवश्यकता होती है।

इसलिए, हम उपरोक्त सभी को एक साथ लाते हैं।

हाथ से बनाया हुआ कैश

खराब परिदृश्य:

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

अच्छे परिदृश्य:

• एक मजबूत डेटाबेस डेवलपमेंट टीम है।
• कार्यान्वित PL / SQL तर्क।
• ऐसी सीमाएँ हैं जो अन्य कैशिंग तकनीकों का उपयोग करने से रोकती हैं।

सर्वर साइड परिणाम कैश

खराब परिदृश्य:

• बहुत सारे अलग-अलग परिणाम जो पूरे कैश को धोते हैं;
• अनुरोध _RESULT_CACHE_TIMEOUT से अधिक समय लेते हैं या यह पैरामीटर गलत तरीके से कॉन्फ़िगर किया गया है।
• बहुत बड़े सत्रों के परिणाम समानांतर धागे में कैश में लोड किए जाते हैं।

अच्छे परिदृश्य:

• कैश्ड परिणामों की उचित मात्रा।
• अपेक्षाकृत छोटे डेटा सेट (200-300 पंक्तियाँ)।
• महंगी एसक्यूएल, अन्यथा सभी समय के लिए कुंडी जाएगी।
• कमोबेश स्टैटिक टेबल।
• एक डीबीए है, जो किसी चीज के मामले में आएगा और सभी को बचाएगा।

क्लाइंट साइड परिणाम कैश

खराब परिदृश्य:

• जब तत्काल विकलांगता की बहुत समस्या उत्पन्न होती है।
• पतले ड्राइवरों की आवश्यकता।
  

अच्छे परिदृश्य:

• एक सामान्य मध्य परत विकास टीम है।
• बाहरी कैशिंग परत का उपयोग किए बिना बहुत सी एसक्यूएल पहले से ही उपयोग में है जिसे आसानी से जोड़ा जा सकता है।
• ग्रंथियों पर प्रतिबंध हैं।

निष्कर्ष

मेरा मानना ​​है कि मेरी कहानी सर्वर साइड परिणाम कैश दर्द के बारे में है, इसलिए निष्कर्ष निम्नानुसार हैं:

1. हमेशा स्मृति आकार का मूल्यांकन सही ढंग से प्रश्नों की संख्या को ध्यान में रखते हुए करें, न कि परिणामों की संख्या, यानी: ब्लॉक, अपेक्स, नौकरी, अनुकूली आँकड़े इत्यादि।
2. स्वचालित कैश फ्लशिंग विकल्पों (स्नैपशॉट + शेल्फ लाइफ) का उपयोग करने से डरो मत।
3. बड़ी मात्रा में डेटा लोड करते समय अनुरोधों के साथ कैश को अधिभारित न करें, इससे पहले result_cache को अक्षम करें। कैश को गर्म करें।
4. सुनिश्चित करें कि _result_cache_timeout आपकी अपेक्षाओं को पूरा करता है।
5. पूरे डेटाबेस के लिए FORCE का उपयोग न करें। मेमोरी में एक डेटाबेस की आवश्यकता होती है - एक विशेष इन-मेमोरी समाधान का उपयोग करें।
6. जांचें कि क्या FORCE विकल्प का उपयोग व्यक्तिगत तालिकाओं के लिए उचित रूप से किया जाता है ताकि यह तीसरे पक्ष के ETL के साथ काम न करे।
7. तय करें कि क्या अनुकूली आंकड़े Oracle (_optimizer_ads_use_result_cache = false) द्वारा वर्णित के रूप में अच्छे हैं।

हाईलोड ++ साइबेरिया अगले सोमवार, अनुसूची तैयार है और साइट पर प्रकाशित किया गया है। इस लेख के विषय में कई रिपोर्ट हैं:

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

मुझे नोवोसिबिर्स्क में मिलो!