VPN-এ Oracle সেশন হারিয়ে গেছে? keepalive স্তরগুলো দেখুন
ডেটাবেসে নিরব কাজ একটি নিষ্ক্রিয় নেটওয়ার্ক প্রবাহকে ছাড়িয়ে টিকতে পারে। সকেট সুইচ, কার্নেলের ডিফল্ট মান এবং Oracle Net সেটিং সঠিক ক্রমে দেখুন।
পঁচিশ মিনিটের উপকারী ডেটাবেস কাজ প্রায় কোনো আউটপুট দেয় না, এবং পথের প্রতিটি ডিভাইস থেকে সেই প্রবাহ নিষ্ক্রিয় দেখায়। নিষ্ক্রিয় অবস্থাই ঠিক যা সংগ্রহ করা হয়। পরের প্রতিবেদন সবসময় একই আকারের: কুয়েরি চলছিল, তারপর সেশন হারিয়ে গেল, এবং ফলাফল কখনো এল না।
চারটি যাচাই ঠিক করে নিরব সেশন টিকবে কি না, এবং তারা সকেট থেকে বাইরের দিকে যায়। এগুলো ক্রমে করুন, কারণ প্রতিটিই ধরে নেয় আগের স্তর তার কাজ করছে।
কোন প্রবাহ চুপ হয়ে যায়
গুরুত্বপূর্ণ সংযোগটি হলো যা ডেটাবেস ট্রাফিক বহন করে, যা তার নিজের ঠিকানা ও পোর্ট দিয়ে চেনা যায়। আর কিছুই এটিকে সতেজ করে না। গেটওয়েতে পিং, একই হোস্ট থেকে দ্বিতীয় 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 কোনো শিডিউলার নয়।