پہلے طے کریں کہ کون سا ڈیٹا فعال نظام سے نکل سکتا ہے اور بعد میں اسے کیسے حاصل کیا جائے گا۔ اسی سے معلوم ہوگا کہ کیا محفوظ طریقے سے حذف ہو سکتا ہے۔
آرکائیو کرنا قابلِ استعمال تاریخی نقل محفوظ رکھتا ہے۔ پرج کرنا فعال نقل ہٹاتا ہے۔ دونوں الگ فیصلے ہیں: کامیاب ایکسپورٹ اس بات کا ثبوت نہیں کہ حذف کرنا محفوظ ہے۔
فرض کریں آرڈر سسٹم گزشتہ بارہ ماہ کے مکمل آرڈر آن لائن رکھتا ہے۔ یہ صرف مثالی پالیسی ہے۔ پرانا آرڈر جس کا تنازع حل نہیں ہوا، شاید فعال رکھنا پڑے۔
آخری تاریخ، ٹائم زون، استثنا اور تاریخی تلاش کی ضروریات پر اتفاق کریں۔ اگر کاروبار کو پرانی رسید چاہیے تو آرکائیو میں اس کے لیے ضروری شناختیں اور تعلقات برقرار رہنے چاہییں۔
پارٹیشننگ ایک منطقی ٹیبل کو طبعی حصوں میں بانٹتی ہے، مثلاً ہر ماہ کا الگ حصہ۔ ماہانہ پارٹیشن صرف تب ہٹائیں جب ہر ریکارڈ اہل ہو۔ ورنہ مستثنیٰ ریکارڈ محفوظ منتقل کریں یا زیادہ انتخابی حذف استعمال کریں۔
تصور کریں آرڈر کی نقل بنانے کے بعد اصل حذف کرنے سے پہلے رقم درست کی گئی۔ برآمد شدہ نقل میں اب غلط رقم ہے۔
اس خلا کو بند کرنے کا طریقہ چنیں:
طے کریں کہ دیر سے آنے والے ریکارڈ اور بعد کی درستیاں کہاں جائیں گی۔ صرف پرانے timestamps منتخب کرنا دوسرے عمل کو ان قطاروں کی تبدیلی سے نہیں روکتا۔
[Eligible range] -> [Consistent export] -> [Archive + manifest]
|
[Restore and verify]
Manifest برآمد شدہ مواد بتاتا ہے: دائرہ، schema ورژن، تعداد اور فائل checksums۔ یہ آرکائیو کی شناخت اور نامکمل یا خراب فائلوں کی دریافت میں مدد دیتا ہے۔
صرف فائل کی موجودگی نہ دیکھیں:
تصدیق شدہ ماخذ کی آخری حد اور جانچنے والے شخص کو درج کریں۔ آرکائیو تک رسائی محفوظ رکھیں اور اس کی مدتِ حفاظت بھی طے کریں۔ مطلوبہ بحالی کا راستہ ثابت ہونے کے بعد ہی اصل حذف کریں۔
| صورت | طریقہ | کیا جانچیں |
|---|---|---|
| پوری پارٹیشن اہل ہے | منصوبہ بند دیکھ بھال میں الگ یا حذف کریں | آرکائیو کی تصدیق، locks اور منحصر objects۔ |
| اہل قطاریں فعال قطاروں کے ساتھ ملی ہوئی ہیں | چھوٹے، دوبارہ شروع ہونے والے batches میں حذف کریں | مستحکم انتخاب، transaction حجم اور replica تاخیر۔ |
PostgreSQL میں پارٹیشن الگ کرنے سے خودمختار ٹیبل باقی رہتی ہے، جسے حذف سے پہلے آرکائیو اور جانچا جا سکتا ہے۔ اگر تصدیق کے دوران تاریخی تلاش اسی الگ ٹیبل کی طرف بھیجی جائے تو یہ مفید ترتیب ہے۔
پارٹیشن ہٹانا قطار بہ قطار حذف سے بچاتا ہے مگر locks پھر بھی درکار ہیں۔ Concurrent detach کی پابندیاں ہیں، اس لیے نصب ورژن اور dependencies دیکھیں۔ Batch حذف میں transaction logs اور صفائی کا کام بھی مانیٹر کریں۔ PostgreSQL پارٹیشن دیکھ بھال۔
پیش رفت کو برآمد شدہ، تصدیق شدہ، حذف کے لیے تیار اور حذف شدہ مراحل میں مستقل محفوظ کریں۔ Restart کے بعد job کو درست تصدیق شدہ دائرہ معلوم ہونا چاہیے، نہ کہ زیادہ وسیع حد دوبارہ بنائے۔
حذف سے پہلے دوبارہ تصدیق کریں کہ اس دائرے میں ایسی کوئی تبدیلی نہیں آئی جو آرکائیو میں شامل نہ ہو۔ بعد میں تصدیق کریں کہ فعال queries کام کرتی ہیں اور آرکائیو ریکارڈ حاصل کیے جا سکتے ہیں۔
یاد رکھیں: اہلیت طے کریں → تبدیلیاں قابو کریں → بحالی ثابت کریں → حذف چنیں → نتیجہ جانچیں۔ مقصد کم فعال ڈیٹا کے ساتھ قابلِ اعتماد تاریخی رسائی ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں