सभी को नमस्कार! मेरा नाम ल्यूडमिला है, मैं लोड परीक्षण में व्यस्त हूं, मैं साझा करना चाहता हूं कि हमने अपने ग्राहकों में से एक के साथ ओरेकल डीबीएमएस के लिए डेटाबेस से लोड परीक्षण प्रणाली के प्रतिगमन प्रोफाइल के तुलनात्मक विश्लेषण का स्वचालन कैसे किया।

लेख का उद्देश्य डेटाबेस प्रदर्शन की तुलना करने के लिए एक "नया" दृष्टिकोण की खोज करना नहीं है, बल्कि परिणामों की तुलना को स्वचालित करने के लिए हमारे अनुभव और प्रयास का वर्णन करना है
डीबीए ओरेकल को कॉल की संख्या कम करें।



किसी भी डेटाबेस के भार परीक्षण का भार उठाते हुए, हम मुख्य रूप से इसमें रुचि रखते हैं:

• नई विधानसभा स्थापित करने के बाद क्या कुछ टूट गया?
  
• परीक्षण के दौरान डेटाबेस की गतिशीलता।
  

AWR रिपोर्ट की तुलना अकेले आपके लक्ष्यों को प्राप्त करने के लिए पर्याप्त नहीं है।
AWR डंप का केंद्रीकृत भंडारण भी अच्छा अभ्यास है। AWR डंप सभी ऐतिहासिक विचारों (dba_hist) को बनाए रखते हैं।

यह प्रथा हमारे ग्राहक द्वारा पहले ही लागू की जा चुकी है।

लोड परीक्षण के अगले सत्र के बाद, हम परिणामों की तुलना करते हैं:

• औद्योगिक डंप के साथ वर्तमान परीक्षण डंप;
  
• वर्तमान परीक्षण डंप पिछले परीक्षण डंप के साथ।
  

इसकी आवश्यकता क्यों है?

लक्ष्य अलग हैं:

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

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

बेशक, आप परीक्षण के दौरान एंटरप्राइज मैनेजर (या जीवी $ विचारों के अनुरोध के साथ) में सब कुछ ऑनलाइन देख सकते हैं: धूम्रपान, खाने और सोने के लिए मत जाओ ...



शायद आपके पास अपना स्वयं का कस्टम टूल भी है, जो आपके लिए बनाया गया है? आप टिप्पणियों में साझा कर सकते हैं। और हम अपने कार्यों के लिए जो हम उपयोग करते हैं उसे साझा करेंगे।

AWR रिपोर्ट में बहुत सी उपयोगी जानकारी है:



उदाहरण के लिए, यहाँ उपयोगी जानकारी है: क्वेरी कितना निष्पादित हो रही है, sql_id, मॉड्यूल और संक्षिप्त पाठ। यद्यपि पाठ वहाँ है, यह छोटा है और पूर्ण संस्करण SQL पाठ पैराग्राफ की पूरी सूची से लिया जा सकता है।

मंत्रालयों के लिए के रूप में: AWR रिपोर्ट में यह स्पष्ट नहीं है कि ये अनुरोध कब हुए, किस बिंदु पर अधिक थे, और किस पर कम ... आखिरकार, परीक्षण के परिणामों का विश्लेषण करने के लिए, यह समझकर कि क्या हुआ और लगभग किस क्षण महत्वपूर्ण है: समान रूप से पूरे के लिए परीक्षण या शिखर / वृद्धि जैसे कि एक अनुसूची पर। हम यहां केवल एक सीमित शीर्ष भी देखेंगे। यह ऐतिहासिक तालिकाओं को क्वेरी करके अधिक आसानी से देखा जा सकता है।



यहां आप देख सकते हैं कि परीक्षण के दौरान क्या घटनाएं हुईं। इस खंड में डेटा डीबी समय के अनुसार है।

मेरे लिए, इस खंड में निम्नलिखित जानकारी गायब है:

1. Wait_class (हाँ, आपको अनुभव के साथ याद है कि यह घटना किस प्रकार की अपेक्षाओं से संबंधित है)।
   
2. मॉड्यूल द्वारा वितरण (यदि मैं देखता हूं, उदाहरण के लिए, enq की प्रतीक्षा कर रहा है: TX - पंक्ति लॉक विवाद: जानकारी की आवश्यकता है, जिसके तहत यह मॉड्यूल हुआ)।
   
   ऐसे जॉब्स हैं जिनमें संख्याएँ होती हैं जो सिमेंटिक भाग नहीं लेती हैं, यानी आपको समान मॉड्यूल को समूह में रखने की ज़रूरत है और समूह के लिए एक उत्तर प्राप्त करना होगा, उदाहरण के लिए: मॉड्यूल_ए_1, मॉड्यूल_ए -2, मॉड्यूल_ए_3 और मॉड्यूल_1: मॉड्यूल_ बी 2, मॉड्यूल_ बी_3। यही है, दो सिमेंटिक मॉड्यूल थे, लेकिन उन सभी के अलग-अलग नाम हैं।
   
3. जिस वस्तु का हम उल्लेख कर रहे हैं (CURRENT_OBJ # - यदि, उदाहरण के लिए, एक घटना enq होती है: TX - सूचकांक विवाद, तो यह जानना अच्छा होगा कि किस सूचकांक को दोष देना है)।
   
4. Sql_id - जो इस अनुरोध के पाठ को निष्पादित करने का प्रयास करता है।
   
5. प्रति स्नैपशॉट मात्रा के वितरण पर जानकारी (जैसा कि ऊपर वर्णित है ...)।
   

दो परीक्षणों की तुलना करने के लिए, आप AWR रिपोर्ट की तुलना का उपयोग कर सकते हैं:



हुर्रे, यहाँ हमने वेट_क्लास प्रदर्शित किया है; अन्यथा मीनूएँ ऊपर वर्णित के समान हैं।

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

प्रत्येक प्रतिगमन परीक्षण के बाद, ऐतिहासिक तालिकाओं में परिणामों की तुलना डेटाबेस से करना आवश्यक था, AWR रिपोर्ट देखें, समस्याग्रस्त अपेक्षा को स्थानीय करें (किस मॉड्यूल पर यह होता है, किस समय, किस वस्तु पर लटका हुआ है), ताकि परिणामस्वरूप सही विकास टीम के लिए बग उत्पन्न हो सके।

ग्राहक का डेटाबेस 190 टीबी तक पहुंच गया है, सिस्टम में बड़ी संख्या में अनुरोध संसाधित होते हैं: समानांतर मॉड्यूल की संख्या 16237 है।

और फिर मेरे पास एक विचार था कि एडब्ल्यूआर डंप की तुलना करने की प्रक्रिया को कैसे सरल बनाया जाए। इस विचार के साथ, मैं फ्रेड के पास गया। साथ में, हमने एक सुविधाजनक पोर्टल बनाया।

सबसे पहले, मुझसे समस्या का विवरण इस तरह देखा गया:



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

सबसे पहले, मैं घटनाओं की तुलना में दिलचस्पी रखता था, क्योंकि किसी न किसी रूप में क्वेरी निष्पादन की गति की तुलना पहले से ही मौजूद थी। अगले चरण में मुझे प्रत्येक घटना के बारे में विस्तृत जानकारी की आवश्यकता थी: उदाहरण के लिए, यदि घटना सूचकांक विवाद है, तो आपको यह समझने की आवश्यकता है कि वास्तव में कौन सा सूचकांक लटका है।

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

सामान्य तौर पर, यहां वह है जो मैं प्राप्त करना चाहता था:

1. विभिन्न परीक्षणों (अतिरिक्त स्क्वेट्स के बिना) की घटनाओं की मात्रात्मक तुलना;
   
2. सभी संबंधित जानकारी मुझे विश्लेषण के लिए चाहिए: sql_id, क्वेरी पाठ, परीक्षण के दौरान वितरण, जो सत्र, मॉड्यूल को संदर्भित करता है;
   
3. अपने आप को देखने के लिए सुविधाजनक फिल्टर जो बदल गया;
   
4. जीयूआई जीयूआई, सब कुछ इतना रंगीन है कि यह तुरंत दिखाई देता है (आप विकास पक्ष से इच्छुक पार्टियों को स्क्रीन कर सकते हैं)
   
5. मॉड्यूल का समूहीकरण: जैसा कि पहले वर्णित है, 16237 मॉड्यूल, लेकिन, प्रदर्शन किए गए कार्यों के दृष्टिकोण से, कई बार कम।
   

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

पोर्टल के बारे में

तो, सिस्टम में AWR डंप बनाए जाते हैं, जिन्हें डेटाबेस में डाला जाता है और पोर्टल पर तुलना की जाती है।

हमने निम्नलिखित स्टैक का उपयोग किया:

1. ओरेकल डीबी - एडब्ल्यूआर डंप के भंडारण के लिए
2. अजगर 2+

पोर्टल इंटरफ़ेस इस तरह दिखता है:



पोर्टल पर आप तुलना किए गए डंप, टेस्ट टेस्ट या टेस्ट-प्रोम के प्रकार चुन सकते हैं।

प्रत्येक डंप का अपना विशिष्ट पहचानकर्ता है - DBID।

आप निम्न मापदंडों द्वारा भी फ़िल्टर कर सकते हैं:

1. उदाहरण (उदाहरण) - हमारे पास एक क्लस्टर डेटाबेस था;
2. अनुरोध (Sql_id);
3. प्रतीक्षा का प्रकार (Wait_Class);
4. घटना (घटना)।

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

मध्य में तालिका डंप की तुलना का परिणाम है। कॉलम हेडिंग तुरंत दिखाती है कि कौन सा डेटा आउटपुट हो रहा है। दो दाहिने कॉलम दो डंपों के बीच अंतर दिखाते हैं:

• स्नैपशॉट के लिए तुलनात्मक डंप की तुलना में लाल रंग में हाइलाइट किए गए ईवेंट अधिक हैं;
  
• पीला - नई घटनाएं;
  
• हरी - घटनाएँ जो पहले से ही मूल डंप में थीं।
  

यह तुरंत स्पष्ट है कि हमने कितना अच्छा परीक्षण किया है। यदि घटना बहुत बार हुई, तो सबसे अधिक संभावना है:

1. सिस्टम को अधिभारित किया;
2. या पृष्ठभूमि नौकरियों के निष्पादन के लिए स्थितियां बदल गईं और घटना अधिक बार खेलना शुरू हो गई। एक बार इस तरह से कोड में एक त्रुटि पाई गई: घटना लगातार हुई, और वांछित स्थिति शाखा पर नहीं।

यदि हमारे पास एक नई घटना है - पीला - तो यह सिस्टम में किसी प्रकार के परिवर्तन को इंगित करता है, और हमें इसके परिणामों का विश्लेषण करने की आवश्यकता है। यहां आप स्नैपशॉट द्वारा घटनाओं का वितरण देख सकते हैं और प्रतीक्षा के बारे में विस्तृत जानकारी प्रदर्शित कर सकते हैं।

एक बार एक मामला था: एक नई घटना की खोज की गई थी जो काफी दुर्लभ थी और शीर्ष घटनाओं में शामिल नहीं थी, लेकिन इसकी वजह से कार्यक्षमता में मंदी थी, जिसमें महत्वपूर्ण SLAs थे। AWR रिपोर्ट में केवल शीर्ष प्रश्नों के विश्लेषण से यह पता नहीं चल सका।

प्रत्येक अनुरोध के लिए, आप अधिक विस्तृत जानकारी प्राप्त कर सकते हैं:



प्रत्येक प्रविष्टि के लिए, आप निम्नलिखित जानकारी भी देख सकते हैं:

1. क्वेरी sql text;
   
2. मात्रात्मक अनुपात में स्नैपशॉट पर घटनाओं का वितरण, अर्थात्। किस समय में अधिक / कम घटनाएं हुईं;
   
3. जिस पर मॉड्यूल और ऑब्जेक्ट "हैंगिंग" प्रतीक्षा करते हैं।
   

ओरेकल के सिस्टम विचार परिणामों की तुलना करने में शामिल हैं:

DBA_HIST_ACTIVE_SESS_HISTORY, DBA_HIST_SEG_STAT, DBA_HIST_SNAPSHOT, DBA_HIST_SQLTEXT

+

V_DUMPS_LOADED - इसकी स्वयं की सेवा तालिका (ग्राहक द्वारा पहले ही लागू की जा चुकी है), इसमें लोड किए गए डंप की जानकारी है।

कुछ प्रश्न:

चित्रों पर घटनाओं का वितरण:

SELECT S.SNAP_ID, COUNT(*) RCOUNT FROM DBA_HIST_ACTIVE_SESS_HISTORY S, V_DUMPS_LOADED V. WHERE V.ID = :1 AND S.DBID = V.DBID AND S.INSTANCE_NUMBER = :2 AND S.SQL_ID = :3 AND S.EVENT_ID = :4 GROUP BY S.SNAP_ID ORDER BY S.SNAP_ID ASC 

मॉड्यूल द्वारा समूहीकरण (एक एकल तार्किक समूह वाले मॉड्यूल को इसमें जोड़ा जाता है), ऑब्जेक्ट को अवरुद्ध किया जा रहा है:

 SELECT MODULE, OBJECT_NAME, COUNT(*) RCOUNT (SELECT CASE (WHEN INSTR(S.MODULE, '   1')>0 THEN '  1' WHEN INSTR(S.MODULE, '   2')>0 THEN '  2' … ELSE S.MODULE END) MODULE, O.OBJECT_NAME FROM DBA_HIST_ACTIVE_SESS_HISTORY S, V_DUMPS_LOADED V, DBA_HIST_SEG_STAT O WHERE V.ID = :1 AND S.DBID = V.DBID AND S.INSTANCE_NUMBER = :2 AND S.SQL_ID = :3 AND S.EVENT_ID = :4 AND S.CURRENT_OBJ# = O. OBJ# (+) AND V. DBID = O.DBID ) GROUP BY MODULE, OBJECT_NAME ORDER BY RCOUNT DESC 

आखिर में आपको क्या मिला?

पोर्टल ने हमें AWR डंप की तुलना में समय बचाने की अनुमति दी। मैनुअल तुलना में 4-6 घंटे लगते थे, और अब हम 2-3 घंटे बिताते हैं। हमारे पास हमेशा एक दूसरे के साथ और एक औद्योगिक डंप के साथ-साथ विभिन्न परीक्षणों के परिणामों की तुलना करने का अवसर होता है, साथ ही उन फ़िल्टरों को भी सेट करना चाहिए जिनकी अभी ज़रूरत है। यही है, हम आसानी से आपस में ऐतिहासिक डेटा की तुलना कर सकते हैं, न कि केवल वर्तमान परिणाम को ऑनलाइन देख सकते हैं।

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

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

चूंकि पोर्टल एक निश्चित अवधि में एक बार ली गई छवियों का विश्लेषण करता है, इसलिए पोर्टल डेटाबेस की ऑनलाइन निगरानी से पूरी तरह से छूट नहीं लेता है, क्योंकि कुछ घटनाएं छवि में नहीं मिल सकती हैं।

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

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

परिणामस्वरूप समाधान को अभी भी अंतिम रूप दिया जा सकता है, उदाहरण के लिए:

1. अनुरोध की अवधि की तुलना करना;
   
2. क्वेरी योजनाओं की तुलना करना;
   
3. एक ही योजना के साथ अनुरोधों की तुलना करना, लेकिन विभिन्न पाठों के साथ;
   
4. परीक्षण रिपोर्ट (शब्द / एक्सल दस्तावेज़ के रूप में निष्पादन) में उतारना।
   

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

हम एक वर्ष से अधिक समय से पोर्टल का उपयोग कर रहे हैं। फ्रेड, बहुत बहुत धन्यवाद!

ल्यूडमिला मात्स्कस द्वारा पोस्ट किया गया,
जेट इन्फोसिस्टम्स