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 कोणतेही शेड्युलर नाही।