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 कुनै शेड्युलर होइन।