Oracle سत्र VPN से टूट गया? keepalive परतों की जाँच करें

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

चार जाँचें तय करती हैं कि ख़ामोश सत्र बचेगा या नहीं, और वे सॉकेट से बाहर की ओर चलती हैं। इन्हें क्रम से करें, क्योंकि हर एक मानती है कि पिछली परत अपना काम कर रही है।

कौन-सा प्रवाह ख़ामोश होता है

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

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

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

कनेक्शन जो पते, पोर्ट और इंटरफ़ेस इस्तेमाल करता है, उन्हें लिख लें। जब सत्र मरता है, यही विवरण आपको सही डिवाइस से पूछने देते हैं कि उसने क्या किया, बजाय यह पूछने के कि नेटवर्क चालू था या नहीं।

क्या निष्क्रियता नीति समाप्त होती है या सीमित करती है

दो नीतियाँ एक ही लक्षण पैदा करती हैं और उलटी प्रतिक्रियाएँ माँगती हैं। निष्क्रियता का समय-सीमा ऐसी अवस्था हटाती है जिसे योग्य ट्रैफ़िक ताज़ा कर सकता था, और keepalive उसे रोक सकता है। सत्र की निरपेक्ष सीमा गतिविधि की परवाह किए बिना तय अवधि के बाद प्रवाह हटाती है, और कोई keepalive इसे नहीं बदलता।

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

यह अंतर यह भी बताता है कि ट्यूनिंग कब बंद करें। अगर नीति निरपेक्ष सीमा है, तो सही समाधान छोटी कार्य-इकाई, फिर से शुरू हो सकने वाला काम या स्वीकृत अपवाद है, और नीचे की जाँच केवल यह पुष्टि करेगी कि keepalive ने कुछ नहीं बदला।

Linux के डिफ़ॉल्ट के पीछे का सॉकेट स्विच

keepalive हर सॉकेट के लिए वैकल्पिक है। कर्नेल के डिफ़ॉल्ट बताते हैं कि सॉकेट के तंत्र सक्रिय करने के बाद प्रोब कैसे व्यवहार करते हैं, और वे मौजूदा कनेक्शनों के लिए इसे सक्रिय नहीं करते। जो एप्लिकेशन कभी इसकी माँग नहीं करता उसे कोई प्रोब नहीं मिलता, चाहे sysctl मान कुछ भी कहें।

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

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

EXPIRE_TIME डेटाबेस सेटिंग है, नेटवर्क सुधार नहीं

Oracle Net अपना जीवंतता तंत्र देता है, जो प्रक्रिया के प्रभावी प्रोफ़ाइल में कॉन्फ़िगर होता है, न कि किसी मनमानी फ़ाइल में जिसका संयोग से मिलता-जुलता नाम हो। मान मिनटों में व्यक्त होता है।

SQLNET.EXPIRE_TIME = 5

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

ऊपर दिया गया उदाहरण मान किसी अनुमानित अवधि के विरुद्ध समन्वित चयन है, सिफ़ारिश नहीं। प्रलेखित सामान्य मार्गदर्शन लंबा अंतराल है, और सही संख्या स्थापित कार्यान्वयन, स्वीकार्य प्रोब लागत और रास्ते के वास्तविक ताज़ा करने के नियमों पर निर्भर है। सेटिंग को उस प्रोफ़ाइल में रखें जिसे संबंधित प्रक्रिया पढ़ती है, और पुष्टि करें कि प्रक्रिया ने उसे ले लिया। Oracle प्रोफ़ाइल के स्थान और पहचान व्यवहार को अपने पैरामीटर संदर्भ में प्रलेखित करता है।

ख़ामोश अंतराल जाँचें, फिर रिकवरी की योजना बनाएँ

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

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

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

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