oracle real application testing solution test oracle db before moving production
हम के अंतिम भाग के लिए आए हैं Oracle डेटाबेस परीक्षण की श्रृंखला।
अब तक, हम निपटा चुके हैं Oracle डेटाबेस के परीक्षण के तरीके। इस फोकस को जारी रखते हुए हम ओरेकल रियल एप्लीकेशन टेस्टिंग के संबंध में आगे के विवरणों पर विचार करेंगे।
आज हम ओरेकल रियल एप्लीकेशन टेस्टिंग सीखेंगे - एक प्रभावी परिवर्तन आश्वासन प्रणाली जो उत्पादन के लिए पेश करने से पहले परीक्षण वातावरण में सिस्टम परिवर्तन का आकलन करती है।
यह ओरेकल द्वारा वास्तविक उत्पादन वातावरण डीबी वर्कलोड पर कब्जा करने और इसे टी पर प्रतिस्थापित करने का प्रमुख समाधान है पर्यावरण है ।
जैसा कि कई अवसरों पर कहा गया है कि हमें हमेशा यह सुनिश्चित करने की आवश्यकता है कि हम अस्थिरताओं को मिटाने के लिए डेटाबेस का परीक्षण करें और यह सुनिश्चित करने के लिए कि हम अपने उत्पादन उदाहरण में किसी भी अप्रत्याशित मुद्दे का सामना न करें।
हम वर्गीकृत कर सकते हैं ओरेकल रियल एप्लीकेशन टेस्टिंग दो व्यापक वर्गों में:
- SQL प्रदर्शन विश्लेषक
- डेटाबेस फिर से खेलना
इससे पहले कि हम आगे बढ़ते हैं, कृपया ध्यान दें कि SQL प्रदर्शन विश्लेषक और डेटाबेस रिप्ले को अतिरिक्त लाइसेंसिंग की आवश्यकता होती है यानी यह एक अतिरिक्त लागत और एक एंटरप्राइज़ संस्करण विकल्प पर उपलब्ध है।
आप क्या सीखेंगे:
SQL प्रदर्शन विश्लेषक
SQL प्रदर्शन विश्लेषक और डेटाबेस रिप्ले का उपयोग करने के लिए उपयोग किया गया GUI एंटरप्राइज़ मैनेजर है जो नीचे दिखाया गया है:
SQL प्रदर्शन विश्लेषक तक पहुँचने के लिए बस 'SQL प्रदर्शन विश्लेषक' लिंक पर क्लिक करें
(बढ़े हुए देखने के लिए चित्र पर क्लिक करें)
SQL निष्पादन विश्लेषक हमें किसी भी परिवर्तन के प्रदर्शन प्रभाव का पता लगाने में सक्षम बनाता है जिससे SQL निष्पादन और प्रदर्शन पर प्रभाव पड़ सकता है।
वे इस तरह के मामलों में बेहद उपयोगी हैं:
- डेटाबेस अपग्रेड, पैचिंग
- कॉन्फ़िगरेशन ऑपरेटिंग सिस्टम में बदलता है - सॉफ्टवेयर या हार्डवेयर
- ओरेकल ऑप्टिमाइज़र के आँकड़े बदल जाते हैं
- उपयोगकर्ता / स्कीमा परिवर्तन
यह हमेशा परीक्षण या a पर SQL प्रदर्शन विश्लेषण चलाने की सलाह दी जाती है UAT (उपयोगकर्ता अनुप्रयोग परीक्षण) उत्पादन प्रणाली के बजाय प्रणाली। चूंकि, प्रदर्शन के संदर्भ में परिवर्तन के प्रभावों का परीक्षण करते समय हम अनजाने में उत्पादन उदाहरण में चल रहे उपयोगकर्ताओं को प्रभावित कर सकते हैं। इसके अलावा, इसे एक परीक्षण पर चलाने से यह सुनिश्चित होगा कि हम उत्पादन पर वर्तमान में चल रही प्रक्रियाओं के साथ छेड़छाड़ नहीं करेंगे।
सेवा मेरे SQL प्रदर्शन विश्लेषक वर्कफ़्लो का मूल अवलोकन नीचे दिखाया गया है:
SQL प्रदर्शन विश्लेषण में निम्नलिखित चरण शामिल हैं।
चरण 1)SQL कार्यभार को कैप्चर करना
SQL कथन निर्धारित करें जो आपके उत्पादन उदाहरण से आपके SQL कार्यभार का हिस्सा होगा जिसे आप विश्लेषण करना चाहते हैं। इस कार्यभार को आदर्श रूप से उस कार्यभार का प्रतिनिधित्व करना चाहिए जो आपके उत्पादन में हो सकता है।
हम एक SQL ट्यूनिंग सेट में इन कथनों को कैप्चर करते हैं और इस SQL ट्यूनिंग सेट को SQL प्रदर्शन विश्लेषक को खिलाते हैं।
चूंकि एनालाइज़र आपके सिस्टम पर बहुत सारे संसाधनों का उपभोग करता है, हम हमेशा उन्हें टेस्ट या यूएटी सिस्टम पर चलाने की सलाह देते हैं। इसे एक परीक्षण प्रणाली पर चलाने के लिए हमें SQL ट्यूनिंग सेट को निर्यात करना होगा जिसे हमने पहले ही परीक्षण प्रणाली में उत्पादन में बनाया है।
चरण 2)SQL प्रदर्शन विश्लेषक कार्य बनाना
एनालाइज़र को चलाने के लिए, आपको सबसे पहले एक SQL परफ़ॉर्मेंस एनालाइज़र कार्य करना होगा। यह कार्य एक रिपॉजिटरी के अलावा और कुछ नहीं है जो SQL प्रदर्शन विश्लेषक द्वारा निष्पादित विश्लेषण के बारे में सभी डेटा को समेकित करता है। जैसा कि पहले संकेत दिया गया है, SQL ट्यूनिंग सेट को एनालाइज़र के लिए एक उत्तेजक के रूप में खिलाया जाता है।
यूट्यूब एमपी 3 कनवर्टर एप्लिकेशन मुफ्त डाउनलोड करने के लिए
चरण 3)SQL प्रदर्शन परीक्षण पूर्व-बदलें
SQL प्रदर्शन विश्लेषक कार्य और SQL ट्यूनिंग सेट बनाने के बाद, हमें टेस्ट सिस्टम पर बुनियादी ढांचे का निर्माण करने की आवश्यकता है।
कृपया ध्यान दें कि जब हम परीक्षण करने के लिए एक प्रणाली का उपयोग करने की योजना बनाते हैं, तो हमें यह सुनिश्चित करने की आवश्यकता है कि यह हार्डवेयर, सॉफ्टवेयर और भंडारण के मामले में उत्पादन प्रणाली के समान है ताकि हम एक समान वातावरण को दोहरा सकें।
एक बार जब परीक्षण प्रणाली उचित रूप से कॉन्फ़िगर हो जाती है, तो हम SQL प्रदर्शन विश्लेषक का उपयोग करके डेटा के पूर्व-परिवर्तन संस्करण का निर्माण कर सकते हैं।
यह एंटरप्राइज मैनेजर या एपीआई (इनबिल्ट प्रक्रियाओं) का उपयोग करके प्राप्त किया जा सकता है।
चरण 4)एसक्यूएल प्रदर्शन परीक्षण के बाद बदलें
सिस्टम में कुछ बदलाव करने के बाद टेस्ट सिस्टम पर पोस्ट-चेंज ट्रायल किया जाता है।
एक बार जब यह पूरा हो जाता है, तो हमारी तुलना करने के लिए दो SQL परीक्षण होंगे - एक पूर्व-परिवर्तन और परिवर्तन के बाद का परीक्षण।
प्री-चेंज SQL प्रदर्शन ट्रायल के समान, हम एंटरप्राइज मैनेजर या API (इन-बिल्ट प्रक्रिया) का उपयोग करके पोस्ट-चेंज SQL प्रदर्शन ट्रायल बना सकते हैं।
चरण # 5)एक रिपोर्ट तैयार करना
प्री-चेंज और पोस्ट-चेंज ट्रायल को अंजाम देने के बाद, एसक्यूएल एनालाइज़र का उपयोग करके तुलनात्मक विश्लेषण चलाकर उनमें एकत्र किए गए प्रदर्शन डेटा की तुलना की जा सकती है।
एक बार जब यह तुलना कार्य पूरा हो जाता है, तो हम SQL कथन के प्रदर्शन की पहचान करने के लिए एक रिपोर्ट तैयार कर सकते हैं जो हमारे द्वारा परीक्षण किए जाने वाले कार्यभार का हिस्सा था।
रिपोर्ट की समीक्षा करके, हम एसक्यूएल के प्रदर्शन पर निष्कर्ष निकाल सकते हैं और निष्कर्ष निकाल सकते हैं
कथन और फिर उत्पादन में सिस्टम परिवर्तन को तैनात करता है।
इसी तरह, हम विभिन्न सिस्टम परिवर्तनों के साथ विभिन्न कार्यभार का परीक्षण कर सकते हैं और सुनिश्चित कर सकते हैं कि हम उत्पादन में लागू होने से पहले उनमें से प्रत्येक का परीक्षण करें।
ऊपर दिखाए गए वर्कफ़्लो को नीचे दिखाए अनुसार चित्रमय रूप से दर्शाया जा सकता है।
डेटाबेस फिर से खेलना
एंटरप्राइज़ प्रबंधक के माध्यम से उपकरण चलाने के लिए:
(बढ़े हुए देखने के लिए चित्र पर क्लिक करें)
डेटाबेस रिप्ले एक परीक्षण प्रणाली पर आपके उत्पादन वातावरण की अनिवार्य रूप से नकल करके सिस्टम परिवर्तनों के यथार्थवादी परीक्षण की अनुमति देता है। यह उत्पादन प्रणाली पर एक वांछित कार्यभार को कैप्चर करके और SQL निष्पादन, लेनदेन, अर्क और प्रक्रियाओं जैसे मूल कार्यभार के सटीक संसाधन विशेषताओं के साथ एक परीक्षण प्रणाली पर इसे फिर से दोहराता है।
यह सुनिश्चित करने के लिए किया जाता है कि हम किसी भी परिवर्तन के सभी संभावित प्रभावों पर विचार करें, जिसमें अवांछित परिणाम जैसे उत्पाद की बग, अनुचित परिणाम या प्रदर्शन प्रतिगमन शामिल हैं।
व्यापक विश्लेषण और उत्पन्न रिपोर्टिंग भी किसी भी संभावित समस्याओं की पहचान करने में मदद करती है, जैसे कि गलत परिस्थितियों का सामना करना पड़ा और प्रदर्शन में परिवर्तन।
नतीजतन, संगठन परिवर्तन से निपटने के दौरान आश्वस्त हो सकते हैं और सिस्टम परिवर्तन की समग्र सफलता का आकलन करने में आकर्षक हो सकते हैं। जब हम उत्पादन में बदलाव को लागू करना चाहते हैं तो यह किसी भी जोखिम को काफी कम कर देगा। परिवर्तन अपरिहार्य है और यह सुनिश्चित करना है कि हम इस बदलाव के हर पहलू को सभी डिग्री से परखें और उत्पादन को अधिक मजबूत और मजबूत बनाएंगे।
डेटाबेस रिप्ले का एक बेसिक वर्कफ़्लो नीचे दिखाया गया है:
डेटाबेस रिप्ले द्वारा समर्थित परिवर्तन हैं:
- Oracle डाटाबेस अपग्रेड, सॉफ्टवेयर पैचिंग
- उपयोगकर्ता / स्कीमा, डेटाबेस उदाहरण पैरामीटर जैसे मेमोरी, I / O
- हार्डवेयर / सॉफ्टवेयर RAC (रियल एप्लीकेशन क्लस्टर) नोड्स में बदल जाता है
- ऑपरेटिंग सिस्टम परिवर्तन, ऑपरेटिंग सिस्टम पैचिंग
- सीपीयू, मेमोरी, स्टोरेज
डेटाबेस रिप्ले हमें पूर्व के संपर्क में आने से पहले एक परीक्षण प्रणाली पर एक वास्तविक उत्पादन प्रणाली के व्यावहारिक भार को फिर से दोहराकर सिस्टम में संभावित परिवर्तनों के विभिन्न प्रभावों का परीक्षण करने की अनुमति देता है। उत्पादन पर कार्यभार की निगरानी, विश्लेषण और समय की मात्रात्मक निश्चित अवधि में दर्ज की जाती है। यह डेटा समय के साथ रिकॉर्ड किया जाता है और परीक्षण प्रणालियों पर कार्यभार को फिर से भरने के लिए उपयोग किया जाता है।
यह प्रदर्शन करके, हम किसी भी परिवर्तन को लागू करने से पहले कार्यभार के निहितार्थ का सफलतापूर्वक परीक्षण कर सकते हैं जो उत्पादन पर प्रतिकूल प्रभाव डाल सकता है।
वर्कफ़्लो इस प्रकार है:
चरण 1) वर्कलोड कैप्चर
हम क्लाइंट द्वारा फाइल सिस्टम (स्टोरेज) पर 'कैप्चर फाइल्स' नामक फाइलों में किए गए सभी अनुरोधों को रिकॉर्ड करते हैं। इन फ़ाइलों में SQL, बाइंड, प्रक्रियाओं और लेनदेन की जानकारी जैसे क्लाइंट अनुरोधों के बारे में सभी महत्वपूर्ण जानकारी होती है। इन फ़ाइलों को किसी भी सिस्टम में निर्यात किया जा सकता है अगर हम उन्हें किसी अन्य सिस्टम पर फिर से खेलना चाहते हैं।
चरण 2)कार्यभार प्रीप्रोसेसिंग
'कैप्चर फ़ाइलों' में जानकारी कैप्चर करने के बाद हमें उन्हें प्रीप्रोसेस करने की आवश्यकता है। इस चरण में, हम मेटाडेटा बनाते हैं जो कार्यभार को फिर से भरने के लिए आवश्यक प्रत्येक डेटा का विवरण प्रदान करता है।
चूंकि यह कदम सिस्टम से बड़ी मात्रा में संसाधनों का उपयोग करता है, इसलिए इसे उत्पादन के अलावा किसी अन्य सिस्टम पर चलाने की सलाह दी जाती है, जहां लोड फिर से हो सकता है। यदि आपके पास परीक्षण करने के लिए कोई अन्य प्रणाली नहीं है और उन्हें उत्पादन में चलाना चाहते हैं, तो उन्हें गैर-पीक घंटों के दौरान चलाना सुनिश्चित करें ताकि उत्पादन पर चलने वाले उपयोगकर्ता और प्रक्रिया प्रभावित न हों।
चरण 3)वर्कलोड रिप्ले
अब, हम उन्हें परीक्षण प्रणाली पर फिर से चला सकते हैं। इस समय हम सभी लेन-देन, संदर्भ, प्रक्रियाओं और SQL को फिर से दोहराते हैं जो कैप्चर चरण के दौरान शुरू में कैप्चर किए गए डेटा को एकत्रित करते हैं क्योंकि हर प्रक्रिया इस संक्रमण से गुजरती है।
चरण 4)रिपोर्ट तैयार करना
प्रदर्शन विश्लेषक के समान, आप उन सभी परीक्षणों की तुलना करने के लिए रिपोर्ट तैयार और देख सकते हैं जिन्हें आपने निष्पादित किया है।
समाप्त करने के लिए, हम डेटाबेस रिप्ले का परीक्षण करते समय कुछ त्वरित सुझाव देते हैं:
- जब भी संभव हो समान टेस्ट प्रणाली का उपयोग करें
- इसके प्रभाव को समझने के लिए एक समय में एक परिवर्तन का परीक्षण करें
- डिफ़ॉल्ट रीप्ले विकल्पों से शुरुआत करना सुनिश्चित करें और फिर अपनी आवश्यकता के आधार पर यदि आवश्यक हो तो बदलाव करें।
- दूसरा रिप्ले करने से पहले, परीक्षण के सभी पहलुओं को समझना सुनिश्चित करें
- अपने परीक्षा परिणामों को सहेजना और आवश्यक किसी भी परिवर्तन / परीक्षण क्रिया को दस्तावेज़ करना सुनिश्चित करें
- सुनिश्चित करें कि परीक्षण के किसी भी रन के दौरान कोई अन्य वर्कलोड या उपयोगकर्ता सिस्टम का उपयोग नहीं कर रहे हैं
निष्कर्ष:
ओरेकल डेटाबेस और अनुप्रयोग परीक्षण के विभिन्न पहलुओं और विभिन्न तरीकों के साथ, कृपया हमेशा और जितनी बार संभव हो, परीक्षण करना सुनिश्चित करें; किसी भी परिवर्तन को लागू करने या उत्पादन में किसी भी नए मापदंडों को लागू करने से पहले आवेदन और उपयोगकर्ता के वातावरण को समझें।
अनुशंसित पाठ
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)
- डेस्कटॉप, क्लाइंट सर्वर परीक्षण और वेब परीक्षण के बीच अंतर
- Oracle डाटाबेस का परीक्षण कैसे करें
- वेब अनुप्रयोग सुरक्षा परीक्षण गाइड
- एप्लिकेशन टेस्टिंग - सॉफ्टवेयर टेस्टिंग की मूल बातों में!
- डिवाइस पर अपना एप्लिकेशन इंस्टॉल करना और ग्रहण से परीक्षण शुरू करना
- परीक्षण प्राइमर eBook डाउनलोड
- विनाशकारी परीक्षण और गैर विनाशकारी परीक्षण ट्यूटोरियल