تیز VPN بھی ہم وقت SQL تصدیق کو کیوں سست کرتا ہے
تصدیق عمارت سے نکل کر ہم وقت نقول کی طرف جاتی ہے۔ انتظار کی قسم سے بھیجنے اور redo قطاروں تک جائیں، پھر طے کریں کہ کیا غیر ہم وقت صحیح سودا ہے۔
بنیادی سرور پر استفسار کا سیشن کھولیں اور دیکھیں کہ سادہ تحریر کس چیز کا انتظار کر رہی ہے۔ اگر ڈیٹا بیس ہم وقت تصدیق والے دستیابی گروپ کا حصہ ہے اور ثانوی جڑا ہوا ہے تو اس انتظار کا کچھ حصہ عمارت سے نکل جاتا ہے: لاگ ریکارڈ نقول کی طرف جاتے ہیں، وہاں سخت کیے جاتے ہیں، اور اس سختی کی خبر تصدیق مکمل ہونے سے پہلے واپس آتی ہے۔ بینڈوتھ اس آنے جانے کو کم نہیں کرتی۔ نیچے کی تفصیل تصدیق کا پیچھا اسکرین سے دور دراز ڈسک تک اور واپس کرتی ہے۔
بنیادی سرور پر انتظار کی قسم سے شروع کریں
دور دراز نقول پر انتظار کرنے والی تحریر CPU یا تالے کے انتظار کی بجائے لاگ سے متعلق انتظار کے طور پر ظاہر ہوتی ہے، اور لین دین کی مدت قطاروں کی تعداد کے بجائے آنے جانے کی پیروی کرتی ہے۔ بہت سی چھوٹی تصدیقیں اسے واضح کر دیتی ہیں، کیونکہ ہر ایک سفر الگ ادا کرتی ہے۔ ایک بڑا بیچ آپریشن وہی لاگت ایک طویل تصدیق کے اندر چھپا دیتا ہے۔
رابطے کے بارے میں کوئی نتیجہ اخذ کرنے سے پہلے اپنے کام کا بوجھ تصدیق کی تعدد کے مطابق ترتیب دیں۔
نیٹ ورک پڑھنے سے پہلے نقول کی حالت پڑھیں۔ اہم شمار کنندگان بھیجنے کی قطار، redo قطار اور ہم آہنگی کی حالت ہیں، اور مل کر وہ دکھاتے ہیں کہ ثانوی ساتھ چل رہا ہے یا پیچھے رہ رہا ہے۔ بڑھتی بھیجنے کی قطار نقل و حمل کی طرف اشارہ کرتی ہے، جبکہ بڑھتی redo قطار ثانوی کے اپنے کام یا ذخیرے کی طرف۔ یہ مختلف مرمت ہیں، اور بینڈوتھ بڑھانے سے کوئی بھی بہتر نہیں ہوتی۔
تصدیق کا ثانوی تک پیچھا کریں
ہم وقت تصدیق میں بنیادی سرور تصدیق کو مکمل قرار دینے سے پہلے اس بات کی تصدیق کا انتظار کرتا ہے کہ متعلقہ لاگ ثانوی پر سخت کر دیا گیا ہے۔ سخت کا مطلب لاگ میں پائیدار ہے، ڈیٹا صفحات میں دوبارہ چلایا گیا نہیں۔ یہی فرق بتاتا ہے کہ ہم وقت ثانوی redo میں پیچھے کیوں رہ سکتا ہے جبکہ وہ سختی کی تصدیق کرتا رہتا ہے۔
راستہ ترتیب سے طے کریں اور پورے کے بجائے ہر مرحلے کو ناپیں۔ لاگ ریکارڈ نقل و حمل سے گزرتے ہیں، ثانوی انہیں لکھتا اور فلش کرتا ہے، اور تصدیق اسی راستے سے واپس آتی ہے۔ نقل و حمل کی تاخیر، ثانوی کی شیڈولنگ اور ثانوی کی لاگ ڈسک کی تاخیر سب مجموعے میں آتی ہیں، اور صرف پہلی نیٹ ورک کے مالک کی ہے۔ جس ثانوی کا لاگ حجم کسی اور چیز سے بھرا ہو وہ رابطے کے خالی ہونے پر بھی ہر تصدیق کو لمبا کر سکتا ہے۔
SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;اس تصویر کو خاموش دوپہر میں ایک بار کے بجائے نمائندہ تحریر سے پہلے اور بعد میں لیں۔ فرق ہی بتاتا ہے کہ تصدیق کے انتظار میں کون سی قطار ہلی۔
رابطہ نہیں، راستہ ناپیں
تھرو پٹ ٹیسٹ دو ایسے مقامات کے درمیان صلاحیت ناپتا ہے جو آپ کی نقول نہیں ہیں، ایسے بوجھ کے تحت جو آپ کا کام نہیں ہے۔ نیٹ ورک کے مالک سے حقیقی نقول کے راستے پر تاخیر اور نقصان طلب کریں جبکہ حقیقی ٹریفک چل رہی ہو، دونوں سمتوں میں۔ یہاں نقصان صلاحیت سے زیادہ اہم ہے، کیونکہ کھویا ہوا حصہ دوبارہ ترسیل کا متقاضی ہے اور ہر تصدیق ایک توثیق کا انتظار کرتی ہے۔ ڈاؤن لوڈ ٹیسٹ میں بہترین دکھنے والا رابطہ بھی باتونی تصدیق کے نمونے کے لیے نامناسب ہو سکتا ہے۔
ناپتے وقت ڈیٹا بیس کی نقل و حمل کی سلامتی اور رسائی کنٹرولز کو برقرار رکھیں۔ راستہ ناپنا کبھی انہیں نظر انداز کرنے کی وجہ نہیں ہے۔
اوقات کو وجدان کے بجائے شمار کنندگان سے منسلک کریں۔ اگر بھیجنے کی قطار خالی رہے اور تصدیق اب بھی انتظار کرے تو تاخیر تصدیق میں یا ثانوی کے فلش میں ہے۔ اگر بھیجنے کی قطار مسلسل بڑھے تو حد نقل و حمل یا صلاحیت ہے۔ لکھیں کہ کس مشاہدے نے نتیجے کی تائید کی، تاکہ اگلا شخص بحث کے بجائے پیمائش دہرا سکے۔
غیر ہم وقت موڈ اصل میں کیا بدلتا ہے
غیر ہم وقت تصدیق ثانوی کی سختی کی توثیق کے انتظار کو ہٹا دیتی ہے، اسی لیے تحریر تیز ہوتی ہے اور اسی لیے آپ کی پائیداری کی حیثیت بدلتی ہے۔ بنیادی سرور اس دور دراز توثیق کے بغیر لین دین کی تصدیق کرتا ہے۔ پھر ثانوی کو پیچھے رہنے دیا جاتا ہے، اور یہی پیچھے رہنا خطرہ ہے۔
اگر بنیادی سرور اس سے پہلے کہ لاگ کوئی قابل استعمال فیل اوور ہدف پا لے، ضائع ہو جائے تو اس نقل پر سروس کو مجبوراً منتقل کرنا ایسے لین دین پھینک دیتا ہے جن کے بارے میں ایپلیکیشن کو پہلے ہی بتایا جا چکا تھا کہ تصدیق ہو چکی ہے۔
یہ بازیابی کے نقطے کا فیصلہ ہے اور یہ ڈیٹا بیس کے مالک کا ہے، کارکردگی کے جائزے کا نہیں۔ پہلے برداشت کیے جانے والے ڈیٹا نقصان کی کھڑکی مقرر کریں، اسے پورا کرنے والا موڈ چنیں، پھر اسی حد کے اندر بہتری لائیں۔ ہم وقت تحفظ برقرار رکھنے والے اختیارات میں ایپلیکیشن کی اجازت کے مطابق ناقابل گریز تصدیقی سفر ہٹانا، ناپے گئے نقل و حمل یا ذخیرے کی رکاوٹ درست کرنا، اور نقول کو ہلانا شامل ہے تاکہ توثیق کم فاصلہ طے کرے۔ انہیں اس پائیداری کی ضرورت کے ساتھ تولیں جس سے آپ نے آغاز کیا اور جو تبدیل نہیں ہوئی۔