मुझे किसी का फोन आया कि उन्हें अपने आवेदन में TNS-12519 त्रुटियां मिल रही हैं। निश्चित रूप से, वे संदेश श्रोता.लॉग फ़ाइल में भी थे।
TNS-12519: TNS:no appropriate service handler found
जो लोग इस त्रुटि से परिचित नहीं हैं, उनके लिए आमतौर पर इसका मतलब दो चीजों में से एक है। या तो सेवा का नाम श्रोता के साथ पंजीकृत नहीं है या डेटाबेस अपनी प्रक्रियाओं की अधिकतम संख्या तक पहुंच गया है। उत्तरार्द्ध के लिए, क्या होता है कि श्रोता जानता है कि डेटाबेस किसी भी नई प्रक्रिया को स्वीकार नहीं कर सकता है, इसलिए यह बोलने के लिए सेवा का नाम आउट-ऑफ-सर्विस लेता है। एक त्वरित "lsnrctl स्थिति" मुझे दिखाती है कि सेवा का नाम सही ढंग से पंजीकृत है। तो यह बाद वाला होना चाहिए। फिर मैं निम्नलिखित प्रश्न जारी करता हूं और अपने संदेह की पुष्टि करता हूं।
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 299 300
यकीन है कि पर्याप्त। मैं अधिकतम प्रक्रियाओं तक पहुँच गया हूँ, जो मेरे SPFILE में 300 के रूप में परिभाषित है। मैंने पैरामीटर को बढ़ाकर 600 कर दिया और इंस्टेंस को बाउंस कर दिया। हमने दो बार प्रक्रियाओं की संख्या के साथ त्रुटि को फिर से मारा। मुझे स्पष्ट रूप से इस पर और गहराई से विचार करने की आवश्यकता है।
कुछ पृष्ठभूमि के लिए, और कुछ के लिए जो बाद में महत्वपूर्ण होगा, यह जानना महत्वपूर्ण है कि यह डेटाबेस हमारे स्वचालित परीक्षण प्रयासों का समर्थन करता है। हमारे पास एक परीक्षण दोहन है जो हमारे प्राथमिक उत्पादन अनुप्रयोग का प्रयोग करता है। यह परीक्षण सूट एप्लिकेशन लॉन्च करता है, डेटाबेस से जुड़ता है, कुछ बटन दबाता है और कुछ मेनू आइटम का चयन करता है और फिर डिस्कनेक्ट हो जाता है।
कनेक्शन अनुरोध कहां से आ रहे थे यह देखने के लिए मैंने श्रोता.लॉग फ़ाइल की जांच की। ये अनुरोध एक दुष्ट एप्लिकेशन सर्वर से आ रहे थे, हमारे परीक्षण सूट से नहीं। मुझे पता था कि कुछ गड़बड़ है क्योंकि हमने अभी तक परीक्षण सूट शुरू नहीं किया था और हमें त्रुटियां मिल रही थीं। हमने एप्लिकेशन सर्वर को ठीक कर दिया है और मैंने त्रुटियों को वापस नहीं देखा। हमने फिर परीक्षण सूट को निकाल दिया और कुछ समय बाद, TNS-12519 त्रुटियां वापस आ गईं। हम्म्...मैंने सोचा कि मुझे अपराधी मिल गया है। लेकिन आइए हमारी प्रक्रिया उपयोग की जांच करें।
SQL> select resource_name,current_utilization,max_utilization 2 from v$resource_limit where resource_name='processes';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION --------------- ------------------- --------------- processes 89 157
इसलिए मैं वर्तमान में 157 के अधिकतम उपयोग के साथ 89 प्रक्रियाओं को देख रहा हूं। मैं 600 की अपनी नई सीमा के आसपास कहीं नहीं हूं। तो क्या देता है? मुझे यह पता लगाने में थोड़ा समय लगा कि मामला क्या है। सेवा का नाम सही ढंग से पंजीकृत है और मैं अपनी सीमा के आसपास कहीं नहीं हूं। एमओएस नोट 552765.1 इस बारे में बात करता है कि श्रोता टीएनएस-12519 त्रुटि पर कैसे पहुंचता है। पहले, मैं सबसे आम कारण देख रहा था। अधिकतम प्रक्रियाओं तक पहुँच गया था। लेकिन इस बार नहीं तो क्या देता है?
छानबीन के बाद, मुझे श्रोता के लॉग में मेरा उत्तर मिला। लेकिन यह किसी बड़े त्रुटि संदेश की तरह स्पष्ट नहीं था। TNS-12519 त्रुटि की पहली घटना सुबह 9:38 बजे हुई थी। मैंने श्रोता लॉग में "service_update" के लिए grep'ed किया और इन प्रविष्टियों को देखा।
25-JUN-2015 09:17:08 * service_update * orcl * 0 25-JUN-2015 09:17:26 * service_update * orcl * 0 25-JUN-2015 09:17:29 * service_update * orcl * 0 25-JUN-2015 09:17:44 * service_update * orcl * 0 25-JUN-2015 09:17:50 * service_update * orcl * 0 25-JUN-2015 09:17:53 * service_update * orcl * 0 25-JUN-2015 09:18:56 * service_update * orcl * 0 25-JUN-2015 09:18:59 * service_update * orcl * 0 25-JUN-2015 09:19:50 * service_update * orcl * 0 25-JUN-2015 09:20:11 * service_update * orcl * 0 25-JUN-2015 09:21:27 * service_update * orcl * 0 25-JUN-2015 09:22:09 * service_update * orcl * 0 25-JUN-2015 09:24:05 * service_update * orcl * 0 25-JUN-2015 09:27:53 * service_update * orcl * 0 25-JUN-2015 09:29:32 * service_update * orcl * 0 25-JUN-2015 09:34:07 * service_update * orcl * 0 25-JUN-2015 09:41:45 * service_update * orcl * 0
ध्यान दें कि यह सेवा अद्यतन नियमित रूप से 9:17 और 9:18 पर होता है, लेकिन सेवा अद्यतनों के बीच का समय अधिक और अधिक समय लेता है। ध्यान दें कि सेवा अपडेट के अंत में (9:34 से 9:41) 8 मिनट 38 सेकंड का समय था। यह महत्वपूर्ण क्यों है?
यह एक Oracle 11.2.0.4 डेटाबेस है। 11.2 और इससे पहले के लिए, PMON प्रक्रियाओं के बाद सफाई और श्रोता को जानकारी देने के लिए जिम्मेदार है। डेटाबेस स्टार्टअप पर, PMON श्रोता के साथ सेवाओं को पंजीकृत करने का प्रयास करता है। पीएमओएन एक और काम करता है जो श्रोता को बताता है कि कितनी अधिकतम प्रक्रियाओं को सेवित किया जा सकता है। इस मामले में, PMON श्रोता को बताता है कि इसमें अधिकतम 600 प्रक्रियाएं हो सकती हैं। PMON और भी करता है, लेकिन इस चर्चा के लिए, इतना ही काफी है।
जानने के लिए एक महत्वपूर्ण टुकड़ा यह है कि श्रोता कभी नहीं जानता कि वर्तमान में कितनी प्रक्रियाएं जुड़ी हुई हैं। यह केवल जानता है कि कितने कनेक्शन अनुरोधों ने ब्रोकर की मदद की है। श्रोता कभी नहीं जानता कि प्रक्रिया डेटाबेस से डिस्कनेक्ट हो जाती है या नहीं। ऊपर दिया गया service_update वह स्थान है जहां PMON श्रोता को बता रहा है कि वास्तव में कितनी प्रक्रियाओं का उपयोग किया जा रहा है। तो 9:34:07 पर, PMON सर्विस अपडेट श्रोता को बताता है कि उपयोग में 145 प्रक्रियाएं हैं। श्रोता अब अप-टू-डेट है। जब कोई नया कनेक्शन अनुरोध आता है, तो श्रोता इसे 146 प्रक्रियाओं तक बढ़ा देता है। सेवा अद्यतनों के बीच, श्रोता पूरी तरह से अनजान है कि सामान्य या असामान्य रूप से 1 या अधिक प्रक्रियाओं को समाप्त कर दिया गया हो सकता है। यह अगली सेवा अपडेट होने तक प्रक्रियाओं की संख्या में वृद्धि करता रहता है, जब श्रोता को इस बात का सटीक लेखा-जोखा मिल जाता है कि कितनी प्रक्रियाएं उत्पन्न हुई हैं।
इसलिए हमारे पास सर्विस अपडेट के बीच 8.5 मिनट का अंतर है। श्रोता के पास वापस आने में PMON को इतना समय क्यों लगा? वैसे इसके लिए सुराग श्रोता में भी है। लॉग भी। मैंने 9:34 सर्विस_अपडेट से पहले और 9:41 सर्विस अपडेट के बाद लॉग से सब कुछ छीन लिया। वहां से, जो कुछ बचा है उसमें "(CONNECT_DATA=" के लिए grep करना और लाइनों की गिनती प्राप्त करने के लिए "wc -l" पर पाइप करना आसान था।
इस 8.5 मिनट के अंतराल के दौरान, मेरे पास 450 से अधिक नए कनेक्शन अनुरोध थे! फिर भी उन नए कनेक्शनों में से अधिकांश को समाप्त कर दिया गया जैसा कि V$RESOURCE_LIMIT ने दिखाया कि मेरे पास अधिकतम 150 थे। PMON अपने डेटाबेस कनेक्शन से बाहर निकलने वाले एप्लिकेशन के लिए सफाई में इतना व्यस्त था कि श्रोता को अपडेट करने से पहले इसमें एक बड़ा अंतराल था। जहां तक श्रोता का संबंध था, 150 वर्तमान कनेक्शन और 450 नए कनेक्शन का मतलब था कि यह 600 की अपनी सीमा तक पहुंच गया।
PMON को अपने अगले सर्विस अपडेट के साथ श्रोता तक पहुंचने में 10 मिनट तक का समय लग सकता है। सत्र से बाहर निकलने के बाद सफाई करना श्रोता के लिए सेवा अद्यतन की तुलना में उच्च प्राथमिकता है। 10 मिनट के निशान पर, PMON सेवा अद्यतन को सर्वोच्च प्राथमिकता देता है यदि सेवा अद्यतन उस समय अंतराल में पहले नहीं किया गया था।
याद रखें कि यह स्वचालित परीक्षण का समर्थन करने वाला डेटाबेस है। हमें कई कनेक्ट/डिस्कनेक्ट ऑपरेशनों के साथ रहना होगा क्योंकि हमारे पास एक स्वचालित रोबोट है जो हमारे एप्लिकेशन को रैपिड-फायर फैशन में परीक्षण कर रहा है। हम यह नहीं बदलना चाहते कि एप्लिकेशन कैसे काम करता है क्योंकि यह एक उपयोगकर्ता द्वारा चलाए जाने पर बहुत अच्छा काम करता है। हमारा स्वचालित परीक्षण सूट एप्लिकेशन को अलग-अलग तरीके से निष्पादित कर रहा है जो इसे करने के लिए डिज़ाइन किया गया था। लेकिन हम कोड में बदलाव से उत्पादन प्रभावित होने से पहले संभावित रूप से बग को बेनकाब करने के लिए इसके लिखित रूप में आवेदन का प्रयोग करना चाहते हैं।
अभी के लिए, मैंने PROCESSES पैरामीटर को उस मान तक बढ़ा दिया है, जिस तक हम कभी नहीं पहुंचेंगे। यह सब इसलिए कि श्रोता अपने आंतरिक काउंटर में सीमा को नहीं मार सकता। जितनी अधिक प्रक्रियाएँ, उतनी ही अधिक मेमोरी को SGA में उस उच्च संख्या का समर्थन करने की आवश्यकता होती है। लेकिन यह डेटाबेस इसे संभाल सकता है।
अगर किसी को 5 मिनट की विंडो में सर्विस अपडेट प्राप्त करने का तरीका पता है, तो कृपया मुझे बताएं। इस व्यवहार को नियंत्रित करने के लिए कोई प्रलेखित पैरामीटर नहीं हैं और मैं एक गैर-दस्तावेजी पैरामीटर भी नहीं ढूंढ पा रहा हूं।
अंत में, यह समस्या मेरे 11.2.0.4 डेटाबेस में से एक में है। Oracle 12c आर्किटेक्चर को थोड़ा बदल देता है। नई श्रोता पंजीकरण (LREG) पृष्ठभूमि प्रक्रिया उस कार्य को संभालती है जो PMON करता था। मेरे पास अभी तक परीक्षण करने के लिए एक प्रणाली नहीं है, लेकिन मैं शर्त लगाता हूं कि LREG में 12c में वही मुद्दा नहीं होगा जो PMON यहां 11g में प्रदर्शित कर रहा है क्योंकि LREG को सफाई कर्तव्यों को संभालना नहीं होगा जो PMON करता है। एमओएस नोट 1592184.1 दिखाता है कि एलआरईजी सेवा अद्यतन करेगा।
अद्यतन:चूंकि मैंने यह लेख लिखा है, इसलिए मुझे इसकी नई LREG प्रक्रिया के साथ डेटाबेस को 12c में अपग्रेड करने का मौका मिला है। LREG के साथ श्रोता की सेवा अद्यतनों को संभालने के साथ, हमने देखा कि समस्या गायब हो गई है। भारी सत्र गतिविधि के समय भी, विशेष रूप से कनेक्टिंग और डिस्कनेक्टिंग के दौरान, LREG ने नियमित सेवा अपडेट किए जो PMON अक्सर प्रदर्शन करने में सक्षम नहीं होते।
