پچیس منٹ کا مفید ڈیٹا بیس کام تقریباً کوئی آؤٹ پٹ پیدا نہیں کرتا، اور راستے کے ہر آلے سے یہ بہاؤ غیر فعال دکھائی دیتا ہے۔ غیر فعال حالت ہی وہ چیز ہے جو جمع کی جاتی ہے۔ بعد کی رپورٹ ہمیشہ ایک ہی شکل رکھتی ہے: استفسار چل رہا تھا، پھر سیشن غائب ہو گیا، اور نتیجہ کبھی نہ آیا۔

چار جانچیں طے کرتی ہیں کہ خاموش سیشن بچے گا یا نہیں، اور یہ ساکٹ سے باہر کی طرف چلتی ہیں۔ انہیں ترتیب سے کریں، کیونکہ ہر ایک فرض کرتی ہے کہ پچھلی تہہ اپنا کام کر رہی ہے۔

کون سا بہاؤ خاموش ہوتا ہے

اہم رابطہ وہ ہے جو ڈیٹا بیس ٹریفک لے کر جاتا ہے، جو اپنے پتوں اور پورٹوں سے پہچانا جاتا ہے۔ کوئی اور چیز اسے تازہ نہیں کرتی۔ گیٹ وے کو پنگ، اسی ہوسٹ سے دوسرا 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 نے کچھ نہیں بدلا۔

لینکس کی طے شدہ قدروں کے پیچھے ساکٹ سوئچ

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 کوئی شیڈولر نہیں۔

متعلقہ مضامین